INTERNET DRAFT Expiration Date: October 2002 Vijayanand C HCL Technologies Fast Reroute Extensions to CRLDP draft-vijay-mpls-crldp-fastreroute-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. 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 describes the use of CR-LDP [CRLDP] to establish backup LSP tunnels for local repair of LSP tunnels established by CR-LDP. This document proposes extensions to existing CR-LDP for setting up backup tunnels for protecting LSPs on an exclusive bandwidth basis or shared bandwidth basis 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 Vijayanand C [Page 1] INTERNET DRAFT Fast Reroute Extensions to CR-LDP April 2002 of MPLS solutions. CR-LDP is an extension to LDP[LDP] for establishing traffic engineered 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. Several solutions and approaches have been proposed for providing protection and recovery for MPLS CR-LDP tunnels in [MPLS-FRR], [CRLDP-PP]. This document describes the use of CR-LDP [CRLDP] to establish backup LSP segments to take over traffic while local repair is in progress for LSP tunnels. These backup segments exists across sections of the LSP protecting it selectively against node and link failures. These backup segments have the provision to 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 October 2002 [page 2 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP April 2002 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 object 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 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HC Limit : The hop count limit indicates the maximum number of hops a backup segment can have. Flags : Vijayanand C October 2002 [page 3 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP April 2002 0x00 - Bandwidth protection not needed 0x01 - Shared Bandwidth protection needed 0x02 - Exclusive Bandwidth protection needed If shared bandwidth protection is desired then tunnels that desire such protection can share bandwidth along the links of the backup segment, else each tunnel should be given exclusive bandwidth in the back up segment. 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 no bandwidth guarantees are needed for the short time when local repair is going on. 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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: Vijayanand C October 2002 [page 4 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP April 2002 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vijayanand C October 2002 [page 5 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP April 2002 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. 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, in addition to the usual CR- LDP request message processing. An alternate path is computed by the node and a label request with the BACKUP TLV is sent along the back up path. The BACKUP TLV is constructed at the PLR after the backup segment is computed. The ER TLV that is sent along the back up segment contains hops upto the Merge Point(MP) only, where the protected LSP and backup segments merge. The list of ER HOPs in the primary LSP is used along with the topology information to compute the merge point. The MP, when it processes the label request, 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. The BACKUP TLV is used by the MP to recognize it as a request for setting up the backup segment. This request is not propagated any further. Label mapping is 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. 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. Hence 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 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. Vijayanand C October 2002 [page 6 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP April 2002 Similarly there would be backup segments across R1 to R3 and R3 to R5. That is, every node along the path that recognizes the TUNNEL PROTECT TLV initiates a backup segment. 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 links in common. The common nodes start from a node on the backup segment called the point of backup merger upto the MP with the primary LSP. The nodes 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 TLV, 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 links 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. In this case, since shared bandwidth protection is desired, the higher of the bandwidths is used. However different label request messages have to be propagated to maintain the identity of the individual LSPs. This results in a scenario where LSPs share bandwidth. This choice 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 because 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. Vijayanand C October 2002 [page 7 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP April 2002 Traffic is switched back to the new primary LSP from the backup 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 is released a new backup segment is initiated by the PLR and established as described earlier. 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 contain BACKUP TLV in addition to the usual list of TLVs. If the LSP is torn from a node downstream of MP, by means of withdraw messages, each of the MPs long the path back to the head- end propagate withdraw to both the primary and back up segments. There is however, no need for the BACKUP TLV in the withdraw message as the PLR can identify the back up segment. 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 Back up path computation is done by the PLR taking the following aspects into consideration (apart from the usual CRLDP constraints parameters): - 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 hop count limit for the back up segment. The hop count of the segment computed should be within the specified path count limit - The backup segment should provide link and node protection for atleast one node and one link. Vijayanand C October 2002 [page 8 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP April 2002 - The list of ER HOPS in the label request for the primary LSP needs to be taken into account so that the backup segment does not deviate too much from the requested ER HOPs. 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 tunnel 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. 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 8. 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. The author also recalls the valuable and motivating technical discussions had with Anton Basil, Mani Manoharan, Arumugam R, ArunKumar, and Srinivasa Gopinath. 9. Authors Address Vijayanand C HCL Technologies Limited Technologies Division PM Tower, 6th Floor, 37,Greams Road, Chennai - 600 008, India Phone : +91-44-8291735/36/37 Ext: 629 Email : vijayc@ctd.hcltech.com 10. References Vijayanand C October 2002 [page 9 ] INTERNET DRAFT Fast Reroute Extensions to CR-LDP April 2002 [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, " LDP Specification ",RFC3036, January 2001 [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 [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 October 2002 [page 10 ]