MPLS Working Group Adrian Farrel (editor) Internet Draft Movaz Networks, Inc. Document: draft-iwata-mpls-crankback-05.txt Expiration Date: September 2003 Atsushi Iwata Norihito Fujita NEC Corporation Gerald R. Ash AT&T Simon Marshall-Unitt Data Connection Ltd. March 2003 Crankback Routing Extensions for MPLS Signaling <draft-iwata-mpls-crankback-05.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 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 use in Multi-Protocol Label Switching (MPLS) signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, so that the LSP setup request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 1]
Internet Draft March 2003 Furthermore, 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. Crankback has been identified by the ITU-T as requirement for the Automatically Switched Optical Network (ASON) and should be added to the GMPLS signaling protocols to meet this requirement. Table of Contents 1. Summary for Sub-IP Area 3 1.1. Summary 3 1.2. Related documents 3 1.3. Where does it fit in the Picture of the Sub-IP Work 3 1.4. Why is it Targeted at this WG 3 1.5. Justification 3 2. Changes and Further Work 4 2.1. Changes from the Previous Version 4 2.2. Future Work 4 3. Introduction 4 4. Explicit Versus Implicit Rerouting Indications 6 5. Overview of Crankback Function 8 6. Existing Support for Crankback Rerouting 10 6.1. RSVP-TE 10 6.2. GMPLS 10 6.3. Information Required for Rerouting 10 6.4. Signaling a New Route 11 7. MPLS Signaling Protocol Independent Information and Procedures 11 7.1. Requesting Crankback and Controlling In-Network Rerouting 11 7.2. Action on Detecting a Failure 12 7.3. Required Information 12 7.3.1 Link TLV 13 7.3.2 Node TLV 16 7.4. Action on Receiving Crankback Information 17 7.4.1 Reroute Attempts 17 7.4.2 Location Identifiers of Blocked Links or Nodes 18 7.4.3 Locating Errors within Loose or Abstract Nodes 18 7.4.4 When Rerouting Fails 19 7.5. Limiting Rerouting Attempts 19 7.5.1 New Status Codes for Rerouting 19 8. RSVP-TE Extensions for Crankback 19 8.1. Overview 19 8.1.1 ResvErr Processing 20 8.1.2 Notify Message Processing 21 8.2. Indication of Rerouting Behavior 21 8.3. Rerouting Object 23 8.4. Error Values 24 8.5. Backward Compatibility 24 9. Routing Protocol Interactions 25 10. LSP Restoration Considerations 25 10.1. Upstream of the Fault 25 10.2. Downstream of the Fault 26 Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 2]
Internet Draft March 2003 11. Security Considerations 27 11.1. RSVP-TE 27 12. Acknowledgments 27 13. Normative References 27 14. Informational References 28 15. Authors' Addresses 28 16. Full Copyright Statement 29 1. Summary for Sub-IP Area 1.1. Summary This document describes requirements, procedures and protocol extensions for Crankback Routing in MPLS and GMPLS networks. These extensions address some of the requirements laid out by the ITU-T for the Automatically Switched Optical Network (ASON). 1.2. Related documents See the Reference Section 1.3. Where does it fit in the Picture of the Sub-IP Work This work is applicable to MPLS and GMPLS signaling protocols. 1.4. Why is it Targeted at this WG MPLS is a product of the MPLS WG. This draft extends the MPLS signaling protocols. At past IETF gatherings it has been suggested that this draft might equally be handled by the CCAMP WG. We await further direction from the WG chairs and the ADs. 1.5. Justification Crankback Routing is a requirement in large and multi- area networks, in networks with rapidly changing topologies or resource usage, or in networks where setup latency may be high. The requirement for Crankback Routing in the Automatically Switched Optical Network (ASON) has been identified by the ITU-T. It is therefore appropriate to consider if and how GMPLS can be extended to provide the function. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 3]
Internet Draft March 2003 2. Changes and Further Work This section to be removed before the draft progresses to RFC. 2.1. Changes from the Previous Version The main changes are: - minor typographical - retirement of all references to CR-LDP - additional work items to consider changing signaling mechanisms to utilize the IF-ID ErrorSpec present in [GMPLS-RSVP] - update references. 2.2. Future Work The following work items have been identified. - Extend crankback information to allow it to report on individual links from bundles, labels and specific resources. - Provide a mechanism to limit the number of rerouting attempts that should be made in total, within an area and at an individual node. - Add and explain methods for controlling which nodes in a network and on an LSP may make rerouting attempts. - The final versions of [GMPLS-RSVP] introduced the IF-ID ErrorSpec where failure information beyond the basic failure reason and reporting node id can be included in TLVs within the ErrorSpec object in a PathErr, ResvErr or notify message. This mechanism is ideal for the propagation of crankback failure information. It is likely that this document will be updated to use that mechanism rather than the one currently described. 3. Introduction RSVP-TE (RSVP Extensions for LSP Tunnel) [RSVP-TE] can be used for establishing explicitly routed LSPs in an MPLS network. Using 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]. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 4]
Internet Draft March 2003 Explicit paths can be computed based on the distributed information at the LSR initiating a LSP and signaled as Explicit Routes during LSP establishment. Explicit Routes may contain 'loose hops' and 'abstract nodes' that convey routing through any of a collection of nodes. This mechanism may be used to devolve parts of the path computation to intermediate nodes such as 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 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-RSVP] 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". These existing mechanisms provide a certain amount of information about the path of the failed LSP. If the ingress LSR 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]. We propose the use of crankback routing in RSVP-TE. Crankback routing requires notifying an upstream LSR of the location of the blocked link or node. In some cases this requires more information than is currently available in the signaling protocols. 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. 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. LSP restoration must therefore be performed with inaccurate information, which is likely to cause setup blocking. Crankback routing would improve failure recovery in these situations. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 5]
Internet Draft March 2003 Generalized MPLS [GMPLS] extends MPLS into networks that manage TDM and lambda resources. 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. This implies that crankback routing would also be useful in an GMPLS network. Crankback has been identified by the ITU-T as requirement for the Automatically Switched Optical Network (ASON) [G8080] and should be added to the GMPLS signaling protocols to meet this requirement. Once crankback information has been supplied to the repair point, it may compute a new path to route around the problem. It may be, however, that the repair point does not have sufficient topology information to compute an Explicit Route that is guaranteed to avoid the failed link or node. In this case, Route Exclusions [LEE] may be particularly helpful. That is, when computing a path loose hops and abstract nodes may be used, and [LEE] offers the opportunity to use route exclusions to force avoidance of the failed node, link or resource. This draft proposes a crankback routing system that is an extension of RSVP-TE and discusses the identification of blocked links or nodes in an MPLS network. 4. 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. Various protocol options and exchanges including the error values of PathErr message [RSVP, RSVP-TE] and the Notify message [GMPLS-RSVP] allow an implementation to infer a situation where rerouting can be done. This allows for recovery from network errors or resource contention. However, such inference of recovery signaling is not always desirable since it may be doomed to failure. Experience of using release messages in TDM-based networks for analogous purposes provides some guidance. One can use the receipt of a release message with a cause value (CV) indicating "link congestion" (a CV already standardized in ISUP, for example) to trigger a rerouting attempt at the originating node. However, this sometimes leads to problems. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 6]
Internet Draft March 2003 *--------------------* *-----------------* | | | | | N2 ----------- N3-|--|----- AT--- EO2 | | | | \| | / | | | | | |--|- / | | | | | | | \/ | | | | | | | /\ | | | | | |--|- \ | | | | | /| | \ | | | N1 ----------- N4-|--|----- EO1 | | | | | *--------------------* *-----------------* AS-1 AS-2 Figure 1. Example of network topology Figure 1 is illustrates five examples based on service- provider experiences with respect to crankback (i.e., explicit indication) versus implicit indication through release/CV, or "no bandwidth available" (NBA). 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). Note that two distinct areas are used in this example to expose the issues clearly. In fact, the issues are not limited to multi-area networks, but arise whenever path computation is distributed throughout the network. For example where loose routes, AS routes or path computation domains are used. 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. In this scenario, CV34 should be used and correctly interpreted to indicate that the LSP should be blocked and not re-signaled. If RA was required, it would be indicated by the use of crankback. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 7]
Internet Draft March 2003 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 trying the alternate route. It is certainly the case that with topology exchange, such as OSPF, the ingress LSR could infer the rerouting condition. However, convergence of routing information is typically slow with respect to desired LSP setup times. 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. [ASH1] 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 the ability to support much larger AS sizes. Therefore, the alternate routing should be indicated based on an explicit indication (as in examples 3 and 4), and it is best to know the following information separately: a) where blockage/congestion occurred (as in examples 1-2) and b) whether alternate routing "should" be attempted even if there is no "blockage" (as in example 4). 5. Overview of Crankback Function Crankback routing is performed when an LSP setup request is blocked along the path, as described in the following procedures. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 8]
Internet Draft March 2003 When an LSP setup request is blocked due to unavailable resources, an error response with the location identifier of the blockage, should be returned to the LSR initiating the LSP setup (ingress LSR), the area border LSR, or some other repair point. This error response carries an error specification as standard - this indicates the cause of the error and the node/link on which the error occurred. In a flat network without segmentation, when the ingress LSR receives the error response 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 LSP setup request is sent over this path. On the other hand, in a network segmented into areas such as with hierarchical OSPF, the following procedures can be used. The error response is generated as described, but the area border LSR may terminate the error response and perform alternate routing within the area for which the LSR is an ingress. In a third scenario, any node within an area may act as a repair point. In this case, the LSR behaves much as an area border LSR described above. It can terminate the error response and perform alternate routing. This may be particularly useful where domains of computation are applied within the network, but care must be taken to prevent all nodes in the network behaving in this way or rerouting thrash may occur. This scenario is somewhat like `MPLS fast reroute', in which any node in the MPLS domain can establish `local repair' LSPs after failure notification. The repair point LSR that computes the alternate path should store the location identifiers of the blockages indicated in the error indication until the LSP is successfully established or until the LSR abandons rerouting attempts. Since the crankback routing may happen more than once while establishing a 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. If a second error response is received by a repair point while it is performing crankback rerouting, it should update the history table and use the entire gathered information when making a further rerouting attempt. The maximum number of crankback rerouting attempts allowed may be limited for any one LSP at any single node. 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 Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 9]
Internet Draft March 2003 improve the performance. When a repair point receives more than the maximum number of error responses, it processes the last error response as an ordinary (non- crankback) error response, does not attempt further rerouting and forwards the error upstream if it is not the ingress. When a non-ingress LSR experiences this situation, it sends an error response to the ingress LSR and specifies the error "Maximum number of reroutings aborted". The ingress LSR, upon receiving this message, may attempt to find a wholly disjoint route (perhaps through another area) or reports the LSP as failed. 6. Existing Support for Crankback Rerouting As already described, RSVP-TE includes error notifications from which a rerouting requirement can be inferred. These notifications also contain information about the failed steps in the path. This section outlines what information is carried and shows how in some circumstances this may not be enough to properly facilitate crankback rerouting. 6.1. RSVP-TE In RSVP-TE a failed LSP setup attempt results in a PathErr message returned upstream. The PathErr carries an ErrSpec Object which indicates the node or interface reporting the error and the reason for the failure. Crankback rerouting can now be performed explicitly avoiding the node or interface reported. 6.2. GMPLS GMPLS extends the error reporting described above by allowing LSRs to report the errored interface in addition to the identity of the node reporting the error. This information would typically only be used in response to an LSP request that included the IF_ID (PHOP 3) object to identify the data link to which the signaling applies. This further enhances the ability of a recomputing node to route around the error. 6.3. Information Required for Rerouting In order to correctly compute a route that avoids the blocking problem in the network, a repair point LSR must gain as much crankback information as possible. Ideally, the repair node will be given the node, link and reason for the failure. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 10]
Internet Draft March 2003 However, this information may not be enough to help with recomputation. Consider an explicit route that contains an abstract node or a loose hop. In this case, the failed node and link is not necessarily enough to tell the repair point which hop in the explicit route has failed. The crankback information needs to provide context into the explicit route. 6.4. Signaling a New Route If a new route can be computed it can be signaled as an explicit route that will avoid the blocking issues. Sometimes, however, the repair point may not always be able to compute a route. For example, it may not have sufficient topology information about the part of the network where the failure occurred. In this case, the repair point may still attempt to re- signal the LSP using the route exclusion procedures described in [LEE]. 7. MPLS Signaling Protocol Independent Information and Procedures 7.1. Requesting Crankback and Controlling In-Network Rerouting When a request is made to setup an LSP tunnel, the ingress LSR should specify whether it wants crankback information to be collected in the event of a failure and whether it requests rerouting attempts by the intermediate nodes. A Rerouting Flag field is added to the protocol setup request messages. Three values for the Rerouting Flag are defined. These values are mutually exclusive. No Rerouting Intermediate nodes SHOULD NOT attempt rerouting after failure. Nodes detecting failures are not requested to supply crankback information. End-to-end Rerouting Intermediate nodes SHOULD NOT attempt rerouting after failure. Nodes detecting failures SHOULD supply full crankback information. ARB Rerouting Intermediate nodes MAY attempt rerouting after failure only if they are Area Border Routers. Nodes detecting failures SHOULD supply full crankback information. Segment-based Rerouting Intermediate nodes MAY attempt rerouting after failure. Nodes detecting failures SHOULD supply full crankback information. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 11]
Internet Draft March 2003 7.2. Action on Detecting a Failure A node that detects the failure to setup an LSP or the failure of an established LSP SHOULD act according to the Rerouting Flag passed on the LSP setup request. If Segment-based Rerouting is allowed, the detecting node MAY immediately attempt to reroute. If End-to-end Rerouting is indicated, or if Segment-based Rerouting is allowed and the detecting node chooses not to make rerouting attempts (or has exhausted all possible rerouting attempts), the detecting node returns a protocol error indication and SHOULD include full crankback information. 7.3. Required Information As described above, full crankback information should indicate the node, link and other resources which have been attempted but have failed because of allocation issues or network failure. These details are reported in the Rerouting Information. The following information is carried in Routing Information: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where each TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 16 bits Indicates type of interface being identified. Defined values are: Type Meaning Description --------------------------------------------------- 1 Link TLV The Value describes a Link 2 Node TLV The Value describes a Node Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 12]
Internet Draft March 2003 Length: 16 bits Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned. 7.3.1 Link TLV When the TLV type is 1 (one) indicating a link TLV, the value has the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Type | Num | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier Components 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier Components N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol Type A one-octet unsigned integer containing the unique identifier of the 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. A type value other than 1 is only permitted if the Rerouting Flag in the LSP setup request indicated support for ABR or segment-based rerouting. 1: ER-Hop 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. Note that if adjacent Areas use different routing protocols, the ABR is responsible for mapping the rerouting information. In general, the correct procedure is to convert to ER-Hop (1) when transitioning such Areas. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 13]
Internet Draft March 2003 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 ER-Hop (1), the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First ER-Hop TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Second ER-Hop TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ First ER-Hop TLV The first hop in the explicit route received by the reporting LSR. Second ER-Hop TLV The second hop in the explicit route received by the reporting LSR. Together with the First ER-Hop, this assists the repair point to locate the error within the context of the explicit route that it sent out. 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. When the protocol type is OSPF for IPv6 (4), the following 8-octet format is used. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 14]
Internet Draft March 2003 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. 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). Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 15]
Internet Draft March 2003 IP Interface Address The IP address assigned to the interface advertised in IS-IS for IPv6 (5). 7.3.2 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. When the TLV type is 2 indicating a node TLV, the value has the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Type | Num | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 values as defined for the Link TLV are 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 ER-Hop (1), the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First ER-Hop TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ First ER-Hop The first hop in the explicit route received by the reporting node. When the protocol type is OSPFv2 for IPv4 (2) or OSPF for IPv6 (4), the following 4-octet format is used. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 16]
Internet Draft March 2003 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 IS-IS for IPv6 (5). 7.4. Action on Receiving Crankback Information 7.4.1 Reroute Attempts As described in section 3, a node receiving crankback information in an error response must first check to see whether it is allowed to perform rerouting. This is indicated by the Rerouting Flags in the LSP setup request. If a node is not allowed to perform rerouting it should forward the error upstream, or if it is the ingress report the LSP as having failed. If rerouting is allowed, the node should attempt to compute a path to the destination using the constraints of the original (received) explicit path excluding the failed/blocked node/link. The new path should be added to an LSP setup request as an explicit route and signaled. LSRs performing crankback rerouting should store all received crankback information for an LSP until the LSP is successfully established or until the node abandons its attempts to reroute the LSP. This allows it to combine crankback information from multiple failures when computing a new path. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 17]
Internet Draft March 2003 7.4.2 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. Both protocol-independent and protocol- dependent identifiers may be specified. Although a general identifier that is independent of other protocols is preferable, there are a couple of restrictions on its use as described in the following subsection. 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. 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 Flag on the LSP setup request must have been set to 0010 or 0100 (or both), which implies support for ABR or segment-based rerouting (hierarchical rerouting). In this draft, we specify routing protocol specific link and node identifiers for OSPFv2 for IPv4, IS-IS for IPv4, OSPF for IPv6, and IS-IS for IPv6. These identifiers may only be used if segment-based rerouting (hierarchical rerouting) is supported, as indicated by the Routing Behavior flag on the LSP setup request. If the link blockage occurs in the upstream direction because the downstream node has no resources available on that link, the downstream node can use the LSP setup request message-sender's IP address to generate an ER-TLV for the upstream node (it can use this generated ER-Hop TLV with the first ER-Hop TLV to identify the link). 7.4.3 Locating Errors within Loose or Abstract Nodes The explicit route on the original LSP setup request may contain a loose hop or an Abstract Node. In these cases, the crankback information may refer to links or nodes that were not in the original explicit route. In order to compute a new path, the repair point may need to identify the pair of hops (or nodes) in the explicit route between which the error/blockage occurred. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 18]
Internet Draft March 2003 To assist this, the crankback information reports the top two hops of the explicit route as received at the reporting node. The first hop will likely identify the node or the link, the second hop will identify a 'next' hop from the original explicit route. 7.4.4 When Rerouting Fails When a node cannot or chooses not to perform crankback rerouting it must forward the error response further upstream. However, when a node was responsible for expanding or replacing the explicit route as the LSP setup was processed it MUST update the crankback information with regard to the explicit route that it received. Only if this is done will the upstream nodes stand a chance of successfully routing around the problem. 7.5. Limiting Rerouting Attempts Each repair point should apply a locally configurable limit to the number of attempts it makes to reroute an LSP. This helps to prevent excessive network usage in the event of significant faults and allows back-off to other repair points which may have a better chance of routing around the problem. 7.5.1 New Status Codes for Rerouting A new status/error code is used to identify that a node has abandoned crankback rerouting because a it has reached a threshold for retry attempts. A node receiving an error response with this status code MAY also attempt crankback rerouting, but it is RECOMMENDED that such attempts be limited to the ingress LSR. 8. RSVP-TE Extensions for Crankback 8.1. Overview Crankback rerouting is appropriate for use with RSVP-TE. 1) Path establishment may fail because of an inability to route, perhaps because links are down. In this case a PathErr is returned to the initiator. 2) Path establishment may fail because resources are unavailable. This is particularly relevant in GMPLS where explicit label control may be in use. Again, a PathErr is returned to the initiator. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 19]
Internet Draft March 2003 3) Resource reservation may fail on the reverse path, as the Resv is processed, and resources are reserved. If resources are not available on the required link or at a specific node, a ResvErr message is returned to the egress node indicating "Admission Control failure" [RSVP]. The egress is allowed to change the Rspec and try again, but in the event that this is not practical or not supported, the egress 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. Note that in multi-area networks, the ResvErr might be intercepted and acted on at an area border router. 4) It is also possible to make resource reservations on the forward path as the Path message is processed. This choice is made in any 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". Crankback information would be useful to an upstream node (such as the ingress) if it is supplied on a PathErr or a Notify message that is sent upstream. 8.1.1 ResvErr Processing As described above, the resource allocation failure for RSVP-TE may occur on 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. However, it is the intention of RSVP is that such errors are propagated to the egress using a ResvErr message to allow the egress the option of re- issuing the Resv with different resource requirements (although not on an alternate path). This means that a PathErr with crankback information must not be issued as soon as the error is detected at a transit node, but that the crankback information must be encoded in the ResvErr and passed back to the egress for action. When a ResvErr carrying crankback information 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, and after all local recovery procedures have failed, it SHOULD generate a PathErr message carrying the crankback information and send it to the ingress LSR. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 20]
Internet Draft March 2003 If a ResvErr reports on more than one filter spec (because the Resv carried more than one filter spec) then only one set of crankback information should be present in the ResvErr and it should apply to all filter specs carried. In this case it may be necessary to generate more than one PathErr according to the normal rules of RSVP. 8.1.2 Notify Message Processing [GMPLS-RSVP] defines a new message, the Notify message, to enhance error reporting in RSVP-TE networks. The Notify message is sent to 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 of a failure an LSR that supports [GMPLS- RSVP] and the crankback extensions defined in this draft MAY choose to send a Notify message carrying crankback information. This would ensure a speedier report of the error to the ingress/egress LSRs and might make LSP restoration faster. 8.2. Indication of Rerouting Behavior The behavior specified by the Routing Flag of section 7.1 is achieved in RSVP-TE by a change to the LSP_TUNNEL Session Attribute Object. New values for the Flags field are defined. 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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 21]
Internet Draft March 2003 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 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 ABR (hierarchical) rerouting desired. This flag indicates the Area Border Router 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. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 22]
Internet Draft March 2003 0x20 Segment-based (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. 8.3. Rerouting Object We define a new object, the "Rerouting Object" (analogous to the "Rerouting TLV" defined for CR-LDP), to carry crankback information. The new object is added to the definition of the PathErr, ResvErr and Notify messages, specifying it as optional. The altered messages are defined as follows. Note that the forms used are from [GMPLS-RSVP] - the inclusion of [ <REROUTING> ] is equally applicable to standard RSVP-TE [RSVP-TE]. <PathErr message> ::= <Common Header> [ <INTEGRITY> ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ <MESSAGE_ID> ] <SESSION> <ERROR_SPEC> [ <ACCEPTABLE_LABEL_SET> ... ] [ <REROUTING> ] [ <POLICY_DATA> ...] [ <sender descriptor> ] <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ <MESSAGE_ID> ] <SESSION> <RSVP_HOP> <ERROR_SPEC> [ <SCOPE> ] [ <ACCEPTABLE_LABEL_SET> ... ] [ <REROUTING> ] [ <POLICY_DATA> ...] <STYLE> [ <error flow descriptor> ] <Notify message> ::= <Common Header> [ <INTEGRITY> ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] [ <MESSAGE_ID> ] <ERROR_SPEC> [ <REROUTING> ] <notify session list> Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 23]
Internet Draft March 2003 <notify session list> := [<notify session list>] <upstream notify session> | <downstream notify session> <upstream notify session> ::= <SESSION> [<ADMIN_STATUS> ] [ <POLICY_DATA>...] <sender descriptor> <downstream notify session> ::= <SESSION> [<POLICY_DATA>...] <flow descriptor list> 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 Node Rerouting Subobject These subobjects conform to the TLV formats described in section 5.3. 8.4. Error Values Error values for the Error Code "Admission Control Failure" are defined in [RSVP]. A new error value is defined for the error code "Routing Problem". "Rerouting limit exceeded indicates that rerouting has failed because the number of crankback rerouting attempts has gone beyond the predetermined threshold at an individual LSR. 8.5. Backward Compatibility It is recognized that not all nodes in an RSVP-TE network will 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. Class-Num = 11bbbbbb Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 24]
Internet Draft March 2003 The node should ignore the object but forward it, unexamined and unmodified, in all messages resulting from this message. 9. Routing Protocol Interactions If the routing-protocol-specific link or node identifiers are used in the Link TLV and Node TLV defined above, the 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 PathErr message with the Rerouting Object towards an ingress LSR, the 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 Object. The ingress LSR, upon receiving this 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. 10. LSP Restoration Considerations LSP restoration is performed to recover 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 a 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. 10.1. Upstream of the Fault When an LSR detects a fault on an adjacent downstream link or node, a PathErr message is sent upstream. In GMPLS this message may carry a state removal indication. Each LSR receiving the message then releases the corresponding LSP. (Note that if the state removal indication is not present on the PathErr message it is necessary for the ingress node to issue a PathTear message to cause the resources to be released.) If the failed LSP is expected to be restored at an upstream LSR, Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 25]
Internet Draft March 2003 the Rerouting Object with the location information of the failed link or node is included in the PathErr message. The ingress, intermediate area border LSR, or indeed any repair point permitted by the Rerouting Flags, that receives the PathErr message can terminate the message and then perform alternate routing. In a flat network without segmentation, when the ingress LSR receives the PathErr 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 Path message is sent over this path toward the egress LSR. In a network segmented into areas such as with hierarchical OSPF, the following procedures can be used. As explained in Section 8.2, the LSP restoration behavior is indicated in the Flags field of the Session Attributes object of the Path message. If the Flags indicate end-to- end rerouting, the PathErr message with the Rerouting object is returned all the way back to the ingress LSR, which may then issue a new Path message along another path, which is the same procedure as in the flat network case above. If the Flags field indicates ABR rerouting (hierarchical rerouting), the ingress area border LSR MAY terminate the PathErr message carrying the Rerouting object and then perform alternate routing within the area for which the area border LSR is the ingress LSR. If the Flags field indicates segment-based rerouting (hierarchical rerouting), any node MAY apply the procedures described above for ABR rerouting. 10.2. Downstream of the Fault On the downstream side of the failure, an LSR detecting the failure sends a PathTear for the LSP.. When a PathTear message is received at the egress of the LSP, it performs the normal processing. That is, it releases the LSP. An intermediate area border LSR receiving the PathTear message for an LSP that was setup with Flags field indicating ABR rerouting (hierarchical rerouting) can terminate the PathTear and wait until the new Path message for the LSP restoration is received. There is an inherent danger in this step, however, since it is possible that the LSP restoration will take a path that avoids this LSR, or even that the LSP restoration will not take place. If a node decides to absorb the PathTear in this way it is RECOMMENDED that the LSR run a local timer to tidy up and forward the PathTear in the event that it does not see the LSP restoration. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 26]
Internet Draft March 2003 If segment-based rerouting is indicated, any node receiving a PathTear MAY act as described for ABRs above. Otherwise, a node receiving a PathTear SHOULD release the resources associated with the LSP and forward the message downstream. 11. Security Considerations It should be noted that while the extensions in this draft introduce no new security holes in the protocols, should a malicious user gain protocol access to the network, the crankback information might be used to prevent establishment of valid LSPs. The implementation of rerouting attempt thresholds are particularly important in this context. 11.1. RSVP-TE The crankback routing extensions and procedures for LSP restoration as applied to RSVP-TE introduce no further new security considerations. Refer to [RSVP], [RSVP-TE] and [GMPLS-RSVP] for a description of applicable security considerations. 12. Acknowledgments We would like to thank Juha Heinanen and Srinivas Makam for their review and comments, and Zhi-Wei Lin for his considered opinions. Thanks, too, to John Drake for encouraging us to resurrect this draft and consider the use of the IF-ID ErrorSpec. 13. Normative References [RSVP] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC2205, September 1997. [RSVP-TE] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, December 2001. [GMPLS] P. Ashwood-Smith and L. Berger, et al., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003. [GMPLS-RSVP] L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473, January 2003. [OSPF] J. Moy, "OSPF Version 2", RFC2328, April 1998. [OSPF6] R. Coltun, et al., "OSPF for IPv6", RFC2740, December 1999. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 27]
Internet Draft March 2003 [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", draft-ietf-isis- ipv6-02.txt, April 2001 (work in progress). 14. Informational References [ASH1] G. Ash, "Traffic Engineering & QoS methods for IP-, ATM-, & TDM-Based Multiservice Networks", draft-ietf- tewg-qos-routing-04.txt, October 2001 (work in progress). [AWDUCHE1] D. Awduche, et al., "Requirements for Traffic Engineering Over MPLS", RFC2702, September 1999. [G8080] ITU-T Recommendation G.808/Y.1304, Architecture for the Automatically Switched Optical Network (ASON), November 2001. [LEE] C-Y. Lee, A. Farrel and S De Cnodder, "Exclude Routes - Extension to RSVP-TE", draft-lee-ccamp-rsvp-te-exclude- route-02.txt, March 2003 (work in progress). [MAKAM] V. Sharma, et al., "Framework for MPLS-based Recovery", RFC 3469, February 2003. [PNNI] ATM Forum, "Private Network-Network Interface Specification Version 1.0 (PNNI 1.0)", <af-pnni- 0055.000>, May 1996. [SHARMA] V. Sharma, et al., "An Assessment of QoS and Protection in MPLS", MPLS'99 Conference, June 1999. 15. Authors' Addresses Adrian Farrel (editor) Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Phone: +1-(703)-847-1867 Email: afarrel@movaz.com Atsushi Iwata NEC Corporation Networking 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: a-iwata@ah.jp.nec.com Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 28]
Internet Draft March 2003 Norihito Fujita NEC Corporation Networking 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@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 Simon Marshall-Unitt Data Connection Ltd. 100 Church Street Enfield, Middlesex EN2 6BQ, UK Phone: +44-(20)-8366-1177 Email: smu@dataconnection.com 16. Full Copyright Statement Copyright (c) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Iwata, et al. draft-iwata-mpls-crankback-05.txt [Page 29]