RFC 4920
Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE 🦋
Part 1 of 8, bestie! 💖 This RFC is about what happens when an LSP setup gets blocked and needs to try again somewhere else. Super important stuff 😭
Okay so the title block first: this is from the Network Working Group, published July 2007 as a Standards Track document, which means it's a real standard. A. Farrel (Ed.) of Old Dog Consulting is the editor, and A. Satyanarayana of Cisco Systems, Inc., A. Iwata and N. Fujita of NEC Corporation, and G. Ash of AT&T are the other authors. The header doesn't list anything it obsoletes or updates. 🌸
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 💅
Copyright Notice ©️
Copyright (C) The IETF Trust (2007). 🌈
Abstract ✨
Okay so here's the core problem 👀 In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. That means Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests can get blocked by links or nodes that don't have enough resources. 😩
Crankback is the fix: setup failure information gets sent back from the point of failure, so new setup attempts can avoid the blocked resources. It's giving rescue energy 🫶 Crankback can also be applied to LSP recovery, to show where the failed link or node is.
This document specifies crankback signaling extensions for MPLS signaling using RSVP-TE, as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and for GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. With these extensions, the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. That's a huge glow-up for successful setup and recovery ratios, especially when a bunch of setup requests get triggered at the same time 🔥
Table of Contents 🗂️
Section A: Problem Statement
1. Introduction and Framework ......................................4
1.1. Background .................................................4
1.2. Control Plane and Data Plane Separation ....................5
1.3. Repair and Recovery ........................................5
1.4. Interaction with TE Flooding Mechanisms ....................6
1.5. Terminology ................................................7
2. Discussion: Explicit versus Implicit Re-Routing Indications .....7
3. Required Operation ..............................................8
3.1. Resource Failure or Unavailability .........................8
3.2. Computation of an Alternate Path ...........................8
3.2.1. Information Required for Re-Routing .................9
3.2.2. Signaling a New Route ...............................9
3.3. Persistence of Error Information ..........................10
3.4. Handling Re-Route Failure .................................11
3.5. Limiting Re-Routing Attempts ..............................11
4. Existing Protocol Support for Crankback Re-Routing .............11
4.1. RSVP-TE ...................................................12
4.2. GMPLS-RSVP-TE .............................................13
Section B: Solution
5. Control of Crankback Operation .................................13
5.1. Requesting Crankback and Controlling In-Network
Re-Routing ................................................13
5.2. Action on Detecting a Failure .............................14
5.3. Limiting Re-Routing Attempts ..............................14
5.3.1. New Status Codes for Re-Routing ....................15
5.4. Protocol Control of Re-Routing Behavior ...................15
6. Reporting Crankback Information ................................15
6.1. Required Information ......................................15
6.2. Protocol Extensions .......................................16
6.3. Guidance for Use of IF_ID ERROR_SPEC TLVs .................20
6.3.1. General Principles .................................20
6.3.2. Error Report TLVs ..................................21
6.3.3. Fundamental Crankback TLVs .........................21
6.3.4. Additional Crankback TLVs ..........................22
6.3.5. Grouping TLVs by Failure Location ..................23
6.3.6. Alternate Path Identification ......................24
6.4. Action on Receiving Crankback Information .................25
6.4.1. Re-Route Attempts ..................................25
6.4.2. Location Identifiers of Blocked Links or Nodes .....25
6.4.3. Locating Errors within Loose or Abstract Nodes .....26
6.4.4. When Re-Routing Fails ..............................26
6.4.5. Aggregation of Crankback Information ...............26
6.5. Notification of Errors ....................................27
6.5.1. ResvErr Processing .................................27
6.5.2. Notify Message Processing ..........................28
6.6. Error Values ..............................................28
6.7. Backward Compatibility ....................................28
7. LSP Recovery Considerations ....................................29
7.1. Upstream of the Fault .....................................29
7.2. Downstream of the Fault ...................................30
8. IANA Considerations ............................................30
8.1. Error Codes ...............................................30
8.2. IF_ID_ERROR_SPEC TLVs .....................................31
8.3. LSP_ATTRIBUTES Object .....................................31
9. Security Considerations ........................................31
10. Acknowledgments ...............................................32
11. References ....................................................33
11.1. Normative References .....................................33
11.2. Informative References ...................................33
Appendix A.........................................................35Section A: Problem Statement 🎀
1. Introduction and Framework 🌸
1.1. Background
Okay so, RSVP-TE (RSVP Extensions for LSP Tunnels) [RFC3209] can set up explicitly routed LSPs in an MPLS network. With RSVP-TE, you can also reserve resources along a path to guarantee and/or control QoS for the traffic carried on the LSP. To pick an explicit path that meets Quality of Service (QoS) guarantees, you need to know what resources each link or node has available. To collect that resource information, routing protocols like OSPF and Intermediate System to Intermediate System (IS-IS) can be extended to distribute additional state information [RFC2702]. 📊
Explicit paths can be computed from the distributed information at the LSR (ingress) that starts an LSP, and then signaled as Explicit Routes during LSP establishment. Explicit Routes can include 'loose hops' and 'abstract nodes', which stand for routing through a collection of nodes. This mechanism may be used to hand off parts of the path computation to intermediate nodes, such as area border LSRs. 🧚
In a distributed routing environment, though, the resource information used to compute a constraint-based path can be out of date. So a setup request might get blocked, for example, because a link or node along the selected path doesn't have enough resources. 😤
In RSVP-TE, a blocked LSP setup may result in a PathErr message sent to the ingress, or a ResvErr sent to the egress (terminator). These messages may result in the LSP setup being abandoned. In Generalized MPLS [RFC3473], the Notify message may also be used to speed up notification of failures on existing LSPs to ingress and egress LSRs, or to a specific "repair point" -- an LSR responsible for performing protection or restoration. 🚨
These existing mechanisms give you a certain amount of information about the path of the failed LSP. 🔍
Generalized MPLS [RFC3471] and [RFC3473] extends MPLS into networks that manage Layer 2, TDM and lambda resources as well as packet resources. So crankback routing is useful in GMPLS networks too! 🌈
In a network without wavelength converters, setup requests are more likely to get blocked than in a conventional MPLS environment, because the same wavelength must be allocated at each Optical Cross-Connect on an end-to-end explicit path. This makes crankback routing even more important in certain GMPLS networks. 💜
1.2. Control Plane and Data Plane Separation
Throughout this document, the processes and techniques are described as though the control plane and data plane elements that make up a Label Switching Router (LSR) coreside and are related in a one-to-one manner. This is only for the convenience of documentation. 📝
It should be noted that GMPLS LSRs may be decomposed so that the control plane components are not physically collocated. Furthermore, one presence in the control plane may control more than one LSR in the data plane. These points have several consequences for this document:
- The nodes, links, and resources that are reported as errors are data plane entities.
- The nodes, areas, and Autonomous Systems (ASs) that report that they have attempted re-routing are control plane entities.
- Where a single control plane entity is responsible for more than one data plane LSR, crankback signaling may be implicit in just the same way as LSP establishment signaling may be.
The above points may be considered self-evident, but they are stated here for absolute clarity. 🙈
The stylistic convenience of referring to both the control plane element responsible for a single LSR and the data plane component of that LSR simply as "the LSR" should not be taken to mean that this document is only applicable to a collocated one-to-one relationship. Also, in the majority of cases, the control plane and data plane components are related in a 1:1 ratio and are usually collocated. 💖
Part 2 is next, so stay tuned 🦋
1.3. Repair and Recovery
okay so if the ingress LSR or an intermediate area border LSR knows where the blocked link or node is, it can designate an alternate path and then reissue the setup request 🦋. Figuring out which link or node is blocked can be done with the mechanism known as crankback routing [PNNI, ASH1]. In RSVP-TE, crankback signaling means notifying the upstream LSR of where the blocked link or node is 💅. Sometimes that takes more info than the signaling protocols currently have, ngl 🙈.
On the flip side, various recovery schemes for link or node failures have been proposed in [RFC3469], and they include fast re-routing ✨. These schemes rely on a protecting LSP existing to protect the working LSP, but if both the working and protecting paths fail, the LSP has to be re-established end-to-end, avoiding the known failures 😭. Fast re-routing by establishing a recovery path on demand after a failure is the same deal: it needs a new LSP computed that avoids the known failures. End-to-end recovery for alternate routing needs the location of the failed link or node, and crankback routing schemes could be used to notify the upstream LSRs of where the failure is 🫶.
Furthermore, when a bunch of link or node failures happen at the same time, the gap between the distributed routing info and the real-time network state gets way bigger than in normal LSP setups 💀. So LSP recovery might be performed with inaccurate info, which is likely to cause setup blocking. Crankback routing could improve failure recovery in these situations 🌈.
The requirement for end-to-end allocation of lambda resources in GMPLS networks without wavelength converters means that end-to-end recovery may be the only way to recover from LSP failures 👑. Why? Segment protection may be much harder to achieve in networks of photonic cross-connects, where a particular lambda may already be in use on other links. End-to-end protection offers the choice of using another lambda, but this choice is not available in segment protection 💜.
This requirement makes crankback re-routing particularly useful in a GMPLS network, especially in dynamic LSP re-routing cases (i.e., when there is no pre-establishment of the protecting LSP) 🍓.
1.4. Interaction with TE Flooding Mechanisms
GMPLS uses Interior Gateway Protocols (IGPs) (OSPF and IS-IS) to flood traffic engineering (TE) info, which builds a traffic engineering database (TED). The TED acts as the data source for path computation 🧚.
Crankback signaling is not meant to supplement or replace the normal operation of the TE flooding mechanism, since these mechanisms are independent of each other 🎀. So info gathered from crankback signaling may be applied to compute an alternate path for the LSP it was signaled for, but it is not meant to influence the computation of paths for other LSPs.
Any requirement to rapidly flood updates about resource availability so they can be applied as deltas to the TED and used in future path computations is out of scope for this document 📝.
1.5. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. Discussion: Explicit versus Implicit Re-Routing Indications
there have been problems in service provider networks when "inferring" from indirect info that re-routing is allowed 🙃. This document proposes the use of an explicit re-routing indication that authorizes re-routing, and contrasts it with the inferred or implicit re-routing indication that has previously been used ✨.
Various existing protocol options and exchanges, including the error values of PathErr messages [RFC2205, RFC3209] and the Notify message [RFC3473], allow an implementation to infer a situation where re-routing can be performed. This allows for recovery from network errors or resource contention 🫶.
However, inferring recovery signaling is not always desirable, since it may be doomed to failure 💀. For example, experience with release messages in TDM-based networks, for analogous implicit and explicit re-routing indications purposes, provides some guidance. This background information is given in Appendix A 📚.
It is certainly the case that with topology information distribution, as performed with routing protocols such as OSPF, the ingress LSR could infer the re-routing condition. However, convergence of topology info using routing protocols is typically slower than the expected LSP setup times 🐢. One of the reasons for crankback is to avoid the overhead of available-link-bandwidth flooding, and to more efficiently use local state info to direct alternate routing to the path computation point 💅.
[ASH1] shows how event-dependent-routing can just use crankback, and not available-link-bandwidth flooding, to decide on the re-route path in the network through "learning models" 🧠. Reducing this flooding reduces overhead and can lead to the ability to support much larger AS sizes 🌸.
Therefore, the use of alternate routing should be based on an explicit indication, and it is best to know the following info separately:
- where blockage/congestion occurred.
- whether alternate routing "should" be attempted.
3. Required Operation
Section 1 identifies some of the circumstances under which crankback may be useful 👀. Crankback routing is performed as described in the following procedures, when an LSP setup request is blocked along the path or when an existing LSP fails.
3.1. Resource Failure or Unavailability
When an LSP setup request is blocked due to unavailable resources, an error message response with the location identifier of the blockage should be returned to the LSR initiating the LSP setup (ingress LSR), the area border LSR, the AS border LSR, or some other repair point 📮.
This error message carries an error specification according to [RFC3209]. It indicates the cause of the error and the node/link on which the error occurred 🔍. Crankback operation may require further information as detailed in Sections 3.2.1 and 6.
A repair point (for example, an ingress LSR) that receives crankback info resulting from the failure of an established LSP may apply local policy to govern how it attempts repair of the LSP 🎯. For example, it may prioritize repair attempts between multiple LSPs that have failed, and it may consider LSPs that have been locally repaired ([RFC4090]) to be less urgent candidates for end-to-end repair. Furthermore, there is a likelihood that other LSRs are also attempting LSP repair for LSPs affected by the same fault, which may give rise to resource contention within the network. So an LSR may stagger its repair attempts in order to reduce the chance of resource contention ⏳.
3.2. Computation of an Alternate Path
In a flat network without partitioning of the routing topology, when the ingress LSR receives the error message, it computes an alternate path around the blocked link or node to satisfy QoS guarantees, using link state info about the network 🗺️. If an alternate path is found, a new LSP setup request is sent over this path.
On the other hand, in a network partitioned into areas, such as with OSPF, the area border LSR may intercept and terminate the error response, and perform alternate (re-)routing within the downstream area 🧩.
In a third scenario, any node within an area may act as a repair point. In this case, each LSR behaves much like an area border LSR as described above. It can intercept and terminate the error response and perform alternate routing 🦋. This may be particularly useful where domains of computation are applied within the (partitioned) network, where such domains are not coincident on the routing partition boundaries. However, if all nodes in the network perform re-routing, it is possible to spend excessive network and CPU resources on re-routing attempts that would be better made only at designated re-routing nodes 😩. This scenario is somewhat like 'MPLS fast re-route' [RFC4090], in which any node in the MPLS domain can establish 'local repair' LSPs upon failure notification.
3.2.1. Information Required for Re-Routing
In order to correctly compute a route that avoids the blocking problem, a repair point LSR must gather as much crankback info as possible 🕵️♀️. Ideally, the repair node will be given the node, link, and reason for the failure.
The reason for the failure may provide an important discriminator to help decide what action should be taken 🚦. For example, a failure that indicates "No Route to Destination" is likely to give rise to a new path computation excluding the reporting LSR, but the reason "Temporary Control Plane Congestion" might lead to a simple retry after a suitable pause ⏸️.
However, even this info may not be enough to help with re-computation. Consider, for instance, an explicit route that contains a non-explicit abstract node or a loose hop. In this case, the failed node and link are not necessarily enough to tell the repair point which hop in the explicit route has failed 🤯. The crankback info needs to indicate where, within the explicit route, the problem has occurred.
3.2.2. Signaling a New Route
If the crankback info can be used to compute a new route avoiding the failed/blocking network resource, the route can be signaled as an Explicit Route ✅.
However, the repair point may not have sufficient topology info to compute an Explicit Route that is guaranteed to avoid the failed link or node. In this case, Route Exclusions [RFC4874] may be particularly helpful. To achieve this, [RFC4874] allows the crankback info to be presented as route exclusions, to force avoidance of the failed node, link, or resource 🚧.
3.3. Persistence of Error Information ✨
okay bestie, so the repair point LSR that works out the alternate path should store the location identifiers of the blockages from the error message 📝 until the downstream LSRs successfully set up the LSP, or until the repair point LSR gives up on re-routing attempts. 💅
crankback signaling info can come back to the same repair point LSR more than once while it's setting up one LSP, so the repair point LSR SHOULD maintain a history table of every blockage it has experienced for this LSP. Keep it at least until the routing protocol updates the state of this info, so the path computations can detour ALL the blockages. 🧠
if a second error response reaches a repair point while it's doing crankback re-routing, it should update the history table of experienced blockages and use the whole gathered info for its next re-routing attempt. 🔥
the whole point of this history table is to connect the dots when the same LSR keeps retrying. 🔗 say A tries to route through B, and B sends back a failure with crankback info. then A tries through C, and that also fails with crankback info. the next attempt SHOULD NOT go through B again, and the history table is how A remembers that. 🙈
the signaling controller for A can throw the history table away once the LSP gets set up through A. 🎉 it MAY keep the table after the signaling controller for A sends an error upstream, but honestly the value is questionable, since a future retry from crankback re-routing should not try to route through A anyway. 🤷♀️ if the history info sticks around for longer, it SHOULD be discarded once a local timeout expires. this timer is required so the repair point doesn't apply the history table to an attempt by the ingress to re-establish a failed LSP. the table should still be available for re-routing attempts before the ingress declares the LSP failed. ⏰
It is RECOMMENDED that the repair point LSR discard the history table using a timer no larger than the LSP retry timer configured on the ingress LSR. 💖
the timers between the ingress and the repair point LSRs usually line up through manual configuration of timers local to each LSR. that part is outside the scope of this document, so it's not our problem here. 🙃
and just to be clear, the info in the history table is not meant to supplement the TED when computing paths for other LSPs. 🚫
3.4. Handling Re-Route Failure 🌸
multiple blockages (for the same LSP) can happen, and retry attempts can fail more than once. 😩 keeping error info from earlier attempts stops setup attempts from thrashing, and the knowledge about blockages grows with every try. 📈
it can happen that after several retries, a repair point still can't compute a path to the destination (aka the egress of the LSP) that dodges all the blockages. 💀 in that case, it must pass an error indication message upstream. the upstream nodes (especially the ingress LSR) that might be repair points for the LSP setup get the most out of it if that message lists ALL the downstream blockages AND the repair point that couldn't find an alternate path. 🗺️
3.5. Limiting Re-Routing Attempts 🛑
it's super important to stop LSP setup attempts from repeating forever with crankback routing info after errors get signaled, or during periods of high congestion. 🚨 reducing the number of retries also helps, because failed retries pile on setup latency and drag down performance with extra signaling processing and message exchanges across the network. 🐢
the max number of crankback re-routing attempts can be limited in a bunch of ways. this document lets an LSR limit the retries per LSP, and it assumes that limit gets applied either as a per-node configuration for the LSRs that can re-route, or as a network-wide configuration value. 🎀
when a particular LSR runs out of retries, it reports the failure upstream until it hits the next repair point where more re-routing attempts may be tried. or it reaches the ingress, which can act as a repair point or declare the LSP failed. 🧚 it's important that the crankback info provided says routing back through this node will not succeed. this situation is similar to the one in Section 3.4. 💜
4. Existing Protocol Support for Crankback Re-Routing ✨
crankback re-routing fits right in with RSVP-TE. 🦋 here's how LSP establishment can go sideways:
- LSP establishment can fail because it can't route, maybe because links are down. in that case, a PathErr message gets sent back to the ingress. 🔌
- LSP establishment can fail because resources are unavailable. this is especially relevant in GMPLS, where explicit label control might be in use. again, a PathErr message goes back to the ingress. 🏷️
- resource reservation can fail during LSP establishment, as the Resv is processed. if resources aren't available on the required link or at a specific node, a ResvErr message goes back to the egress node, saying "Admission Control failure" [RFC2205]. the egress is allowed to change the FLOWSPEC and try again. but if that isn't practical or supported (especially in the non-PSC context), the egress LSR can pick any one of these actions:
- ignore the situation and let recovery happen through Path refresh message and refresh timeout [RFC2205]. 😌
- send a PathErr message towards the ingress saying "Admission Control failure". 📮
heads up that in multi-area/AS networks, the ResvErr might get intercepted and acted on at an area/AS border router. 👀
- it's also possible to make resource reservations on the forward path as the Path message is processed. this choice works with LSP setup in GMPLS networks [RFC3471], [RFC3473]. in this case, if resources aren't available, a PathErr message goes back to the ingress saying "Admission Control failure". 🚫
crankback info would be super useful to an upstream node (like the ingress) if it's sent upstream on a PathErr or a Notify message. 💅
4.1. RSVP-TE 🍓
in RSVP-TE, a failed LSP setup attempt sends a PathErr message back upstream. 📬 the PathErr message carries an ERROR_SPEC object, which says which node or interface reported the error and why it failed. 🔍
crankback re-routing can be done explicitly, steering around the node or interface that got reported. 🛣️
4.2. GMPLS-RSVP-TE 🌈
GMPLS builds on the error reporting above by letting LSRs report the interface that's in error, on top of the identity of the node reporting it. ✨ that makes it way easier for a re-computing node to route around the problem. 🧠
GMPLS also introduces a targeted Notify message, which can report LSP failures directly to a selected node. 🎯 it carries the same error reporting facilities as described above. the Notify message can speed up the spread of error notifications, but in a network where crankback routing happens at multiple nodes, the LSRs need some agreement on whether PathErr or Notify kicks off crankback. 🤝 that agreement is constrained by the re-routing behavior selection (as listed in Section 5.4). without it, multiple nodes might try to repair the LSP at the same time, because:
- these messages can take different paths before they reach the ingress LSR, and
- the destination of the Notify message might not be the ingress LSR. 🙀
Section B : Solution 💖
5. Control of Crankback Operation 👑
5.1. Requesting Crankback and Controlling In-Network Re-Routing 🎀
when a request is made to set up an LSP tunnel, the ingress LSR should say whether it wants crankback info collected if something fails. it should also say whether it wants re-routing attempts by any intermediate nodes or specific ones. 📣 for this, a Re-routing Flag field gets added to the protocol setup request messages. the values are mutually exclusive, so pick one. 🙅♀️
No Re-routing The ingress node MAY attempt re-routing
after failure. Intermediate nodes SHOULD
NOT attempt re-routing after failure.
Nodes detecting failures MUST report an
error and MAY supply crankback information.
This is the default and backwards
compatible option.
End-to-end Re-routing The ingress node MAY attempt re-routing
after failure. Intermediate nodes SHOULD
NOT attempt re-routing after failure.
Nodes detecting failures MUST report an
error and SHOULD supply crankback
information.
Boundary Re-routing Intermediate nodes MAY attempt re-routing
after failure only if they are Area Border
Routers or AS Border Routers (ABRs/ASBRs).
The boundary (ABR/ASBR) can either decide
to forward the error message upstream to
the ingress LSR or try to select another
egress boundary LSR. Other intermediate
nodes SHOULD NOT attempt re-routing. Nodes
detecting failures MUST report an error and
SHOULD supply crankback information.
Segment-based Re-routing Any node MAY attempt re-routing after it
receives an error report and before it
passes the error report further upstream.
Nodes detecting failures MUST report an
error and SHOULD supply full crankback
information.5.2. Action on Detecting a Failure 🚨
a node that detects a failure to set up an LSP, or the failure of an established LSP, SHOULD act according to the Re-routing Flag passed on the LSP setup request. 🏃♀️
if Segment-based Re-routing is allowed, or if Boundary Re-routing is allowed and the detecting node is an ABR or ASBR, the detecting node MAY immediately attempt to re-route. ⚡
if End-to-end Re-routing is indicated, or if Segment-based or Boundary Re-routing is allowed and the detecting node chooses not to make re-routing attempts (or has used up all possible re-routing attempts), the detecting node MUST return a protocol error indication and SHOULD include full crankback information. 💅🫶
5.3. Limiting Re-Routing Attempts 🌙
each repair point SHOULD apply a locally configurable limit to the number of attempts it makes to re-route an LSP. 🧱 this helps prevent excessive network usage when there are significant faults, and it lets things back off to other repair points that might have a better chance of routing around the problem. 🦋✨
5.3.1. New Status Codes for Re-Routing ✨
okay so this is the status code for when a node gives up on crankback re-routing because it hit its retry threshold 💀 the error code/value is "Routing Problem"/"Re-routing limit exceeded" (24/22) 🙈
a node that receives an error response with this status code MAY also attempt crankback re-routing itself, but it is RECOMMENDED that those attempts be limited to the ingress LSR 🫶
5.4. Protocol Control of Re-Routing Behavior 💅
so the LSP_ATTRIBUTES object from [RFC4420] is what carries the Re-Routing Flag (from Section 4.1) on Path messages 🦋 there are three bits you can put in the LSP Attributes TLV, and IANA assigned the bit numbers, so they're official, no cap 👑
Bit Name and Usage
Number
1 End-to-end re-routing desired.
This flag indicates the end-to-end re-routing behavior for an
LSP under establishment. This MAY also be used for
specifying the behavior of end-to-end LSP recovery for
established LSPs.
2 Boundary re-routing desired.
This flag indicates the boundary re-routing behavior for an
LSP under establishment. This MAY also be used for
specifying the segment-based LSP recovery through nested
crankback for established LSPs. The boundary ABR/ASBR can
either decide to forward the PathErr message upstream to an
upstream boundary ABR/ASBR or to the ingress LSR.
Alternatively, it can try to select another egress boundary
LSR.
3 Segment-based re-routing desired.
This flag indicates the segment-based re-routing behavior for
an LSP under establishment. This MAY also be used to specify
the segment-based LSP recovery for established LSPs.6. Reporting Crankback Information 🎀
6.1. Required Information 🌸
like we said above, full crankback information SHOULD point out the node, link, and other resources that got tried but failed because of allocation issues or network failure 😭
the default crankback information SHOULD include the interface and the node address 💖
any address reported in that crankback info SHOULD be one that the routing protocols (OSPF and IS-IS) distributed in their TE link state advertisements 🧚 extra stuff like component link identifiers is on top of that, though ✨
6.2. Protocol Extensions 🦋
[RFC3473] defines an IF_ID ERROR_SPEC object that you can use on PathErr, ResvErr and Notify messages to carry the info from the Error Spec Object defined in [RFC3209] 💅 the IF_ID ERROR_SPEC Object also has room for TLVs that identify the link tied to the error, which is so iconic 👑
the TLVs for this object come from [RFC3471], and they're listed below 🌈 they get used in two places: in the IF_ID RSVP_HOP object to identify links, and in the IF_ID ERROR_SPEC object to identify the failed resource, which is usually the downstream resource from the reporting node 🫶
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4 (Interface address)
2 20 IPv6 Addr. IPv6 (Interface address)
3 12 Compound IF_INDEX (Interface index)
4 12 Compound COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 Compound COMPONENT_IF_UPSTREAM (Component interface)TLVs 4 and 5 are obsoleted by [RFC4201], so they SHOULD NOT be used to identify component interfaces in IF_ID ERROR_SPEC objects 🙈
to make crankback reporting work, these extra TLVs are defined too 🍓
Type Length Format Description
--------------------------------------------------------------------
6 var See below DOWNSTREAM_LABEL (GMPLS label)
7 var See below UPSTREAM_LABEL (GMPLS label)
8 8 See below NODE_ID (TE Router ID)
9 x See below OSPF_AREA (Area ID)
10 x See below ISIS_AREA (Area ID)
11 8 See below AUTONOMOUS_SYSTEM (Autonomous system)
12 var See below ERO_CONTEXT (ERO subobject)
13 var See below ERO_NEXT_CONTEXT (ERO subobjects)
14 8 IPv4 Addr. PREVIOUS_HOP_IPv4 (Node address)
15 20 IPv6 Addr. PREVIOUS_HOP_IPv6 (Node address)
16 8 IPv4 Addr. INCOMING_IPv4 (Interface address)
17 20 IPv6 Addr. INCOMING_IPv6 (Interface address)
18 12 Compound INCOMING_IF_INDEX (Interface index)
19 var See below INCOMING_DOWN_LABEL (GMPLS label)
20 var See below INCOMING_UP_LABEL (GMPLS label)
21 8 See below REPORTING_NODE_ID (Router ID)
22 x See below REPORTING_OSPF_AREA (Area ID)
23 x See below REPORTING_ISIS_AREA (Area ID)
24 8 See below REPORTING_AS (Autonomous system)
25 var See below PROPOSED_ERO (ERO subobjects)
26 var See below NODE_EXCLUSIONS (List of nodes)
27 var See below LINK_EXCLUSIONS (List of interfaces)for types 1, 2, and 3, the Value field format is already defined in [RFC3471] 💖 for types 14 and 16, the Value field matches type 1, and for types 15 and 17, it matches type 2 🌸 type 18 matches type 3 too ✨
types 6, 7, 19, and 20 have a variable length, and their Value field is a label as defined in [RFC3471] 🦋 like with all labels, it's assumed that any node that can process the label knows its syntax and semantics from the context 🧚 also, all TLVs are zero-padded to a multiple of four octets, so if a label isn't itself a multiple of four octets, it must be told apart from the trailing zero pads using knowledge from the context 😭
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 is 32 bits 🌈 it's the TE Router ID (TLV type 8) or the Router ID (TLV type 21) that identifies the node within the IGP 👑
for types 9 and 22, the Value field looks like this 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OSPF Area Identifier is the 4-octet area identifier for the node 💅 it tells you which area the failure happened in 🔥
for types 10 and 23, the Value field looks like this 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | IS-IS Area Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IS-IS Area Identifier (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length is the length of the actual (non-padded) IS-IS Area Identifier in octets 💖 valid values run from 2 to 11 inclusive ✨
IS-IS Area Identifier is the variable-length IS-IS area identifier 🌸 it gets padded with trailing zeroes to a four-octet boundary 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Autonomous System Number is 32 bits 🧚 it's the AS Number of the associated Autonomous System 💜 if 16-bit AS numbers are in use, the low order bits (16 through 31) should be used and the high order bits (0 through 15) should be set to zero 🙈
for types 12, 13, and 25, the Value field looks like this 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ERO Subobjects ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ERO Subobjects is a sequence of Explicit Route Object (ERO) subobjects 🌈 any ERO subobjects are allowed, whether they're defined in [RFC3209], [RFC3473], or other documents 👑 each ERO subobject carries its own type and length 🍓
for type 26, the Value field looks like this 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Node Identifiers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Node Identifiers is a sequence of TLVs of types 1, 2, or 8 🦋 they point at downstream nodes that already took part in crankback attempts and got declared unusable for the current LSP setup attempt 💀 an interface identifier can be used to identify a node too ✨
for type 27, the Value field looks like this 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Link Identifiers ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Link Identifiers is a sequence of TLVs in the same format as type 1, 2, or 3 TLVs 💜 they name the incoming interfaces at downstream nodes that already took part in crankback attempts and got declared unusable for the current LSP setup attempt 🔥
6.3. Guidance for Use of IF_ID ERROR_SPEC TLVs 🌸
6.3.1. General Principles ✨
Okay so, if crankback isn't being used, putting an IF_ID ERROR_SPEC object in PathErr, ResvErr, and Notify messages just follows the processing rules from [RFC3473] and [RFC4201] 💅. A sender MAY also add extra TLVs of types 6 through 27 to report crankback information for informational/monitoring purposes 📊.
If crankback is being used, the sender of a PathErr, ResvErr, or Notify message MUST use the IF_ID ERROR_SPEC object and MUST include at least one of the TLVs in the range 1 through 3, as described in [RFC3473], [RFC4201], and the previous paragraph 🫶. Additional TLVs SHOULD also be included to report further information. The next section gives advice on which TLVs should be used in different situations, and which TLVs must be supported by LSRs 🧚.
Note that all of those additional TLVs are optional and MAY be omitted 🌸. Including the optional TLVs SHOULD be done wherever it helps with error reporting and crankback. The TLVs sort into three buckets: the ones that are essential for reporting the error, the ones that give extra info that is or may be fundamental to crankback being useful, and the ones that give extra info that may be useful for crankback in some circumstances 💜.
Note that all LSRs MUST be prepared to receive and forward any TLV as per [RFC3473] 🦋. That includes TLVs of type 4 or 5 as defined in [RFC3473] and obsoleted by [RFC4201]. There is, however, no requirement for an LSR to actively process any TLVs beyond the ones defined in [RFC3473]. An LSR that plans to do crankback re-routing SHOULD support receiving and processing all of the fundamental crankback TLVs, and is RECOMMENDED to support receiving and processing the additional crankback TLVs too 🔥.
Here's the tea ☕: some assumptions about which TLVs will be used MAY be made based on the deployment scenario. For example, a router deployed in a single-area network does not need to support receiving and processing TLV types 22 and 23. Those TLVs might be inserted in an IF_ID ERROR_SPEC object, but the receiver of a PathErr message would not need to process them 🙈.
6.3.2. Error Report TLVs 🎀
Error Report TLVs are the ones in the range 1 through 3. (Heads up: the obsoleted TLVs 4 and 5 may be counted in this category too, but they SHOULD NOT be used 💀.)
As we said above, when crankback information is reported, the IF_ID ERROR_SPEC object MUST be used. When that object is used, at least one of the TLVs in the range 1 through 3 MUST be present. Which TLV you pick depends on the circumstances of the error and the device's capabilities. For example, a device that doesn't support IPv6 won't need the ability to create a TLV of type 2. But such a device MUST still be prepared to receive and process all error report TLVs 💅.
6.3.3. Fundamental Crankback TLVs 🔥
A lot of these TLVs report the specific resource that failed. TLV type 1, for example, can be used to report that the setup attempt was blocked by some kind of resource failure on a specific interface, identified by the IP address supplied. TLVs in this category are 1 through 11, although TLVs 4 and 5 can be considered excluded from this category because they're obsoleted 🦋.
These TLVs SHOULD be supplied whenever the node detecting and reporting the failure has the information available. (Note that some of these TLVs MUST be included, as described in the previous two sections.) The TLVs of type 8, 9, 10, and 11 MAY, however, be omitted according to local policy and how relevant the information is ✨.
6.3.4. Additional Crankback TLVs 🧚
Some TLVs help locate the fault within the context of the path of the LSP being set up. TLVs of types 12, 13, 14, and 15 help set the context of the error within the scope of an explicit path that has loose hops or non-precise abstract nodes 🗺️. ERO context information isn't always a requirement, but a node may notice that it is a member of the next hop in the ERO (such as a loose or non-specific abstract node) and deduce that its upstream neighbor may have selected the path using next hop routing. In that case, providing the ERO context will be useful to the upstream node that performs re-routing 🫶.
Note the distinction between TLVs 12 and 13 is the distinction between "this is the hop I was trying to satisfy when I failed" and "this is the next hop I was trying to reach when I failed" 💜.
Reporting nodes SHOULD also supply TLVs from the range 12 through 20 as appropriate for reporting the error. The reporting nodes MAY also supply TLVs from the range 21 through 27 🌈.
Note that when deciding whether a TLV in the range 12 through 20 "is appropriate", the reporting node should consider, amongst other things, whether the information is pertinent to the cause of the failure. For example, when a cross-connection fails, the outgoing interface may be faulted, in which case only the interface (for example, TLV type 1) needs to be reported. But if the problem is that the incoming interface cannot be connected to the outgoing interface because of temporary or permanent cross-connect limitations, the node should also include a reference to the incoming interface (for example, TLV type 16) 🔍.
Four TLVs (21, 22, 23, and 24) let you expand on where the reporting node is. These TLVs would not be included if the information isn't of use within the local system, but ABRs relaying the error might add them 🌍. Note that the Reporting Node ID (TLV 21) need not be included if the IP address of the reporting node, as indicated in the ERROR_SPEC itself, is enough to fully identify the node.
The last three TLVs (25, 26, and 27) provide additional information for recomputation points. The reporting node (or a node forwarding the error) MAY make suggestions about how the error could have been avoided, for example by supplying a partial ERO that would let the LSP be set up successfully if it were used 🧩. As the error propagates back upstream and crankback routing is attempted and fails, it's beneficial to collect lists of failed nodes and links so that they won't be included in further computations performed at upstream nodes 🚫. These lists may also be factored into route exclusions [RFC4874].
Note that there is no ordering requirement on any of the TLVs within the IF_ID Error Spec, and no implication should be drawn from the ordering of the TLVs in a received IF_ID Error Spec 🙃.
The decision of precisely which TLV types a reporting node includes depends on the specific capabilities of the node, and is outside the scope of this document 🌷.
6.3.5. Grouping TLVs by Failure Location 🗂️
Further guidance on including crankback TLVs can be given by grouping them according to where the failure happened and the context in which it's reported. For example, a TLV that reports an area identifier would only need to be included as the crankback error report transits an area boundary 🌉.
Resource Failure
6 DOWNSTREAM_LABEL
7 UPSTREAM_LABEL
Interface Failures
1 IPv4
2 IPv6
3 IF_INDEX
4 COMPONENT_IF_DOWNSTREAM (obsoleted)
5 COMPONENT_IF_UPSTREAM (obsoleted)
12 ERO_CONTEXT
13 ERO_NEXT_CONTEXT
14 PREVIOUS_HOP_IPv4
15 PREVIOUS_HOP_IPv6
16 INCOMING_IPv4
17 INCOMING_IPv6
18 INCOMING_IF_INDEX
19 INCOMING_DOWN_LABEL
20 INCOMING_UP_LABEL
Node Failures
8 NODE_ID
21 REPORTING_NODE_ID
Area Failures
9 OSPF_AREA
10 ISIS_AREA
22 REPORTING_OSPF_AREA
23 REPORTING_ISIS_AREA
25 PROPOSED_ERO
26 NODE_EXCLUSIONS
27 LINK_EXCLUSIONS
AS Failures
11 AUTONOMOUS_SYSTEM
24 REPORTING_ASAlthough aggregation of crankback information is out of the scope of this document, it's worth knowing this topic is closely aligned with the info presented here. Aggregation is discussed further in Section 6.4.5 🧁.
6.3.6. Alternate Path Identification 🦋
No new object is used to distinguish between Path/Resv messages for an alternate LSP. So the alternate LSP uses the same SESSION and SENDER_TEMPLATE/FILTER_SPEC objects as the ones used for the initial LSP under re-routing 💖.
6.4. Action on Receiving Crankback Information 👑
6.4.1. Re-Route Attempts 🔁
As described in Section 2, a node receiving crankback information in a PathErr must first check whether it's allowed to perform re-routing. This is indicated by the Re-routing Flags in the LSP_ATTRIBUTES object during an LSP setup request 🚦.
If a node isn't allowed to perform re-routing, it should forward the PathErr message, or if it's the ingress, report the LSP as having failed 😬.
If re-routing is allowed, the node should try to compute a path to the destination using the original (received) explicit path and 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 re-routing should store all received crankback information for an LSP until the LSP is successfully established, or until the node abandons its attempts to re-route the LSP 📦. On the next crankback re-routing path computation attempt, the LSR should exclude all the failed nodes, links, and resources reported from previous attempts 🙅♀️.
Whether the crankback information is discarded immediately upon successful LSP establishment, or retained for a period in case the LSP fails, is an implementation decision 🤷♀️.
6.4.2. Location Identifiers of Blocked Links or Nodes 📍
In order to compute an alternate path by crankback re-routing, it's necessary to identify the blocked links or nodes and their locations. 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 and IS-IS, each link and node in a network can be uniquely identified, for example by the context of a TE Router ID and the Link ID. 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 🗺️.
Note that when the routing-protocol-specific link identifiers are used, the Re-routing Flag on the LSP setup request must have been set to show support for boundary or segment-based re-routing 🚩.
In this document, we specify routing protocol specific link and node identifiers for OSPFv2, OSPFv3, and IS-IS for IPv4 and IPv6. These identifiers may only be used if segment-based re-routing is supported, as indicated by the Routing Behavior flag on the LSP setup request 💜.
6.4.3. Locating Errors within Loose or Abstract Nodes 🔍
Okay so the explicit route on the original LSP setup request might have a loose or an Abstract Node in it 🧠, which means the crankback info could point at links or nodes that were never in the original explicit route. Messy, but we handle it! 💅
To compute a new path, the repair point may need to figure out which pair of hops (or nodes) in the explicit route the error/blockage happened between 🎯
So the crankback info 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, and the second hop will identify a 'next' hop from the original explicit route. Two hops, zero confusion ✨
6.4.4. When Re-Routing Fails 🙅♀️
Sometimes a node cannot or chooses not to do crankback re-routing, and that's okay 🫶 In that case it must forward the PathErr message further upstream.
BUT, if a node was the one responsible for expanding or replacing the explicit route while the LSP setup was being processed, it MUST update the crankback information with regard to the explicit route that it received 🔥 Only if that happens will the upstream nodes have a real chance of routing around the problem. No update, no glow-up 💀
6.4.5. Aggregation of Crankback Information 🧩
So when a setup blocking error or an error in an established LSP happens and crankback information gets sent in an error notification message, an upstream node may choose to attempt crankback re-routing. If that node's re-routing attempts fail, it will collect a set of failure information. When it gives up, it MUST propagate the failure message further upstream and include crankback information when it does 🦋
Now, listing every single failure from multiple crankback failures by multiple repair point LSRs downstream could lead to way too much signaled information using the protocol extensions in this document 😭 So there's a compression mechanism for that using TLVs 26 and 27 🎀 These TLVs let you accumulate failure info in a more concise way as crankback failures travel upstream. Iconic efficiency 👑
Aggregation can look like reporting all links from a node as unusable by flagging the node as unusable, flagging an ABR as unusable when there's no downstream path available, or including a TLV of type 9, which results in excluding the entire area, and so on 🌸 The precise details of how aggregation is performed are beyond the scope of this document, so don't come for me about it 🙈
6.5. Notification of Errors 📣
6.5.1. ResvErr Processing 🌊
As described above, the resource allocation failure for RSVP-TE may happen on the reverse path when the Resv message is being processed. In that case it's still useful to return the received crankback information to the ingress LSR ✨ However, when the egress LSR receives the ResvErr message, per [RFC2205] it still has the option of re-issuing the Resv with different resource requirements (although not on an alternate path). Second chances, bestie 🥹
When a ResvErr carrying crankback information gets to an egress LSR, the egress LSR MAY ignore this object and do the same actions it would do for any other ResvErr. However, if the egress LSR supports the crankback extensions defined in this document, 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 💅
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_SPEC carried. In this case, it may be necessary per [RFC2205] to generate more than one PathErr 🫠
6.5.2. Notify Message Processing 📬
[RFC3473] defines the Notify message to enhance error reporting in RSVP-TE networks. It is NOT meant to replace the PathErr and ResvErr messages 🙅♀️ (okay it's not in caps in the original, so let me be clear: it is not intended to replace them.) 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 happens, like a link hardware failure, the LSRs that detect the error MAY send Notify messages to the requested addresses. What kind of error triggers a Notify message is an implementation detail 🤷♀️
If a failure happens, an LSR that supports [RFC3473] and the crankback extensions defined in this document MAY choose to send a Notify message carrying crankback information. This makes sure the error gets reported faster to the ingress and/or egress LSRs 🚀
6.6. Error Values 🔢
Error values for the Error Code "Admission Control Failure" are defined in [RFC2205]. Error values for the error code "Routing Problem" are defined in [RFC3209] and [RFC3473].
A new error value is defined for the "Routing Problem" error code. "Re-routing limit exceeded" means re-routing has failed because the number of crankback re-routing attempts has gone past the predetermined threshold at an individual LSR 🚫
6.7. Backward Compatibility 🔙
Not every node in an RSVP-TE network will support the extensions in this document, and that's totally real 🌈 It's important that an LSR that doesn't support these extensions can still process a PathErr, ResvErr, or Notify message even if it carries the newly defined IF_ID ERROR_SPEC information (TLVs). Nobody gets left on read 🫶
This document does not introduce any backward compatibility issues, provided that existing implementations conform to the TLV processing rules defined in [RFC3471] and [RFC3473] ✨
7. LSP Recovery Considerations 🛟
LSP recovery is performed to recover an established LSP when a failure happens along the path 💫 For LSP recovery, the crankback re-routing extensions explained above can be applied to improve performance. This section gives an example of applying the extensions above to LSP recovery. The goal is a general overview of how this might work, NOT a detailed procedure for LSP recovery, so keep that in mind 🧁
Although there are several techniques for LSP recovery, this section explains on-demand LSP recovery, which tries to set up a new LSP on demand after an LSP failure is detected 🎯
7.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, the ERROR_SPEC object may carry a Path_State_Remove_Flag indication, and each LSR that receives the message then releases the corresponding LSP. (Note that if the state removal indication is not present on the PathErr message, the ingress node MUST issue a PathTear message to cause the resources to be released.) If the failed LSP has to be recovered at an upstream LSR, the IF_ID ERROR SPEC that includes the location information of the failed link or node is included in the PathErr message. The ingress, the intermediate area border LSR, or indeed any repair point permitted by the Re-routing Flags that receives the PathErr message can terminate the message and then perform alternate routing 🌷
In a flat network, when the ingress LSR receives the PathErr message with the IF_ID ERROR_SPEC TLVs, it computes an alternate path around the blocked link or node that still satisfies the QoS guarantees. 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, the following procedures can be used. As explained in Section 5.4, the LSP recovery behavior is indicated in the Flags field of the LSP_ATTRIBUTES object of the Path message. If the Flags indicate End-to-end re-routing, the PathErr message is returned all the way back to the ingress LSR, which may then issue a new Path message along another path. That's the same procedure as in the flat network case above 🔁
If the Flags field indicates Boundary re-routing, the ingress area border LSR MAY terminate the PathErr message 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 re-routing, any node MAY apply the procedures described above for Boundary re-routing 🪄
7.2. Downstream of the Fault ⬇️
This section only applies to errors that happen after an LSP has been established. Note that an LSR that generates a PathErr with the Path_State_Remove Flag SHOULD also send a PathTear downstream to clean up the LSP 🧹
A node that detects a fault and is downstream of it MAY send a PathErr and/or Notify message containing an IF_ID ERROR SPEC that includes the location information of the failed link or node, and MAY send a PathTear to clean up the LSP at all other downstream nodes 💜
However, if the reservation style for the LSP is Shared Explicit (SE), the detecting LSR MAY choose not to send a PathTear. This leaves the downstream LSP state in place and makes make-before-break repair of the LSP possible by re-utilizing downstream resources 🦋 Note that if the detecting node does not send a PathTear immediately, then the unused state will time out according to the normal rules of [RFC2205] ⏳
At a well-known merge point, an ABR or an ASBR, a similar decision might also be made to better facilitate make-before-break repair. In this case, a received PathTear might be 'absorbed' and not propagated further downstream for an LSP that has an SE reservation style. Note, however, that this is a divergence from the protocol and might severely impact normal tear-down of LSPs 😬
8. IANA Considerations 📋
8.1. Error Codes 🔢
IANA maintains a registry called "RSVP Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes". This subregistry includes the RSVP-TE "Routing Problem" error code that is defined in [RFC3209] 🗂️
IANA has assigned a new error value for the "Routing Problem" error code as follows:
22 Re-routing limit exceeded.8.2. IF_ID_ERROR_SPEC TLVs 🏷️
The IF_ID_ERROR_SPEC TLV type values defined in [RFC3471] are maintained by IANA in the "Interface_ID Types" subregistry of the "GMPLS Signaling Parameters" registry 💖
IANA has made new assignments from this subregistry for the new TLV types defined in Section 6.2 of this document ✨
8.3. LSP_ATTRIBUTES Object 🧾
IANA maintains an "RSVP TE Parameters" registry with an "Attributes Flags" subregistry. IANA has made three new allocations from this registry, as listed in Section 5.4 🌸
These bits are defined for inclusion in the LSP Attributes TLV of the LSP_ATTRIBUTES. The values shown have been assigned by IANA 🎀
9. Security Considerations ✨
okay bestie, this section is SERIOUS but also kind of iconic, so let's get into it 🔐💅
The RSVP-TE trust model basically assumes that RSVP-TE neighbors and peers trust each other to swap legit, non-malicious messages 🫶 This assumption is necessary so the signaling protocol can actually function, like, it's the foundation 🧱
Also, this trust model is assumed to cascade 🌊 So if an LSR trusts its neighbors, it extends that trust to every LSR its neighbor trusts too. That means the trust model is usually applied across the whole network to create a trust domain 👑
Authentication of neighbor identity is already a standard part of RSVP-TE, and so is protecting messages against tampering and spoofing 🛡️ For the details, check out [RFC2205], [RFC3209], and [RFC3473], which describe the applicable security considerations 📚 These considerations and mechanisms apply to hop-by-hop message exchanges (like the ones used for crankback propagation on PathErr messages) and to directed message exchanges (like the ones used for crankback propagation on Notify messages) 💌
Key management can also be used with RSVP-TE to help protect against impersonation and message content falsification 🔑 This requires maintaining, exchanging, and configuring keys on each LSR. Honestly, that maintenance can be super exhausting for operators, so it's important to limit the number of keys while still making sure you get the level of security you need 😩
This document does not introduce any protocol elements or message exchanges that change how RSVP-TE security works 🙅♀️
However, crankback is envisaged as an inter-domain mechanism, so crankback information is likely to be exchanged across trust domain borders 🌍 In these cases, the information from within a neighboring domain would be of little or no value to the node doing crankback re-routing, so it would be ignored 🙈 Plus, the reporting domain will almost certainly have applied some form of information aggregation to keep its network topology confidential 🤫
A direct attack by one domain on another is possible, and domain admins should apply policies to protect their domains against the results of another domain trying to thrash LSPs by letting them set up before reporting them as failed 😤 On the whole, commercial contracts between trust domains are expected to provide a degree of protection 📝
A more serious threat might arise if a domain reports that neither it nor its downstream neighbor can provide a path to the destination 😱 Such a report could be bogus, because the reporting domain might not have given the downstream domain a chance to try to provide a path. The same problem does not arise for nodes within a domain, thanks to the trust model. This type of malicious behavior is hard to overcome, but it may be detected by sending indirect path computation requests directly to the falsely reported domain, using mechanisms such as the Path Computation Element [RFC4655] 🕵️♀️
A separate document describing inter-domain MPLS and GMPLS security considerations will be produced 📄
Finally, while the extensions in this document introduce no new security holes in the protocols, if a malicious user gains protocol access to the network, the crankback information might be used to prevent the establishment of valid LSPs 💀 So all deployers should carefully consider the existing security features available in RSVP-TE, and all implementations that offer crankback SHOULD make those features available 🔥 Also, re-routing attempt thresholds are especially useful in this context 🧠
10. 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 document and consider the use of the IF_ID ERROR SPEC object 🌸 Big thanks for a welcome and very thorough review by Dimitri Papadimitriou 👑
Stephen Shew made useful comments for clarification through the ITU-T liaison process ✨
Simon Marshall-Unitt made contributions to this document 🫶
SecDir review was provided by Tero Kivinen 🔍 Thanks to Ross Callon for useful discussions of prioritization of crankback re-routing attempts 💅
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
Ayyangar, "Encoding of Attributes for Multiprotocol Label
Switching (MPLS) Label Switched Path (LSP) Establishment
Using Resource ReSerVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4420, February 2006.11.2. Informative References
[ASH1] G. Ash, ITU-T Recommendations E.360.1 --> E.360.7, "QoS
Routing & Related Traffic Engineering Methods for IP-,
ATM-, & TDM-Based Multiservice Networks", May, 2002.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework for
Multi-Protocol Label Switching (MPLS)-based Recovery", RFC
3469, February 2003.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007.
[PNNI] ATM Forum, "Private Network-Network Interface
Specification Version 1.0 (PNNI 1.0)", <af-pnni-0055.000>,
May 1996.Appendix A. Experience of Crankback in TDM-Based Networks ✨
okay so this appendix is basically the lore of why we don't just blindly trust release messages 🫶 Service providers in TDM-based networks already learned this the hard way, and it's giving "learn from the past or get blocked" 💀
Using the receipt of a release message with a Cause Value (CV) of "link congestion" to trigger a re-route attempt at the originating node is a tempting move. However, it sometimes causes problems 🙈
*--------------------* *-----------------*
| | | |
| N2 ----------- N3-|--|----- AT--- EO2 |
| | | \| | / | |
| | | |--|- / | |
| | | | | \/ | |
| | | | | /\ | |
| | | |--|- \ | |
| | | /| | \ | |
| N1 ----------- N4-|--|----- EO1 |
| | | |
*--------------------* *-----------------*
A-1 A-2
Figure 1. Example of network topologyFigure 1 shows four examples from real service-provider experiences comparing crankback (explicit indication) with implicit indication through a release with CV. Here, N1, N2, N3, and N4 live in one area (A-1), while AT, EO1, and EO2 live in another (A-2) 🌸
Two areas are used so the issues are super easy to see, but the drama isn't limited to multi-area networks. It shows up any time path computation is spread across the network, like with loose routes, AS routes, or path computation domains 🦋
- A connection request from N1 to EO1 might route through N4 and then find "all circuits busy." N4 sends a release message back to N1 with CV34 indicating all circuits busy. Normally, a node like N1 is programmed to block the connection request when it gets CV34. But there's a good reason to try routing the request through N2 and N3 instead 🍓
Some service providers use a technique called Route Advance (RA). If an RA-capable node gets a release message with CV34, it treats that as an implicit re-route indication and tries to find an alternate route for the connection request if one exists. In this case, the alternate route N1-N2-N3-EO1 can be tried and may well succeed ✨
- Say a connection request goes from N2 to N3 to AT while trying to reach EO2, and it gets blocked at link AT-EO2. Node AT returns a CV34, and with RA, N2 may try to re-route N2-N1-N4-AT-EO2. But of course this fails again 😭 The problem is that N2 can't tell where the blocking happened just from the CV34, so there's no point in more alternate routing. 💀
- Now try a connection request from N2 to EO2, where link N3-AT is blocked. In this case N3 should return crankback information (and not CV34) so that N2 can alternate route to N1-N4-AT-EO2, which may well be successful 🫶
- In a final example, a connection request goes from EO1 to N2. EO1 first tries to route the request directly to N3. However, N3 may reject it even if there is bandwidth available on link N3-EO1, perhaps for priority routing reasons, like reserving bandwidth for high-priority requests. When N3 returns CV34 in the release message, EO1 blocks the request (which is a normal response to CV34, especially if E01-N4 is already known to be blocked) instead of trying the alternate route through AT-N3-N2, which might work. If N3 returns crankback information, EO1 could try that alternate route instead 💅
Sure, with topology exchange like OSPF, the ingress LSR could infer the re-routing condition. But routing information converges more slowly than the expected LSP setup times, so that's not quite the same vibe 🥺 One of the big reasons for crankback is avoiding the overhead of available-link-bandwidth flooding, and using local state information more efficiently to steer alternate routing at the ingress-LSR 🧚
[ASH1] shows how event-dependent-routing can use just crankback, and not available-link-bandwidth flooding, to decide on the re-route path through "learning models." Cutting down on that flooding reduces overhead and can make much larger AS sizes possible 🌈
So the alternate routing should be based on an explicit indication (as in examples 3 and 4), and it's best to know these two things separately:
- a) where the blockage or 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).
Authors' Addresses 🧚
Adrian Farrel (Editor)
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Arun Satyanarayana
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
Phone: +1 408 853-3206
EMail: asatyana@cisco.com
Atsushi Iwata
NEC Corporation
System Platforms Research Laboratories
1753 Shimonumabe Nakahara-ku,
Kawasaki, Kanagawa, 211-8666, JAPAN
Phone: +81-(44)-396-2744
Fax: +81-(44)-431-7612
EMail: a-iwata@ah.jp.nec.com
Norihito Fujita
NEC Corporation
System Platforms Research Laboratories
1753 Shimonumabe Nakahara-ku,
Kawasaki, Kanagawa, 211-8666, JAPAN
Phone: +81-(44)-396-2091
Fax: +81-(44)-431-7644
EMail: n-fujita@bk.jp.nec.com
Gerald R. Ash
AT&T
EMail: gash5107@yahoo.comFull Copyright Statement 💜
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This is the legal fine print, so I'm keeping it word for word 🎀
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.Intellectual Property 🔥
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document. It also doesn't say whether any license under those rights might or might not be available, and it doesn't claim to have independently looked for any such rights 🫶 You can find the rules about rights in RFC documents in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses to be made available, or the result of an attempt to get a general license or permission to use such proprietary rights for implementers or users of this specification, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that information to the IETF at ietf-ipr@ietf.org 🌸
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society 🦋
📦 where this page comes from
- ietf: rfc4920 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms