idnits 2.17.1 draft-ietf-ccamp-crankback-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1577. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2007) is 6303 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RC3473' is mentioned on line 202, but not defined == Missing Reference: 'RFC4373' is mentioned on line 537, but not defined == Missing Reference: 'RFC4201' is mentioned on line 918, but not defined == Unused Reference: 'G8080' is defined on line 1500, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Farrel (Editor) 2 Internet Draft Old Dog Consulting 3 Category: Standards Track 4 Expires: July 2007 A. Satyanarayana 5 Cisco Systems, Inc. 7 A. Iwata 8 N. Fujita 9 NEC Corporation 11 G. Ash 12 AT&T 14 January 2007 16 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE 17 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 In a distributed, constraint-based routing environment, the 45 information used to compute a path may be out of date. This means 46 that Multiprotocol Label Switching (MPLS) and Generalized MPLS 47 (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup 48 requests may be blocked by links or nodes without sufficient 49 resources. Crankback is a scheme whereby setup failure information is 50 returned from the point of failure to allow new setup attempts to be 51 made avoiding the blocked resources. Crankback can also be applied to 52 LSP recovery to indicate the location of the failed link or node. 54 This document specifies crankback signaling extensions for use in 55 MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to 56 RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in 57 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling 58 Functional Description", RFC3473. These extensions mean that the LSP 59 setup request can be retried on an alternate path that detours around 60 blocked links or nodes. This offers significant improvements in the 61 successful setup and recovery ratios for LSPs, especially in 62 situations where a large number of setup requests are triggered at 63 the same time. 65 Table of Contents 67 Section A : Problem Statement 69 1. Terminology......................................................3 70 1.1. Control Plane and Data Plane Separation........................3 71 2. Introduction and Framework.......................................4 72 2.1. Background.....................................................4 73 2.2. Repair and Recovery............................................5 74 2.3. Interaction with TE Flooding Mechanisms .......................6 75 3. Discussion: Explicit Versus Implicit Re-routing Indications......6 76 4. Required Operation...............................................7 77 4.1. Resource Failure or Unavailability.............................7 78 4.2. Computation of an Alternate Path...............................8 79 4.2.1 Information Required for Re-routing...........................8 80 4.2.2 Signaling a New Route.........................................9 81 4.3. Persistence of Error Information...............................9 82 4.4. Handling Re-route Failure.....................................10 83 4.5. Limiting Re-routing Attempts..................................10 84 5. Existing Protocol Support for Crankback Re-routing..............11 85 5.1. RSVP-TE ......................................................11 86 5.2. GMPLS-RSVP-TE ................................................12 88 Section B : Solution 90 6. Control of Crankback Operation..................................12 91 6.1. Requesting Crankback and Controlling In-Network Re-routing....12 92 6.2. Action on Detecting a Failure.................................13 93 6.3. Limiting Re-routing Attempts..................................13 94 6.3.1 New Status Codes for Re-routing..............................13 95 6.4. Protocol Control of Re-routing Behavior.......................14 96 7. Reporting Crankback Information.................................14 97 7.1. Required Information..........................................14 98 7.2. Protocol Extensions...........................................14 99 7.3 Guidance for Use of IF_ID Error Spec TLVs......................18 100 7.3.1 General Principles...........................................18 101 7.3.2 Error Report TLVs............................................19 102 7.3.3 Fundamental Crankback TLVs...................................19 103 7.3.4 Additional Crankback TLVs....................................20 104 7.3.5 Grouping TLVs by Failure Location............................21 105 7.3.6 Alternate Path identification................................22 106 7.4. Action on Receiving Crankback Information.....................22 107 7.4.1 Re-route Attempts............................................22 108 7.4.2 Location Identifiers of Blocked Links or Nodes...............23 109 7.4.3 Locating Errors within Loose or Abstract Nodes...............23 110 7.4.4 When Re-routing Fails........................................23 111 7.4.5 Aggregation of Crankback Information.........................24 112 7.5. Notification of Errors........................................24 113 7.5.1 ResvErr Processing...........................................24 114 7.5.2 Notify Message Processing....................................25 115 7.6. Error Values..................................................25 116 7.7. Backward Compatibility........................................25 117 8. LSP Recovery Considerations.....................................26 118 8.1. Upstream of the Fault.........................................26 119 8.2. Downstream of the Fault.......................................27 120 9. IANA Considerations.............................................27 121 9.1. Error Codes...................................................27 122 9.2. IF_ID_ERROR_SPEC TLVs.........................................27 123 9.3. LSP_ATTRIBUTES Object.........................................28 124 10. Security Considerations........................................28 125 11. Acknowledgments................................................29 126 12. Normative References...........................................30 127 13. Informational References.......................................30 128 14. Authors' Addresses.............................................31 129 A. Experience of Crankback in TDM-based Networks..................34 131 Section A : Problem Statement 133 1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 1.1. Control Plane and Data Plane Separation 141 Throughout this document the processes and techniques are described 142 as though the control plane and data plane elements that comprise a 143 Label Switching Router (LSR) are coresident and related in a 144 one-to-one manner. This is a convenience of documentation only. 146 It should be noted that GMPLS LSRs may be decomposed such that the 147 control plane components are not physically collocated. Further, one 148 presence in the control plane may control more than one LSR in the 149 data plane. These points have several consequences with respect to 150 this document: 152 o The nodes, links and resources that are reported as in error, are 153 data plane entities. 155 o The nodes, areas and ASs that report that they have attempted 156 re-routing, are control plane entities. 158 o Where a single control plane entity is responsible for more than 159 one data plane LSR, crankback signaling may be implicit in just 160 the same way as LSP establishment signaling may be. 162 The above points may be considered self-evident, but are stated 163 here for absolute clarity. 165 The stylistic convenience of referring to both the control plane 166 element responsible for a single LSR and the data plane component of 167 that LSR simply as "the LSR", should not be taken to mean that this 168 document is applicable only to a collocated one-to-one relationship. 169 Further, in the majority case the control plane and data plane 170 components are related in a 1:1 ratio and are usually collocated. 172 2. Introduction and Framework 174 2.1. Background 176 RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can be used for 177 establishing explicitly routed LSPs in an MPLS network. Using 178 RSVP-TE, resources can also be reserved along a path to guarantee 179 and/or control QoS for traffic carried on the LSP. To designate an 180 explicit path that satisfies QoS guarantees, it is necessary to 181 discern the resources available to each link or node in the network. 182 For the collection of such resource information, routing protocols, 183 such as OSPF and IS-IS , can be extended to distribute additional 184 state information [RFC2702]. 186 Explicit paths can be computed based on the distributed information 187 at the LSR (ingress) initiating an LSP and signaled as Explicit 188 Routes during LSP establishment. Explicit Routes may contain 'loose 189 hops' and 'abstract nodes' that convey routing through a collection 190 of nodes. This mechanism may be used to devolve parts of the path 191 computation to intermediate nodes such as area border LSRs. 193 In a distributed routing environment, however, the resource 194 information used to compute a constraint-based path may be out of 195 date. This means that a setup request may be blocked, for example, 196 because a link or node along the selected path has insufficient 197 resources. 199 In RSVP-TE, a blocked LSP setup may result in a PathErr message sent 200 to the ingress, or a ResvErr sent to the egress (terminator). 201 These messages may result in the LSP setup being abandoned. In 202 Generalized MPLS [RC3473] the Notify message may additionally be 203 used to expedite notification of failures of existing LSPs to ingress 204 and egress LSRs, or to a specific "repair point" - an LSR responsible 205 for performing protection or restoration. 207 These existing mechanisms provide a certain amount of information 208 about the path of the failed LSP. 210 Generalized MPLS [RFC3471] and [RFC3473] extends MPLS into networks 211 that manage Layer 2, TDM and lambda resources as well as packet 212 resources. Thus, crankback routing is also useful in GMPLS networks. 214 In a network without wavelength converters, setup requests are likely 215 to be blocked more often than in a conventional MPLS environment 216 because the same wavelength must be allocated at each Optical 217 Cross-Connect on an end-to-end explicit path. This makes crankback 218 routing all the more important in certain GMPLS networks. 220 2.2. Repair and Recovery 222 If the ingress LSR or intermediate area border LSR knows the location 223 of the blocked link or node, it can designate an alternate path and 224 then reissue the setup request. Determination of the identity of the 225 blocked link or node can be achieved by the mechanism known as 226 crankback routing [PNNI, ASH1]. In RSVP-TE, crankback signaling 227 requires notifying the upstream LSR of the location of the blocked 228 link or node. In some cases this requires more information than is 229 currently available in the signaling protocols. 231 On the other hand, various recovery schemes for link or node 232 failures have been proposed in [RFC3469] and include fast 233 re-routing. These schemes rely on the existence of a protecting LSP 234 to protect the working LSP, but if both the working and protecting 235 paths fail it is necessary to re-establish the LSP on an end-to-end 236 basis avoiding the known failures. Similarly, fast re-routing by 237 establishing a recovery path on demand after failure requires 238 computation of a new LSP that avoids the known failures. End-to-end 239 recovery for alternate routing requires the location of the failed 240 link or node. Crankback routing schemes could be used to notify the 241 upstream LSRs of the location of the failure. 243 Furthermore, in situations where many link or node failures occur at 244 the same time, the difference between the distributed routing 245 information and the real-time network state becomes much greater than 246 in normal LSP setups. LSP recovery might, therefore, be performed 247 with inaccurate information, which is likely to cause setup blocking. 248 Crankback routing could improve failure recovery in these situations. 250 The requirement for end-to-end allocation of lambda resources in 251 GMPLS networks without wavelength converters means that end-to-end 252 recovery may be the only way to recover from LSP failures. This is 253 because segment protection may be much harder to achieve in networks 254 of photonic cross-connects where a particular lambda may already be 255 in use on other links: End-to-end protection offers the choice of use 256 of another lambda, but this choice is not available in segment 257 protection. 259 This requirement makes crankback re-routing particularly useful in a 260 GMPLS network, in particular in dynamic LSP re-routing cases (no 261 protecting LSP pre-establishment). 263 2.3. Interaction with TE Flooding Mechanisms 265 GMPLS uses IGPs (OSPF and IS-IS) to flood traffic engineering (TE) 266 information that is used to construct a traffic engineering database 267 (TED) which acts as a data source for path computation. 269 Crankback signaling is not intended to supplement or replace the 270 normal operation of the TE flooding mechanism, since these mechanisms 271 are independent of each other. That is, information gathered from 272 crankback signaling may be applied to compute an alternate path for 273 the LSP for which the information was signaled, but the information 274 is not intended to be used to influence the computation of the paths 275 of other LSPs. 277 Any requirement to rapidly flood updates about resource availability 278 so that they may be applied as deltas to the TED and utilized in 279 future path computations are out of scope of this document. 281 3. Discussion: Explicit Versus Implicit Re-routing Indications 283 There have been problems in service provider networks when 284 "inferring" from indirect information that re-routing is allowed. 285 This document proposes the use of an explicit re-routing indication 286 that explicitly authorizes re-routing, and contrasts it with the 287 inferred or implicit re-routing indication that has previously 288 been used. 290 Various existing protocol options and exchanges including the error 291 values of PathErr message [RFC2205, RFC3209] and the Notify message 292 [RFC3473] allow an implementation to infer a situation where 293 re-routing can be performed. This allows for recovery from network 294 errors or resource contention. 296 However, such inference of recovery signaling is not always desirable 297 since it may be doomed to failure. For example, experience of using 298 release messages in TDM-based networks for analogous implicit and 299 explicit re-routing indications purposes provides some guidance. This 300 background information is given in Appendix A. 302 It is certainly the case that with topology information distribution 303 as performed with routing protocols such as OSPF, the ingress LSR 304 could infer the re-routing condition. However, convergence of 305 topology information using routing protocols is typically slower than 306 the expected LSP setup times. One of the reasons for crankback is to 307 avoid the overhead of available-link-bandwidth flooding, and to more 308 efficiently use local state information to direct alternate routing 309 at the path computation point. 311 [ASH1] shows how event-dependent-routing can just use crankback, and 312 not available-link-bandwidth flooding, to decide on the re-route path 313 in the network through "learning models". Reducing this flooding 314 reduces overhead and can lead to the ability to support much larger 315 AS sizes. 317 Therefore, the use of alternate routing should be based on an 318 explicit indication, and it is best to know the following information 319 separately: 321 - where blockage/congestion occurred 322 - whether alternate routing "should" be attempted. 324 4. Required Operation 326 Section 2 identifies some of the circumstances under which crankback 327 may be useful. Crankback routing is performed as described in the 328 following procedures, when an LSP setup request is blocked along the 329 path, or when an existing LSP fails. 331 4.1. Resource Failure or Unavailability 333 When an LSP setup request is blocked due to unavailable resources, an 334 error message response with the location identifier of the blockage 335 should be returned to the LSR initiating the LSP setup (ingress LSR), 336 the area border LSR, the AS border LSR, or to some other repair 337 point. 339 This error message carries an error specification according to 340 [RFC3209] - this indicates the cause of the error and the node/link 341 on which the error occurred. Crankback operation may require further 342 information as detailed in sections 4.2.1 and 7. 344 A repair point (for example, an ingress LSR) that receives crankback 345 information resulting from the failure of an established LSP may 346 apply local policy to govern how it attempts repair of the LSP. For 347 example, it may prioritise repair attempts between multiple LSPs that 348 have failed, and it may consider LSPs that have been locally repaired 349 ([RFC4090]) to be less urgent candidates for end-to-end repair. 350 Further, there is a likelihood that other LSRs are also attempting 351 LSP repair for LSPs affected by the same fault which may give rise to 352 resource contention within the network, so an LSR may stagger its 353 repair attempts in order to reduce the chance of resource contention. 355 4.2. Computation of an Alternate Path 357 In a flat network without partitioning of the routing topology, when 358 the ingress LSR receives the error message it computes an alternate 359 path around the blocked link or node to satisfy QoS guarantees using 360 link state information about the network. If an alternate path is 361 found, a new LSP setup request is sent over this path. 363 On the other hand, in a network partitioned into areas such as with 364 OSPF, the area border LSR may intercept and terminate the error 365 response, and perform alternate (re-)routing within the downstream 366 area. 368 In a third scenario, any node within an area may act as a repair 369 point. In this case, each LSR behaves much as an area border LSR as 370 described above. It can intercept and terminate the error response, 371 and perform alternate routing. This may be particularly useful where 372 domains of computation are applied within the (partitioned) network, 373 where such domains are not coincident on the routing partition 374 boundaries. However if, all nodes in the network perform re-routing 375 it is possible to spend excessive network and CPU resources on 376 re-routing attempts that would be better made only at designated 377 re-routing nodes. This scenario is somewhat like 'MPLS fast re-route' 378 [RFC4090], in which any node in the MPLS domain can establish 'local 379 repair' LSPs upon failure notification. 381 4.2.1 Information Required for Re-routing 383 In order to correctly compute a route that avoids the blocking 384 problem, a repair point LSR must gather as much crankback information 385 as possible. Ideally, the repair node will be given the node, link 386 and reason for the failure. 388 The reason for the failure may provide an important discriminator to 389 help decide what action should be taken. For example, a failure that 390 indicates "No Route to Destination" is likely to give rise to a new 391 path computation excluding the reporting LSR, but the reason 392 "Temporary Control Plane Congestion" might lead to a simple retry 393 after a suitable pause. 395 However, even this information may not be enough to help with 396 re-computation. Consider for instance an explicit route that contains 397 a non-explicit abstract node or a loose hop. In this case, the failed 398 node and link is not necessarily enough to tell the repair point 399 which hop in the explicit route has failed. The crankback information 400 needs to indicate where, within the explicit route, the problem has 401 occurred. 403 4.2.2 Signaling a New Route 405 If the crankback information can be used to compute a new route 406 avoiding the failed/blocking network resource, the route can be 407 signaled as an Explicit Route. 409 However, it may be that the repair point does not have sufficient 410 topology information to compute an Explicit Route that is guaranteed 411 to avoid the failed link or node. In this case, Route Exclusions 412 [EXCLUDE] may be particularly helpful. To achieve this, [EXCLUDE] 413 allows the crankback information to be presented as route exclusions 414 to force avoidance of the failed node, link or resource. 416 4.3. Persistence of Error Information 418 The repair point LSR that computes the alternate path should store 419 the location identifiers of the blockages indicated in the error 420 message until the LSP is successfully established by downstream LSRs 421 or until the repair point LSR abandons re-routing attempts. Since 423 crankback signaling information may be returned to the same repair 424 point LSR more than once while establishing a specific LSP, the 425 repair point LSR SHOULD maintain a history table of all experienced 426 blockages for this LSP (at least until the routing protocol updates 427 the state of this information) so that the resulting path 428 computation(s) can detour all blockages. 430 If a second error response is received by a repair point (while it is 431 performing crankback re-routing) it should update the history table 432 that lists all experienced blockages, and use the entire gathered 433 information when making a further re-routing attempt. 435 Note that the purpose of this history table is to correlate 436 information when repeated retry attempts are made by the same LSR. 437 For example, suppose that an attempt is made to route from A through 438 B, and B returns a failure with crankback information, an attempt may 439 be made to route from A through C, and this may also fail with the 440 return of crankback information - the next attempt SHOULD NOT be to 441 route from A through B, and this may be achieved by use of the 442 history table. 444 The history table can be discarded by the signaling controller for A 445 if the LSP is successfully established through A. The history table 446 MAY be retained after the signaling controller for A sends an error 447 upstream, however it is questionable what value this provides since a 448 future retry as a result of crankback re-routing should not attempt 449 to route through A. If the history information is retained for a 450 longer period it SHOULD be discarded after a local timeout has 451 expired. This timer is required so that the repair point does not 452 apply the history table to an attempt by the ingress to re-establish 453 a failed LSP, but to allow the history table to be available for use 454 in re-routing attempts before the ingress declares the LSP as failed. 456 It is RECOMMENDED that the repair point LSR discard the history table 457 using a timer no larger than the LSP retry timer configured on the 458 ingress LSR. The correlation of the timers between the ingress and 459 repair point LSRs is typically by manual configuration of timers 460 local to each LSR, and is outside the scope of this document. 462 It is not intended that the information in the history table be used 463 to supplement the TED for the computation of paths of other LSPs. 465 4.4. Handling Re-route Failure 467 Multiple blockages (for the same LSP) may occur, and successive setup 468 retry attempts may fail. Retaining error information from previous 469 attempts ensures that there is no thrashing of setup attempts, and 470 knowledge of the blockages increases with each attempt. 472 It may be that after several retries, a given repair point is unable 473 to compute a path to the destination (that is, the egress of the LSP) 474 that avoids all of the blockages. In this case, it must pass an 475 error indication message upstream. It is most useful to the upstream 476 nodes (and in particular to the ingress LSR) that may as repair 477 points for the LSP setup, if the error indication message identifies 478 all of the downstream blockages and also the repair point that was 479 unable to compute an alternate path. 481 4.5. Limiting Re-routing Attempts 483 It is important to prevent endless repetition of LSP setup attempts 484 using crankback routing information after error conditions are 485 signaled, or during periods of high congestion. It may also be useful 486 to reduce the number of retries, since failed retries will increase 487 setup latency and degrade performance by increasing the amount of 488 signaling processing and message exchanges within the network. 490 The maximum number of crankback re-routing attempts allowed may be 491 limited in a variety of ways. This document allows an LSR to limit 492 the retries per LSP, and assumes that such a limit will be applied 493 either as a per node configuration for those LSRs that are capable 494 of re-routing, or as a network-wide configuration value. 496 When the number of retries at a particular LSR is exceeded, the LSR 497 reports the failure in an upstream direction until it reaches the 498 next repair point where further re-routing attempts may be attempted, 499 or reaches the ingress which may act as a repair point or declare the 500 LSP as faioled. It is important that the crankback information 501 provided indicates that routing back through this node will not 502 succeed - this situation is similar to that in section 4.4. 504 5. Existing Protocol Support for Crankback Re-routing 506 Crankback re-routing is appropriate for use with RSVP-TE. 508 1) LSP establishment may fail because of an inability to route, 509 perhaps because links are down. In this case a PathErr message is 510 returned to the ingress. 512 2) LSP establishment may fail because resources are unavailable. 513 This is particularly relevant in GMPLS where explicit label 514 control may be in use. Again, a PathErr message is returned to the 515 ingress. 517 3) Resource reservation may fail during LSP establishment, as the 518 Resv is processed. If resources are not available on the required 519 link or at a specific node, a ResvErr message is returned to the 520 egress node indicating "Admission Control failure" [RFC2205]. The 521 egress is allowed to change the FLOWSPEC and try again, but in the 522 event that this is not practical or not supported (particularly in 523 the non-PSC context), the egress LSR may choose to take any one of 524 the following actions. 526 - Ignore the situation and allow recovery to happen through 527 Path refresh message and refresh timeout [RFC2205]. 529 - Send a PathErr message towards the ingress indicating 530 "Admission Control failure". 532 Note that in multi-area/AS networks, the ResvErr might be 533 intercepted and acted on at an area/AS border router. 535 4) It is also possible to make resource reservations on the forward 536 path as the Path message is processed. This choice is compatible 537 with LSP setup in GMPLS networks [RFC3471], [RFC4373]. In this 538 case if resources are not available, a PathErr message is returned 539 to ingress indicating "Admission Control failure". 541 Crankback information would be useful to an upstream node (such as 542 the ingress) if it is supplied on a PathErr or a Notify message that 543 is sent upstream. 545 5.1. RSVP-TE 547 In RSVP-TE a failed LSP setup attempt results in a PathErr message 548 returned upstream. The PathErr message carries an ERROR_SPEC object, 549 which indicates the node or interface reporting the error and the 550 reason for the failure. 552 Crankback re-routing can be performed explicitly avoiding the node 553 or interface reported. 555 5.2. GMPLS-RSVP-TE 557 GMPLS extends the error reporting described above by allowing LSRs to 558 report the interface that is in error in addition to the identity of 559 the node reporting the error. This further enhances the ability of a 560 re-computing node to route around the error. 562 GMPLS introduces a targeted Notify message that may be used to 563 report LSP failures direct to a selected node. This message carries 564 the same error reporting facilities as described above. The Notify 565 message may be used to expedite the propagation of error 566 notifications, but in a network that offers crankback routing at 567 multiple nodes there would need to be some agreement between LSRs 568 as to whether PathErr or Notify provides the stimulus for crankback 569 operation. This agreement is constrained by the re-routing behavior 570 selection (as listed in section 6.4). Otherwise, multiple nodes might 571 attempt to repair the LSP at the same time, because: 573 1) these messages can flow through different paths before 574 reaching the ingress LSR, and 576 2) the destination of the Notify message might not be the 577 ingress LSR. 579 Section B : Solution 581 6. Control of Crankback Operation 583 6.1. Requesting Crankback and Controlling In-Network Re-routing 585 When a request is made to set up an LSP tunnel, the ingress LSR 586 should specify whether it wants crankback information to be collected 587 in the event of a failure, and whether it requests re-routing 588 attempts by any or specific intermediate nodes. For this purpose, a 589 Re-routing Flag field is added to the protocol setup request 590 messages. The corresponding values are mutually exclusive. 592 No Re-routing The ingress node MAY attempt re-routing after 593 failure. Intermediate nodes SHOULD NOT attempt 594 re-routing after failure. Nodes detecting 595 failures MUST report an error and MAY supply 596 crankback information. This is the default 597 and backwards compatible option. 599 End-to-end Re-routing The ingress node MAY attempt re-routing after 600 failure. Intermediate nodes SHOULD NOT attempt 601 re-routing after failure. Nodes detecting 602 failures MUST report an error and SHOULD 603 supply crankback information. 605 Boundary Re-routing Intermediate nodes MAY attempt re-routing 606 after failure only if they are Area Border 607 Routers or AS Border Routers. The boundary 608 (ABR/ASBR) can either decide to forward the 609 error message upstream to the ingress 610 LSR or try to select another egress boundary 611 LSR. Other intermediate nodes SHOULD NOT 612 attempt re-routing. Nodes detecting failures 613 MUST report an error and SHOULD supply 614 crankback information. 616 Segment-based Re-routing 617 Any node MAY attempt re-routing after it 618 receives an error report and before it passes 619 the error report further upstream. Nodes 620 detecting failures MUST report an error and 621 SHOULD supply full crankback information. 622 6.2. Action on Detecting a Failure 624 A node that detects the failure to setup an LSP or the failure of an 625 established LSP SHOULD act according to the Re-routing Flag passed on 626 the LSP setup request. 628 If Segment-based Re-routing is allowed, or if Boundary Re-routing is 629 allowed and the detecting node is an ABR or ASBR, the detecting node 630 MAY immediately attempt to re-route. 632 If End-to-end Re-routing is indicated, or if Segment-based or 633 Boundary Re-routing is allowed and the detecting node chooses 634 not to make re-routing attempts (or has exhausted all possible 635 re-routing attempts), the detecting node MUST return a protocol 636 error indication and SHOULD include full crankback information. 638 6.3. Limiting Re-routing Attempts 640 Each repair point SHOULD apply a locally configurable limit to the 641 number of attempts it makes to re-route an LSP. This helps to prevent 642 excessive network usage in the event of significant faults, and 643 allows back-off to other repair points which may have a better chance 644 of routing around the problem. 646 6.3.1 New Status Codes for Re-routing 648 An error code/value of "Routing Problem"/"Re-routing limit exceeded" 649 (24/TBD) is used to identify that a node has abandoned crankback 650 re-routing because it has reached a threshold for retry attempts. 652 A node receiving an error response with this status code MAY also 653 attempt crankback re-routing, but it is RECOMMENDED that such 654 attempts be limited to the ingress LSR. 656 6.4. Protocol Control of Re-routing Behavior 658 The LSP_ATTRIBUTES object defined in [RFC4420] is used on Path 659 messages to convey the Re-Routing Flag described in section 5.1. 660 Three bits are defined for inclusion in the LSP Attributes TLV as 661 follows. The bit numbers below are suggested and actual values are 662 to be assigned by IANA. 664 Bit Name and Usage 665 Number 667 1 End-to-end re-routing desired. 668 This flag indicates the end-to-end re-routing behavior for an 669 LSP under establishment. This MAY also be used for specifying 670 the behavior of end-to-end LSP recovery for established LSPs. 672 2 Boundary re-routing desired. 673 This flag indicates the boundary re-routing behavior for an 674 LSP under establishment. This MAY also be used for specifying 675 the segment-based LSP recovery through nested crankback for 676 established LSPs. The boundary ABR/ASBR can either decide to 677 forward the PathErr message upstream to an upstream boundary 678 ABR/ASBR or to the ingress LSR. Alternatively, it can try to 679 select another egress boundary LSR. 681 3 Segment-based re-routing desired. 682 This flag indicates the segment-based re-routing behavior for 683 an LSP under establishment. This MAY also be used to specify 684 the segment-based LSP recovery for established LSPs. 686 7. Reporting Crankback Information 688 7.1. Required Information 690 As described above, full crankback information SHOULD indicate the 691 node, link and other resources, which have been attempted but have 692 failed because of allocation issues or network failure. 694 The default crankback information SHOULD include the interface and 695 the node address. 697 Any address reported in such crankback information SHOULD be an 698 address that was distributed by the routing protocols (OSPF and ISIS) 699 in their TE link state advertisements. However, some additional 700 information such as component link identifiers is additional to this. 702 7.2. Protocol Extensions 704 [RFC3473] defines an IF_ID ERROR_SPEC object that can be used on 705 PathErr, ResvErr and Notify messages to convey the information 706 carried in the Error Spec Object defined in [RFC3209]. Additionally, 707 the IF_ID ERROR_SPEC Object has scope for carrying TLVs that identify 708 the link associated with the error. 710 The TLVs for use with this object are defined in [RFC3471], and are 711 listed below. They are used to identify links in the IF_ID RSVP_HOP 713 Object, and in the IF_ID ERROR_SPEC object to identify the failed 714 resource which is usually the downstream resource from the reporting 715 node. 717 Type Length Format Description 718 -------------------------------------------------------------------- 719 1 8 IPv4 Addr. IPv4 (Interface address) 720 2 20 IPv6 Addr. IPv6 (Interface address) 721 3 12 Compound IF_INDEX (Interface index) 722 4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface) 723 5 12 Compound COMPONENT_IF_UPSTREAM (Component interface) 725 Note that TLVs 4 and 5 are obsoleted by [RFC4201] and SHOULD NOT be 726 used to identify component interfaces in IF_ID ERROR_SPEC objects. 728 In order to facilitate reporting of crankback information, the 729 following additional TLVs are defined. Note that the Type values 730 shown here are only suggested values - final values are TBD and to be 731 determined by IETF consensus. 733 Type Length Format Description 734 -------------------------------------------------------------------- 735 6 var See below DOWNSTREAM_LABEL (GMPLS label) 736 7 var See below UPSTREAM_LABEL (GMPLS label) 737 8 8 See below NODE_ID (TE Router ID) 738 9 x See below OSPF_AREA (Area ID) 739 10 x See below ISIS_AREA (Area ID) 740 11 8 See below AUTONOMOUS_SYSTEM (Autonomous system) 741 12 var See below ERO_CONTEXT (ERO subobject) 742 13 var See below ERO_NEXT_CONTEXT (ERO subobjects) 743 14 8 IPv4 Addr. PREVIOUS_HOP_IPv4 (Node address) 744 15 20 IPv6 Addr. PREVIOUS_HOP_IPv6 (Node address) 745 16 8 IPv4 Addr. INCOMING_IPv4 (Interface address) 746 17 20 IPv6 Addr. INCOMING_IPv6 (Interface address) 747 18 12 Compound INCOMING_IF_INDEX (Interface index) 748 19 var See below INCOMING_DOWN_LABEL (GMPLS label) 749 20 var See below INCOMING_UP_LABEL (GMPLS label) 750 21 8 See below REPORTING_NODE_ID (Router ID) 751 22 x See below REPORTING_OSPF_AREA (Area ID) 752 23 x See below REPORTING_ISIS_AREA (Area ID) 753 24 8 See below REPORTING_AS (Autonomous system) 754 25 var See below PROPOSED_ERO (ERO subobjects) 755 26 var See below NODE_EXCLUSIONS (List of nodes) 756 27 var See below LINK_EXCLUSIONS (List of interfaces) 758 For types 1, 2 and 3 the format of the Value field is already defined 759 in [RFC3471]. 761 For types 14 and 16, they format of the Value field is the same as 762 for type 1. 764 For types 15 and 17, the format of the Value field is the same as for 765 type 2. 767 For type 18 the format of the Value field is the same as for type 3. 769 For types 6, 7, 19 and 20 the length field is variable and the Value 770 field is a label as defined in [RFC3471]. As with all uses of labels, 771 it is assumed that any node that can process the label information 772 knows the syntax and semantics of the label from the context. Note 773 that all TLVs are zero-padded to a multiple four octets so that if a 774 label is not itself a multiple of four octets it must be 775 disambiguated from the trailing zero pads by knowledge derived from 776 the context. 778 For types 8 and 21 the Value field has the format: 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Router ID | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Router ID: 32 bits 788 The TE Router ID (TLV type 8) or the Router ID (TLV type 21) 789 used to identify the node within the IGP. 791 For types 9 and 22 the Value field has the format: 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | OSPF Area Identifier | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 OSPF Area Identifier 801 The 4-octet area identifier for the node. This identifies the 802 area where the failure has occurred. 804 For types 10 and 23 the Value field has the format: 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Length | ISIS Area Identifier | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 ~ ISIS Area Identifier (continued) ~ 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 Length 816 Length of the actual (non-padded) IS-IS Area Identifier in 817 octets. Valid values are from 2 to 11 inclusive. 819 ISIS Area Identifier 821 The variable-length IS-IS area identifier. Padded with 822 trailing zeroes to a four-octet boundary. 824 For types 11 and 24 the Value field has the format: 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Autonomous System Number | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Autonomous System Number: 32 bits 834 The AS Number of the associated Autonomous System. Note that 835 if 16-bit AS numbers are in use, the low order bits (16 836 through 31) should be used and the high order bits (0 through 837 15) should be set to zero. 839 For types 12, 13 and 25 the Value field has the format: 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | | 845 ~ ERO Subobjects ~ 846 | | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 ERO Subobjects: 851 A sequence of ERO subobjects. Any ERO subobjects are allowed 852 whether defined in [RFC3209], [RFC3473] or other documents. 853 Note that ERO subobjects contain their own types and lengths. 855 For type 26 the Value field has the format: 857 0 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | | 861 ~ Node Identifiers ~ 862 | | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Node Identifiers: 867 A sequence of TLVs as defined here of types 1, 2 or 8 that 868 indicates downstream nodes that have already participated in 869 crankback attempts and have been declared unusable for the 870 current LSP setup attempt. Note that an interface identifier 871 may be used to identify a node. 873 For type 27 the Value field has the format: 875 0 1 2 3 876 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 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | | 879 ~ Link Identifiers ~ 880 | | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 Link Identifiers: 885 A sequence of TLVs as defined here of the same format as type 886 1, 2 or 3 TLVs that indicate incoming interfaces at downstream 887 nodes that have already participated in crankback attempts and 888 have been declared unusable for the current LSP setup attempt. 890 7.3 Guidance for Use of IF_ID ERROR_SPEC TLVs 892 7.3.1 General Principles 894 If crankback is not being used, inclusion of an IF-ID ERROR_SPEC 895 object in PathErr, ResvErr and Notify messages follows the processing 896 rules defined in [RFC3473] and [RFC4201]. A sender MAY include 897 additional TLVs of types 6 through 27 to report crankback information 898 for informational/monitoring purposes. 900 If crankback is being used, the sender of a PathErr, ResvErr or 901 Notify message MUST use the IF_ID ERROR_SPEC object and MUST include 902 at least one of the TLVs in the range 1 through 3 as described in 903 [RFC3473], [RFC4201], and the previous paragraph. Additional TLVs 904 SHOULD also be included to report further information. The following 905 section gives advice on which TLVs should be used under different 906 circumstances, and which TLVs must be supported by LSRs. 908 Note that all such additional TLVs are optional and MAY be omitted. 909 Inclusion of the optional TLVs SHOULD be performed where doing so 910 helps to facilitate error reporting and crankback. The TLVs fall into 911 three categories: those that are essential to report the error, those 912 that provide additional information that is or may be fundamental to 913 the utility of crankback, and those that provide additional 914 information that may be useful for crankback in some circumstances. 916 Note that all LSRs MUST be prepared to receive and forward any TLV as 917 per [RFC3473]. This includes TLVs of type 4 or 5 as defined in 918 [RFC3473] and obsoleted by [RFC4201]. There is, however, no 919 requirement for an LSR to actively process any but the TLVs defined 920 in [RFC3473]. An LSR that proposes to perform crankback re-routing 921 SHOULD support receipt and processing of all of the fundamental 922 crankback TLVs, and is RECOMMENDED to support the receipt and 923 processing of the additional crankback TLVs. 925 It should be noted, however, that some assumptions about the TLVs 926 that will be used MAY be made based on the deployment scenarios. For 927 example, a router that is deployed in a single-area network does not 928 need to support the receipt and processing of TLV types 22 and 23. 929 Those TLVs might be inserted in an IF_ID ERROR_SPEC object, but would 930 not need to be processed by the receiver of a PathErr message. 932 7.3.2 Error Report TLVs 934 Error Report TLVs are those in the range 1 through 3. (Note that 935 the obsoleted TLVs 4 and 5 may be considered in this category, but 936 SHOULD NOT be used.) 938 As stated above, when crankback information is reported, the IF_ID 939 ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is 940 used, at least one of the TLVs in the range 1 through 3 MUST be 941 present. The choice of which TLV to use will be dependent on the 942 circumstance of the error and device capabilities. For example, a 943 device that does not support IPv6 will not need the ability to create 944 a TLV of type 2. Note, however, that such a device MUST still be 945 prepared to receive and process all error report TLVs. 947 7.3.3 Fundamental Crankback TLVs 949 Many of the TLVs report the specific resource that has failed. For 950 example, TLV type 1 can be used to report that the setup attempt was 951 blocked by some form of resource failure on a specific interface 952 identified by the IP address supplied. TLVs in this category are 1 953 through 11, although TLVs 4 and 5 may be considered to be excluded 954 from this category by dint of having been obsoleted. 956 These TLVs SHOULD be supplied whenever the node detecting and 957 reporting the failure with crankback information has the information 958 available. (Note that some of these TLVs MUST be included as 959 described in the previous two sections.) 961 The TLVs of type 8, 9, 10 and 11 MAY, however, be omitted according 962 to local policy and relevance of the information. 964 7.3.4 Additional Crankback TLVs 966 Some TLVs help to locate the fault within the context of the path of 967 the LSP that was being set up. TLVs of types 12, 13, 14 and 15 help 968 to set the context of the error within the scope of an explicit path 969 that has loose hops or non-precise abstract nodes. The ERO context 970 information is not always a requirement, but a node may notice that 971 it is a member of the next hop in the ERO (such as a loose or 972 non-specific abstract node) and deduce that its upstream neighbor may 973 have selected the path using next hop routing. In this case, 974 providing the ERO context will be useful to the upstream node that 975 performs re-routing. 977 Note the distinction between TLVs 12 and 13 is the distinction 978 between "this is the hop I was trying to satisfy when I failed" and 979 "this is the next hop I was trying to reach when I failed. 981 Reporting nodes SHOULD also supply TLVs from the range 12 through 20 982 as appropriate for reporting the error. The reporting nodes MAY also 983 supply TLVs from the range 21 through 27. 985 Note that in deciding whether a TLV in the range 12 through 20 "is 986 appropriate", the reporting node should consider amongst other 987 things, whether the information is pertinent to the cause of the 988 failure. For example, when a cross-connection fails it may be that 989 the outgoing interface is faulted, in which case only the interface 990 (for example, TLV type 1) needs to be reported, but if the problem is 991 that the incoming interface cannot be connected to the outgoing 992 interface because of temporary or permanent cross-connect 993 limitations, the node should also include reference to the incoming 994 interface (for example, TLV type 16). 996 Four TLVs (21, 22, 23 and 24) allow the location of the reporting 997 node to be expanded upon. These TLVs would not be included if the 998 information is not of use within the local system, but might be 999 added by ABRs relaying the error. Note that the Reporting Node ID 1000 (TLV 21) need not be included if the IP address of the reporting 1001 node as indicated in the ERROR_SPEC itself, is sufficient to fully 1002 identify the node. 1004 The last three TLVs (25, 26, and 27) provide additional information 1005 for recomputation points. The reporting node (or some node forwarding 1006 the error) MAY make suggestions about how the error could have been 1007 avoided, for example by supplying a partial ERO that would cause the 1008 LSP to be successfully set up if it were used. As the error 1009 propagates back upstream and as crankback routing is attempted and 1010 fails, it is beneficial to collect lists of failed nodes and links so 1011 that they will not be included in further computations performed at 1012 upstream nodes. These lists may also be factored into route 1013 exclusions [EXCLUDE]. 1015 Note that there is no ordering requirement on any of the TLVs within 1016 the IF_ID Error Spec, and no implication should be drawn from the 1017 ordering of the TLVs in a received IF_ID Error Spec. 1019 The decision of precisely which TLV types a reporting node includes 1020 is dependent on the specific capabilities of the node, and is 1021 outside the scope of this document. 1023 7.3.5 Grouping TLVs by Failure Location 1025 Further guidance as to the inclusion of crankback TLVs can be given 1026 by grouping the TLVs according to the location of the failure and the 1027 context within which it is reported. For example, a TLV that reports 1028 an area identifier would only need to be included as the crankback 1029 error report transits an area boundary. 1031 Resource Failure 1032 6 DOWNSTREAM_LABEL 1033 7 UPSTREAM_LABEL 1034 Interface failures 1035 1 IPv4 1036 2 IPv6 1037 3 IF_INDEX 1038 4 COMPONENT_IF_DOWNSTREAM (obsoleted) 1039 5 COMPONENT_IF_UPSTREAM (obsoleted) 1040 12 ERO_CONTEXT 1041 13 ERO_NEXT_CONTEXT 1042 14 PREVIOUS_HOP_IPv4 1043 15 PREVIOUS_HOP_IPv6 1044 16 INCOMING_IPv4 1045 17 INCOMING_IPv6 1046 18 INCOMING_IF_INDEX 1047 19 INCOMING_DOWN_LABEL 1048 20 INCOMING_UP_LABEL 1049 Node failures 1050 8 NODE_ID 1051 21 REPORTING_NODE_ID 1052 Area failures 1053 9 OSPF_AREA 1054 10 ISIS_AREA 1055 22 REPORTING_OSPF_AREA 1056 23 REPORTING_ISIS_AREA 1057 25 PROPOSED_ERO 1058 26 NODE_EXCLUSIONS 1059 27 LINK_EXCLUSIONS 1060 AS failures 1061 11 AUTONOMOUS_SYSTEM 1062 24 REPORTING_AS 1064 Although discussion of aggregation of crankback information is out of 1065 the scope of this document, it should be noted that this topic is 1066 closely aligned to the information presented here. Aggregation is 1067 discussed further in section 7.4.5. 1069 7.3.6 Alternate Path Identification 1071 No new object is used to distinguish between Path/Resv messages for 1072 an alternate LSP. Thus, the alternate LSP uses the same SESSION and 1073 SENDER_TEMPLATE/FILTER_SPEC objects as the ones used for the initial 1074 LSP under re-routing. 1076 7.4. Action on Receiving Crankback Information 1078 7.4.1 Re-route Attempts 1080 As described in section 3, a node receiving crankback information in 1081 a PathErr must first check to see whether it is allowed to perform 1082 re-routing. This is indicated by the Re-routing Flags in the 1083 LSP_ATTRIBUTES object during LSP setup request. 1085 If a node is not allowed to perform re-routing it should forward the 1086 PathErr message, or if it is the ingress report the LSP as having 1087 failed. 1089 If re-routing is allowed, the node should attempt to compute a path 1090 to the destination using the original (received) explicit path and 1091 excluding the failed/blocked node/link. The new path should be added 1092 to an LSP setup request as an explicit route and signaled. 1094 LSRs performing crankback re-routing should store all received 1095 crankback information for an LSP until the LSP is successfully 1096 established or until the node abandons its attempts to re-route the 1097 LSP. On the next crankback re-routing path computation attempt, the 1098 LSR should exclude all the failed nodes and links and resources 1099 reported from previous attempts. 1101 It is an implementation decision whether the crankback information is 1102 discarded immediately upon successful LSP establishment or retained 1103 for a period in case the LSP fails. 1105 7.4.2 Location Identifiers of Blocked Links or Nodes 1107 In order to compute an alternate path by crankback re-routing, it is 1108 necessary to identify the blocked links or nodes and their locations. 1109 The common identifier of each link or node in an MPLS network should 1110 be specified. Both protocol-independent and protocol-dependent 1111 identifiers may be specified. Although a general identifier that is 1112 independent of other protocols is preferable, there are a couple of 1113 restrictions on its use as described in the following subsection. 1115 In link state protocols such as OSPF and IS-IS, each link and node 1116 in a network can be uniquely identified. For example, by the context 1117 of a TE Router ID and the Link ID. If the topology and resource 1118 information obtained by OSPF advertisements is used to compute a 1119 constraint-based path, the location of a blockage can be represented 1120 by such identifiers. 1122 Note that, when the routing-protocol-specific link identifiers are 1123 used, the Re-routing Flag on the LSP setup request must have been set 1124 to show support for boundary or segment-based re-routing. 1126 In this document, we specify routing protocol specific link and node 1127 identifiers for OSPFv2, OSPFv3, and IS-IS for IPv4 and IPv6. These 1128 identifiers may only be used if segment-based re-routing is 1129 supported, as indicated by the Routing Behavior flag on the LSP setup 1130 request. 1132 7.4.3 Locating Errors within Loose or Abstract Nodes 1134 The explicit route on the original LSP setup request may contain a 1135 loose or an Abstract Node. In these cases, the crankback information 1136 may refer to links or nodes that were not in the original explicit 1137 route. 1139 In order to compute a new path, the repair point may need to identify 1140 the pair of hops (or nodes) in the explicit route between which the 1141 error/blockage occurred. 1143 To assist this, the crankback information reports the top two hops of 1144 the explicit route as received at the reporting node. The first hop 1145 will likely identify the node or the link, the second hop will 1146 identify a 'next' hop from the original explicit route. 1148 7.4.4 When Re-routing Fails 1150 When a node cannot or chooses not to perform crankback re-routing it 1151 must forward the PathErr message further upstream. 1153 However, when a node was responsible for expanding or replacing the 1154 explicit route as the LSP setup was processed it MUST update the 1155 crankback information with regard to the explicit route that it 1156 received. Only if this is done will the upstream nodes stand a 1157 chance of successfully routing around the problem. 1159 7.4.5 Aggregation of Crankback Information 1161 When a setup blocking error or an error in an established LSP occurs 1162 and crankback information is sent in an error notification message, 1163 some node upstream may choose to attempt crankback re-routing. If 1164 that node's attempts at re-routing fail the node will accumulate a 1165 set of failure information. When the node gives up it MUST propagate 1166 the failure message further upstream and include crankback 1167 information when it does so. 1169 Including a full list of all failures that have occurred due to 1170 multiple crankback failures by multiple repair point LSRs downstream 1171 could lead to too much information signaled using the protocol 1172 extensions described in this document. A compression mechanism for 1173 such information is available using TLVs 26 and 27. These TLVs allow 1174 for a more concise accumulation of failure information as crankback 1175 failures are propagated upstream. 1177 Aggregation may involve reporting all links from a node as unusable 1178 by flagging the node as unusable, flagging an ABR as unusable when 1179 there is no downstream path available, or including a TLV of type 9 1180 which results in the exclusion of the entire area, and so on. The 1181 precise details of how aggregation of crankback information is 1182 performed are beyond the scope of this document. 1184 7.5. Notification of Errors 1186 7.5.1 ResvErr Processing 1188 As described above, the resource allocation failure for RSVP-TE may 1189 occur on the reverse path when the Resv message is being processed. 1190 In this case, it is still useful to return the received crankback 1191 information to the ingress LSR. However, when the egress LSR receives 1192 the ResvErr message, per [RFC2205] it still has the option of 1193 re-issuing the Resv with different resource requirements (although 1194 not on an alternate path). 1196 When a ResvErr carrying crankback information is received at an 1197 egress LSR, the egress LSR MAY ignore this object and perform the 1198 same actions as for any other ResvErr. However, if the egress LSR 1199 supports the crankback extensions defined in this document, and after 1200 all local recovery procedures have failed, it SHOULD generate a 1201 PathErr message carrying the crankback information and send it to the 1202 ingress LSR. 1204 If a ResvErr reports on more than one FILTER_SPEC (because the Resv 1205 carried more than one FILTER_SPEC) then only one set of crankback 1206 information should be present in the ResvErr and it should apply to 1207 all FILTER_SPEC carried. In this case, it may be necessary per 1208 [RFC2205] to generate more than one PathErr. 1210 7.5.2 Notify Message Processing 1212 [RFC3473] defines the Notify message to enhance error reporting in 1213 RSVP-TE networks. This message is not intended to replace the PathErr 1214 and ResvErr messages. The Notify message is sent to addresses 1215 requested on the Path and Resv messages. These addresses could (but 1216 need not) identify the ingress and egress LSRs respectively. 1218 When a network error occurs, such as the failure of link hardware, 1219 the LSRs that detect the error MAY send Notify messages to the 1220 requested addresses. The type of error that causes a Notify message 1221 to be sent is an implementation detail. 1223 In the event of a failure, an LSR that supports [RFC3473] and the 1224 crankback extensions defined in this document MAY choose to send a 1225 Notify message carrying crankback information. This would ensure a 1226 speedier report of the error to the ingress/egress LSRs. 1228 7.6. Error Values 1230 Error values for the Error Code "Admission Control Failure" are 1231 defined in [RFC2205]. Error values for the error code "Routing 1232 Problem" are defined in [RFC3209] and [RFC3473]. 1234 A new error value is defined for the error code "Routing Problem". 1235 "Re-routing limit exceeded" indicates that re-routing has failed 1236 because the number of crankback re-routing attempts has gone beyond 1237 the predetermined threshold at an individual LSR. 1239 7.7. Backward Compatibility 1241 It is recognized that not all nodes in an RSVP-TE network will 1242 support the extensions defined in this document. It is important 1243 that an LSR that does not support these extensions can continue to 1244 process a PathErr, ResvErr or Notify message even if it carries the 1245 newly defined IF_ID ERROR_SPEC information (TLVs). 1247 This document introduces no backward compatibility issues provided 1248 that existing implementations conform to the TLV processing rules 1249 defined in [RFC3471] and [RFC3473]. 1251 8. LSP Recovery Considerations 1253 LSP recovery is performed to recover an established LSP when a 1254 failure occurs along the path. In the case of LSP recovery, the 1255 extensions for crankback re-routing explained above can be applied 1256 for improving performance. This section gives an example of applying 1257 the above extensions to LSP recovery. The goal of this example is 1258 to give a general overview of how this might work, and not to give a 1259 detailed procedure for LSP recovery. 1261 Although there are several techniques for LSP recovery, this 1262 section explains the case of on-demand LSP recovery, which 1263 attempts to set up a new LSP on demand after detecting an LSP 1264 failure. 1266 8.1. Upstream of the Fault 1268 When an LSR detects a fault on an adjacent downstream link or node, 1269 a PathErr message is sent upstream. In GMPLS, the ERROR_SPEC object 1270 may carry a Path_State_Remove_Flag indication. Each LSR receiving the 1271 message then releases the corresponding LSP. (Note that if the state 1272 removal indication is not present on the PathErr message, the ingress 1273 node MUST issue a PathTear message to cause the resources to be 1274 released.) If the failed LSP has to be recovered at an upstream LSR, 1275 the IF_ID ERROR SPEC that includes the location information of the 1276 failed link or node is included in the PathErr message. The ingress, 1277 intermediate area border LSR, or indeed any repair point permitted by 1278 the Re-routing Flags, that receives the PathErr message can terminate 1279 the message and then perform alternate routing. 1281 In a flat network, when the ingress LSR receives the PathErr message 1282 with the IF_ID ERROR_SPEC TLVs, it computes an alternate path around 1283 the blocked link or node satisfying the QoS guarantees. If an 1284 alternate path is found, a new Path message is sent over this path 1285 toward the egress LSR. 1287 In a network segmented into areas, the following procedures can be 1288 used. As explained in Section 6.4, the LSP recovery behavior is 1289 indicated in the Flags field of the LSP_ATTRIBUTES object of the 1290 Path message. If the Flags indicate "End-to-end re-routing", the 1291 PathErr message is returned all the way back to the ingress LSR, 1292 which may then issue a new Path message along another path, which is 1293 the same procedure as in the flat network case above. 1295 If the Flags field indicates Boundary re-routing, the ingress area 1296 border LSR MAY terminate the PathErr message and then perform 1297 alternate routing within the area for which the area border LSR is 1298 the ingress LSR. 1300 If the Flags field indicates segment-based re-routing, any node MAY 1301 apply the procedures described above for Boundary re-routing. 1303 8.2. Downstream of the Fault 1305 This section only applies to errors that occur after an LSP has been 1306 established. Note that an LSR that generates a PathErr with 1307 Path_State_Remove Flag SHOULD also send a PathTear downstream to 1308 clean up the LSP. 1310 A node that detects a fault and is downstream of the fault MAY send 1311 a PathErr and/or Notify message containing an IF_ID ERROR SPEC that 1312 includes the location information of the failed link or node, and MAY 1313 send a PathTear to clean up the LSP at all other downstream nodes. 1315 However, if the reservation style for the LSP is Shared Explicit (SE) 1316 the detecting LSR MAY choose not to send a PathTear - this leaves the 1317 downstream LSP state in place and facilitates make-before-break 1318 repair of the LSP re-utilizing downstream resources. Note that if the 1319 detecting node does not send a PathTear immediately then unused sate 1320 will timeout according to the normal rules of [RFC2205]. 1322 At a well-known merge point, an ABR or an ASBR, a similar decision 1323 might also be made so as to better facilitate make-before-break 1324 repair. In this case a received PathTear might be 'absorbed' and not 1325 propagated further downstream for an LSP that has SE reservation 1326 style. Note, however, that this is a divergence from the protocol and 1327 might severely impact normal tear-down of LSPs. 1329 9. IANA Considerations 1331 9.1 Error Codes 1333 IANA maintains a registry called "RSVP Parameters" with a subregistry 1334 called "Error Codes and Globally-Defined Error Value Sub-Codes". This 1335 subregistry includes the RSVP-TE "Routing Problem" error code that is 1336 defined in [RFC3209]. 1338 IANA is requested to assign a new error value for the "Routing 1339 Problem" error code as follows: 1341 17 Re-routing limit exceeded. 1343 The value of 17 is suggested and is for confirmation by IANA. 1345 9.2 IF_ID_ERROR_SPEC TLVs 1347 The IF_ID_ERROR_SPEC TLV type values defined in [RFC3471] 1348 are maintained by IANA in the "Interface_ID Types" sub-registry of 1349 the "GMPLS Signaling Parameters" registry. 1351 IANA is requested to make new assignments from this subregistry for 1352 the new TLV types defined in Section 7.2 of this document. 1354 The text 'see below' may be replaced by 'see RFC' within the 1355 subregistry to give a clear reference to the location of the 1356 definition of the TLV format. 1358 9.3 LSP_ATTRIBUTES Object 1360 IANA maintains an "RSVP TE Parameters" registry with an "Attributes 1361 Flags" subregistry. IANA is requested to make three new allocations 1362 from this registry as listed in Section 6.4. 1364 These bits are defined for inclusion in the LSP Attributes TLV of 1365 the LSP_ATTRIBUTES. The values shown are suggested and are for 1366 confirmation by IANA. 1368 10. Security Considerations 1370 The RSVP-TE trust model assumes that RSVP-TE neighbors and peers 1371 trust each other to exchange ligitimate and non-malicious messages. 1372 This assumption is necessary in order that the signaling protocol can 1373 function. 1375 Note that this trust model is assumed to cascade. That is, if an LSR 1376 trusts its neighbors, it extends this trust to all LSRs that its 1378 neighbor trusts. This means that the trust model is usually applied 1379 across the whole network to create a trust domain. 1381 Authentication of neighbor identity is already a standard provision 1382 of RSVP-TE, as is the protection of messages against tampering and 1383 spoofing. Refer to [RFC2205], [RFC3209], and [RFC3473] for a 1384 description of applicable security considerations. These 1385 considerations and mechanisms are applicable to hop-by-hop message 1386 exchanges (such as used for crankback propagation on PathErr 1387 messages) and directed message exchanges (such as used for crankback 1388 propagation on Notify messages). 1390 Key management may also be used with RSVP-TE to help to protect 1391 against impersonation and also against message content falsification. 1392 This requires the maintenance, exchange, and configuration of keys on 1393 each LSR. Note that such maintenance may be especially onerous to 1394 operators, hence it is important to limit the number of keys while 1395 ensuring the required level of security. 1397 This document does not introduce any protocol elements or message 1398 exchanges that change the operation of RSVP-TE security. 1400 However, it should be noted that crankback is envisaged as an 1401 inter-domain mechanism, and as such it is likely that crankback 1402 information is exchanged over trust domain borders. In these cases 1403 it is expected that the information from within a neighboring 1404 domain would be of little or no value to the node performing 1405 crankback re-routing and would be ignored. In any case, it is highly 1406 likely that the reporting domain will have applied some form of 1407 information aggregation in order to preserve the confirentiality of 1408 its network topology. 1410 The issue of a direct attack by one domain upon another domain is 1411 possible and domain administrators should apply policies to protect 1412 their domains against the results of another domain attempting to 1413 thrash LSPs by allowing them to set up before reporting them as 1414 failed. On the whole, it is expected that commercial contracts 1415 between trust domains will provide a degree of protection. 1417 A more serious threat might arise if a domain reports that neither it 1418 nor its downstream neighbor can provide a path to the destination. 1419 Such a report could be bogus in that the reporting domain might not 1420 have allowed the downstream domain the chance to attempt to provide a 1421 path. (Note that the same problem does not arise for nodes within a 1422 domain because of the trust model.) This type of malicious behavior 1423 is hard to overcome, but may be detected by use of indirect path 1424 computation requests send direct to the falsely reported domain using 1425 mechanisms such as the Path Computation Element [RFC4655]. 1427 Note that a separate document describing inter-domain MPLS and GMPLS 1428 security considerations will be produced. 1430 Finally, it should be noted that while the extensions in this 1431 document introduce no new security holes in the protocols, should a 1432 malicious user gain protocol access to the network, the crankback 1433 information might be used to prevent establishment of valid LSPs. 1434 Thus, the existing security features available in RSVP-TE should be 1435 carefully considered by all deployers and SHOULD be made available by 1436 all implementations that offer cranback. Note that the implementation 1437 of re-routing attempt thresholds are also particularly useful in this 1438 context. 1440 11. Acknowledgments 1442 We would like to thank Juha Heinanen and Srinivas Makam for their 1443 review and comments, and Zhi-Wei Lin for his considered opinions. 1444 Thanks, too, to John Drake for encouraging us to resurrect this 1445 document and consider the use of the IF_ID ERROR SPEC object. Thanks 1446 for a welcome and very thorough review by Dimitri Papadimitriou. 1448 Stephen Shew made useful comments for clarification through the 1449 ITU-T liaison process. 1451 Simon Marshall-Unitt made contributions to this draft. 1453 SecDir review was provided by Tero Kivinen. Thanks to Ross Callon for 1454 useful discussions of prioritization of crankback re-routing 1455 attempts. 1457 12. Normative References 1459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1460 Requirement Levels", BCP 14, RFC 2119, March 1997. 1462 [RFC2205] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) 1463 Version 1 Functional Specification", RFC2205, September 1464 1997. 1466 [RFC3209] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 1467 Tunnels", RFC3209, December 2001. 1469 [RFC3471] P. Ashwood-Smith and L. Berger, et al., "Generalized 1470 MPLS - Signaling Functional Description", RFC 3471, 1471 January 2003. 1473 [RFC3473] L. Berger, et al., "Generalized MPLS Signaling - RSVP-TE 1474 Extensions", RFC 3473, January 2003. 1476 [RFC4420] Farrel, A., et al, "Encoding of Attributes for 1477 Multiprotocol Label Switching (MPLS) Label Switched Path 1478 (LSP) Establishment Using RSVP-TE", RFC 4420, February 1479 2006. 1481 13. Informational References 1483 [ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS 1484 Routing & Related Traffic Engineering Methods for IP-, 1485 ATM-, & TDM-Based Multiservice Networks", May, 2002. 1487 [RFC2702] D. Awduche, et al., "Requirements for Traffic 1488 Engineering Over MPLS", RFC2702, September 1999. 1490 [RFC3469] V. Sharma, et al., "Framework for MPLS-based Recovery", 1491 RFC 3469, February 2003. 1493 [RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 1494 for LSP Tunnels", RFC 4090, May 2005. 1496 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1497 Computation Element (PCE)-Based Architecture", RFC 4655, 1498 August 2006. 1500 [G8080] ITU-T Recommendation G.808/Y.1304, Architecture for the 1501 Automatically Switched Optical Network (ASON), November 1502 2001. For information on the availability of this 1503 document, please see http://www.itu.int. 1505 [EXCLUDE] C-Y. Lee, A. Farrel and S. De Cnodder, "Exclude Routes - 1506 Extension to RSVP-TE", 1507 draft-ietf-ccamp-rsvp-te-exclude-route, work in 1508 progress. 1510 [PNNI] ATM Forum, "Private Network-Network Interface 1511 Specification Version 1.0 (PNNI 1.0)", 1512 , May 1996. 1514 14. Authors' Addresses 1516 Adrian Farrel (Editor) 1517 Old Dog Consulting 1518 Phone: +44 (0) 1978 860944 1519 EMail: adrian@olddog.co.uk 1521 Arun Satyanarayana 1522 Cisco Systems, Inc. 1523 170 West Tasman Dr. 1524 San Jose, CA 95134 1525 Phone: +1 408 853-3206 1526 Email: asatyana@cisco.com 1528 Atsushi Iwata 1529 NEC Corporation 1530 System Platforms Research Laboratories 1531 1753 Shimonumabe Nakahara-ku, 1532 Kawasaki, Kanagawa, 211-8666, JAPAN 1533 Phone: +81-(44)-396-2744 1534 Fax: +81-(44)-431-7612 1535 E-Mail: a-iwata@ah.jp.nec.com 1537 Norihito Fujita 1538 NEC Corporation 1539 System Platforms Research Laboratories 1540 1753 Shimonumabe Nakahara-ku, 1541 Kawasaki, Kanagawa, 211-8666, JAPAN 1542 Phone: +81-(44)-396-2091 1543 Fax: +81-(44)-431-7644 1544 E-Mail: n-fujita@bk.jp.nec.com 1545 Gerald R. Ash 1546 AT&T 1547 Room MT D5-2A01 1548 200 Laurel Avenue 1549 Middletown, NJ 07748, USA 1550 Phone: (+1) 732-420-4578 1551 Fax: (+1) 732-368-8659 1553 EMail: gash@att.com 1555 Intellectual Property Statement 1557 The IETF takes no position regarding the validity or scope of any 1558 Intellectual Property Rights or other rights that might be claimed to 1559 pertain to the implementation or use of the technology described in 1560 this document or the extent to which any license under such rights 1561 might or might not be available; nor does it represent that it has 1562 made any independent effort to identify any such rights. Information 1563 on the procedures with respect to rights in RFC documents can be 1564 found in BCP 78 and BCP 79. 1566 Copies of IPR disclosures made to the IETF Secretariat and any 1567 assurances of licenses to be made available, or the result of an 1568 attempt made to obtain a general license or permission for the use of 1569 such proprietary rights by implementers or users of this 1570 specification can be obtained from the IETF on-line IPR repository at 1571 http://www.ietf.org/ipr. 1573 The IETF invites any interested party to bring to its attention any 1574 copyrights, patents or patent applications, or other proprietary 1575 rights that may cover technology that may be required to implement 1576 this standard. Please address the information to the IETF at ietf- 1577 ipr@ietf.org. 1579 Disclaimer of Validity 1581 This document and the information contained herein are provided on an 1582 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1583 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1584 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1585 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1586 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1589 Full Copyright Statement 1591 Copyright (C) The IETF Trust (2007). 1593 This document is subject to the rights, licenses and restrictions 1594 contained in BCP 78, and except as set forth therein, the authors 1595 retain all their rights. 1597 Appendix A. Experience of Crankback in TDM-based Networks 1599 Experience of using release messages in TDM-based networks for 1600 analogous repair and re-routing purposes provides some guidance. 1602 One can use the receipt of a release message with a cause value (CV) 1603 indicating "link congestion" to trigger a re-routing attempt at the 1604 originating node. However, this sometimes leads to problems. 1606 *--------------------* *-----------------* 1607 | | | | 1608 | N2 ----------- N3-|--|----- AT--- EO2 | 1609 | | | \| | / | | 1610 | | | |--|- / | | 1611 | | | | | \/ | | 1612 | | | | | /\ | | 1613 | | | |--|- \ | | 1614 | | | /| | \ | | 1615 | N1 ----------- N4-|--|----- EO1 | 1616 | | | | 1617 *--------------------* *-----------------* 1618 A-1 A-2 1620 Figure 1. Example of network topology 1622 Figure 1 illustrates four examples based on service-provider 1623 experiences with respect to crankback (i.e., explicit indication) 1624 versus implicit indication through a release with CV. In this 1625 example, N1, N2,N3, and N4 are located in one area (A-1), and AT, 1626 EO1, and EO2 are in another area (A-2). 1628 Note that two distinct areas are used in this example to expose the 1629 issues clearly. In fact, the issues are not limited to multi-area 1630 networks, but arise whenever path computation is distributed 1631 throughout the network. For example where loose routes, AS routes or 1632 path computation domains are used. 1634 1. A connection request from node N1 to EO1 may route to N4 and then 1635 find "all circuits busy". N4 returns a release message to N1 with 1636 CV34 indicating all circuits busy. Normally, a node such as N1 is 1637 programmed to block a connection request when receiving CV34, 1638 although there is good reason to try to alternate route the 1639 connection request via N2 and N3. 1641 Some service providers have implemented a technique called route 1642 advance (RA), where if a node that is RA capable receives a 1643 release message with CV34, it will use this as an implicit 1644 re-route indication and try to find an alternate route for the 1645 connection request if possible. In this example, alternate route 1646 N1-N2-N3-EO1 can be tried and may well succeed. 1648 2. Suppose a connection request goes from N2 to N3 to AT trying to 1649 reach EO2 and is blocked at link AT-EO2. Node AT returns a CV34 1650 and with RA, N2 may try to re-route N2-N1-N4-AT-EO2, but of 1651 course this fails again. The problem is that N2 does not realize 1652 where this blocking occurred based on the CV34, and in this case 1653 there is no point in further alternate routing. 1655 3. However, in another case of a connection request from N2 to E02, 1656 suppose that link N3-AT is blocked. In this case N3 should return 1657 crankback information (and not CV34) so that N2 can alternate 1658 route to N1-N4-AT-EO2, which may well be successful. 1660 4. In a final example, for a connection request from EO1 to N2, EO1 1661 first tries to route the connection request directly to N3. 1662 However, node N3 may reject the connection request even if there 1663 is bandwidth available on link N3-EO1 (perhaps for priority 1664 routing considerations, e.g., reserving bandwidth for high 1665 priority connection requests). However, when N3 returns CV34 in 1666 the release message, EO1 blocks the connection request (a normal 1667 response to CV34 especially if E01-N4 is already known blocked) 1668 rather than trying to alternate route through AT-N3-N2, which 1669 might be successful. If N3 returns crankback information, EO1 1670 could respond by trying the alternate route. 1672 It is certainly the case that with topology exchange, such as OSPF, 1673 the ingress LSR could infer the re-routing condition. However, 1674 convergence of routing information is typically slower than the 1675 expected LSP setup times. One of the reasons for crankback is to 1676 avoid the overhead of available-link-bandwidth flooding, and to more 1677 efficiently use local state information to direct alternate routing 1678 at the ingress-LSR. 1680 [ASH1] shows how event-dependent-routing can just use crankback, 1681 and not available-link-bandwidth flooding, to decide on the 1682 re-route path in the network through "learning models". Reducing 1683 this flooding reduces overhead and can lead to the ability to 1684 support much larger AS sizes. 1686 Therefore, the alternate routing should be indicated based on 1687 an explicit indication (as in examples 3 and 4), and it is best 1688 to know the following information separately: 1690 a) where blockage/congestion occurred (as in examples 1-2), 1692 and 1694 b) whether alternate routing "should" be attempted even if 1695 there is no "blockage" (as in example 4).