IETF Draft Changcheng Huang Multi-Protocol Label Switching Vishal Sharma Expires: December 2000 Srinivas Makam Ken Owens Tellabs Operations, Inc. Bora Akyol Pluris, Inc. June 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 working and protection LSPs and for propagating fault notification upon LSP failure. Huang et al. Expires December 2000 [Page 1] IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000 Table of Contents 1. Motivation 2. Purpose of this Document 3. Background 4. Terminology 5. Extensions for Protection Domain Configuration 6. Fault Notification Message 7.1. Extensions to Support Hop-by-Hop Fault Notification 7.2. Extensions to Support Notification Via Dedicated LSPs 8. Open Issues 9. Security Concerns 10. Acknowledgements 11. AuthorsĘ Addresses 121. References 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] 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. 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 Huang et al. Expires December 2000 [Page 2] IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000 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 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 new attributes to the EXPLICIT_ROUTE object (ERO) to help configure a protection domain. This allows for the identification of the protected LSP(s), and the identification of the endpoints (the protection switch LSR (PSL) and the protection merge LSR (PML)) of a protected path or path segment. -- 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. -- 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. PML: Path Merge LSR. A PML is defined as an LSR that receives both the working and the recovery paths of a protected LSP. RNT: Reverse Notification Tree. A special point-to-multipoint LSP to transport fault notification messages for a multipoint-to-point working LSP. Virtually Merged LSPs: A collection of LSPs that belong to the same RSVP session, and all of which form a tree structure and terminate at the same destination, but they are not physically merged. Huang et al. Expires December 2000 [Page 3] IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 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 transit-points of the protected LSP or LSP segment (or optical trail) and protection 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)(PSL) that will execute protection switching from a working path to a protection path. Sometimes it maybe also necessary to identify the nodes which merge traffic from the working and protection paths, that is the PMLs [2]. The configuration of the protection domain 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 PSL) Since it is unlikely that the working and protection paths will be established by using normal routing, we will assume that a protection domain will be configured by using the explicit route object (ERO) in the Path message of RSVP_TE. This is because the working and protection paths will likely be computed by intelligent on-line or off-line algorithms, and will, therefore, need to be explicitly specified during the setup phase. The last octet of the current sub- objects in the ERO is not defined. Therefore, we propose to use this octet by defining its unused bits as follows: Bit Number Purpose Value Bit 0 Notification Enabling 1= notification (indicates whether this is a required hop which has to generate fault 0= notification notification) not required Bit 1 Protection Path Indicator 1 = protection (Indicates whether the current path node lies on the protection 0 = regular path path) Bit 2 PSL 1 = yes (Indicates whether the current 0 = no node is a PSL) Bit 3 PML 1 = yes (Indicates whether the current 0=no node is a PML) Bit 4 RNT Root 1 = yes (Indicates whether the current 0 = no node is the root of an RNT) Huang et al. Expires December 2000 [Page 4] IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000 Bits 5 to 7 Codepoint for the notification 000 = Hop-by-Hop mechanism used. 001 = MPLS LSP for (Identifies the type of virtually merged notification mechanism that 010 = MPLS LSP for will be used) physically merged 011 = SONET K1, K2 bytes (FFS). If a node identified by an ERO does not support a protection attribute described above, a PathErr message should be returned to the source node, with error code "Routing Problem Error" and error value Bad EXPLICIT ROUTE Attributes. Following the approach in [1], the working and protection LSPs will share the same Session ID but will use different LSP IDs. The Path message for the protection LSPs will travel from the ingress node of the protection LSP (which is also the ingress node of its associated working LSP)to the egress node of the protection LSP (which is also the egress node of its associated working LSP). The Resv message will follow the same path but in the reverse order. An egress node can decide on the reservation style for a particular LSP in the following way. If the LSP is a LSP that requires notification (bit 0=1), the egress node of the working path should terminate the Path message and return a RESV message requesting the shared explicit (SE) reservation style. Similarly, if the LSP is a protection LSP (bit 1=1), the egress node of the protection path (which is also the egress node of its corresponding working path) should again request the SE reservation style. This will avoid reserving bandwidth redundantly. 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. 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 PathErr for notification would require a change in the way the PathErr 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 Huang et al. Expires December 2000 [Page 5] IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000 unnecessarily overloads the meaning of the PathErr message. -- Furthermore, as per the current RSVP specification, a PathErr 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 7.1, 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 PathErr 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 PathErr message would require an intermediate node to differentiate between a normal PathErr 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: ::= [ ] [...] [] ::= 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 | Huang et al. Expires December 2000 [Page 6] IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000 +---------+----------+----------+----------+ | | // Labels of Other Working Paths // | | +---------+----------+----------+----------+ Upon the occurrence of a fault, the notification 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 hop-by-hop they are sent as RSVP messages, but when using a different notification protocol or method, they could as easily be sent by encapsulating them in a format appropriate for the notification protocol or method (for example, MPLS packets, SONET overhead bytes) used. 7.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 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 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. 7.2 Extensions to Support Notification Via Dedicated LSPs Huang et al. Expires December 2000 [Page 7] IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000 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), SE can have different options, such as supporting an LSP per sender or a multipoint-to-point 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 may 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 downstream of this shared link on a diversely routed segment) does not affect all LSPs. In general, the RNT mechanism described in [2] can only support either a single point-to-point LSP or a multipoint-to-point LSP. 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 point-to-multipoint) for supporting 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 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 multipoint-to-point LSP that passed through this node earlier), it should copy the label and forward the Confirmation message to the next downstream node, this process will continue until it reaches the root of the RNT. 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 also copy the label and forward the Confirmation message to the next downstream node. Huang et al. Expires December 2000 [Page 8] IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000 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 multipoint-to-point working LSP, or on several virtually merged working LSPs. For a single point-to-point LSP or for a multipoint- to-point LSP, the node can use the egress label of the working path as a key. For virtually merged LSPs it can use the session ID as a key 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. 8. Open Issues Extensions to support using SONET or WDM layer for notification need further study. 9. Security Concerns This Internet Draft does not introduce additional security concerns to signaling in MPLS networks other than those identified in [1]. 10. 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. 11. AuthorsĘ Addresses Changcheng Huang Vishal Sharma Tellabs Operations, Inc. Tellabs Research Center 4951 Indiana Avenue One Kendall Square Lisle, IL 60532 Bldg. 100, Ste. 121 Changcheng.Huang@tellabs.com Cambridge, MA 02139-1562 Ph: 630-512-7954 Vishal.Sharma@tellabs.com Phone: 617-577-8760 Srinivas Makam Ken Owens Tellabs Operations, Inc. Tellabs Operations, Inc. Huang et al. Expires December 2000 [Page 9] IETF Draft Extensions to RSVP-TE for MPLS Path Protection June 2000 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 12. 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- 05.txt, February, 1999. [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-00.txt, March 2000. [3] Makam, S. et al, "A Framework for MPLS-based Recovery", Work in Progress, Internet Draft, draft-makam-mpls-recovery-frmwrk-00.txt, March 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-ip-optical-framework-00.txt, March 2000.