IETF Draft Vishal Sharma Multi-Protocol Label Switching Srinivas Makam Expires: May 2001 Ken Owens Ben Mack-Crane Tellabs Operations, Inc. Changcheng Huang Carleton University Bora Akyol Pluris, Inc. November 2000 Extensions to RSVP-TE for MPLS Path Protection 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, RSVP-TE [1] has introduced extensions to RSVP to support the establishment of LSP tunnels. This draft extends RSVP-TE to support path protection [2] in MPLS. Specifically, we provide signaling support for establishing backup LSPs and for propagating fault notification upon LSP failure. Huang, et al [Page 1] IETF Draft Extensions to RSVP-TE 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 EXPLICIT ROUTE PROTECTION sub-object 5 5.2 PATH PROTECTION object 6 5.2.1 RNT Type 7 5.2.2 Hold-off and Wait-to-rstore Timer Options 7 5.2.3 Flags 8 5.3 Error Codes for ERO 8 6. Fault Notification Message 9 6.1 Extensions to Support Hop-by-Hop Fault Notification 10 6.2 Extensions to Support Notification Via Dedicated LSPs 11 7. Open Issues 12 8. Security Concerns 13 9. Acknowledgements 13 10. AuthorsĘ Addresses 13 11. References 13 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. Since RSVP-TE has been devised specifically to support the establishment of LSP tunnels and provides some limited support for local repair, a logical choice is to extend it to support path protection as well. 2. Purpose of this Document The purpose of this document is to extend RSVP-TE 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. The major differences between this 01 version and the previous 00 version are: Huang et al. Expires December 2000 [Page 2] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 -- Bits defined in the ERO subject replaced by a new ERO sub- object -- Define new Protection Object that is embeded in the ERO sub- object -- More encoding details 3. Background RSVP-TE [1] extends the RSVP protocol to support the establishment of LSP tunnels. New objects that have been added for this purpose include RECORD-ROUTE, SESSION-ATTRIBUTE, EXPLICIT-ROUTE, LABEL- REQUEST and LABEL. To create an LSP tunnel, the sender node creates an RSVP Path message with a LABEL-REQUEST object. If the sender wishes the Path message to follow a pre-determined route, it uses an EXPLICIT-ROUTE object to identify the route. The destination node of a label-switched path responds to a LABEL-REQUEST by allocating a label and including a LABEL object in the RSVP Resv message that it sends in response to the Path message. The Resv message is sent back upstream by following, in reverse order, the path state that was created by the Path message on its way downstream. Although RSVP-TE offers some support for reliability, such as a Hello message for detecting link failures and an option in the SESSION-ATTRIBUTE object that allows for local repair, 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 RSVP-TE to enable support of MPLS path protection. Specifically, we propose the following: -- Adding an Explicit Route PROTECTION sub-object to the ERO 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 object to the path message to help configure a protection domain. -- Adding Path Protection Error Codes -- Adding a LABEL-REQUEST object in the Resv message and a LABEL object in the Confirmation message to support the establishment of a layer 2 path for propagating fault related notification(s). This is needed because RSVP-TE does not currently provide a mechanism to implement a reverse notification tree (RNT) [2] via the establishment of point-to- multi-point LSPs. As will be seen later, in some circumstances having a RNT implementation based on layer 2 forwarding can substantially speed up notification by eliminating the need to process the notification message at intermediate nodes. Huang et al. Expires December 2000 [Page 3] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 -- Adding a Notification message to carry the fault information signal (FIS) and the fault recovery signal (FRS). 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 RSVP session, and all of which terminate at the same destination, and share a common route from some point towards that destination. 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.) RSVP 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 ERO object is used. An Explicit Route Protection sub-object is being defined as an extension to the existing RSVP ERO 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 Huang et al. Expires December 2000 [Page 4] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 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 EXPLICIT ROUTE PROTECTION sub-object A new sub-object of the ERO is used to identify the PSL and PML. The PATH PROTECTION sub-object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length |P| Prot. Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH PROTECTION Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This subobject could be strict or loose (i.e., the L bit could be 0 or 1). The Type is 5 (Explicit Route Protection). The Length is 12 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 EXPLICIT ROUTE PROTECTION sub-object must follow the appropriate ERO Subobject to identify the PSL/PML[2]. PATH PROTECTION The PSL, after processing the EXPLICIT ROUTE PROTECTION sub-object, will add the PATH PROTECTION Object to the Path Message. The PML, after processing the EXPLICIT ROUTE PROTECTION sub-object, will remove the PATH PROTECTION Object from the Path Message. Huang et al. Expires December 2000 [Page 5] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 5.2 PATH PROTECTION object A Path message travels from a sender to receiver(s) along the same path(s) used by the data packets. The IP source address of a Path 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-RSVP cloud. The nodes that the Path message travels from a sender to receiver(s) may not need path protection for the entire path. The PSL, after processing the EXPLICIT ROUTE PROTECTION sub-object, will insert the PATH PROTECTION object into the Path message. Therefore, only the nodes that are part of the protection domain receive informational elements in regard to protection. The PML, after processing the EXPLICIT ROUTE PROTECTION sub-object, will remove the PATH PROTECTION object from the Path message. The format of an RSVP Path message with the Path Protection Object extension is: ::= [ ] [ ] [ ] [ ] [ ] [ ... ] The presence of this object specifies that protection is supported. The following table illustrates the structure of the Path Protection Object. 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 attibutes are equal to: Length is 8, Class is 0bbbbbbb (TBD), C-type is 1. RNTT Specifies how the notification is implemented . Huang et al. Expires December 2000 [Page 6] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 Hold-off Timer Option Specifies the hold-off time requirements. 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 Path 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 PATH 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 Huang et al. Expires December 2000 [Page 7] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 5.2.3 Flags The following flags are defined: 0x01 Working Path Enabled This flag permits the ingress node or the PSL to identify that the Path Message is for the working path 0x02 Protection Path Enabled This flag permits the ingress node or the PSL to identify that the Path 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 resourvces 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 Error Codes for ERO In the processing described above, certain errors must be reported as a "Routing Problem". The value of the "Routing Problem" error code is 24. The following defines error values for the Routing Problem Error Code: Value Error: 11 Bad EXPLICIT_ROUTE Protection sub-object 12 Bad PSL node 13 Bad PML node 14 Protection Mechanism not supported Huang et al. Expires December 2000 [Page 8] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 6. Fault Notification Message A second requirement for a path protection mechanism is to have an appropriately defined message that is used to convey fault information from the point of failure to the node responsible for initiating recovery action(s). The notification information should enable each intermediate node (lying between the point of failure and the protection switch LSR) to unambiguously identify the LSPs affected by the failure, and enable it to forward this information to the appropriate nodes further upstream. Ideally, MPLS would have some sort of OAM functionality for this purpose. Since MPLS lacks OAM functionality, this section presents a solution. Although the PathErr message could be enhanced to support fault notification, such enhancements may require significant changes to the format and behavior of the PathErr message, as explained below. -- A PathErr message is typically sent in response to a Path message. A notification message, on the other hand, needs to be sent as soon as the fault is detected, and should not need to wait for the arrival of the next Path message. Thus, adapting Path Err for notification would require a change in the way the Path Err message is currently handled. Although it is possible to change the semantics of the PathErr message to be sent as soon as a fault is detected, this unnecessarily overloads the meaning of the PathErr message. -- Furthermore, as per the current RSVP specifications,a Path Err message is forwarded hop-by-hop (with attendant processing). This limits the notification mechanism to the hop-by-hop approach. As we explain in Section 5, for a faster response, it may be advantageous to have the option to set up a point-to-multipoint LSP as a realization of an RNT. -- Yet another observation is that merely extending the Error Value field of the ERROR SPEC object in the Path Err message is not sufficient to convey the required fault notification-related information. Thus, a new object needs to be defined to carry this additional information in any case. Adding this to the Path Err message would require an intermediate node to differentiate between a normal Path Err message and one carrying fault notification information. Thus, it is cleaner to have a separate message for doing so, since it provides a general notification structure that can be used by either hop-by-hop or LSP-based forwarding. Therefore, we define a new notification message as follows: ::= [ ] [] [] ::= Huang et al. Expires December 2000 [Page 9] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 The NOTIFICATION objects are defined as follows: Class =? C-type =1 for IPv4 failure notification C-type =2 for Ipv4 recovery notification +---------+----------+----------+----------+ | Ipv4 Failure Detection Node ID | +------------------------------------------| | MPLS Label of a Working Path | +---------+----------+----------+----------+ | | // Labels of Other Working Paths // | | +---------+----------+----------+----------+ Class =? C-type =3 for Ipv6 failure notification C-type =4 for Ipv6 recovery notification +---------+----------+----------+----------+ | | | Ipv6 Failure Detection Node ID | | | | | +---------+----------+----------+----------+ | MPLS Label of a Working Path | +---------+----------+----------+----------+ | | // Labels of Other Working Paths // | | +---------+----------+----------+----------+ on message may either be conveyed hop-by-hop (involving some amount of processing and modification at each hop) or it may be conveyed by using a layer 2 label switched path, which we call the MPLS LSP approach. Observe that in essence what the notification objects describe, is the content and format of the fault notification information. When using RSVP-TE they are sent as RSVP messages, but when using a different signaling protocol or method, they could as easily be sent by encapsulating them in a format appropriate for the signaling protocol or method (for example, SONET overhead bytes) used. 6.1 Extensions to support hop-by-hop fault notification The hop-by-hop approach of transporting a notification message can be supported with minimal changes, and multiple sessions can share the same message on a particular link. In this case, however, notification messages have to be processed at each node and therefore introduce extra delay. Upon the occurrence of a failure the propagation of LSAs may cause unstable states. Observe that a hop-by-hop notification message has to compete with the propagation of routing information, which can potentially result in an Huang et al. Expires December 2000 [Page 10] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 unpredictable situation (this could be mitigated by delaying the propagation of LSAs via some holdoff mechanism). The easiest way to support hop-by-hop fault notification is to send a Notification message hop-by-hop. A node detecting a fault generates a Notification message. The node must identify all of the working LSPs affected by the fault (which may not be in the same session), insert in the Notification object(s) the labels used by the upstream node(s) to identify these LSPs, and forward the Notification message to the corresponding upstream node(s). Each intermediate node examines the NOTIFICATION object list to learn of all the affected working paths and their corresponding upstream interfaces. Those interfaces will then repack their own Notification messages with the labels used by their upstream neighbors to identify these LSPs, and in turn forward the Notification message to their own upstream neighbors. This process continues at successive nodes, until a PSL is reached. The PSL removes the labels of the working paths that it originates, and itself forwards the message as an intermediate node, until the last NOTIFICATION object has been removed. Notification messages should be encapsulated in a raw IP packet, with their destination address set equal to the RSVP PHOP. 6.2 Extensions to Support Notification Via Dedicated LSPs Currently, RSVP-TE supports two styles of reservation, namely FF and SE. While FF can only support point-to-point LSPs (because it creates a distinct reservation for the traffic from each sender that is not shared by other senders), SE can have different options, such as supporting an LSP per sender or a multipoint-to-point (merged) LSP. Although there is a single reservation on a link for all the senders in SE, since each sender is explicitly listed in the RESV message, different labels may be assigned to different senders, thereby creating different LSPs. In the latter case, these different LSPs (which share some links in common) maybe diversely routed at the downstream links. It is, therefore, difficult to share a notification message for different LSPs on a particular link without examining the payload of the notification message at each hop. This is because not all LSPs sharing a link may need to be notified if a failure (which may have occurred upstream of this shared link on a diversely routed segment) does not affect all LSPs. Therefore, the RNT is a general mechanism that can support either a single point- to-point LSP or a merged LSP. In general, therefore, for notification via dedicated LSPs, different working LSPs must use different RNTs. But if LSPs that belong to the same session form a tree structure (without necessarily merging at the point of convergence), they too can share an RNT. We will call such LSPs virtually merged. To setup a dedicated LSP (point-to-point or merged) for suporting a RNT, the root of the RNT should insert LABEL-REQUEST object and RESV-CONFIRM object in the Resv message that it receives from the down stream node before forwarding it to the upstream node. (Recall Huang et al. Expires December 2000 [Page 11] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 that the root of the RNT need not be the destination of the LSPs, nor need it be a PML.) The PSL receiving this message will allocate a label, generate a Confirmation message, insert a LABEL object in that message and forward it to the downstream node. Each intermediate node will replace the label with a newly allocated label and forward it to the next downstream node. The root of the RNT will terminate the message. Since a multipoint-to-point LSP should share the same RNT, when an intermediate node finds that the labels of the working path are merged on the downstream link, and a label has already been allocated for the protection path on that downstream link (by a Confirmation message from a different source on the multi-point to point LSP that passed through this node earlier), it should terminate the Confirmation message. Virtually merged LSPs should also share the same RNT. When an intermediate node finds that a label for the protection path is already allocated for the same working session (by a Confirmation message from the source of a different virtually merged LSP), it too should terminate the Confirmation message. Each node on the protected path should maintain an inverse cross- connect table [2] The key used to index the inverse-crossconnect table depends on whether the node lies on a single point-to-point or point-to-multipoint working LSP, or on several virtually merged working LSPs. For a single point-to-point LSP or for a point-to- multipoint LSP, the node can use the egress label as an index. Similarly for virtually merged LSPs it can reference the session ID as an index into the inverse crossconnect table. Upon the occurrence of a fault, the node detecting the fault identifies the working paths affected by the fault. It then uses its inverse cross-connect table to identify their corresponding RNTs. The node then generates a Notification message for each RNT and sends it over the LSP dedicated to that RNT. The Notification message should at least carry the Node ID of the node detecting the fault. Intermediate nodes forward the message as normal MPLS packets, using normal label swapping. The PSL that terminates an RNT path also terminates the Notification message and starts protection switching process. The Notification message should be encapsulated by an MPLS layer frame (e.g. the shim header). No extra IP encapsulation is required. 7. Open Issues Extensions to support using SONET or WDM layer for notification need further study. Huang et al. Expires December 2000 [Page 12] IETF Draft Extensions to RSVP-TE for MPLS Path Protection November 2000 8. Security Concerns This Internet Draft does not introduce additional security concerns to signaling in MPLS networks other than those identified in [1]. 9. 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. 10. AuthorsĘ Addresses Changcheng Huang Vishal Sharma Department of Systems and Tellabs Research Center Computer Engineering 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 11. References [1] Awduche, D, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", Internet Draft, Work in Progress, draft-ietf-mpls-revp- lsp-tunnel-07.txt, August 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. Huang et al. Expires December 2000 [Page 13] IETF Draft Extensions to RSVP-TE for MPLS Path Protection 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. [4] Shew, S. "Fast Restoration of MPLS Label Switched Paths", Work in Progress, Internet Draft, , 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. Huang et al. Expires December 2000 [Page 14]