Internet Draft Network Working Group Norihito Fujita Internet Draft Atsushi Iwata <draft-fujita-mpls-crldp-crankback-00.txt> NEC Corporation Expires in six months Gerald R. Ash AT&T March 2000 Crankback Routing Extensions for CR-LDP <draft-fujita-mpls-crldp-crankback-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 This draft proposes crankback routing extensions for CR-LDP signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that label requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the proposed crankback routing schemes can be also applied to end-to-end LSP restoration by indicating the Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 1] Internet Draft March 2000 location of the failure link or node. This would significantly improve the recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. 1. Introduction CR-LDP (Constraint-based Routing Label Distribution Protocol) is defined in [CR-LDP] for establishing explicitly routed LSPs (CR-LSPs) in an MPLS network. Using CR-LDP, resources can also be reserved along a path to guarantee or control QoS for traffic carried on the CR-LSP. To designate an explicit path that satisfies QoS constraints, it is necessary to discern the resources available to each link or node in the network. For the collection of such resource information, routing protocols, such as OSPF [OSPF], can be extended to distribute additional state information [LI]. Explicit paths can be designated based on the distributed information at the LSR initiating a CR-LSP and, if necessary, intermediate gateway LSRs. In a distributed routing environment, however, the resource information used to compute a constraint-based path may be out of date. This means that a setup request may be blocked, for example, because a link or node along the selected path has insufficient resources. When a setup failure occurs, a notification is returned to the setup initiator (ingress LSR). In the current CR-LDP, the ingress LSR receiving the notification has to terminate the message and give up the LSP establishment. If the ingress or intermediate gateway LSR knows the location of the blocked link or node, the LSR can designate an alternate path and then reissue the setup request, which can be achieved by the mechanism known as crankback routing [PNNI, ASH]. We propose the use of crankback routing in CR-LDP. Crankback routing requires notifying an upstream LSR of the location of the blocked link or node. On the other hand, various restoration schemes for link or node failures have been proposed in [SWALLOW, MAKAM, SHARMA] and others. Fast restoration by pre-establishing a backup LSP is useful for failures on a primary LSP. If both the primary and backup paths fail, however, it is necessary to repair the LSP on an end-to-end basis. End-to-end restoration for alternate routing requires the location of the failed link or node. A proposed crankback routing schemes could also be used to notify upstream LSRs of the location of the failure. Furthermore, in situations where many link or node failures occur at the same time, the difference between the distributed routing information and the real-time network state becomes much greater than in normal LSP setups. The LSP restoration must therefore be performed with inaccurate information, which is likely to cause setup blocking. Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 2] Internet Draft March 2000 Crankback routing would also improve failure recovery in these situations. Recently, Multi-Protocol Lambda Switching has also been discussed. In a network without wavelength converters, setup requests are likely to be blocked more often than in a conventional MPLS environment because the same wavelength must be allocated at each OXC on an end-to-end explicit path. Furthermore, end-to-end restoration is the only way to recover LSP failures [CHAUDHURI]. This implies that crankback routing would also be useful in an MPLambdaS network. This draft proposes a crankback routing system that is an extension of CR-LDP and discusses the identification of blocked links or nodes in an MPLS network. Although we address CR-LDP as the label distribution technique in the following, a similar discussion can be applied to TE-RSVP [TE-RSVP]. 2. Crankback Routing Behaviors Crankback routing can be performed in the following situation. a. A setup request is blocked. b. An established LSP fails. Although crankback routing can be done on a hop-by-hop basis, which may be useful for fast restoration, we address source-route based crankback routing in this draft. 2.1. Crankback Routing due to Setup Request Blockage When a label request is blocked due to unavailable resources, a notification message with a Rerouting TLV with the location identifier of the blockage, is returned to the LSR initiating the label request (ingress LSR). The notification message is called a "crankback notification". It may include information such as bandwidth availability, as described in [ASHW]. This issue is left for further study. In a flat network without segmentation, the ingress LSR receives the message and designates an alternate path around the blocked link or node to satisfy QoS constraints using link state information about the area. If an alternate path is found, a new label request is sent over this path. In a network segmented into areas such as hierarchical OSPF, the area border node may terminate the crankback notification and then perform alternate routing instead of the ingress LSR. The LSR that computed the alternate path stores the location Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 3] Internet Draft March 2000 identifiers of the blockages indicated in a crankback notification until it receives a corresponding label mapping message. Upon receiving a crankback notification again after retrying a label request, another alternate path is computed based on the previous blocked links or nodes in the stored information as well as the current ones in the received notification message. Optionally, the maximum number of crankback routing allowed for establishing an LSP may be limited. This is useful to prevent a endless repetition of crankback routing in certain error conditions. It is also useful for reducing the number of unnecessary retries, which do not improve performance. When crankback notifications exceed the threshold, the message that exceeded the threshold is processed as an ordinary (non-crankback) notification and no more label requests are issued. Other mechanisms for controlling crankback routing can also be used. 2.2. Crankback Routing due to LSP Failures When an LSR detects a fault on an adjacent downstream link or node, a label withdraw message is sent upstream over a CR-LSP configured on the LSR. Each LSR receiving the message then releases the corresponding LSP. If the failed LSP is expected to be restored at an upstream LSR, the Rerouting TLV with the location information of the fault link or node is included in a label withdraw message. The ingress or intermediate gateway LSR receiving the message can terminate this messages and then perform alternate routing. On the downstream side of the failure, an LSR detecting the failure sends a label release message over a CR-LSP configured on the LSR. The egress or intermediate gateway LSR receiving the message can terminate this message and wait until the new label request for restoration is received. Other behaviors are the same as those of performing crankback routing upon setup request blockage. 3. Location Identifiers of Blocked Links or Nodes In order to compute an alternate path by crankback routing, it is necessary to identify where blocked links or nodes are. The common identifier of each link or node in an MPLS network should be specified. We propose both protocol-independent and protocol- dependent identifiers. Although a general identifier that is independent of other protocols is preferable, there are a couple of restrictions on its use. In a CR-LDP label request, an explicit route can be represented as a Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 4] Internet Draft March 2000 list of ER-Hop TLVs in the ER-TLV. The first ER-Hop TLV is removed when the label request is sent to the next abstract node. Therefore, we propose that the blockage location be represented using the top ER-Hop TLVs upon a blockage. In the case of a node blockage, the first ER-Hop TLV is returned in a crankback notification. Upon a link blockage, the first and second ER-Hop TLVs is returned, which means that the blockage location is the link between the two nodes indicated by these TLVs. If the abstract node described by the ER-Hop TLV is represented by a strict hop with a prefix length of 32, this indicates one IP address of a single IPv4 node. If this condition is met, the indication of the blockage location by the ER-Hop TLVs allows an ingress or intermediate gateway LSR to compute an alternate path to detour just the link/node. If not, the link or node where a setup failure occurred probably will not be identified. Furthermore, if an initial label request is traversed with hop-by-hop routing, the label request message does not have an ER-TLV. These examples imply that ER-Hop TLVs cannot always be used as the location identifier of a blockage. An alternate indicator of such blocked links or nodes is required. In link state protocols such as OSPF and IS-IS, each link and node in a network can be uniquely identified. For example, the OSPF protocol uses Router ID as the node identifier and the combination of Router ID and Link ID as the link identifier. If the topology and resource information obtained by OSPF advertisements is used to compute a constraint-based path, the location of a blockage can be represented by such identifiers. We also propose protocol-specific link or node identifiers that can be used for multiple routing protocols. In this draft, we specify identifications for OSPF and IS-IS. Extension for other routing protocols, such as BGP, etc., can be easily applied but is left for further study. Although a general link/node identifier in a network is preferable, it is difficult to specify it because MPLS signaling protocols are independent of routing protocols. This issue is left for further study. 4. Additional TLVs In this section, we define additional TLVs included in notification and label withdraw messages. 4.1. Rerouting TLV When resource allocation for a label request is not allowed, a notification message is returned. In a network where crankback routing is supported, the Rerouting TLV is included in the notification message. This message must carry the LSPID TLV of the Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 5] Internet Draft March 2000 corresponding CR-LSP. The Status TLV included in the notification message indicates the cause of the problem. Additional status codes can be added to the current defined ones to give more detail about the blockage such as "Reserved" and "Heavily Loaded" [ASH]. If LSP restoration is supported, the Rerouting TLV is included in label withdraw messages caused by network failures. The message must also carry the LSPID TLV of the corresponding CR-LSP. The Status TLV can be also included to indicate the cause of the problem. 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| Rerouting (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location Identifier Components | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Location Identifier Components One or more TLVs of the following are included. Link TLV: See below for the format. Node TLV: See below for the format. 4.2. Link TLV The Link TLV is used to identify a link where a setup blockage or a fault is detected. 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| Link (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Protocol Type | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier Components 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier Components N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol Type A one-octet unsigned integer containing the unique identifier of a protocol used for QoS routing. The following type numbers are defined. If a constraint-based route is to be calculated with no routing protocols, type 1 should be used. A location is identified Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 6] Internet Draft March 2000 using ER-Hop TLVs, independent of protocols. 1: CR-LDP (ER-Hop TLVs) 2: OSPF 3: IS-IS 128-255: Reserved for private and experimental use. Num; Number of Link Identifier Components A one-octet unsigned integer specifying the number of Link Identifier Components included in the TLV. One or more Link Identifier Components A variable length field containing link identifiers for relevant protocol types. When the type is CR-LDP (1), the following format is used. The first and second ER-Hop TLVs upon setup blockage are included. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First ER-Hop TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Second ER-Hop TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the protocol type is OSPF (2), the following 8-octet format is used. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router ID The same value as the Router ID used in OSPF. Link ID The same value as the Link ID used in OSPF. When the protocol type is IS-IS (3), the following 12-octet format is used. 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 Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 7] Internet Draft March 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + System ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System ID The same value as System ID used in IS-IS. IP Interface Address The IP address assigned to the interface advertised in IS-IS. 4.3. Node TLV The Node TLV is used to identify a node where a setup blockage or a fault is detected. 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| Node (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Protocol Type | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Identifier Components 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Identifier Components N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol Type A one-octet unsigned integer containing the unique identifier of the protocol used for QoS routing. The same value as defined in the Link TLV is used. Num; Number of Node Identifier Components A one-octet unsigned integer specifying the number of Node Identifier Components included in the TLV. One or mode Node Identifier Components A variable length field containing the node identifier for relevant protocol types. When the type is CR-LDP (1), the following format is used. The first ER-Hop TLV upon setup blockage is included. Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 8] Internet Draft March 2000 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First ER-Hop TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the protocol type is OSPF (2), the following 4-octet format is used. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router ID The same value as the Router ID used in OSPF. When the protocol type is IS-IS (3), the following 8-octet format is used. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + System ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System ID The same value as the System ID used in IS-IS. 5. Security Considerations Security considerations are not addressed in this version of the draft. 6. Acknowledgments We would like to thank Juha Heinanen and Srinivas Makam for their review and comments. 7. References [CR-LDP] B. Jamoussi, et.al., "Constraint-Based LSP Setup using LDP", <draft-ietf-mpls-cr-ldp-03.txt>, September 1999. [OSPF] J. Moy, "OSPF Version 2", RFC2328, April 1998. Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 9] Internet Draft March 2000 [LI] T. Li, G. Swallow, D. Awduche, "IGP Requirements for Traffic Engineering with MPLS", <draft-li-mpls-igp-te-00.txt>, February 1999. [PNNI] ATM Forum, "Private Network-Network Interface Specification Version 1.0 (PNNI 1.0)",, May 1996. [ASH] G. Ash, B. Jamoussi, Y. Lee, O. Aboul-Magd, "QoS Resource Management in MPLS-Based Networks", <draft-ash-qos-routing-00.txt>, February 1999. [SWALLOW] R. Goguen, G. Swallow, "RSVP Label Allocation for Backup Tunnels", <draft-swallow-rsvp-bypass-label-00.txt>, October 1999. [MAKAM] S. Makam, V. Sharma, K. Owens, C. Huang, "Protection/Restoration of MPLS Networks", , October 1999. [SHARMA] V. Sharma, C. Huang, S. Makam, K. Owens, "An Assessment of QoS and Protection in MPLS", MPLS'99 Conference, June 1999. [CHAUDHURI] S. Chaudhuri, G. Hjalmtysson, J. Yates, "Control of Lightpaths in an Optical Network", , February 2000. [TE-RSVP] D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow, V. Srinvasan, "Extensions to RSVP for LSP Tunnels", , September 1999. [ASHW] P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, "IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR-LDP", <draft-ietf-mpls-te-feed-00.txt>, February 2000. 8. Authors' Addresses Norihito Fujita NEC Corporation C&C Media Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81 (44) 856-2123 Fax: +81 (44) 856-2230 Email: n-fujita@ccm.cl.nec.co.jp Atsushi Iwata NEC Corporation C&C Media Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 10] Internet Draft March 2000 Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81 (44) 856-2123 Fax: +81 (44) 856-2230 Email: iwata@ccm.cl.nec.co.jp Gerald R. Ash AT&T Room MT E3-3C37 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732 420-4578 Fax: +1 732 440-6687 Email: gash@att.com Fujita & Iwata draft-fujita-mpls-crldp-crankback-00.txt [Page 11]