INTERNET DRAFT Expiration Date: May 2003 Vijayanand C HCL Technologies Fast Reroute Extensions to Constraint based Routed Label Distribution Protocol draft-vijay-mpls-crldp-fastreroute-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document proposes extensions to existing CR-LDP for setting up MPLS backup tunnels. These tunnels can protect Label Switched Paths on an exclusive bandwidth basis or shared bandwidth on the back up paths, as desired by the initiator of the tunnel at the head end node. Several backup segments are maintained for a single LSP and they are meant to provide link and node failure protection along various segments of the LSP. Sharing of backup segments across multiple LSPs is also facilitated to achieve scalability 1. Introduction MPLS serves as a high speed switching mechanism which leverages existing layer 2 protocols with popular layer 3 routing protocols and serves to establish a common control and management plane. High availability, fault tolerance and failure recovery are expected out of MPLS solutions. Constraint Routed Label Distribution Protocol (CR-LDP[CR-LDP]) is an extension to Label Distribution Protocol Vijayanand C [Page 1] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 (LDP[LDP]) for establishing traffic engineered Label Switched Paths(LSPs) across the network to meet the needs of real-time applications and QoS conscious applications. The need for quick responses to failures and recovery from such failures is all the more important in such a scenario. Besides the scheme described in this memo, alternative solution and approaches have been proposed for providing protection and recovery for MPLS TE tunnels in [MPLS- FRR], [RSVPTE-FRR] and [CRLDP-PP]. This document describes the use of CR-LDP to establish backup LSP segments to take over traffic while local repair is in progress for LSP tunnels. These backup segments exist across sections of the LSP, protecting it selectively against node and link failures. These backup segments may be shared across multiple LSPs traversing the protected set of links and nodes, thus providing a scalable solution. Exclusive bandwidth protection, Shared bandwidth protection and protection without bandwidth guarantee are the options proposed in this document. By the term LSP we mean an explicitly routed LSP with or without bandwidth constraints. In order to meet the needs of real-time applications such as voice and video, in case of failure, it is required to re-direct such traffic onto alternate paths in a few milliseconds. Since the local repair mechanism cannot compute and establish an alternate path in such a short time back up tunnels are used to take over the traffic in the intervening time. Traffic will not be lost or delayed much due to the latency in the local repair mechanism. Once the backup segments are in place then on failure of a node or link the traffic is switched to the back up tunnel from the point of local repair. The backup segments are intended to cover both node and link failures till the local repair mechanism computes an alternate path for the primary LSP. Since the back up segments operate for a short time they can be chosen to provide shared bandwidth protection or no bandwidth guarantee at all depending on the application requirement and the anticipated time for local repair. 2. Terminology 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 [RFC-WORDS]. The reader is assumed to be familiar with the terminology in [CRLDP] LSR - Label Switch Router LSP - An MPLS Label Switched Path Vijayanand C December 2002 [page 2 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 Local Repair - Techniques used to repair LSP tunnels quickly when a node or link along the LSPs path fails. Protected/Primary LSP - An LSP is said to be protected at a given hop if it has one or multiple associated backup segments originating at that hop. Backup Segment - An LSP segment that is used to backup up one or more primary LSPs traversing a set of nodes and links PLR - Point of Local Repair. The head-end of a backup segment MP - Merge Point. The LSR where one or more backup segments rejoin the path of the protected LSP, downstream of the potential failure. One to Many backup segment - A backup segment which protects multiple LSPs by bandwidth sharing along its links though the labels for them along the links would be different. The bandwidth of this segment is the highest of bandwidths shared by all individual LSPs. 3. CR-LDP Extensions We propose two additional TLVs, TUNNEL_PROTECT TLV and BACKUP TLV to CR-LDP. The TUNNEL PROTECT TLV has the U and F bit set to 1 .The BACKUP TLV has the U and F bits set to zero. TUNNEL_PROTECT TLV will be used in the Label Request message while the BACKUP TLV will be used in the Label Request message and Label Release message. 3.1 TUNNEL_PROTECT TLV The tunnel protect TLV is used by the Ingress LSR to indicate that the tunnel needs to be backed up while local repair is in progress. The format of the tunnel protect TLV is given below Vijayanand C December 2002 [page 3 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |11| Type( TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC limit | Flags | PLR Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLR ID 1 ( Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Avoid Node ID 1 ( Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // .... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLR ID n ( Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Avoid Node ID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HC Limit: The hop count limit indicates the maximum number of hops a backup segment can have. Flags : 0x00 - Bandwidth protection not needed 0x01 - Shared Bandwidth protection needed 0x02 - Exclusive Bandwidth protection needed Bandwidth protection not needed indicates that backup segments need not have any bandwidth reservation in the back up segment. This and shared bandwidth can be chosen when little or no bandwidth guarantees are needed for the short time when local repair is going on. Shared Bandwidth protection needed indicates that tunnels that desire such protection can share bandwidth along the links of the backup segment. Exclusive Bandwidth protection needed indicates that each tunnel should be given exclusive bandwidth in the back up segment. PLR Flag : 0x00 - No PLRs and avoid nodes are specified 0x01 - List of PLRs and avoid nodes are specified Vijayanand C December 2002 [page 4 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 The PLR Flag denotes whether or not an explicit list of PLR node IDs and corresponding Avoid Node IDs are specified in this TLV. The PLR IDs and Avoid Node IDs are processed only if the PLR Flag is set to one. Setting the PLR flag to one gives the flexibility for the head end LSR to specify the list of nodes, which will act as points of local repair along with the nodes that they should avoid in the backup segments they originate. If the PLR Flag is set to zero, then all the nodes along the path which recognize the TUNNEL PROTECT TLV and implement this extension should initiate backup segments. PLR ID (1 - n): IPv4 address identifying the beginning point of a backup segment which is a PLR. Any local address on the PLR can be used. Avoid Node ID (1 - n) IP address identifying the immediate downstream node that the PLR should avoid. Router ID of downstream node is preferred. The PLR Node ID and Avoid Node ID are optional. If the PLR Flag is not set then all the nodes in the path of the label request which recognize the Tunnel protect TLV can act as PLR nodes. The format of the request message with the TUNNEL PROTECT TLV is given below 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPID TLV (CR-LDP,mandatory) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-TLV (CR-LDP,optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TUNNEL PROTECT TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pinning TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Class TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vijayanand C December 2002 [page 5 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 | Pre-emption TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2 BACKUP TLV The back up TLV is used along the backed up section of the tunnel while signaling the same. The format of the TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |00| Type( TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLR Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Merge Node ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PLR Node ID indicates the point of local repair. This is the node which serves as the starting point of the backup segment The Merge Node ID indicates the node where the backup segment merges with the primary LSP The flags field has the same meaning as in TUNNEL PROTECT TLV This TLV is originated by the PLR itself The format of the label request message with the BACKUP TLV is given below 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPID TLV (CR-LDP,mandatory) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-TLV (CR-LDP,optional) | Vijayanand C December 2002 [page 6 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BACKUP TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pinning TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Class TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pre-emption TLV (CR-LDP, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. Signaling for Back up Tunnels and Operational Overview While setting up the LSP tunnel, at the head-end LSR, the TUNNEL PROTECT TLV is sent in the label request message for tunnels which need to be protected/backed up. If the TUNNEL PROTECT TLV has the PLR Flag set then it carries the Identifiers of nodes, which can act as Points of Local repair and quickly switch traffic onto backup segments, in PLR Node ID. For each such PLR Node ID a corresponding Avoid Node ID is also specified. The nodes whose node IDs appear as PLR Nodes IDs in the TUNNEL PROTECT TLV should initiate backup segments. The initiation of the backup segments is in addition to the usual CR LDP request message processing at the nodes to establish the primary LSP. Each of the backup segments must bypass/avoid the node whose ID is mentioned as the avoid node ID for the respective PLRs. After the PLR node processes the TUNNEL PROTECT TLV it should propagate the label request further after removing the PLR Node ID and Avoid Node ID pertaining to itself. If the PLR flag is not set in the TUNNEL PROTECT TLV, each node along the path, which recognizes this TLV and is capable of rapidly switching over traffic to backup segments in case of failure, initiates the setting up of backup segments. This is in addition to the usual CR-LDP label request message processing in these nodes. An alternate path is computed by the node subject to the Hop count limit in the TUNNEL PROTECT TLV and the path should bypass atleast one downstream node to rejoin the primary/protected LSP. In both the cases described above, a BACKUP TLV is constructed with the computed merge node. The merge node (also called Merge Point(MP) ) of the BACKUP TLV is the end of the back up segment computed and the node where the backup segment rejoins the primary LSP. A label request with the BACKUP TLV is sent along the back up Vijayanand C December 2002 [page 7 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 path. The ER TLV that is sent in this Label request message must contain hops upto the Merge Point(MP) only. The MP, when it processes the label request along the back up path, recognizes that it is the end of a back up segment and merges it with the primary/protected LSP whose LSPID is present in the LSPID TLV of the request message. The BACKUP TLV is used by the MP to recognize it as a request for setting up the backup segment. This request must not be propagated any further. Label mapping must be sent towards the PLR when label mapping is received for the primary/protected LSP. Thus the MP will send two label mappings one along the primary LSP and another along the backup segment. Both these mappings will travel towards the PLR along different paths( along primary LSP request path and backup segment request path) and the PLR node can distinguish the two mappings as belonging to the primary LSP and backup segment since the requests were sent by itself. In case any of the nodes along the backup segment including the MP do not recognize the BACKUP_TLV, an unknown TLV notification must be sent towards the PLR and the backup segment establishment would fail. Consider the scenario where the PLR flag is not set in the TUNNEL PROTECT TLV. In this case, potentially, each node along the path would have a backup segment starting from it and ending at a node which is atleast more than one hop away( ie, 2 or more hops) along the PLR, to ensure link and node protection. [R1]---[R2]----[R3]----[R4]---[R5] \\ // [R6]===[R7] In the above example, R2 in this case would build a backup segment [R2->R6->R7->R4]. The doubled lines represent this segment. The backup tunnel for [R1->R2->R3->R4->R5] again rejoins the original path at R4. R2 is the PLR and R4 the MP. Similarly there would be a backup segment across R3 to R5 if R3 was a candidate PLR. The above scenario would also arise when the TUNNEL PROTECT TLV has [PLR, Avoid Node IDs] sequence as [R2,R3] and [R3,R4]. Multiple back-up segments of the same LSP could merge into a single backup segment if paths computed by nodes on the same primary LSP for the same primary LSP have nodes in common. The common nodes, start from a node on the backup segment called the point of backup Vijayanand C December 2002 [page 8 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 merger, upto the MP with the primary LSP. The nodes at the point of backup merger recognize this and propagate only a single label request from the point of backup merger of the backup segments. For this, the path from the point of backup merger to the merge point with the primary LSP should be exactly same in the ER HOP TLVs of the merged label requests sent along the back up segments, otherwise merging should not be done. In this case when the mapping message arrives at the point of backup merger in the backup segment it sends out two label mappings towards each of the PLR nodes upstream. [R1]---[R2]----[R3]----[R4]---[R5]---[R6] \\ \\ // [R7]=== [R8]=== [R9] In the above example, the backup segments from R2 and R3 have R5 as the MP as per the computation done by them. The two backup segments merge at R8.Hence R8 is the point of backup merger, while R5 is the MP with the primary LSP. Another scenario for merger occurs in the back up path when two different tunnels requesting shared bandwidth protection have nodes in common from point of backup merger in back up path to merge point with primary LSP. The flags field in the BACKUP TLV, will be used to determine whether sharing can be done from point of backup merger in the backup segment. If the flags field in the BACKUP TLV indicates shared bandwidth protection, then this backup segment can be merged with an existing backup segment which is also signaled for shared bandwidth protection. Even though the bandwidth is shared across the backup segments, different label request messages have to be propagated to maintain the identity of the individual LSPs. The shared nodes of the backup segments would recognize that the backup segment can share bandwidth with existing backup segments by examining the flags in the BACKUP TLV. In these nodes, the bandwidth reserved for the set of LSPs sharing bandwidth would be the maximum of all bandwidths of such LSPs. This choice of sharing bandwidth in backup segments across LSPs is useful because the backup tunnels operate for a very short time when local repair of primary LSP is in progress. This results in a one to many backup segment since the bandwidth in the backup segment is shared by multiple primary LSPs. When there is a node or link failure the traffic is immediately switched to the backup segment at the PLR even while the local repair mechanism is initiated in the PLR. Thus the traffic is not lost/delayed because of the computation and set up latency of the local repair mechanism. When the local repair mechanism completes, the primary LSP is complete once again. Let this be called as the new primary LSP. Traffic is switched back to the new primary LSP from the backup Vijayanand C December 2002 [page 9 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 segment. The repaired segment of the new primary LSP would traverse a different set of links and nodes compared to the failed segment. Hence the new primary LSP segment needs to be protected. For this, the existing backup segment is first released. The release is initiated by the PLR. The release message contains the BACKUP TLV to indicate that it is for the back up segment. The MP uses the BACKUP TLV to identify that the release is for the back up segment. After the backup segment of the old primary LSP is released a new backup segment is initiated by the PLR for the new primary LSP and established as described earlier. The backup segments have to be torn down when the primary LSP is released from the head end or tail end. When a primary LSP is released from its head end via a release message, each of the PLR nodes which have initiated back up segments have to release the back up segments in addition to the primary segments by means of release message along the backup segments. These release messages must contain BACKUP TLV in addition to the TLVs present in the Label release message. If a PLR node receives a withdraw message due to a failure in the downstream path, the withdraw message should not be propagated upstream. The PLR shall initiate set up of a new LSP segment and when this completes the old failed segment is released. Similarly if an MP node detects a failure upstream then it should not propagate or generate any release messages to its downstream nodes. The release message for the primary LSP should be propagated to the downstream nodes by the MP, only after the release message is received from the backup segment also. This ensures that the LSP is released from the head end by the administrator and the release received via the primary LSP segment is not due to a failure in the primary segment. The backup segment must also be torn down when there is a failure along the backup segment itself. In case a failure occurs along the backup segment, the existing backup segment is torn down by withdraw and release messages from the point of failure. The PLR then reinitiates a new backup segment. Label mapping and withdraw messages sent on the back up segment from the MP to the PLR should not be propagated towards the head end by the PLR 5. Back up Path Computation Vijayanand C December 2002 [page 10 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 Back up path computation is done by the PLR taking the following aspects into consideration (apart from the usual CRLDP constraints parameters): - The hops in the ER HOP TLV of the request message in the primary LSP. The backup segment should rejoin the primary LSP as close to the PLR Node as possible after bypassing atleast one downstream node. - The hop count limit for the back up segment. The hop count of the segment computed should be within the specified hop count limit - The Avoid Node IDs, if specified in the TUNNEL PROTECT TLV - Whether shared or exclusive bandwidth protection is needed. If shared bandwidth reservation is only needed then bandwidth used by existing shared bandwidth LSPs can be re-used. This involves knowledge of existing LSPs which are open to sharing bandwidth in their back up paths. - The backup segment should provide link and node protection for atleast one node and one link if the PLR and Avoid Node IDs are not specified in the TUNNEL PROTECT TLV. The algorithm used for this computation is outside the scope of this document. 6. Interoperability Considerations The PLR nodes, the merge point nodes and all nodes along the back up segments must recognize this extension to CRLDP in order to provide this feature. Nodes in the primary LSP which donot support this feature will ignore the additional TLVs and silently forward them since the U and F bits are set in the TUNNEL PROTECT TLV. This will result in they not being part of any back up paths established as per this document. If any of the nodes along the backup segment including the MP do not recognize the BACKUP_TLV an unknown TLV notification must be sent towards the PLR and the backup segment establishment through that node would fail. 7. Open Issues Rapid Notification of failure to the PLR node is outside the scope of this document and may affect the effectiveness of this solution Vijayanand C December 2002 [page 11 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 8. Related Work Other alternative solutions have been provided in [MPLS- FRR],[RSVPTE-FRR} and [CRLDP-PP]. [MPLS-FRR] describes a shared fast reroute mechanism for RSVP-TE, wherein each node along the protected path has a back up segment for Fast reroute starting from it and terminating at the egress. These segments bypass the entire primary LSP from the node to the egress downstream. RSVPTE-FRR describes a mechanism specific to RSVP-TE for providing one to one and shared backup for LSP segments. CRLDP-PP is a proposal for path protection of an LSP segment within a protection domain wherein the entire LSP segment inside the protection domain in protected by a backup segment. This memo describes a mechanism which is different from the above by providing protection to a localized area resulting in formation of localized protection segments using CR-LDP for CR-LDP tunnels. This works smoothly with the local repair mechanism and the periodic traffic engineering path re-computation mechanisms. 9. Acknowledgements The author expresses his deep sense of gratitude and heartfelt thanks to Manikantan Srinivasan for his extremely valuable feedbacks on this effort. The author also recalls Shankaranarayanan Ramamurthy who inspired MPLS ideas and the discussions had with him on issues in contemporary networks. The author thanks Kannan for his valuable suggestions and comments. 10. Authors Address Vijayanand C HCL Technologies Limited Technologies Division 184-188,NSK Salai, Vadapalani, Chennai - 600 026, India Phone : +91-44-3728366 Ext: 1318 Email : vijayc@ctd.hcltech.com 11. References [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, " LDP Specification ",RFC3036, January 2001 Vijayanand C December 2002 [page 12 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP May 2003 [CRLDP] B. Jamoussi, L. Andersson, R. Callon, R. Dantu, L. Wu, P. Doolan,N. Feldman,A. Fredette,M. Girish, E. Gray,J. Heinanen, T. Kilty, A. Malis, "Constraint-Based LSP Setup using LDP",RFC 3212, January 2002. [MPLS-FRR] Atsushi Iwata, Norihito Fujita, Tetsurou Nishida "MPLS Signaling Extensions for Shared Fast Rerouting", work in progress, , July 2001. [CRLDP-PP] Ken Owens,Vishal Sharma,Srinivas Makam,Ben Mack- Crane,Changcheng Huang,Bora Akyol "Extensions to CRLDP for MPLS Path Protection",work in progress , July 2001 [RSVPTE-FRR] Ping Pan, Der-Hwa Gan, George Swallow, Jean Philippe Vasseur, Dave Cooper, Alia Atlas, Markus Jork " Fast Reroute Extensions to RSVP-TE for LSP Tunnels",work in prgress, draft-ietf- mpls-rsvp-lsp-fastreroute-00.txt,July 2002 [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft-katz-yeung-ospf-traffic-05.txt, June 2001. [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- ietf-isis-traffic-03.txt, June 2001. [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. Vijayanand C December 2002 [page 13 ]