Internet Draft IETF Draft Ken Owens Multi-Protocol Label Switching Srinivas Makam Expires: May 2001 Vishal Sharma Ben Mack-Crane Tellabs Operations, Inc. Changcheng Huang Carleton University Bora Akyol Pluris, Inc. November 2000 Extensions to CRLDP for MPLS Path Protection <draft-owens-crldp-path-protection-ext-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 deliver reliable service, multi-protocol label switching (MPLS) requires a set of procedures to enable protection of the traffic carried on label switched paths (LSPs). Thus existing signaling mechanisms must be extended appropriately to support such functionality. Recently, CR-LDP [ ] has introduced extensions to LDP to support the establishment of LSP tunnels. This draft extends CR-LDP to support path protection [ ]in MPLS. Specifically, we provide signaling support for establishing working and backup LSPs. Owens, et al [Page 1] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000 Table of Contents Page 1. Motivation 2 2. Purpose of this Document 2 3. Background 3 4. Terminology 4 5. Extensions to Support Protection Domain Configuration 4 5.1 ER Protection ER-Hop TLV 5 5.2 Path Protection TLV 6 5.2.1 RNT Type 7 5.2.2 Hold-off and Wait-to-restore Timer Options 7 5.2.3 Flags 8 5.3 Status Codes 8 6. Open Issues 8 7. Security Concerns 8 8. Acknowledgements 9 9. Authors' Addresses 9 10. References 9 1. Motivation Recently, there has been considerable standards activity within the IETF towards establishing a recovery framework for MPLS [3], and towards devising recovery mechanisms for MPLS-based networks [2], [4], [5], [7], [8], [9] and, lately, also for intelligent optical networks [6]. A number of these proposals have considered path-based recovery. There is, therefore, a need to appropriately extend existing signaling protocols to facilitate the operation of these path-based recovery mechanisms. 2. Purpose of this Document The purpose of this document is to extend CR-LDP to support path protection in MPLS networks. Although we focus here on the path protection mechanism proposed in [2], several of the extensions that we introduce are general, and are applicable to any path-based recovery scheme; for example, optical lightpath recovery. 3. Background CR-LDP [1] extends the LDP protocol to support the establishment of constraint based routed LSP. New TLVs that have been added for this purpose include LSPID, Explicit Route, Explicit Route Hop, Route Pinning, Preemption, Traffic Parameters, Resource Class, and CR-LSP FEC. To create a constraint routed LSP, the sender node creates an CR-LDP Label Request message. If the sender wishes the Label Request message to follow a pre-determined route, it uses an Explicit Route TLV to identify the route. The destination node of a label-switched Owens, et al [Page 2] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000 path responds to a Label Request by allocating a label and including a LABEL object in the CR-LDP Label Mapping message that it sends in response to the Label Request message. The Label Mapping message is sent back upstream by following, in reverse order, the path state that was created by the Label Request message on its way downstream. Although CR-LDP offers some support for reliability, such as a Hello message for detecting link failures and an Initialization Message, it still does not provide adequate support to allow for the operation of a path protection mechanism [2]. In this draft, we introduce extensions to CR-LDP to enable support of MPLS path protection. Specifically, we propose the following: -- Adding an Explicit Route Protection ER-Hop type to allow for the identification of the endpoints (the path switch LSR (PSL) and the path merge LSR (PML)) of a protected path or path segment (protection domain). -- Adding Path Protection TLV to the Label Request message to help configure a protection domain. -- Adding Path Protection Error Codes 4. Terminology The terminology used in our draft follows that defined in [1], [2] and [3]. We will repeat some of the important terms here for the convenience of the reader. PSL: Path Switch LSR. A PSL is defined as an LSR that originates both the working and the recovery paths of a protected LSP. The PSL is the source of the recovery path. PML: Path Merge LSR. A PML is defined as an LSR that receives both the working and the recovery paths of a protected LSP. The PML is the destination of the recovery path. RNT: Reverse Notification Tree. An RNT is used to notify all upstream neighbors of a node that has detected a fault. Virtually Merged LSPs: A collection of LSPs that belong to the same CR-LDP session, and all of which terminate at the same destination, and share a common route from some point towards that destination. Owens, et al [Page 3] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000 5. Extensions to Support Protection Domain Configuration One of the first requirements for a path-based protection scheme is the configuration of a protection domain [3], namely the identification and configuration of the set of LSRs (or OXCs in an agile optical network) that are the end-points of the protected LSP or LSP segment (or optical trail). In addition, for a path-based protection mechanism [2] it is also necessary to identify the node(s) that will serve as the root(s) of the reverse notification tree(s) (RNT), and to identify the node(s) (PMLs) that will merge traffic from the working and protection paths [2]. The configuration of the protection domain ideally occurs in conjunction with the establishment of the working path. (Note that in a path-based scheme, the protection path may be pre-configured or may be configured after the fault is detected and a notification communicated to the path switch LSR (PSL), which is responsible for switching traffic from the failed working path to the protection/backup path.) CR-LDP allows the path to be specified loosely (each node determines it's next hop) or explicitly (each node has been given it's next hop). In either case, the ER TLV is used. An Explicit Route Protection ER-Hop TLV is being defined as an extension to the existing CR-LDP ER message fields. The origination or PSL node in the MPLS network participates in setting up the working and protection paths. The destination or PML point node in the MPLS network participates in setting up a recovery path as a merging network switch element. The PSL learns the working and protection paths that are merged to the same outgoing network switch element during signaling or working/protection path configuration process. 5.1 ER PROTECTION ER-HOP TLV A new ER-Hop TLV is used to identify the PSL and PML. ER Protection has the following format: 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 = 0X0805 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|P| Prot. Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Protection TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ER-Hop Type is 0x08ff (TBD), the L bit could be strict or loose (i.e., the L bit could be 0 or 1), and the Length is 12. Owens, et al [Page 4] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000 P Whether this element is the PSL or PML. 0 denotes PSL. Protection Type The protection type this particular working and protection path pair supports. The current values) are (future values are for FFS): 0000000 1+1 0000001 1:1 Router ID The element's Router ID. The ER Protection ER-Hop must follow the appropriate ER-Hop to identify the PSL/PML[2]. Path Protection TLV The PSL, after processing the ER Protection ER-Hop, will add the Path Protection TLV to the Label Request Message. The PML, after processing the ER Protection ER-Hop, will remove the Path Protection TLV from the Label Request Message. 5.2 Path Protection TLV A Label Request message travels from a sender to receiver(s) along the same path(s) used by the data packets. The IP source address of a Label Request message must be an address of the sender it describes, while the destination address must be the DestAddress for the session. These addresses assure that the message will be correctly routed through a non-LDP cloud. The nodes that the Label Request message travels from a sender to receiver(s) may not need path protection for the entire path. The PSL, after processing the ER Protection ER-Hop, will insert the Path Protection object into the Label Request message. Therefore, only the nodes that are part of the protection domain receive informational elements in regard to protection. The PML, after processing the ER Protection ER-Hop, will remove the Path Protection object from the Label Request message. Owens, et al [Page 5] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000 The format of an CR-LDP Label Request message with the Path Protection TLV extension is: 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Protection 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The presence of this TLV specifies that protection is supported. The following table illustrates the structure of the Path Protection TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RNTT |Holdoff Option | WTR Option |R|Flags | RESVD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the attributes are equal to: U=0, F=0, type is 0x08FF (TBD), and Length is 8. RNTT Specifies how the notification is implemented . Hold-off Timer Option Specifies the hold-off time requirements. Owens, et al [Page 6] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000 Wait-to-Restore Timer Option Specifies the wait-to-restore time requirements. Revertive Option Specifies whether the recovery action is revertive. Flags Specifies whether the Label Request message is for the working path or protection path. RESVD Reserved for Future Use 5.2.1 RNT Type Specifies whether the RNT is implemented as a Hop-by-hop (Layer 3) LSP, as an MPLS (Layer 2) LSP, or over SONET K1/K2 bytes. The default is Hop-by-hop, 000. Other valid values: 001 MPLS LSP 010 SONET K1/K2 5.2.2 Hold-off and Wait-to-restore Timer Options In order to give lower layers (i.e. SONET) time to perform restoration, the timer options specify the hold-off and wait-to- restore time requirements. Since each element along the path must be able to support the timer options when specified, the options must be specified in the Label Request message. The defaults (although could be operator defined) for the timer options are: 00000000 No timer requirements 00000001 50ms timer requirements 00000010 100ms timer requirements 00001011 1s timer requirements 00001100 2s timer requirements 00010100 10s timer requirements 01000110 1m timer requirements 01001111 10m timer requirements 11111111 Policy Derived Timer Requirements 5.2.3 Flags The following flags are defined: 0x01 Working Path Enabled Owens, et al [Page 7] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000 This flag permits the ingress node or the PSL to identify that the Label Request Message is for the working path 0x02 Protection Path Enabled This flag permits the ingress node or the PSL to identify that the Label Request Message is for the protection/recovery path. 0x04 Extra Traffic This flag permits the protection links to carry extra traffic. This flag is an indication that any resources allocated to this protection path are available to be used by other traffic, however it does not necessarly mean that the extra traffic will use the same labels as the protection path. 5.3 Status Codes for Protection In the processing described above, certain errors must be reported as due to failure of established paths specified in the CR-TLVs. The following defines status code types: Type Status Code -------- ------------- 0x440000FF Bad EXPLICIT_ROUTE Protection sub-object 0x440000FF Bad PSL node 0x440000FF Bad PML node 0x440000FF Protection Mechanism not supported 6. Open Issues 1. Extensions to support using SONET or WDM layer for notification need further study. 2. Establishment of a layer 2 path for propagating fault related notification(s) is needed because CR-LDP does not currently provide a mechanism to implement a reverse notification tree (RNT) [2] via the establishment of point-to-multi-point LSPs. 3. Adding a Notification message to carry the fault information signal (FIS) and the fault recovery signal (FRS). 7. Security Concerns Owens, et al [Page 8] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000 This Internet Draft does not introduce additional security concerns to signaling in MPLS networks other than those identified in [1]. 8. Acknowledgements We would like to thank Neil Harrison, Dave Allan, and J. Noel Chiappa, and Ben Mack-Crane for useful discussions on MPLS protection, which were helpful in articulating some of the ideas in this draft. 9. Authors' Addresses Changcheng Huang Vishal Sharma Department of Systems and Computer Engineering Tellabs Research Center Carleton University One Kendall Square 1125 Colonel By Drive Bldg. 100, Ste. 121 Ottawa, Ontario K1S 5B6 Cambridge, MA 02139-1562 Phone: (613) 520-2600 ext. 2477 Vishal.Sharma@tellabs.com Phone: 617-577-8760 Srinivas Makam Ken Owens Tellabs Operations, Inc. Tellabs Operations, Inc. 4951 Indiana Avenue 1106 Fourth Street Lisle, IL 60532 St. Louis, MO 63126 Srinivas.Makam@tellabs.com Ken.Owens@tellabs.com Ph: 630-512-7217 Phone: 314-918-1579 Bora Akyol Pluris, Inc. 10455 Bandley Drive Cupertino, CA 95014 Akyol@pluris.com Ph: 408-861-3302 10. References [1] A Jamoussi, B. "Constraint-Based LSP Setup using LDP", Work in Progress, Internet Draft <draft-ietf-mpls-cr-ldp-04.txt>, July 2000. [2] Huang, C., Sharma, V., Makam, V., and Owens, K., "A Path Protection Mechanism for MPLS networks," Internet Draft, Work in Progress, draft-chang-mpls-path-protection-02.txt, November 2000. [3] Makam, S. et al, "A Framework for MPLS-based Recovery," Work in Progress, Internet Draft, draft-ietf-mpls-recovery-frmwrk-00.txt, September 2000. Owens, et al [Page 9] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000 [4] Shew, S. "Fast Restoration of MPLS Label Switched Paths," Work in Progress, Internet Draft, <draft-shew-lsp-restoration-00.txt>, October 1999. [5] Goguen, R. and Swallow, G., "RSVP Label Allocation for Backup Tunnels", draft-swallow-rsvp-bypass-label-00.txt, work in progress, October 1999. [6] Luciani, J., et al, "IP over Optical Networks û A Framework," Work in Progress, Internet Draft, draft-many-ip-optical- framework-01.txt, July 2000. [7] Hellstrand, F. and Andersson, L.,"Extensions to CR-LDP and RSVP- TE for setup of pre-established recovery tunnels", Work in Progress, Internet Draft, draft-hellstrand-mpls-recovery-merge- 00.txt, July 2000. [8] Kini, S., et al, "Shared backup Label Switched Path restoration", Work in Progress, Internet Draft, draft-kini- restoration-shared-backup-00.txt, November 2000. [9] Kini, S., et al, "ReSerVation Protocol with Traffic Engineering extensions. Extension for Label Switched Path restoration", Work in Progress, Internet Draft, draft-kini-rsvp-lsp-restoration- 00.txt, November 2000. Owens, et al [Page 10] IETF Draft Extensions to CR-LDP for MPLS Path Protection November 2000