Internet Draft Internet Draft Fiffi Hellstrand Multi-Protocol Label Switching Loa Andersson Expiration Date: May 2001 Nortel Networks November 2000 Extensions to CR-LDP and RSVP-TE for setup of pre-established recovery tunnels <draft-hellstrand-mpls-recovery-merge-01.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 To protect an Explicit Routed Label Switched Path (ER-LSP) an explicitly routed LSP can be used as a recovery path. We consider a repair scheme where a Recovery LSP (R-LSP) spans one or several hops. After a switchover of traffic to the R-LSP we want to allow the traffic to merge onto the original LSP at the merging node downstream of the fault without causing any extra resource reservation. This merge operation differs in a number of details from that employed for a normal MP2P LSP. Also, if any resource allocation is associated with the recovery paths carefulness should be taken to avoid multiple resource reservation on the same path for the protection of one LSP. Our objective is to define extensions to both CR-LDP and RSVP-TE that address these differences. CR-LDP and RSVP-TE are defined in [CR-LDP] and [RSVP-TE], respectively, for path setup within a MPLS domain. In this draft we specify mechanisms required to support this merge. Hellstrand, et al. [Page 1] Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000 Table of Contents 1.0 Introduction 2.0 Protection of LSP 2.1 Protection Merge 2.2 Explicit Merge 3.0 Proposal 3.1 Extensions to CR-LDP 3.1.1 Error Notifications 3.2 Extensions to RSVP-TE 3.3 Recovery Path Resource Reservations 4.0 Security Considerations 5.0 Intellectual Property Considerations 6.0 Acknowledgements 7.0 Author's Addresses 8.0 References 1.0 Introduction Protection of traffic is growing in importance and especially recovery schemes that can provide fast restoration at layer 3. MPLS- based recovery has been pointed out as strong candidate in this area, see [FRMWK]. To provide protection, recovery paths are established so that potential failure points are circumvented. The recovery path may have a common point with the original path at some arbitrary point downstream of the failure. If a failure is detected, a switchover to the recovery path(s) is performed. Our objective is to let the traffic flowing on the recovery path physically merge onto the original working path at a common node downstream. This applies to both local and global repair. To protect Explicit Routed LSPs (ER-LSPs), we consider the setup of pre-established recovery LSPs to allow for a merge at the Path Merge LSR (PML, [FRMWK]). How to find a disjoint path between the Path Switch LSR (PSL, [FRMWK]) and the PML or how the switchover is performed is not discussed in this ID. 2.0 Protection of ER-LSP To protect from a link or node failure an ER-LSP recovery tunnel may be setup between the switching and the merging node on a path disjoint from the potential failure point. For each ER-LSP to protect , an recovery LSP is setup through the tunnel. The Recovery LSP originates at the PSL and the PML terminates it and merge the traffic onto the primary LSP. At the setup of the recovery LSP, the PML need information about which primary path it belongs to and allow for merging of traffic. Hellstrand et al. [Page 2] Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000 CR-LDP and RSVP-TE are defined in [CR-LDP] and [RSVP], respectively. They both support explicitly routed label switched paths. Therefore, it is natural to extend them to allow for merging of a recovery LSP with the primary LSP. 2.1 Protection Merging At the Path Merging LSR (PML) the recovery LSP terminates and the recovered traffic should be merged onto the primary LSP. To be able to accomplish the merge the recovery LSP setup procedure must be able to identify the primary LSP. The identification of the LSP is done by the use of the unique LSPID that is defined for every ER-LSP. By including the LSPID of the primary LSP in the setup of the associated recovery LSP the PML may be able to perform an identification. 2.2 Explicit merging A recovery scenario is a special case of merging of two LSPs. In a normal case an LSP may explicitly not allow another LSP to merge onto the same path or, if it is allowed, an update of any resource allocations should be made for the merged LSP. In a recovery scenario when the traffic is switched over to the recovery path, the primary path does not longer work and hence does not forward any traffic. At the merging point, the PML, there is only one traffic stream that either comes, at normal conditions, on the primary path or, at failure situations, on the recovery path. Traffic only runs on one path at the same time - either the recovery path or the primary path. The traffic stream is not doubled on the merged LSP and hence no update of any resource allocation is needed. To allow for this special case an indication is needed to explicitly inform that recovery merge is requested. 3.0 Proposal To support the merge of an explicitly routed recovery LSP with the primary ER-LSP, extensions are proposed for CR-LDP and RSVP-TE. 3.1 Extensions to CR-LDP A new optional TLV is proposed for the Label Request Message to support the setup of a Recovery LSP. The Label Request Message defined in [LDP] optionally carries one or more of the optional Constraint-based Routing TLVs (CR-TLVs) defined in [CR-LDP]. This Recovery-TLV (R-TLV) is proposed to be an optional CR-TLV. The R-TLV includes information about which primary LSP the recovery LSP should merge onto in form of the primary LSP's LSPID. Also, a flag may be set to indicate compulsorily merge. Hellstrand et al. [Page 3] Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000 The encoding for the R-LSP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Type = 0x0824 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Reserved | Local Primary CR-LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Ingress LSR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type A fourteen-bit field carrying the value of the R-TLV Type = 0x0824. Length Specifies the length of the value field in bytes = 4. M flag The M flag if set indicates compulsorily merge is allowed and that no extra resource allcotation should be made for the merged LSP. Reserved Zero on transmission. Ignored on receipt. Local Primary CR-LSP ID The Local Primary LSP ID is an identifier of the primary CR-LSP the recovery LSP should be merge with. The Local Primary LSP ID is locally unique within the Ingress LSR originating the Primary CR-LSP. Primary Ingress LSR Router ID The LSR which originates the primary CR-LSP. An LSR may use any of its own IPv4 addresses in this field. 3.1.1 Error Notifications A Notification Message carries a Status TLV, both defined in [LDP], to signal error notifications associated with the establishment of a CR-LSP and the processing of the CR-TLV. The proposed R-TLV adds some new status codes as follows: Status code Type Primary LSP not identified 0x44000-- LSR not merge capable 0x44000-- 3.2 Extensions to RSVP-TE In [RSVP-TE] a reroute option is included. It is possible to setup a recovery LSP that is disjoint with the primary LSP for one or several hops. The recovery LSP terminates at the same egress LSR as the Hellstrand et al. [Page 4] Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000 Primary LSP does and hence may have links in common downstream of a potential failure point. By using a shared SESSION object the recovery LSP allows for sharing resources with the Primary LSP on common links. Once traffic is flowing on the recovery LSP, the primary LSP is torn down. The extensions proposed in this draft aim at allow for the recovery path to have a different egress LSR (termination point) than the primary LSP and allow for a physical merge of traffic back onto the primary LSP at this termination point. To accomplish that an extension is proposed as follows. The LSP TUNNEL Session Attribute Object [RSVP-TE] can be added to the Path message and includes additional control information. There is a code point called "local protection" in [RSVP-TE] but the use of it is unclear. If that codepoint cannot be used a new flag code is proposed to be added to the FLAGS field. 0x09 Recovery path This flag indicates that the tunnel is setup as a pre-established recovery tunnel and should be physical merged with the primary LSP at the node where they share same session object. To identify the Primary LSP at the PML the existing SESSION object, instead of the LSPID, SHALL be used in the Path Message of the recovery tunnel. Whether further extensions to cover this case are needed is for further study. 3.3 Recovery Path Resource Reservations When protecting constraint based routed LSPs, resources may have been allocated along their original route. When applying protection, resource reservation may be desired to reserve for the recovery paths as well. In case of segmenting the protection of the LSP, e.g. applying local repair at each node, the recovery LSPs created to protect the same LSP may share paths and nodes in the network. Usually that would not be a problem but when resource reservations are involved multiple allocations can be made for the same traffic. To avoid this nodes along the recovery path MAY note the - The primary LSPID carried in the Recovery TLV in the Label Request Message defined for CR-LDP, or - The Recovery path flag carried in the LSP TUNNEL Session Attribute Object in RSVP-TE, to identify the protected LSP and take further actions to prevent multiple resource reservations. 4.0 Security Considerations The MPLS extension that is specified herein does not raise any security issues that are not already present in the MPLS architecture. Hellstrand et al. [Page 5] Internet Draft draft-hellstrand-mpls-recovery-merge-01.txt Nov 2000 5.0 Intellectual Property Considerations The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 6.0 Acknowledgements We would like to thank Philip Matthews, David Allan and Don Fedyk for valuable input and comments. 7.0 Authors' Addresses Fiffi Hellstrand Nortel Networks St Eriksgatan 115, PO Box 6701 113 85 Stockholm, Sweden Ph: +46 8 5088 3687 e-mail: fiffi@nortelnetworks.com Loa Andersson Nortel Networks St Eriksgatan 115, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34 e-mail: loa.andersson@nortelnetworks.com 8.0 References [FRMWK] Makam, S. et al, "A Framework for MPLS-based Recovery", Work in Progress, Internet Draft draft-ietf-mpls-recovery-frmwrk- 01.txt, November 2000. [CR-LDP] Jamoussi et al, _Constraint-Based LSP Setup using LDP_ Work in progress, Internet Draft draft-ietf-mpls-cr-ldp-04.txt, July 2000 [RSVP-TE] Awduche, D, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", Work in Progress, Internet Draft draft-ietf-mpls-rsvp- lsp-tunnel-05.txt, February, 1999. [LDP] Andersson et al, "Label Distribution Protocol Specification", Work in Progress, Internet Draft draft-ietf-mpls-ldp-08.txt, June 2000. Hellstrand et al. [Page 6]