Network Working Group Atsushi Iwata Internet Draft Norihito Fujita <draft-iwata-mpls-crankback-00.txt> NEC Corporation Expiration Date: May 2001 Gerald R. Ash AT&T Adrian Farrel Data Connection Ltd. November 2000 Crankback Routing Extensions for MPLS Signaling <draft-iwata-mpls-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. Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 1]
Internet Draft November 2000 Abstract This draft proposes crankback routing extensions for CR-LDP signaling and for RSVP-TE 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 LSP setup requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP and RSVP-TE 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 crankback routing schemes can also be applied to LSP restoration by indicating the location of the failure link or node. This would significantly improve the successful recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. Table of Contents Page 1. Introduction 3 2. Explicit versus implicit rerouting indications 4 3. Crankback routing behaviors due to LSP setup blockage 6 4. New status codes for rerouting 8 5. Location Identifiers of Blocked Links or Nodes 8 6. Indication of Rerouting Behavior 9 7. Additional TLVs 10 7.1. Rerouting TLV 10 7.2. Link TLV 11 7.3. Node TLV 14 8. Routing protocol interactions 16 9. RSVP-TE considerations 16 9.1 Indication of Rerouting Behavior 18 9.2 Rerouting Object 19 9.3 Link-Rerouting Subobject 20 9.4 Node-Rerouting Subobject 23 9.5 Error Values 25 9.6 ResvErr Usage 25 9.7 Notify Message Usage 25 9.8 Backward Compatibility 26 10. LSP restoration considerations 27 11. Security Considerations 28 12. Acknowledgments 28 13. References 28 Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 2]
Internet Draft November 2000 1. Introduction CR-LDP (Constraint-based Routing Label Distribution Protocol) [CR- LDP] and RSVP-TE (RSVP Extensionf for LSP Tunnel) [RSVP-TE] can be used for establishing explicitly routed LSPs (CR-LSPs) in an MPLS network. Using CR-LDP and RSVP-TE, resources can also be reserved along a path to guarantee or control QoS for traffic carried on the 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] and IS-IS [ISIS], can be extended to distribute additional state information [AWDUCHE1]. Explicit paths can be designated based on the distributed information at the LSR initiating a LSP and, if necessary, intermediate area border 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. In the current CR-LDP specification, when an LSP setup failure occurs, a Notification message is returned to the setup initiator (ingress LSR), which terminates this message and gives up the LSP establishment. In RSVP-TE, a blocked LSP setup may result in a PathErr message sent to the initiator or a ResvErr sent to the terminator (egress LSR). These messages may result in the LSP setup being abandoned. In Generalized MPLS [GMPLS] the Notify message can be used in RSVP-TE networks to expedite notification of LSP failures to ingress and egress LSRs, or to a specific "repair point". If the ingress or intermediate area border 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, ASH1, ASH2]. We propose the use of crankback routing in CR-LDP and RSVP-TE. 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 [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 reestablish the LSP on an end-to-end basis. End- to-end restoration for alternate routing requires the location of the failed link or node. The 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 Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 3]
Internet Draft November 2000 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. Crankback routing would also improve failure recovery in these situations. Recently, Multi-Protocol Lambda Switching has also been discussed [AWDUCHE2]. 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 RSVP-TE and discusses the identification of blocked links or nodes in an MPLS network. For the sake of clarity, the general discussions in the following sections are restricted to the use of CR-LDP as the label distribution technique. A similar discussion can be applied to TE- RSVP [TE-RSVP] as discussed in Sec.9. 2. Explicit versus implicit rerouting indications There have been problems in service provider networks when "inferring" from indirect information that rerouting is allowed. In the case of using an explicit rerouting indication, rerouting is explicitly authorized and not inferred. In the feedback case [ASHW], or in the current error sub-codes of the Notification message [CR- LDP], one can infer a situation where rerouting can be done, but it also can lead to other problems, which have been experienced in practice, as illustrated below. *--------------------* *-----------------* | | | | | N2 ----------- N3-|--|----- AT--- EO2 | | | | x|--|--x x | | | | | | | x | | | | | x|--|--x x | | | N1 ----------- N4-|--|----- EO1 | | | | | *--------------------* *-----------------* AS-1 AS-2 Figure 1. Example of network topology Experiences of using release messages in TDM-based networks for analogous purposes provide some guidance. One can use a release Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 4]
Internet Draft November 2000 message with a cause value (CV) indicating "link congestion" (a CV already standardized in ISUP, for example) to try to then do rerouting at the originating node. However, this sometimes leads to other problems. Figure 1 is used to illustrate five examples based on actual service-provider experiences with respect to crankback (i.e., explicit indication) versus release/CV, or "no bandwidth available" (NBA) (i.e., implicit indication) processing. In this example, N1, N2,N3, and N4 are located in one area (AS-1), and AT, EO1, and EO2 are in another area (AS-2). (1) A connection request from node N1 to EO1 may route to N4 and then find "all circuits busy" (equivalent to NBA). N4 returns a release message to N1 with cause value (CV) 34 (indicates all circuits busy/NBA). Normally a node such as N1 is programmed to block a connection request when receiving CV34, although there is good reason to try to alternate route the connection request via N2 and N3. Some service providers have implemented a technique called route advance (RA), where if a node that is RA capable receives a release message with CV34 then it will try to find an alternate route for the connection request if possible. In this example alternate route N1-N2-N3-EO1 can be tried and may well succeed. (2) Now suppose a connection request goes from N2 to N3 to AT trying to reach EO2 and is blocked at link AT-EO2. Node AT returns a CV34, however N2 will not realize where this blocking occurred based on the CV34, and in this case there is no point in further alternate routing. However with RA it may try to route N2-N1-N4-AT-EO2, but of course this fails again. With crankback, however, this could be resolved, since crankback also indicates where the blocking occurred, and in this scenario a crankback should not be returned. Rather, a CV34 should be returned and should result in blocking the connection request at N2 (the proper response to CV34). (3) However in another case of a connection request from N2 to E02, suppose that link N3-AT is blocked, then in this case N3 should return a crankback (and not CV34) so that N2 can alternate route to N1-N4-AT-EO2, which may well be successful. (4) In a final example, for a connection request from EO1 to N2, EO1 first tries to route the connection request directly to N3. However, node N3 may reject the connection request even if there is bandwidth available on link N3-EO1 (perhaps for priority routing considerations, e.g., reserving bandwidth for high priority connection requests). However when N3 returns CV34 in the release message, EO1 blocks the connection request (a normal response to CV34, given that E01-N4 is already known blocked due to NBA) rather than trying to alternate route through AT-N3-N2, which may well be successful. Had N3 returned a crankback, the EO1 could respond by Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 5]
Internet Draft November 2000 trying the alternate route. (5) Granted that with topology exchange, such as OSPF, the ingress LSR could infer the rerouting condition. However, one of the reasons for crankback is to avoid the overhead or available-link-bandwidth (ALB) flooding to more efficiently use local state information to direct alternate routing at the ingress-LSR. The draft [ASH2] shows how event-dependent-routing (EDR) can just use crankback, and not ALB flooding as required by state-dependent-routing (SDR), to decide on the path in the network through "learning models". Reducing the ALB flooding reduces overhead and can lead to large AS size. Therefore, the alternate routing should be indicated based on an explicit indication (as in examples 2 and 5), and it is best to know the following information separately: a) where blockage/congestion occurred (as in examples 2-3), and b) whether alternate routing "should" be attempted even if there is no "blockage" (as in example 4). 3. Crankback routing behaviors due to LSP setup blockage Crankback routing is performed when an LSP setup request is blocked along the path, as described in the following procedures. When a Label Request message is blocked due to unavailable resources, a Notification message with the location identifier of the blockage, should be returned to the LSR initiating the Label Request (ingress LSR) or the area border LSR. This location identifier of the blockage is described in the Rerouting TLV specified in the Section 7. The existence of the Rerouting TLV in the Notification message implies the explicit indication of the alternate rerouting, as discussed in the previous section. This message may optionally include the feedback TLV, as specified in [ASW], to piggy-back the current available bandwidth information on the blocked link. This fed-back information carried by the feedback TLV can be incorporated into subsequent route computations at the ingress LSR or the area border LSR, which greatly helps to reduce the LSP blocking probability and improves the accuracy of the routing by this learning behavior. In a flat network without segmentation, when the ingress LSR receives the Notification message with the Rerouting TLV, it 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 message is sent over Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 6]
Internet Draft November 2000 this path. On the other hand, in a network segmented into areas such as with hierarchical OSPF, the following procedures are used. As explained in Section 6, the crankback routing behavior is indicated in the "Routing Behavior Flag" (RtgFlg) of the LSPID TLV in the Label Request message. If the "Routing Behavior Flag" is set to end-to-end rerouting, the Notification message with the Rerouting TLV is returned all the way back to the ingress LSR, which may then issue a new Label Request message along another path, which is the same as the case of the flat network above. If the "Routing Behavior Flag" is set as segment-based rerouting (hierarchical rerouting), the area border LSR must terminate the Notification message with the Rerouting TLV and then perform alternate routing within the area, where the area border LSR is located at the ingress side of the area, instead of the ingress LSR of the entire network. The ingress LSR or the intermediate area border LSR that computed the alternate path should store the location identifiers of the blockages indicated in the Rerouting TLV in the Notification message, until it receives a corresponding Label Mapping message. Since the crankback routing may happen more than once for establishing an specific LSP, the history table of all experienced blockages for this LSP should be maintained to perform an accurate path computation to detour the blockages. Thus, until the LSP is established completely, it should be better to maintain the history table of the location identifiers of the blockages notified in each Notify message received at the LSR. Therefore, while the crankback routing is being processed for the LSP, if another Notification message with a Rerouting TLV is received again at the ingress LSR or the intermediate area border LSR for this LSP to trigger another crankback routing, the path computation should be done by the ingress LSR or the intermediate area border LSR, based on the previous blocked links or nodes in the history table as well as the current ones in the received Notification message. This history table may be used for the following LSP setups to compute an accurate path computation during some period or may also be cleared each time an LSP is established. For establishing an LSP, the maximum number of crankback rerouting attempts allowed may be limited. This is useful to prevent an endless repetition of crankback routing in certain error conditions or during periods of high congestion. It is also useful for reducing the number of unnecessary retries, which do not improve the performance. When either an ingress LSR or an area border LSR receives more than the maximum number of Notification messages with the Rerouting TLV, it processes this Notification message as an ordinary (non-crankback) Notification message and does not issue any more Label Request messages. When an area border LSR experiences this situation, it Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 7]
Internet Draft November 2000 sends back to the ingress LSR in the previous area and specifies the error code "Maximum number of reroutings aborted" in the Status TLV within the Notification message. The ingress LSR, upon receiving this message, is allowed to find another area border LSR by pruning this area border LSR in order to try to find another alternative path. 4. New status codes for rerouting The Status TLV included in the Notification message [CR-LDP] indicates the cause of the problem, such as "Resource unavailable" and "Traffic Parameters Unavailable". For rerouting behaviors, additional status codes are defined for the Status TLV in the Notification message. When an ingress LSR and intermediate area border LSR receiving this Status TLV does not support the rerouting functions explained above, this TLV is allowed to be silently ignored. The code "Alternate rerouting should be attempted" is used for an explicit crankback rerouting indication, such as policy related rerouting, and is specified by an intermediate LSR. The code "Maximum number of reroutings aborted" is used by an intermediate area border LSR to indicate when the number of crankback reroutings goes beyond the predetermined threshold. When the ingress LSR or the intermediate area border LSR receives this code, it tries to find another area border LSR through which it might be able to find another alternative path. Other codes could be added in the future for other possible rerouting behaviors (to be determined). Status Code Type -------------------------------------- ---------- Alternate rerouting should be attempted 0x44000016 Maximum number of reroutings aborted 0x44000017 5. Location Identifiers of Blocked Links or Nodes In order to compute an alternate path by crankback rerouting, 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 specify 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 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, Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 8]
Internet Draft November 2000 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 the Rerouting TLV in the Notification message. Upon a link blockage, the first and second ER-Hop TLVs are 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 area border 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 [OSPF] and IS-IS [ISIS], 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 routing- protocol-specific link or node identifiers that can be used for multiple routing protocols. Note that, when the routing-protocol- specific link identifiers are used, the Routing Behavior Flag of LSPID TLV carried in the Label Request message must be set 0010, which implies segment-based rerouting (hierarchical rerouting). In this draft, we specify identifications for OSPFv2 for IPv4, IS-IS for IPv4, OSPF for IPv6, and IS-IS for IPv6. 6. Indication of Rerouting Behavior The LSPID TLV is specified in [CR-LDP] and is a mandatory TLV in the Label Request message. The "Routing Behavior Flag" (RtgFlg) is newly specified within the reserved field of [CR-LDP], as shown below. It is used for indicating the behavior of the crankback rerouting for the Label Request message. Note that "Action Indicator Flag" [CR-LDP][ASH3] in the LSPID TLV may be used for this purpose. The current definition of this ActFlg flag is to indicate the action that should be taken if the LSP already exists on the LSR receiving the message. If the spec [CR-LDP] allows this ActFlg flag to be extended to support an LSP under being established, the specified RtgFlg flag can be merged into the ActFlg flag. Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 9]
Internet Draft November 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| LSPID-TLV (0x0821) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |RtgFlg |ActFlg | Local CR-LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress LSR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RtgFlg Routing Behavior Flag: A 4-bit field that indicates explicitly the behavior of rerouting, or crankback routing for an LSP under establishment. This RtgFlg can also be used for specifying the behavior of LSP restoration for established LSPs. A set of code points is specified as follows: 0000: indicates no rerouting 0001: indicates end-to-end rerouting 0010: indicates segment-based rerouting (hierarchical rerouting) 7. Additional TLVs In this section, we define additional TLVs included in the Notification message for indicating the location of blocked links or blocked nodes. The defined TLVs can also be used for LSP restoration, where these TLVs are carried in Label Withdraw messages for triggering LSP restoration to the ingress LSR. 7.1. Rerouting TLV When resource allocation for a Label Request message 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 corresponding CR-LSP. The Status TLV included in the Notification message indicates the cause of the problem. Additional status codes are added to the current defined ones, as described in Sec.4. If LSP restoration is supported, the Rerouting TLV may be included in Label Withdraw messages caused by network failures. In this case, the message must also carry the LSPID TLV of the corresponding CR-LSP, and its Status TLV indicates the cause of the problem. Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 10]
Internet Draft November 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Rerouting (0x850) | 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. 7.2. Link TLV In case of crankback routing, the Link TLV is used to identify a link where a setup blockage is detected. In case of LSP restoration, the Link TLV is included to identify a link where 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 (0x851) | 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 using ER-Hop TLVs, independent of protocols. If a type other than 1 is used, or the routing-protocol-specific link identifiers are used, the Routing Behavior Flag of the LSPID TLV carried in the Label Request message must be set 0010, which implies that segment- based rerouting (hierarchical rerouting) is used. 1: CR-LDP (ER-Hop TLVs) 2: OSPFv2 for IPv4 [OSPF] 3: Integrated IS-IS (or IS-IS) for IPv4 [ISIS] Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 11]
Internet Draft November 2000 4: OSPF for IPv6 [OSPF6] 5: Integrated IS-IS (or IS-IS) for IPv6 [ISIS6] 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 OSPFv2 for IPv4 (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 OSPFv2 for IPv4. Link ID The same value as the Link ID used in OSPFv2 for IPv4. Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 12]
Internet Draft November 2000 When the protocol type is OSPF for IPv6 (4), 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router ID The same value as the Router ID used in OSPF for IPv6. Interface ID The same value as the Interface ID used in OSPF for IPv6. When the protocol type is IS-IS for IPv4 (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + System ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System ID The same value as System ID used in IS-IS for IPv4 (3). IP Interface Address The IP address assigned to the interface advertised in IS-IS for IPv4 (3). Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 13]
Internet Draft November 2000 When the protocol type is IS-IS for IPv6 (5), the following 24-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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + | | | + IP Interface Address | | | + | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System ID The same value as System ID used in IS-IS for IPv6 (5). IP Interface Address The IP address assigned to the interface advertised in IS-IS for IPv6 (5). 7.3. Node TLV In case of crankback rerouting, the Node TLV is used to identify a node or an abstract node where a setup blockage is detected. In the case of LSP restoration, the Node TLV is included to identify a node or an abstract node where a fault is detected. 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 (0x852) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Protocol Type | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Identifier Components 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Identifier Components N | Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 14]
Internet Draft November 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 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 OSPFv2 for IPv4 (2) or OSPF for IPv6 (4), 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 OSPFv2 for IPv4 or in OSPF for IPv6. When the protocol type is IS-IS for IPv4 (3) or IS-IS for IPv6 (5), 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 15]
Internet Draft November 2000 System ID The same value as the System ID used in IS-IS for IPv4 (3) or in IS-IS for IPv6 (5). 8. Routing protocol interactions If the routing-protocol-specific link or node identifiers are used in the Link TLV and Node TLV defined above, CR-LDP signaling software has to have an interface to interact with the routing protocol, OSPFv2 for IPv4, IS-IS for IPv4, OSPF for IPv6, or IS-IS for IPv6. For example, when an intermediate LSR issues a Notification message with the Rerouting TLV toward an ingress LSR, the CR-LDP signaling module of the intermediate LSR should interact with the routing logic to determine the routing-protocol-specific link or node ID where the blockage or fault occurred and carry this information onto the Link TLV and Node TLV inside the Rerouting TLV. The ingress LSR, upon receiving this Notification message, should interact with the routing logic to compute an alternative path by pruning the specified link ID or node ID in the routing database. Although such protocol interactions are required, the procedure of this interaction is out of scope in this document. 9. RSVP-TE considerations Nothing precludes the use of crankback routing mechanism and LSP restoration mechanism with appropriate TLV structures in the RSVP-TE messages. We illustrate a simple case of setting up an LSP on an explicit route from router-A to router-B, in which certain Tspec and Flowspec requirements must be met on each link in the LSP. The steps are as follows [RSVP][RSVP-TE]: (1) router-A (ingress LSR) sends an RSVP Path message to router-B (egress LSR) with a) a TSPEC object that specifies the traffic characteristics of the data flow that the route-A will generate on the LSP b) an EXPLICIT_ROUTE object (ERO) that specifies the explicit route of the LSP (2) along the way accumulate Adspec to describe the network resources available (3) at the router-B (the egress LSR) map these to an Rspec to build a FLOWSPEC object which includes a service class and the TSPEC object Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 16]
Internet Draft November 2000 and the RSPEC object. (4) router-B sends the FLOWSPEC object back in a Resv message along the specified explicit route, hop-by-hop in reverse order and reserves the resources link by link Resource allocation failure may occur at two points. (a) On the reverse path, as the Resv is processed, resources are reserved and, if they are not available on the required link or at a specific node, a ResvErr message is returned to the egress node (router-B) indicating "Admission Control failure" [RSVP]. Router-B is allowed to change the Rspec and try again, but in the event that this is not practical or not supported, router-B may choose to take any one of the following actions. - Ignore the situation and allow recovery to happen through Path refresh and refresh timeout [RSVP]. - Send a PathErr towards router-A indicating "Admission Control failure". - Send ResvTear towards router-A to abort the LSP setup. (b) It is also possible to make resource reservations on the forward path as the Path message is processed. This choice is made in many RSVP-TE implementations and is compatible with LSP setup in optical networks [GMPLS]. In this case if resources are not available, a PathErr message is returned to router-A indicating "Admission Control failure". Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 17]
Internet Draft November 2000 9.1 Indication of Rerouting Behavior The behavior specified by the RtgFlg described in Section 6 is achieved in RSVP-TE by a change to the LSP_TUNNEL Session Attribute Object. A new RtgFlg field is added in what was previously a reserved area in the object. The object is now specified as follows. class = SESSION_ATTRIBUTE, LSP_TUNNEL C-Type = 7 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Session Name (NULL padded display string) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Setup Priority The priority of the session with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session. Holding Priority The priority of the session with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session. Flags 0x01 Local protection desired This flag permits transit routers to use a local repair mechanism which may result in violation of the explicit route object. When a fault is detected on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration. 0x02 Label recording desired This flag indicates that label information should be included when doing a route record. 0x04 SE Style desired Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 18]
Internet Draft November 2000 This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node SHOULD use the SE Style when responding with a Resv message. 0x08 End-to-end rerouting desired This flag indicates the end-to-end rerouting behavior for an LSP under establishment. This can also be used for specifying the behavior of end-to-end LSP restoration for established LSPs. 0x10 Segment-based rerouting (hierarchical rerouting) desired. This flag indicates the segment-based rerouting (hierarchical rerouting) behavior for an LSP under establishment. This can also be used for specifying the segment-based (hierarchical) LSP restoration for established LSPs. Name Length The length of the display string before padding, in bytes. Session Name A null padded string of characters. 9.2 Rerouting Object We define a new object, the "rerouting Object", analagous to the "Rerouting TLV" defined in Section 7.1, to explicitly indicate that crankback rerouting is allowed at router-A. The new object is added to the definition of the PathErr message specifying it as optional. When a PathErr message carrying the Rerouting object is received at router-A, router-A MAY attempt crankback rerouting. It can choose from the following actions. - Send PathTear to give up - Do nothing to give up (soft state times out) - Pick a new route and send a new Path - Change the resource requirements and send a new Path message The PathErr message is defined as follows: Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 19]
Internet Draft November 2000 <PathErr message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <ERROR_SPEC> [ <REROUTING> ] [ <POLICY_DATA> ...] [ <sender descriptor> ] The Rerouting Object is defined as follows: IPv4 REROUTING object: Class = TBD, C-Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Rerouting object may contain one or more subobjects of the following types: Link Rerouting Subobject: See below for the format. Node Rerouting Subobject: See below for the format. 9.3 Link-Rerouting Subobject This subobject is analogous to the Link TLV in Sec.7.2. It may be carried in the Rerouting object in a PathErr message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Protocol Type | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier Components 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier Components N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The Type indicates the type of contents of the subobject. 1 Link-Rerouting subobject Length The length in bytes of the subobject Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 20]
Internet Draft November 2000 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 using the ERO, independent of protocols. If a type other than 1 is used, or the routing-protocol-specific link identifiers are used, the Flag of the SESSION_ATTRIBUTE in the LSP_TUNNEL_IPv4 Session Object carried in the Path message must be set 0x10, which implies that segment-based rerouting (hierarchical rerouting) is used. 1: RSVP-TE for IPv4 (EXPLICIT ROUTE Object) 2: OSPFv2 for IPv4 [OSPF] 3: Integrated IS-IS (or IS-IS) for IPv4 [ISIS] 4: OSPF for IPv6 [OSPF6] 5: Integrated IS-IS (or IS-IS) for IPv6 [ISIS6] 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 object. One or more Link Identifier Components A variable length field containing link identifiers for relevant protocol types. When the type is RSVP-TE for IPv4 (1), the following format is used. The first and second ERO hop 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 ERO hop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Second ERO hop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the protocol type is OSPFv2 for IPv4 (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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 21]
Internet Draft November 2000 Router ID The same value as the Router ID used in OSPFv2 for IPv4. Link ID The same value as the Link ID used in OSPFv2 for IPv4. When the protocol type is OSPF for IPv6 (4), 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router ID The same value as the Router ID used in OSPF for IPv6. Interface ID The same value as the Interface ID used in OSPF for IPv6. When the protocol type is IS-IS for IPv4 (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + System ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System ID The same value as System ID used in IS-IS for IPv4 (3). IP Interface Address The IP address assigned to the interface advertised in IS-IS for IPv4 (3). When the protocol type is IS-IS for IPv6 (5), the following 24-octet format is used. Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 22]
Internet Draft November 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + System ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + | | | + IP Interface Address | | | + | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System ID The same value as System ID used in IS-IS for IPv6 (5). IP Interface Address The IP address assigned to the interface advertised in IS-IS for IPv6 (5). 9.4 Node-Rerouting Subobject This subobject is analogous to the Node TLV in Sec.7.3. It may be carried in the Rerouting object in a PathErr message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Protocol Type | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Identifier Components 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Identifier Components N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The Type indicates the type of contents of the subobject. 2 Node-Rerouting subobject Length The length in bytes of the subobject Protocol Type Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 23]
Internet Draft November 2000 A one-octet unsigned integer containing the unique identifier of the protocol used for QoS routing. The same value as defined in the Link-Rerouting subbject is used. Num: Number of Node Identifier Components A one-octet unsigned integer specifying the number of Node Identifier Components included in the object. One or mode Node Identifier Components A variable length field containing the node identifier for relevant protocol types. When the type is RSVP-TE for IPv4 (1), the following format is used. The first ERO Hop upon setup blockage is 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 ERO Hop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the protocol type is OSPFv2 for IPv4 (2) or OSPF for IPv6 (4), 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 OSPFv2 for IPv4 or in OSPF for IPv6. When the protocol type is IS-IS for IPv4 (3) or IS-IS for IPv6 (5), 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 for IPv4 (3) or in Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 24]
Internet Draft November 2000 IS-IS for IPv6 (5). 9.5 Error Values Error values for the Error Code "Admission Control Failure" are defined in [RSVP]. It may be appropriate to define new additional subcodes to provide additional action information. This area is for future study. 9.6 ResvErr Usage As described above, the resource allocation failure for RSVP-TE may occur when the reverse path when the Resv message is being processed. In this case, it is still useful to collect the crankback information and return it to the ingress LSR. This can be achieved by specifying additions to the ResvErr message as follows. <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <ERROR_SPEC> [ <SCOPE> ] [ <REROUTING> ] [ <POLICY_DATA> ...] <STYLE> [ <error flow descriptor> ] The Rerouting object carried on the ResvErr is exactly as described above. When a ResvErr carrying a Rerouting object is received at an egress LSR, the egress LSR MAY ignore this object and perform the same actions as for any other ResvErr. However, if the egress LSR supports the crankback extensions defined in this draft, it SHOULD generate a PathErr message and send it to the ingress LSR. Such a PathErr should contain - an Error_Spec object that shows the egress LSR as the Error Node - the Rerouting object unchanged from the ResvErr. 9.7 Notify Message Usage [GMPLS] defines a new message, the Notify message, to supplement error reporting in RSVP-TE networks. The Notify message is sent to Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 25]
Internet Draft November 2000 addresses requested on the Path and Resv messages. These addresses could (but need not) identify the ingress and egress LSRs respectively. When a network error occurs, such as the failure of link hardware, the LSRs that detect the error MAY send Notify messages to the requested addresses. The type of error that causes a Notify message to be sent is an implementation detail. The Notify message is not intended to replace the PathErr and ResvErr messages. In the event that an LSR that supports [GMPLS] and the crankback extensions defined in this draft, it MAY choose to send a Notify message in the event of resource allocation failure. This would ensure a speedier report of the error to the ingress/egress LSRs and might make LSP restoration faster (see Section 10). To facilitate crankback after a Notify message, the Notify message is extended to optionally carry the Rerouting object as follows. <Notify message> ::= <Common Header> [<INTEGRITY>] <MESSAGE_ID> <ERROR_SPEC> [<REROUTING>] <notify session list> <notify session list> :== [<notify session list>] <notify session> <notify session> :== <SESSION> [<POLICY_DATA>...] <sender descriptor> 9.8 Backward Compatibility It is recognized that not all nodes in an RSVP-TE network will necessarily support the extensions defined in this draft. It is important that an LSR that does not support these extensions can continue to process a PathErr, ResvErr or Notify message even if it carries the new Rerouting object. This is achieved by using the rules set out in Section 3.10 of [RSVP] to define the value of the Class of the new Rerouting object. The value shall be selected from the set of values as follows. o Class-Num = 11bbbbbb The node should ignore the object but forward it, unexamined and unmodified, in all messages resulting from this message. Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 26]
Internet Draft November 2000 10. LSP restoration considerations LSP restoration is performed to recover the failure of an established LSP when a failure occurs along the path. In the case of LSP restoration, the extensions for crankback rerouting explained above can be applied for improving performance. This section gives an example of applying the above extensions to LSP restoration. The goal of this example is to give an general overview of how this might work, and not to give a detailed procedure for LSP restoration. Although there are several techniques for LSP restoration, this section explains the case of on-demand LSP restoration, which attempts to set up a new LSP on demand after detecting an LSP failure. The detailed procedure for LSP restoration will be described in a separate document. 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 failed link or node is included in a Label Withdraw message. The ingress or intermediate area border LSR receiving the message can terminate these messages and then perform alternate routing. On the downstream side of the failure, an LSR detecting the failure sends a Label Release message over the CR-LSP configured on the LSR. The egress or intermediate area border LSR receiving the message can terminate this message and wait until the new Label Request message for the LSP restoration is received. In a flat network without segmentation, when the ingress LSR receives the Label Withdraw message with the Rerouting TLV, it 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 message is sent over this path toward the egress LSR. On the other hand, when the egress LSR receives the Label release message with the LSPID TLV, whose "Routing Behavior Flag" indicates the end-to-end rerouting mode, it must wait until the new Label Request message is received. In a network segmented into areas such as with hierarchical OSPF, the following procedures can be used. As explained in the Section 6, the LSP restoration behavior is indicated in the "Routing Behavior Flag" (RtgFlg) of the LSPID TLV in the Label Request message. If the "Routing Behavior Flag" is set to end-to-end rerouting, the Label Withdraw message with the Rerouting TLV is returned all the way back to the ingress LSR, which may then issue a new Label Request message along another path, which is the same procedure as in the flat Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 27]
Internet Draft November 2000 network case above. If the "Routing Behavior Flag" is set to segment- based rerouting (hierarchical rerouting), the ingress area border LSR must terminate the Label Withdraw message with the Rerouting TLV and then perform alternate routing within the area, where the area border LSR is located on the ingress side of the area, instead of the ingress LSR of the entire network. On the other hand, when the egress area border LSR receives the Label release message with the LSPID TLV, whose "Routing Behavior Flag" indicates segment-based rerouting (hierarchical rerouting), it must wait until the new Label Request message is received. 11. Security Considerations Both the crankback routing extensions and LSP restoration extensions for CR-LDP inherit the same security mechanisms described in Section 6 of [LDP] and [CR-LDP] to protect against spoofing attacks of an LDP session, the privacy of LDP signaling messages, and the denial of service (DoS) attacks to well known UDP/TCP ports for LDP sessions. 12. Acknowledgments We would like to thank Juha Heinanen and Srinivas Makam for their review and comments. 13. References [ASH1] G. Ash, "Routing Guidelines for Efficient Routing Methods," work in progress <draft-ash-itu-sg2-routing-guidelines-00.txt>, October 1999. [ASH2] G. Ash, "Traffic Engineering & QoS methods for IP-, ATM-, & TDM-Based Multiservice Networks," work in progress <draft-ash-te-qos- routing-01.txt>, July 2000. [ASH3] G. Ash, et al., "LSP Modification Using CR-LDP", work in progress <draft-ietf-mpls-crlsp-modify-02.txt>, October 2000. [ASHW] P. Ashwood-Smith, et al., "Improving Topology Data Base Accuracy with LSP Feedback," work in progress <draft-ietf-mpls-te- feed-01.txt>, July 2000. [AWDUCHE1] D. Awduche, et al., "Requirements for Traffic Engineering Over MPLS," RFC2702, September 1999. [AWDUCHE2] D. Awduche, et al., "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossconnects", work in progress <draft-awduche-mpls-te- optical-02.txt>, July 2000. Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 28]
Internet Draft November 2000 [CHAUDHURI] S. Chaudhuri, et al., "Control of Lightpaths in an Optical Network," work in progress <draft-chaudhuri-ip-olxc- control-00.txt>, February 2000. [CR-LDP] B. Jamoussi, et al., "Constraint-Based LSP Setup using LDP," work in progress <draft-ietf-mpls-cr-ldp-04.txt>, July 2000. [GMPLS] P. Ashwood-Smith and L. Berger, et al., "Generalized MPLS - Signaling Functional Description," work in progress, <draft-ietf- mpls- generalized-signaling-00.txt>, October 2000. [INTER-AREA-MPLS1] S. Venkatachalam, "OSPF, IS-IS, RSVP, CR-LDP extensions to support inter-area traffic engineering using MPLS TE," work in progress, <draft-dharanikota-interarea-mpls-te-ext-01.txt>, November 2000. [INTER-AREA-MPLS2] S. Venkatachalam, "A Framework for the LSP Setup Across IGP Areas for MPLS Traffic Engineering," work in progress, <draft-venkatachalam-interarea-mpls-te-01.txt>, November 2000. [ISIS] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments," RFC1195, December 1990. [ISIS6] C. E. Hopps, "Routing IPv6 with IS-IS," work in progress <draft-ietf-isis-ipv6-01.txt>, July 2000. [LDP] L. Andersson, et al., "LDP Specification," work in progress <draft-ietf-mpls-ldp-11.txt>, August 2000. [MAKAM] S. Makam, et al., "Framework for MPLS-based Recovery," work in progress <draft-makam-mpls-recovery-frmwrk-01.txt>, July 2000. [OSPF] J. Moy, "OSPF Version 2," RFC2328, April 1998. [OSPF6] R. Coltun, et al., "OSPF for IPv6," RFC2740, December 1999. [PNNI] ATM Forum, "Private Network-Network Interface Specification Version 1.0 (PNNI 1.0)," <af-pnni-0055.000>, May 1996. [RSVP] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, RFC2205, September 1997. [RSVP-TE] D. Awduche, et al., "Extensions to RSVP for LSP Tunnels," work in progress <draft-ietf-mpls-rsvp-lsp-tunnel-07.txt>, March 2000. [SHARMA] V. Sharma, et al., "An Assessment of QoS and Protection in MPLS," MPLS'99 Conference, June 1999. Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 29]
Internet Draft November 2000 14. Authors' Addresses Atsushi Iwata NEC Corporation Computer & Communication Media Research 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81-(44)-856-2123 Fax: +81-(44)-856-2230 Email: a-iwata@ah.jp.nec.com Norihito Fujita NEC Corporation Computer & Communication Media Research 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@bk.jp.nec.com Gerald R. Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Fax: +1-(732)-368-8659 Email: gash@att.com Adrian Farrel Network Convergence Group Data Connection Ltd. Windsor House Pepper Street Chester, UK Phone: +44-(0)-1244-313440 Fax: +44-(0)-1244-312422 Email: af@dataconnection.com Iwata, et al. draft-ietf-mpls-crankback-00.txt [Page 30]