Internet Draft Internet Draft Fiffi Hellstrand Multi-Protocol Label Switching Loa Andersson Expiration Date: January 2001 Nortel Networks July 2000 Extensions to CR-LDP and RSVP-TE for setup of pre-established recovery tunnels <draft-hellstrand-mpls-recovery-merge-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 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 Hellstrand, Andersson. [Page 1] Internet Draft draft-hellstrand-mpls-00.txt July 2000 merge operation differs in a number of details from that employed for a normal MP2P 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. 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 4.0 Security Considerations 5.0 Intellectual Property Considerations 6.0 Author's Addresses 7.0 References 1.0 Introduction Protection of traffic is growing in importance and especially recovery schemes that can provide fast restoration. 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. Hellstrand, Andersson. [Page 2] Internet Draft draft-hellstrand-mpls-00.txt July 2000 2.0 Protection of ER-LSP To protect from a link or node failure an ER-LSP recovery tunnel is setup between the switching and the merging node to form an LDP adjacency. To protect an ER-LSP the recovery path is explicitly routed to circumvent a potential failure point. 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. 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. Hellstrand, Andersson. [Page 3] Internet Draft draft-hellstrand-mpls-00.txt July 2000 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. 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. Hellstrand, Andersson. [Page 4] Internet Draft draft-hellstrand-mpls-00.txt July 2000 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 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 andallow 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. Ifthat codepoint cannot be used a new flag code is proposed to be added to the FLAGS field. Hellstrand, Andersson. [Page 5] Internet Draft draft-hellstrand-mpls-00.txt July 2000 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 can be used in the Path Message of the recovery tunnel. Whether further extensions to cover this case are needed is for further study. 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. 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 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 Hellstrand, Andersson. [Page 6] Internet Draft draft-hellstrand-mpls-00.txt July 2000 7.0 References [FRMWK] Makam, S. et al, "A Framework for MPLS-based Recovery", Work in Progress, Internet Draft, draft-makam-mpls-recovery-frmwrk-00.txt, Dec. 2000. [CR-LDP] Jamoussi et al, ôConstraint-Based LSP Setup using LDPö work in progress (draft-ietf-mpls-cr-ldp-04.txt), July 2000 [RSVP-TE] Awduche, D, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", Internet Draft, Work in Progress, draft-ietf-mpls-revp-lsp -tunnel-05.txt,February, 1999. [LDP] Andersson et al, "Label Distribution Protocol Specification", work in progress (draft-ietf-mpls-ldp-08), June 2000.