CCAMP Working Group Qing Huang (Editor) Internet Draft G.S. Kuo (Editor) Expiration Date: January 2005 July 2004 Generalized MPLS Recovery Resource Sharing draft-huang-gmpls-recovery-resource-sharing-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract Many protection and restoration (P&R) techniques are proposed to protect LSP in Generalized Multi-Protocol Label Switching (GMPLS) networks. Provisioning better P&R capability requires that much recovery resources be allocated on protection LSP, which may lead to resource waste in GMPLS networks. This draft presents a scheme of recovery resource sharing with traffic balancing for GMPLS LSP based P&R. Its focus is on the discussions of working and protection LSPs selection and the shared resource allocation and release. Internet Draft - Expires January 2005 [page 1] draft-gmpls-recovery-resource-sharing-00.txt July 2004 Table of Contents 1. Introduction...................................................2 2. Notions........................................................3 3. Recovery Resource Sharing With Traffic Balancing...............4 4. Signaling Procedure............................................5 5. PROTECTION Object..............................................6 6. Resource Allocation and Release................................7 6.1 Resource Allocation............................................8 6.2 Resource Release...............................................8 6.3 Illustration of Resource Allocation and Release................9 7. Performance Evaluation........................................10 8. LSP Segment P&R...............................................10 9. Conclusions...................................................11 10. IANA Considerations...........................................11 11. Intellectual Property Considerations..........................11 12. References....................................................11 12.1 Normative References ........................................11 12.2 Informative References ......................................12 13. Authors' Addresses............................................12 Full Copyright Statement..........................................13 Conventions used in this document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In addition, the reader is assumed to be familiar with the terminology used in [GMPLS-ARCH], [RFC-3471], [RFC-3473] and referenced as well as [TERM] and [FUNCT]. 1. Introduction As the real-time and multimedia-oriented services are rapidly increasing on Internet, a small link or node failure is unacceptable to customers. Service continuity is becoming much more important than before. P&R (see [TERM]) is the key technique to improve service continuity by establishing protection path for working path. Obviously, recovery resources reserved on protection path are idle at most time, which is unreasonable from the viewpoint of resource utilization. An efficient way to improve recovery resource utilization is to have protection LSPs, whose working LSPs are physically disjoint, share bandwidth resources. This mechanism was coined as shared mesh restoration and described in [GMPLS-ANAL]. Clearly, not all GMPLS recovery mechanisms can provide shared mesh restoration. For example, in the 1+1 protection mechanism, the traffic is transmitted simultaneously on both the working and protection LSPs. The selector at the egress will decide which path to use according to the quality of signal. Obviously, no recovery resource can be shared in 1+1 protection, while other recovery mechanisms such as M:N recovery aim to provision shared mesh restoration. Internet Draft - Expires January 2005 [page 2] draft-gmpls-recovery-resource-sharing-00.txt July 2004 To share the recovery resources can save bandwidth in networks, thus, rejected session setup requests can be decreased in a certain degree. Moreover, maximum recovery resource sharing with traffic balancing can further decrease rejected session setup requests in GMPLS networks. We will discuss the scheme to optimize recovery resource sharing with traffic balancing and the signaling implement- ation of the scheme. Section 2 introduces the notions used in the draft. Section 3 describes the scheme to optimize recovery resource sharing with traffic balancing. Section 4 provides the signaling implementation of the scheme. Section 5 discusses resource allocation and release. Section 6 evaluates the performance of the proposed scheme. Section 7 presents the application of the scheme in LSP segment P&R. And, Section 8 concludes this draft. 2. Notions We model arbitary GMPLS network as G=(V, E), where V is the set of nodes and E is the set of all links in networks. A LSP is defined as LSP={s, r1, ..., rn, d}, where s and d denote source and destination nodes respectively, and rk denotes the k-th intermediate LSR along the LSP. In addition, to identify a LSP in GMPLS networks, either a global identifier (ID) or a triple must be used. To simplify the presentation, the global identifier (ID) is used in this draft. Furthermore, the following notations are defined: l(i, j): The link from nodes i to j. Cij: The cost of l(i, j). Bij: Total amount of bandwidth reserved for protection LSPs on l(i, j). Rij: Total amount of residual bandwidth on l(i, j). PLij: Set of protection LSPs that traverse l(i, j). PLij={PLij[1], PLij[2], ..., PLij[N]}, where PLij[k] is the ID of the k-th protection LSP and N is the total number of protection LSPs on l(i, j). WLij: Set of LSPs which are protected by l(i, j). WLij={WLij[1], WLij[2], ..., WLij[N]}, where WLij[k] is the ID of the LSP protected by PLij[k]. fij[k]: The bandwidth demand of PLij[k](WLij[k]). t[k][m]: The bandwidth that PLij[k] shares with PLij[m]. So, the actual recovery bandwidth allocated to PLij[k] is fij[k] - sum {m=1}^N [tij[k][m]]. Sij[k]: Set of all links and intermediate nodes along WLij[k]. Internet Draft - Expires January 2005 [page 3] draft-gmpls-recovery-resource-sharing-00.txt July 2004 Inf(Wlsp): Set of all links and intermediate nodes along Wlsp, where Wlsp denotes the selected working LSP. WT[i,j]: Weight of l(i, j) used in computing route. In this draft, we assume node i is the dominating node of l(i, j), that is, the information about PLij, WLij, fij[k], Sij[k] and tij[k][m] are held in node i locally. Thus, PLij, WLij, fij[k], Sij[k] and tij[k][m] can be refreshed on node i when any protection LSP traversing l(i, j) is set up. 3. Recovery Resource Sharing With Traffic Balancing In the proposed scheme, only information of Bij and Rij is required for computing a route, that is, only Bij and Rij are flooded in networks. The flooding of Bij and Rij can be easily implemented by route protocol extensions OSPF [GMPLS-OSPF] / IS-IS [OSPF-ISIS] in GMPLS. The current solutions for recovery resource sharing are the two approaches mentioned in [GMPLS-ANAL]: Full Information and Partial Information approaches. We coin the scheme in this draft as Proper Information approach. Let b be the bandwidth demand of a LSP setup request. When computing the route of working LSP, the Proper Information approach computes the weight of l(i, j) as follows, _ _ Cij / Rij (Rij >= b) | WT[i,j]=| |_ _ infinity (otherwise) After the working LSP is selected, when protection LSP is being selected, WT[i,j] should be computed as follows, ---- Cij (Bij >= b) | WT[i,j]=|---- Cij+Cij*(1-Bij/b) (Bij=b-Bij) | ---- infinity (otherwise) The weight computation of l(i, j) above has two advantages: a) It can provision more probability of recovery resource sharing in GMPLS networks. b) It can balance the traffic in GMPLS networks. When computing working LSP, it is obvious that the WT(i, j) will be less if l(i, j) has more residual bandwidth. When protection LSP is selected, WT(i, j) will be less if l(i, j) has reserved more bandwidth. Thus, links with more reserved bandwidth will be more possible to be selected as the segments of protection LSP. Suppose Plsp is selected as protection LSP. Let Bw(i,j) represent the recovery resources that should be allocated for Plsp on l(i, j). The computation of Bw(i, j) is conducted on node i as follows. Internet Draft - Expires January 2005 [page 4] draft-gmpls-recovery-resource-sharing-00.txt July 2004 w = Bij - sum{k} [fij[k]]; where k must satify: (Inf(Wlsp) AND Sij[k]) is not an empty set; ---- 0 (b <= w) | Bw(i,j)=|---- b - w (Rij >= b-w, b>w) | ---- infinity (otherwise) Note that Bw(i,j) may be set to infinity as above, which means recovery resource reserving action may fail on l(i, j). The reason of this is the bandwidth estimation in computing protection LSP is inaccurate. Two conditions in computing WT[i,j] for protection LSP may cause the failure of Plsp setup: a)Even if Bij>=b is satisfied, only x bandwidth units can be shared due to the restriction that the protected LSPs must be physically disjoint, where x=(b-Bij) are satisfied, b-Bij bandwidth units need to be allocated at least as recovery resources. But, only x bandwidth units can be shared due to the restriction that the protected LSPs must be physically disjoint, where x