IETF Draft Extensions to RSVP-TE for MPLS Path Protection July 2001 Huang et al. Expires December 2000 [Page 14] IETF Draft Ken Owens Multi-Protocol Label Switching Erlang Technology, Inc. Expires: August 2002 Vishal Sharma Metanoia, Inc. Srinivas Makam Ben Mack-Crane Tellabs Operations, Inc. Changcheng Huang Carleton University Bora Akyol Pluris, Inc. July 2001 Extensions to RSVP-TE for MPLS Path Protection ::= [ ] [ ] [ ] [ ] [ ] [ ... ] 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 . 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 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 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: ::= [ ] [à] [] ::= 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 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 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. 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 Computer Metanoia, Inc. Engineering Carleton University 335 Elan Village Lane 1125 Colonel By Drive Unit 203 Ottawa, Ontario K1S 5B6 San Jose, CA 95134-2539 Phone: (613) 520-2600 ext. 2477 Phone: 408-943-1794 v.sharma@ieee.org Srinivas Makam Ken Owens Tellabs Operations, Inc. Erlang Technology, Inc. 4951 Indiana Avenue 1106 Fourth Street Lisle, IL 60532 St. Louis, MO 63126 Srinivas.Makam@tellabs.com keno@erlangtech.com Ph: 630-512-7217 Phone: 314-918-1579 Bora Akyol Ben Mack-Crane Pluris, Inc. Tellabs Operations, Inc. 10455 Bandley Drive 4951 Indiana Avenue Cupertino, CA 95014 Lisle, IL 60532 Akyol@pluris.com Ben.Mackcrane@tellabs.com Ph: 408-861-3302 Ph: 630-848-7875 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. [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.