RFC 4090
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Part 1 of 8 🌸 more parts are coming, so stay tuned!
RFC 4090 is called Fast Reroute Extensions to RSVP-TE for LSP Tunnels 🎀. It's a Standards Track document from the Network Working Group, dated May 2005. The editors are P. Pan (Hammerhead Systems), G. Swallow (Cisco Systems), and A. Atlas (Avici Systems), and all three are marked Ed. The header doesn't list any RFCs that it obsoletes or updates ✨.
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. If you want to know where this protocol stands in terms of standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Copyright Notice
Copyright (C) The Internet Society (2005).Abstract
Okay so this doc defines RSVP-TE extensions for setting up backup label-switched path (LSP) tunnels, which are used for local repair of LSP tunnels 🦋. The whole point is redirecting traffic onto those backup tunnels in 10s of milliseconds when something fails. Literally so fast 😭.
There are two methods here. The one-to-one backup method creates detour LSPs for each protected LSP at every potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point. Because it uses MPLS label stacking, that one bypass tunnel can protect a whole set of LSPs with similar backup constraints, which is giving efficiency 💅. Both methods can protect links and nodes during a network failure. The behavior and RSVP extensions described here let nodes implement either method or both, and they can still interoperate in a mixed network 🫶.
Table of Contents
1. Introduction ...................................................3
1.1. Background ...............................................4
2. Terminology ....................................................4
3. Local Repair Techniques ........................................6
3.1. One-to-One Backup ........................................6
3.2. Facility Backup ..........................................7
4. RSVP Extensions ................................................8
4.1. FAST_REROUTE Object ......................................8
4.2. DETOUR Object ...........................................11
4.2.1. DETOUR Object for IPv4 Address ...................11
4.2.2. DETOUR Object for IPv6 Address ...................12
4.3. SESSION_ATTRIBUTE Flags .................................13
4.4. RRO IPv4/IPv6 Sub-object Flags ..........................14
5. Head-End Behavior .............................................15
6. Point of Local Repair (PLR) Behavior ..........................16
6.1. Signaling a Backup Path .................................17
6.1.1. Backup Path Identification: Sender
Template-Specific ................................19
6.1.2. Backup Path Identification: Path-Specific ........19
6.2. Procedures for Backup Path Computation ..................20
6.3. Signaling Backups for One-to-One Protection .............21
6.3.1. Make-before-Break with Detour LSPs ...............22
6.3.2. Message Handling .................................23
6.3.3. Local Reroute of Traffic onto Detour LSP .........23
6.4. Signaling for Facility Protection .......................24
6.4.1. Discovering Downstream Labels ....................24
6.4.2. Procedures for the PLR before Local Repair .......24
6.4.3. Procedures for the PLR during Local Repair .......25
6.4.4. Processing Backup Tunnel's ERO ...................26
6.5. PLR Procedures during Local Repair ......................26
6.5.1. Notification of Local Repair .....................26
6.5.2. Revertive Behavior ...............................27
7. Merge Node Behavior ...........................................28
7.1. Handling Backup Path Messages before Failure ............28
7.1.1. Merging Backup Paths using the Sender
Template-Specific Method .........................29
7.1.2. Merging Detours using the Path-Specific Method ...29
7.1.3. Message Handling for Merged Detours ..............31
7.2. Handling Failures .......................................31
8. Behavior of All LSRs ..........................................32
8.1. Merging Detours in the Path-Specific Method .............32
9. Security Considerations .......................................33
10. IANA Considerations ...........................................33
11. Contributors ..................................................35
12. Acknowledgments ...............................................36
13. Normative References ..........................................361. Introduction ✨
This document extends RSVP [RSVP] to set up backup label-switched path (LSP) tunnels for local repair of LSP tunnels 💖. It's built for real-time apps like voice over IP, where user traffic needs to be pushed onto backup LSP tunnels in 10s of milliseconds. The trick is to compute and signal those backups before anything breaks, then redirect traffic as close to the failure point as possible. That way the redirect step has no path computation and no signaling delay, and that includes the delay of passing failure notifications between label-switched routers (LSRs). Speed of repair is the main advantage here 👑. The term local repair refers to techniques that redirect traffic to a backup LSP tunnel in response to a local failure.
A protected LSP is an explicitly-routed LSP that has protection. These repair methods only apply to explicitly-routed LSPs. Using them on LSPs that change their routes dynamically, like the LSPs used in unicast IGP routing, is outside the scope of this document 🙅♀️.
Here's the roadmap 🗺️. Section 2 covers the new terminology. Section 3 describes the two basic methods for creating backup LSPs. Section 4 describes the RSVP protocol extensions that support local protection. Section 5 covers the behavior of an LSR that wants to request local protection for an LSP. Section 6 covers the behavior of a potential point of local repair (PLR), including how to pick the right strategy for protecting an LSP and how to implement each strategy. Section 7 describes the behavior of a merge node, which is the LSR where a protected LSP and its backup LSP rejoin. Finally, Section 8 talks about the required behavior of other nodes in the network 🎀.
The methods in this document depend on three assumptions:
- An LSR that's on the path of a protected LSP should always assume it's a merge point. This is necessary because the facility backup method doesn't signal backups through a bypass tunnel before failure.
- If the one-to-one backup method is used and a DETOUR object is included, the LSRs in the traffic-engineered network should support the DETOUR object. This is necessary so the Path message carrying the DETOUR object doesn't get rejected.
- Understanding the DETOUR object is required to support the path-specific method, which means the LSRs in the traffic-engineered network have to be capable of merging detours 🧚.
1.1. Background 💅
Several years before work on this document started, operational networks had already deployed two independent methods of fast reroute. This document calls them one-to-one backup and facility backup 🍓. Vendors who tried to support both ran into compatibility problems when they tried to build a single implementation that could interoperate with both. Each method has technical tradeoffs, and those tradeoffs depend so much on the topology that the community never settled on a single approach 🙈.
So this document rationalizes the RSVP signaling for both methods, so any implementation can recognize every fast reroute request and respond clearly. The response is positive if the method can be performed. Otherwise, it's a clear error that tells the requester to look for alternate backup means. The document also lets a single implementation support both methods, which gives a range of capabilities 🌸. The behavior and RSVP extensions described here allow LERs and LSRs to implement either method or both.
While the two methods could in principle be used in one network, operators are expected to keep deploying one or the other. The goal of this document is to standardize the RSVP signaling so that a network made up of LSRs that implement both methods, or a mix of LSRs where some support one method and others support both, can signal among themselves properly and achieve fast restoration 🦋✨.
2. Terminology ✨
okay bestie, first things first: 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 [RFC-WORDS]. 🎀 these are the capital-letter rules, so pay attention!!
the reader is assumed to be familiar with the terminology in [RSVP] and [RSVP-TE]. 📚 so if the RSVP stuff feels new, go read those first, no cap 💅
here's the glossary, it's giving alphabet soup but make it iconic 🍓
- LSR: Label-Switch Router. 🦋
- LSP: An MPLS Label-Switched Path. In this document, an LSP will always be explicitly routed. 🛤️
- Local Repair: Techniques used to repair LSP tunnels quickly when a node or link along the LSP's path fails. 🩹
- PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a detour LSP. 👑 the PLR is literally the main character of fast reroute, periodt
- One-to-One Backup: A local repair method in which a backup LSP is separately created for each protected LSP at a PLR. 🫶
- Facility Backup: A local repair method in which a bypass tunnel is used to protect one or more protected LSPs that traverse the PLR, the resource being protected, and the Merge Point in that order. 🧚
- Protected LSP: An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop. 🛡️
- Detour LSP: The LSP that is used to re-route traffic around a failure in one-to-one backup. 🌸
- Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility. 🌈
- Backup Tunnel: The LSP that is used to backup up one of the many LSPs in many-to-one backup. 💜
- NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel that bypasses a single link of the protected LSP. 🔗
- NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel that bypasses a single node of the protected LSP. 🙈
- Backup Path: The LSP that is responsible for backing up one protected LSP. A backup path refers to either a detour LSP or a backup tunnel. 🧸
- MP: Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure. The same LSR may be both an MP and a PLR simultaneously. 🤝 yes, one LSR can wear both hats at the same time, iconic behavior
- DMP: Detour Merge Point. In the case of one-to-one backup, this is an LSR where multiple detours converge. Only one detour is signaled beyond that LSR. ✨
- Reroutable LSP: Any LSP for which the head-end LSR requests local protection. See Section 5 for more detail. 🎯
- CSPF: Constraint-based Shortest Path First. 🧮
- SRLG Disjoint: A path is considered to be SRLG disjoint from a given link or node if the path does not use any links or nodes which belong to the same SRLG as that given link or node. 💅 basically the path has to avoid the same shared-risk group, no drama allowed
3. Local Repair Techniques
okay so there are two different methods for local protection, and honestly both are giving main character 🎀 In the one-to-one backup method, a PLR computes a separate backup LSP, called a detour LSP, for each LSP that the PLR protects. In the facility backup method, the PLR creates a single bypass tunnel that can be used to protect multiple LSPs. 🦋 one-to-one is the "one outfit per event" approach, facility backup is the "one outfit for the whole group chat" approach 💖
3.1. One-to-One Backup
in the one-to-one backup method, a label-switched path is established that intersects the original LSP somewhere downstream of the point of link or node failure. A separate backup LSP is established for each LSP that is backed up. 🌷
[R1]----[R2]----[R3]------[R4]------[R5]
\ \ \ / \ /
[R6]----[R7]----[R8]------[R9]
Protected LSP: [R1->R2->R3->R4->R5]
R1's Backup: [R1->R6->R7->R8->R3]
R2's Backup: [R2->R7->R8->R4]
R3's Backup: [R3->R8->R9->R5]
R4's Backup: [R4->R9->R5]
Example 1. One-to-One Backup Techniquein the simple topology shown in Example 1, the protected LSP runs from R1 to R5. R2 can provide user traffic protection by creating a partial backup LSP that merges with the protected LSP at R4. We refer to a partial one-to-one backup LSP [R2->R7->R8->R4] as a detour. 🧁
to protect an LSP that traverses N nodes fully, there could be as many as (N - 1) detours. Example 1 shows the paths for the detours necessary to protect fully the LSP in the example. 📍 to keep the number of LSPs in the network low (very important, bestie), it is desirable to merge a detour back to its protected LSP, when feasible. When a detour LSP intersects its protected LSP at an LSR with the same outgoing interface, it will be merged. 🫧
when a failure occurs along the protected LSP, the PLR redirects traffic onto the local detour. For instance, if the link [R2->R3] fails in Example 1, R2 will switch traffic received from R1 onto the protected LSP along link [R2->R7], using the label received when R2 created the detour. When R4 receives traffic with the label provided for R2's detour, R4 will switch that traffic onto link [R4-R5], using the label received from R5 for the protected LSP. 🚀 At no point does the depth of the label stack increase as a result of the detour. While R2 is using its detour, traffic will take the path [R1->R2->R7->R8->R4->R5]. the stack stays the same size, slay 💅
3.2. Facility Backup
the facility backup method takes advantage of the MPLS label stack. 🧠 Instead of creating a separate LSP for every backed-up LSP, a single LSP is created that serves to back up a set of LSPs. We call such an LSP tunnel a bypass tunnel. 🎁
the bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the PLR. Naturally, this constrains the set of LSPs being backed up via that bypass tunnel to those that pass through some common downstream node. All LSPs that pass through the point of local repair and through this common node that do not also use the facilities involved in the bypass tunnel are candidates for this set of LSPs. 🫶 so basically, the squad has to share a common downstream friend
[R8]
\
[R1]---[R2]----[R3]-----[R4]---[R5]
\ / \
[R6]===[R7] [R9]
Protected LSP 1: [R1->R2->R3->R4->R5]
Protected LSP 2: [R8->R2->R3->R4]
Protected LSP 3: [R2->R3->R4->R9]
Bypass LSP Tunnel: [R2->R6->R7->R4]
Example 2. Facility Backup Techniquein Example 2, R2 has built a bypass tunnel that protects against the failure of link [R2->R3] and node [R3]. The doubled lines represent this tunnel. 🌈 this technique gives you a scalability improvement, because the same bypass tunnel can also be used to protect LSPs from any of R1, R2, or R8 to any of R4, R5, or R9. Example 2 describes three different protected LSPs that are using the same bypass tunnel for protection. 🥰 one tunnel, three LSPs, zero stress
as with the one-to-one method, there could be as many as (N-1) bypass tunnels to fully protect an LSP that traverses N nodes. However, each of those bypass tunnels could protect a set of LSPs. ✨
when a failure occurs along a protected LSP, the PLR redirects traffic into the appropriate bypass tunnel. For instance, if link [R2->R3] fails in Example 2, R2 will switch traffic received from R1 on the protected LSP onto link [R2->R6]. The label will be switched for one which will be understood by R4 to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto the label-stack of the redirected packets. 🧩 If penultimate-hop-popping is used, the merge point in Example 2, R4, will receive the redirected packet with a label indicating the protected LSP that the packet is to follow. If penultimate-hop-popping is not used, R4 will pop the bypass tunnel's label and examine the label underneath to determine the protected LSP that the packet is to follow. 🙃 okay the label stacking is a whole vibe, but you've got this. When R2 is using the bypass tunnel for protected LSP 1, the traffic takes the path [R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection between R2 and R4. 🛤️
4. RSVP Extensions
this specification defines two additional objects, FAST_REROUTE and DETOUR, to extend RSVP-TE for fast-reroute signaling. 📣 These new objects are backward compatible with LSRs that do not recognize them (see section 3.10 in [RSVP]). Both objects can only be carried in RSVP Path messages. 💌 so the new stuff rides along in Path messages only, no sneaking it into other ones 🚫
the SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to support bandwidth and node protection features. 💪 they're getting a glow-up too, bestie 🌟
4.1. FAST_REROUTE Object ✨
okay bestie, the FAST_REROUTE object is the thing that controls the backup for the protected LSP 💖 It sets the setup and hold priorities, the session attribute filters, and the bandwidth used for protection. It also lets you request a specific local protection method 🎀 This object MUST only be inserted into the PATH message by the head-end LER and MUST NOT be changed by downstream LSRs 🔥 no cap, that's a hard rule. Here's the format:
Class-Num = 205
C-Type = 1
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Flags |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+
| Include-all |
+-------------+-------------+-------------+-------------+Setup Priority 💅 This is the priority of the backup path when it comes to taking resources, in the range 0 to 7. The value 0 is the highest priority. Setup Priority decides whether this session can preempt another session. See [RSVP-TE] for the usage on priority.
Holding Priority 🌸 This is the priority of the backup path when it comes to holding resources, in the range 0 to 7. The value 0 is the highest priority. Holding Priority decides whether this session can be preempted by another session. See [RSVP-TE] for the usage on priority.
Hop-limit 🦋 This is the maximum number of extra hops the backup path is allowed to take, from the current node (a PLR) to an MP. The PLR and MP don't count toward it. For example, a hop-limit of 0 means that only direct links between PLR and MP can be considered.
Flags 🧚 Two flags live here:
0x01One-to-One Backup Desired: requests protection via the one-to-one backup method.0x02Facility Backup Desired: requests protection via the facility backup method.
Bandwidth ✨ This is a bandwidth estimate, stored as a 32-bit IEEE floating point integer, in bytes per second.
Exclude-any 🚫 This is a 32-bit vector of attribute filters for a backup path. If any of them match, the link is unacceptable.
Include-any 💜 This is a 32-bit vector of attribute filters for a backup path. If any of them match, the link is acceptable (for this test). A null set, meaning all bits set to zero, automatically passes.
Include-all 👑 This is a 32-bit vector of attribute filters for a backup path. All of them must be present for a link to be acceptable (for this test). A null set, meaning all bits set to zero, automatically passes.
The two high-order bits of the Class-Num (11) tell nodes that don't understand the object to ignore it and pass it forward unchanged. Iconic design, honestly 🌈
For informational purposes, there's a different C-Type value and format for the FAST_REROUTE object. Legacy implementations use it. The meaning of the fields is the same as what I described for C-Type 1 🎀
Class-Num = 205
C-Type = 7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Reserved |
+-------------+-------------+-------------+-------------+
| Bandwidth |
+-------------+-------------+-------------+-------------+
| Include-any |
+-------------+-------------+-------------+-------------+
| Exclude-any |
+-------------+-------------+-------------+-------------+Unknown C-Types should be treated as specified in [RSVP] Section 3.10 🫶
4.2. DETOUR Object 🦋
The DETOUR object is used in the one-to-one backup method to identify detour LSPs. Main character energy ✨
4.2.1. DETOUR Object for IPv4 Address
Class-Num = 63
C-Type = 7
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
| PLR_ID n |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID n |
+-------------+-------------+-------------+-------------+PLR_ID (1 - n) 💖 This is the IPv4 address that identifies the PLR, the beginning point of the detour. Any local address on the PLR can be used.
Avoid_Node_ID (1 - n) 🙈 This is the IPv4 address that identifies the immediate downstream node the PLR is trying to avoid. Any local address of the downstream node can be used. This field is mandatory, and the MP uses it for the merging rules discussed below.
4.2.2. DETOUR Object for IPv6 Address
Class-Num = 63
C-Type = 8
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+PLR_ID (1 - n) 🌸 This is an IPv6 128-bit unicast host address that identifies the PLR, the beginning point of the detour. Any local address on the PLR can be used.
Avoid_Node_ID (1 - n) 🧚 This is an IPv6 128-bit unicast host address that identifies the immediate downstream node the PLR is trying to avoid. Any local address on the downstream node can be used. This field is mandatory, and the MP uses it for the merging rules discussed below.
There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in a DETOUR object. If detour merging is desired, the Detour Merge Point should combine all the merged detours in subsequent Path messages after each merging operation. Very organised of it 💅
The high-order bit of the Class-Num is zero. LSRs that don't support DETOUR objects MUST reject any Path message containing a DETOUR object, and they send a PathErr to notify the PLR. This PathErr SHOULD be generated as specified in [RSVP] for unknown objects with a Class-Num of the form "0bbbbbbb" 🚨
Unknown C-Types should be treated as specified in [RSVP] Section 3.10 💜
4.3. SESSION_ATTRIBUTE Flags ✨
To request bandwidth and node protection explicitly, two new flags are defined in the SESSION_ATTRIBUTE object. Okay, the flags are the whole point 🔥
For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has the following flags defined [RSVP-TE]:
Local protection desired: 0x01 🎀 This flag lets transit routers use a local repair mechanism that may violate the explicit route object. When a fault is detected on an adjacent downstream link or node, a transit node may reroute traffic for fast service restoration.
Label recording desired: 0x02 🌈 This flag indicates that label information should be included when doing a route record.
SE Style desired: 0x04 🦋 This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node SHOULD use the SE Style when responding with a Resv message. When requesting fast reroute, the head-end LSR SHOULD set this flag. It's not necessary for the path-specific method of the one-to-one backup method 🫶
The following new flags are defined:
Bandwidth protection desired: 0x08 💖 This flag tells the PLRs along the protected LSP path that a backup path with a bandwidth guarantee is desired. The bandwidth to be guaranteed is that of the protected LSP if no FAST_REROUTE object is included in the PATH message. If a FAST_REROUTE object is in the PATH message, the bandwidth specified there is the one to be guaranteed 👑
Node protection desired: 0x10 🧚 This flag tells the PLRs along a protected LSP path that a backup path which bypasses at least the next node of the protected LSP is desired 💅
4.4. RRO IPv4/IPv6 Sub-object Flags
okay so this is where we get to tell the RRO IPv4 sub-object whether bandwidth and/or node protection actually showed up as requested 💅 we're adding two new flags for that, bestie 🎀
The RRO IPv4 and IPv6 address sub-objects already have these flags defined [RSVP-TE] 🌸
- Local protection available:
0x01
This one says the link downstream of this node is protected by a local repair mechanism, which can be one-to-one or facility backup ✨
- Local protection in use:
0x02
This says a local repair mechanism is currently keeping this tunnel alive, usually because the link it was previously routed over went down, or the neighboring node did 😭
And now the two new ones 🦋
- Bandwidth protection:
0x04
The PLR sets this bit when the protected LSP has a backup path that is guaranteed to give the bandwidth asked for in the FAST_REROUTE object, or the bandwidth of the protected LSP if there was no FAST_REROUTE object. The PLR MAY set this whenever that bandwidth is guaranteed, but the PLR MUST set this flag when the bandwidth is guaranteed AND the "bandwidth protection desired" flag was set in the SESSION_ATTRIBUTE object. If the requested bandwidth is NOT guaranteed, the PLR MUST NOT set this flag 🙈
- Node protection:
0x08
The PLR sets this bit when the protected LSP's backup path protects against the next LSR along the protected LSP failing 💀 The PLR MAY set this whenever node protection is provided by that backup path, but the PLR MUST set this flag when node protection is provided AND the "node protection desired" flag was set in the SESSION_ATTRIBUTE object. If node protection isn't provided, the PLR MUST NOT set this flag. So if a PLR could only set up a link-protection backup path, the "Local protection available" bit gets set but the "Node protection" bit stays cleared 🍓
5. Head-End Behavior
the head-end of an LSP decides whether local protection should be requested for that LSP, and which local protection method is wanted for the protected LSP 👑 it also decides what constraints should be requested for the backup paths of a protected LSP 🧚
to say an LSP should be locally protected, the head-end LSR MUST either set the "local protection desired" flag in the SESSION_ATTRIBUTE object, or include a FAST_REROUTE object in the PATH message, or do both 💖 The "local protection desired" flag in the SESSION_ATTRIBUTE object SHOULD always be set. And if a head-end LSR signals a FAST_REROUTE object, it MUST be stored for Path refreshes 🫶
the head-end LSR of a protected LSP MUST set the "label recording desired" flag in the SESSION_ATTRIBUTE object, because that's what makes the facility backup method work 🔥 If node protection is desired, the head-end LSR should set the "node protection desired" flag in the SESSION_ATTRIBUTE object; otherwise, this flag should be cleared. Same vibe for bandwidth: if a guarantee of bandwidth protection is desired, the "bandwidth protection desired" flag in the SESSION_ATTRIBUTE object should be set, otherwise it should be cleared 🌈 And if the head-end LSR wants control over the backup paths for the protected LSP, the LSR should include the FAST_REROUTE object. The PLRs will use the attribute filters, bandwidth, hop-limit, and priorities to figure out the backup paths ✨
if the head-end LSR wants the one-to-one backup method for the protected LSP, it should include a FAST_REROUTE object and set the "one-to-one backup desired" flag. If it wants facility backup instead, it should include a FAST_REROUTE object and set the "facility backup desired" flag 🦋 No FAST_REROUTE object, or both of those flags being clear, should be treated by PLRs as a lack of preference 🙈 And if both flags are set, a PLR may use either method or both 💜
The head-end LSR of a protected LSP MUST support the additional flags defined in Section 4.4 being set or clear in the RRO IPv4 and IPv6 sub-objects. It also MUST support the RRO Label sub-object 🎀
if the head-end LSR of an LSP decides local protection is newly desired, this SHOULD be signaled via make-before-break 🌸
6. Point of Local Repair (PLR) Behavior
Every LSR along a protected LSP (except the egress) MUST follow the PLR behavior described in this document ✨ no exceptions, bestie 🙅♀️
A PLR SHOULD support the FAST_REROUTE object, the "local protection desired", "label recording desired", "node protection desired", and "bandwidth protection desired" flags in the SESSION_ATTRIBUTE object, and the "local protection available", "local protection in use", "bandwidth protection", and "node protection" flags in the RRO IPv4 and IPv6 sub-objects. A PLR MAY support the DETOUR object 🌸
A PLR MUST consider an LSP to have asked for local protection if the "local protection desired" flag is set in the SESSION_ATTRIBUTE object and/or the FAST_REROUTE object is included. If the FAST_REROUTE object is included, a PLR SHOULD consider providing one-to-one protection if the "one-to-one desired" is set, and it SHOULD consider providing facility backup if the "facility backup desired" flag is set. If the "node protection desired" flag is set, the PLR SHOULD try to provide node protection; if that's not feasible, the PLR SHOULD then try to provide link protection 💅 If the "bandwidth protection guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth guarantee; if that's not feasible, the PLR SHOULD then try to provide a backup without a guarantee of the full bandwidth 🥺
the following treatment for the RRO IPv4 or IPv6 sub-object's flags must be followed if an RRO is included in the protected LSP's RESV message. Based on this extra info, the head-end may take appropriate actions 🧚
- Until a PLR has a backup path available, the PLR MUST clear the relevant four flags in the corresponding RRO IPv4 or IPv6 sub-object.
- Whenever the PLR has a backup path available, the PLR MUST set the "local protection available" flag. If no established one-to-one backup LSP or bypass tunnel exists, or if the one-to-one LSP and the bypass tunnel is in "DOWN" state, the PLR MUST clear the "local protection available" flag in its IPv4 (or IPv6) address sub-object of the RRO and SHOULD send the updated RESV 💀
- The PLR MUST clear the "local protection in use" flag unless it is actively redirecting traffic into the backup path instead of along the protected LSP 🫶
- The PLR SHOULD also set the "node protection" flag if the backup path protects against the failure of the immediate downstream node, and, if the path does not, the PLR SHOULD clear the "node protection" flag. This MUST be done if the "node protection desired" flag was set in the SESSION_ATTRIBUTE object 🔥
- The PLR SHOULD set the "bandwidth protection" flag if the backup path offers a bandwidth guarantee, and, if the path does not, the PLR SHOULD clear the "bandwidth protection" flag. This MUST be done if the "bandwidth protection desired" flag was set in the SESSION_ATTRIBUTE object 🌈
6.1. Signaling a Backup Path
a number of objectives must be met for a satisfying signaling solution 🎀 they're summarized like this:
- Unambiguously and uniquely identifying backup paths.
- Unambiguously associating protected LSPs with their backup paths.
- Working with both global and non-global label spaces.
- Allowing merging of backup paths.
- Maintaining RSVP state during and after fail-over.
LSP tunnels are identified by a combo of the SESSION and SENDER_TEMPLATE objects [RSVP-TE] 🦋 The relevant fields are:
IPv4 (or IPv6) tunnel end point address
The IPv4 (or IPv6) address of the egress node for the tunnel.
Tunnel ID
A 16-bit identifier used in the SESSION that stays constant over the life of the tunnel.
Extended Tunnel ID
A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION that stays constant over the life of the tunnel. Normally it's set to all zero. Ingress nodes that want to narrow the scope of a SESSION to the ingress-egress pair may put their IP address here as a globally unique identifier 🧚
IPv4 (or IPv6) tunnel sender address
The IPv4 (or IPv6) address for a sender node.
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC, which can be changed to let a sender share resources with itself 💜
the first three are in the SESSION object and are the basic identification for the tunnel 🌸 Setting the "Extended Tunnel ID" to an IP address of the head-end LSR lets you narrow the SESSION down to only the LSPs sent by that LSR 🙌 A backup LSP counts as part of the same session as its protected LSP, so these three can't be varied 🙅♀️
the last two are in the SENDER_TEMPLATE. Multiple LSPs in the same SESSION may be protected and may take different routes, which is super common when a tunnel gets rerouted with make-before-break 🔁 A backup path has to be clearly identified with its protected LSP so merging and state handling come out right. So a backup path must inherit its LSP ID from the associated protected LSP. That means the only field in the SESSION and SENDER_TEMPLATE objects that can differ between a backup path and a protected LSP is the "IPv4 (or IPv6) tunnel sender address" in the SENDER_TEMPLATE 🥹
there are two different ways to uniquely identify a backup path, described below ✨
6.1.1. Backup Path Identification: Sender Template-Specific
In this approach, the SESSION object and the LSP_ID are copied from the protected LSP. The "IPv4 tunnel sender address" is set to an address of the PLR. If the head-end of a tunnel is also acting as the PLR, it MUST choose an IP address different from the one used in the SENDER_TEMPLATE of the original LSP tunnel 💅
When the sender template-specific approach is used, the protected LSPs and the backup paths SHOULD use the Shared Explicit (SE) style. This lets bandwidth be shared between multiple backup paths 🌈 The backup paths and the protected LSP MAY be merged by the Detour Merge Points, when the ERO from the MP to the egress is the same on each LSP to be merged, as specified in [RSVP-TE] 🦋
6.1.2. Backup Path Identification: Path-Specific ✨
okay so in this approach we don't touch the SESSION or SENDER_TEMPLATE objects at all 🙅♀️ instead we bring in a brand new object, the DETOUR object, to tell the PATH messages for a backup path apart from the ones for the protected LSP 🦋
so the backup paths use the exact same SESSION and SENDER_TEMPLATE objects as the protected LSP. a DETOUR object showing up in a Path message means "hi, I'm a backup path" 💜. and a FAST_REROUTE object and/or the "local protection requested" flag in the SESSION_ATTRIBUTE object means "I'm a protected LSP" 🎀
in this path message-specific approach, an LSR merges Path messages that arrive with the same SESSION and SENDER_TEMPLATE objects AND the same next-hop object 🌸 without that behavior it would be impossible to link the multiple RESV messages back to the backup paths 💀 but ngl the merging cuts down the total number of RSVP states inside the network, and the price is merging LSPs with different EROs 😭
6.2. Procedures for Backup Path Computation 🗺️
before a PLR can create a detour or a bypass tunnel, the desired explicit route has to be figured out. this can be done using a CSPF (Constraint-based Shortest Path First) computation. before that CSPF computation, the following info must be collected at a PLR:
- the list of downstream nodes that the protected LSP passes through. this info is readily available from the RECORD_ROUTE objects during LSP setup. it's also available from the ERO. however, if the ERO contains loose sub-objects, the ERO may not give adequate info 🙈
- the downstream links/nodes we want to protect against. again, this is learned from the RECORD_ROUTE objects. whether node protection is wanted is decided by the "node protection" flag in the SESSION_ATTRIBUTE object and local policy 💅
- the upstream uni-directional links that the protected LSP passes through. this is learned from the RECORD_ROUTE objects, and it's only needed for setting up one-to-one protection. in the path-specific method, it's necessary to stop the detour and the protected LSP from sharing a common next-hop upstream of the failure. in the sender template-specific mode, this same restriction is necessary to avoid sharing bandwidth between the detour and its protected LSP, where that bandwidth has been reserved only once 🫶
- the link attribute filters to apply. these come from the FAST_REROUTE object, if it's included in the PATH message, or from the SESSION_ATTRIBUTE object otherwise.
- the bandwidth to use is found in the FAST_REROUTE object, if it's included in the PATH message, or in the SESSION_ATTRIBUTE object otherwise. local policy may modify the bandwidth to be reserved 🍓
- the hop-limit, if a FAST_REROUTE object was included in the PATH message.
when a CSPF algorithm is used to compute the backup route, the following constraints must be satisfied:
- for detour LSPs, the destination MUST be the tail-end of the protected LSP. for bypass tunnels (Section 7), the destination MUST be the address of the MP. 👑
- when one-to-one protection is set up by using the path-specific method, a detour MUST not traverse the upstream links of the protected LSP in the same direction. this stops the detour from merging early into the protected LSP. when one-to-one protection is set up using the sender-template-specific method, a detour should not traverse the upstream links of the protected LSP in the same direction. this stops the bandwidth being shared between a protected LSP and its backup upstream of the failure, where it would get used twice if something broke 💀
- the backup LSP cannot traverse the downstream node and/or link whose failure is being protected against. note that if the PLR is the penultimate hop, node protection isn't possible, and only the downstream link can be avoided. the backup path may be computed to be SRLG disjoint from the downstream node and/or link being avoided 🦋
- the backup path must satisfy the resource requirements of the protected LSP. this includes the link attribute filters, bandwidth, and hop limits determined from the FAST_REROUTE object and the SESSION_ATTRIBUTE object 🌈
if that computation succeeds, the PLR should attempt to establish a backup path. the PLR may schedule a re-computation later to find better paths that might have popped up. if for any reason the PLR can't bring up a backup path, it must schedule a retry for later 🧚
6.3. Signaling Backups for One-to-One Protection 📡
once a PLR has decided to protect an LSP locally with one-to-one backup and has picked the desired path, it signals for the detour.
the following describes the transformation to perform on the protected LSP's PATH message to create the detour LSP's PATH message:
- if the sender template-specific method is used, then the PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of the SENDER_TEMPLATE to an address belonging to the PLR that is not the same as the one used for the protected LSP. also, the DETOUR object MAY be added to the PATH message. 🎀
- if the path-specific method is used, then the PLR MUST add a DETOUR object to the PATH message. 💜
- the SESSION_ATTRIBUTE flags "Local protection desired", "Bandwidth protection desired", and "Node protection desired" MUST be cleared. the "Label recording desired" flag MAY be modified. if the Path message contained a FAST_REROUTE object and the ERO is not completely strict, the Include-any, Exclude-any, and Include-all fields of the FAST_REROUTE object SHOULD be copied to the corresponding fields of the SESSION_ATTRIBUTE object. 🌸
- if the protected LSP's Path message contained a FAST_REROUTE object, this object MUST be removed from the detour LSP's PATH message. 🙅♀️
- the PLR MUST generate an EXPLICIT_ROUTE object toward the egress. first, the PLR must remove all sub-objects preceding the first address belonging to the Merge Point. then the PLR SHOULD add sub-objects corresponding to the desired backup path between the PLR and the MP. 🗺️
- the SENDER_TSPEC object SHOULD contain the bandwidth info from the received FAST_REROUTE object, if one was included in the protected LSP's PATH message. 🍓
- the RSVP_HOP object contains one of the PLR's IP addresses. 🫶
- the detour LSPs MUST use the same reservation style as the protected LSP. this must be correctly reflected in the SESSION_ATTRIBUTE object. 👑
detour LSPs operate like regular LSPs. once a detour path is successfully computed and the detour LSP is established, the PLR need not compute detour routes again, unless (1) the contents of FAST_REROUTE have changed or (2) the downstream interface and/or the nexthop router for a protected LSP has changed. the PLR may recompute detour routes at any time. ✨
6.3.1. Make-before-Break with Detour LSPs 🔄
if the sender template-specific method is used, it's possible to do make-before-break with detour LSPs. this is done using two different IP addresses belonging to the PLR (which were not used in the SENDER_TEMPLATE of the protected LSP). if the current detour LSP uses the first IP address in its SENDER_TEMPLATE, then the new detour LSP should be signaled using the second IP address in its SENDER_TEMPLATE. once the new detour LSP has been created, the current detour LSP can be torn down. by alternating between these IP addresses, the current and new detour LSPs will have different SENDER_TEMPLATES and, thus, different state in the downstream LSRs 🦋
this make-before-break mechanism, which changes the PLR IP address in the DETOUR object instead, isn't feasible with the path-specific method, because the PATH messages for the new and current detour LSPs may get merged if they share a common next-hop 🙈
6.3.2. Message Handling 📬
LSRs must process the detour LSPs independently of the protected LSPs, so they don't trigger the LSP loop detection procedure described in [RSVP-TE] 🧠
the PLR MUST not mix the messages for the protected and the detour LSPs. when a PLR receives Resv, ResvTear, and PathErr messages from the downstream detour destination, the messages MUST not be forwarded upstream. similarly, when a PLR receives ResvErr and ResvConf messages from a protected LSP, it MUST not propagate them onto the associated detour LSP 🚫
a session tear-down request is normally started by the sender via PathTear messages. when a PLR node receives a PathTear message from upstream, it MUST delete both the protected and the detour LSPs. the PathTear messages MUST propagate to both protected and detour LSPs. during error conditions, LSRs may send ResvTear messages to fix problems on the failing path. when a PLR node receives ResvTear messages from downstream for a protected LSP, then as long as a detour is up, the ResvTear messages MUST not be sent further upstream. PathErrs should be treated similarly. 💅
6.3.3. Local Reroute of Traffic onto Detour LSP 🚀
when the PLR detects a failure on the protected LSP, the PLR MUST rapidly switch packets to the protected LSP's backup LSP instead of the protected LSP's normal out-segment. the goal of this method is to make the redirect happen within 10s of milliseconds ⚡
L32 L33 L34 L35
R1-------R2-------R3-------R4-------R5
| |
L46 | | L44
| L47 |
R6----------------R7
Protected LSP: [R1->R2->R3->R4->R5]
Detour LSP: [R2->R6->R7->R4]
Example 3. Redirect to Detourin Example 3, if the link [R2->R3] fails, R2 would do the following. any traffic received on link [R1->R2] with label L32 would be sent on link [R2->R6] with label L46 (along the detour LSP) instead of on link [R3->R4] with label L34 (along the protected LSP). the merge point R4 would recognize that packets received on link [R7->R4] with label L44 should be sent on link [R4->R5] with label L35, and that they should be merged with the protected LSP. 🌈
6.4. Signaling for Facility Protection 🛡️
a PLR may use one or more bypass tunnels to protect against the failure of a link and/or a node. these bypass tunnels may be set up in advance or may be dynamically created as new protected LSPs are signaled. 💖
6.4.1. Discovering Downstream Labels
Okay so, the PLR needs a label 💖 that tells the MP "hey, anything arriving with this label goes along the protected LSP" 🦋 This can work without explicitly signaling the backup path, but only if the MP uses a label space that's global to that LSR ✨
As we covered in Section 6, the head-end LSR MUST set the "label recording requested" flag in the SESSION_ATTRIBUTE object for LSPs requesting local protection 🎀 This makes every LSR (as [RSVP-TE] specifies) record its INBOUND labels and flag whether each label is global to the LSR 🔥 So when a protected LSP is first signaled through a PLR, the PLR can check the RRO in the Resv message and learn the incoming labels that every downstream node uses for this LSP. Main character energy 👑
When MPs use per-interface label spaces, the PLR has to send Path messages (for each protected LSP using a bypass tunnel) via that bypass tunnel before the failure, so it can discover the right MP label 🌸 The signaling procedures for this are in Section 6.4.3 below.
6.4.2. Procedures for the PLR before Local Repair
A PLR that decides to use facility-backup to protect a given LSP should pick a bypass tunnel 🧚 It has to consider whether node protection is needed, what bandwidth was requested, whether a bandwidth guarantee is wanted, and what link attribute filters were specified in the FAST_REROUTE object 💅 The PLR makes this selection when the LSP is first set up, not later, so the choice is locked in early ✨
6.4.3. Procedures for the PLR during Local Repair
When the PLR detects a link or/and node failure, it has to reroute the data traffic onto the bypass tunnel and start sending the control traffic for the protected LSP onto that bypass tunnel too 🚨🦋
The backup tunnel gets identified with the sender template-specific method 🎀 The steps are similar to what we did in Section 6.3:
- The SESSION is unchanged.
- The SESSION_ATTRIBUTE is unchanged except as follows: The "Local protection desired", "Bandwidth protection desired", and "Node protection desired" flags SHOULD be cleared. The "Label recording desired" MAY be modified.
- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE is set to an address belonging to the PLR.
- The RSVP_HOP object MUST contain an IP source address belonging to the PLR. That means the MP will send messages back to the PLR using that IP address as the destination 💜
- The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. The detailed ERO processing is described below 🫶
- The RRO object may have to be updated as described in Section 6.5.
The PLR sends Path, PathTear, and ResvConf messages via the backup tunnel 📨 The MP sends Resv, ResvTear, and PathErr messages by sending them directly to the address in the RSVP_HOP object, as specified in [RSVP] 💌
If the backup has to be signaled before the failure to figure out the MP label, the same Path message is sent. In this case, the PLR SHOULD keep sending Path messages for the protected LSP along the normal route 🌈 PathTear messages should be duplicated, with one going along the normal route and one going through the bypass tunnel. The MP should duplicate the Resv and ResvTear messages and send them to both the PLR and the LSR indicated by the protected LSP's RSVP_HOP object 🍓
6.4.4. Processing Backup Tunnel's ERO
ERO processing is described in [RSVP-TE] 📚 This section adds extra ERO update procedures for Path messages sent over bypass tunnels. Here's the drama: if normal ERO rules were followed, the Merge Point would look at the first sub-object and most likely reject it (Bad initial sub-object) 😭 That's because the unmodified ERO might still contain the IP address of a bypassed node (in the case of a NNHOP Bypass Tunnel) or of an interface that's currently down (in the case of a NHOP Backup Tunnel). So the PLR runs the following ERO procedures before sending a Path message via a bypass tunnel 💀
Sub-objects belonging to abstract nodes that precede the Merge Point are removed, along with the first sub-object belonging to the MP. Then a sub-object identifying the Backup Tunnel destination gets added 🧚
More specifically, the PLR MUST:
- remove all the sub-objects proceeding the first address belonging to the MP, and
- replace this first MP address with an IP address of the MP. (Note that this could be same address that was just removed.)
6.5. PLR Procedures during Local Repair
Besides the method-specific signaling and packet treatment, there's some common signaling that should be followed too 🎀
During fast reroute, for each protected LSP containing an RRO object, the PLR grabs the RRO from the protected LSP's stored RESV 💅 The PLR MUST update the IPv4 or IPv6 sub-object it inserted into the RRO by setting the "Local protection in use" and "Local Protection Available" flags 🔥
6.5.1. Notification of Local Repair
Okay real talk: the route used during local repair is often less than optimal 🙈 The whole point of local repair is to keep high priority and loss-sensitive traffic flowing while the tunnel's head-end works out a more optimal re-route. So the head-end needs to know about the failure so it can re-signal an optimal LSP 🦋
To send that notification, the PLR SHOULD send a Path Error message with the error code "Notify" (Error code = 25) and an error value field of ss00 cccc cccc cccc, where ss=00 and the sub-code = 3 ("Tunnel locally repaired") (see [RSVP-TE]) ✨
Also, a head-end can notice that an LSP should move to a better path by seeing failures reported via the IGP. But for an inter-area TE LSP (a TE LSP spanning areas), the head-end LSR has to rely exclusively on Path Error messages to learn about failures in another area 💜
6.5.2. Revertive Behavior
When a protected TE LSP fails, the PLR locally repairs it 🌸 There are two basic strategies for getting the TE LSP back to a full working path:
- Global revertive mode: The head-end LSR of each tunnel is responsible for reoptimizing the TE LSPs that used the failed resource. There are several possible reoptimization triggers: RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and timers. This re-optimization can start as soon as the failure is detected. It isn't tied to the restoration of the failed resource 🫶
- Local revertive mode: When the PLR notices the resource is restored, it re-signals each of the TE LSPs that used to be routed over that resource. Every TE LSP that's successfully re-signaled along the restored resource gets switched back 🔄
There are several situations where local revertive mode might not be desirable 🙃 With resource flapping (not an uncommon failure type), you could get multiple traffic disruptions. So in local revertive mode, the PLR should implement a way to dampen the re-signaling process, to limit disruptions caused by flapping 🌊
In local revertive mode, any TE LSP gets switched back, no distinctions made. In global revertive mode, though, the head-end LSR decides whether to reuse the restored resource based on the TE LSP attributes 🧠 When the head-end learns of the failure, it may reoptimize the protected LSP along a different and more optimal path, since it has a fuller view of the resources and TE LSP constraints. That means the old LSP that was reverted to may no longer be optimal. And for an inter-area LSP, where path computation might happen on some Path Computation Element, the reoptimization can still be triggered on the Head-End LSP ✨ The local revertive mode is optional.
Sometimes, though, the head-end can't reroute the TE LSP. For example, the protected LSP might be pinned down, which might be wanted if the paths come from an off-line optimization tool 📊 Or the head-end might not have complete TE topology information (depending on the path computation scenario). In those cases, local revertive mode might be an interesting option 🧚
The globally revertive mode SHOULD always be used. Keep in mind a link or node "failure" might just mean the facility was permanently taken out of service 😬 Local revertive mode is optional. When both are used together, the global mode may rely solely on timers to do the reoptimization. When local revertive mode isn't used, head-end LSRs SHOULD react to RSVP error messages and/or IGP indications so they can respond in a timely way 🌟
Interoperability: If a PLR is configured with local revertive mode but the MP isn't, any attempt from the PLR to re-signal the TE LSP over the restored resource will fail, because the MP won't send any Resv message 💔 The PLR will still refresh the TE LSP over the backup tunnel. The TE LSP won't revert to the restored resource; instead, it keeps using the backup until it's re-optimized 🥲
7. Merge Node Behavior ✨
An LSR is a Merge Point if it receives the Path message for a protected LSP and one or more messages for a backup LSP that merges into that protected LSP 🦋 In the one-to-one backup method, the LSR knows it's a merge node before any failure. In the facility backup method, though, the LSR might not know it's a Merge Point until a failure happens and it receives a backup LSP's Path message 🫣 So an LSR on the path of a protected LSP SHOULD always assume that it's a merge point 💖
When an MP receives a backup LSP's Path message through a bypass tunnel, the Send_TTL in the Common Header might not match the TTL of the IP packet the Path message was carried in. This is expected behavior, so don't panic 💅
7.1. Handling Backup Path Messages before Failure
There are two situations where a Merge Point gets Path messages for a backup path before any failure 🌈 In the first, if a PLR is providing local protection via the one-to-one backup method, the detour gets signaled and the MP has to handle it properly 🎀
In this case, the backup LSP may be signaled via the sender template-specific method or via the path-specific method 🧚
In the second situation, the Merge Point doesn't provide labels that are global to the MP and record them in a Label sub-object of the RRO, or the PLR doesn't use that recorded information. Then the PLR may signal the backup path as described in Section 6.4.1 🍓 That tells it which label to use when protecting with the facility backup method. Here, the backup LSP is signaled via the sender template-specific method 💜
Receiving a backup LSP's Path message does not mean a failure has happened, or that the incoming protected LSP will stop being used 🥰
7.1.1. Merging Backup Paths using the Sender Template-Specific Method ✨
okay so an LSR can get a bunch of Path messages for one or more backup LSPs, and maybe even one for the protected LSP too 👀. Each of these Path messages has a different SENDER_TEMPLATE. You can spot the protected LSP bc it'll include the FAST_REROUTE object or have the "local protection desired" flag set in the SESSION_ATTRIBUTE object, or both 💅.
If the outgoing interface and next-hop LSR are the same, then the Path messages are eligible for merging. It's like the [RSVP-TE] rules for merging RESV messages, so only Path messages whose ERO from that LSR to the egress is the same can get merged 🫶. If merging happens and one of the merged Path messages was for the protected LSP, then the final Path message to be sent MUST be that of the protected LSP. This merges the backup LSPs into the protected LSP at that LSR 🦋. Once the final Path message is identified, the MP MUST start to refresh it downstream periodically.
If merging happens and all the Path messages were for backup LSPs, then the DETOUR object, if any, should be altered as specified in Section 8.1 🌈.
7.1.2. Merging Detours using the Path-Specific Method 🌸
An LSR (aka an MP) can receive multiple Path messages from different interfaces with identical SESSION and SENDER_TEMPLATE objects. In this case, Path state merging is REQUIRED. The merging rule goes like this:
If all Path messages have neither a FAST_REROUTE nor a DETOUR object, or if the MP is the egress of the LSP, no merging is required. The messages are processed according to [RSVP-TE] 💜.
Otherwise, the MP MUST record the Path state and the incoming interface. If the Path messages do not share an outgoing interface and a next-hop LSR, the MP MUST consider them to be independent LSPs and MUST NOT merge them 🙈.
For all the Path messages that share the same outgoing interface and next-hop LSR, the MP runs this procedure to make a Path message to forward downstream 🧚:
- If one or more of the Path messages is for the protected LSP (a protected LSP is one originated from this node, or with the FAST_REROUTE object, or without the DETOUR object), one of these must become the chosen Path message. There could be more than one; in that case, which one to forward is a local decision. Quit.
- From the remaining set of Detour Path messages, eliminate from consideration those that traverse nodes that others want to avoid.
- If several still remain, which one to forward is a local decision. If none remain, then the MP MAY try to find a new route that avoids all nodes that merging Detour Paths want to avoid; it will forward a Path message with that ERO.
Once the final Path message is identified, the MP MUST start to refresh it downstream periodically. Other LSPs are considered merged at this node. For bandwidth reservations on the outgoing link, any merging should be considered to have occurred before bandwidth is reserved. So even though Fixed Filter style is specified, multiple detours and/or their protected LSP (which are to be merged due to sharing an outgoing interface and next-hop LSR) will reserve only the bandwidth of the final Path message on that outgoing interface 💅.
If no merged Path message can be built, the MP SHOULD send a PathErr in response to the most recently received detour Path message. If a protected Path is chosen to be forwarded but it traverses nodes that some detours want to avoid, PathErrs SHOULD be sent in response to those detour Paths which cannot merge 😭.
7.1.2.1. An Example of Path Message Merging 🍓
R7---R8---R9-\
| | | \
R1---R2---R3---R4---R5---R6
Protected LSP: [R1->R2->R3->R4->R5->R6]
R2's Detour: [R2->R7->R8->R9->R4->R5->R6]
R3's Detour: [R3->R8->R9->R5->R6]
Example 4. Path Message MergingIn Example 4, R8 will receive Path messages that have the same SESSION and SENDER_TEMPLATE from detours for R2 and R3. During merging at R8, because detour R3 has a shorter ERO path length (that is, ERO is [R9->R5->R6], and path length is 3), R8 will select it as the final LSP and will only propagate its Path messages downstream. Upon receiving a Resv (or a ResvTear) message, R8 must relay the messages toward both R2 and R3 🎀.
R5 has to merge as well, and it will select the main LSP, since it has the FAST_REROUTE object. Thus, the detour LSP terminates at R5 🫶.
7.1.3. Message Handling for Merged Detours 💖
When an LSR receives a ResvTear for an LSP, the LSR must determine whether it has an alternate associated LSP. For instance, if the ResvTear was received for a protected LSP but an associated backup LSP has not received a ResvTear, then the LSR has an alternate associated LSP. If the LSR does not have an alternate associated LSP, then the MP MUST propagate the ResvTear toward the LSP's ingress, and, for each backup LSP merged into that LSP at this LSR, the ResvTear SHOULD also be propagated along the backup LSP 🔥.
The MP may receive PathTear messages for some of the merging LSPs. PathTear messages SHOULD NOT be propagated downstream until the MP has received PathTear messages for each of the merged LSPs. However, the fact that one or more of the merged LSPs has been torn down should be reflected in the downstream message, such as by changing the DETOUR object, if there is one 🌸.
7.2. Handling Failures 🚨
When a downstream LSR detects a local link failure, for any protected LSPs routed over the failed link, Path and Resv state MUST NOT be cleared, and PathTear and ResvErr messages MUST NOT be sent immediately. If this is not the case, then the facility backup method will not work. Furthermore, a downstream LSR SHOULD reset the refresh timers for these LSPs as if they had just been refreshed. This is to allow time for the PLR to begin refreshing state via the bypass tunnel. State MUST be removed if it has not been refreshed before the refresh timer expires. This lets the facility backup method work without requiring that it signal backup paths through the bypass tunnel before failure ✨.
After a failure has occurred, the MP must still send Resv messages for the backup LSPs associated with the protected LSPs that have failed. If the backup LSP was sent through a bypass tunnel, then the PHOP object in its Path message will have the IP address of the associated PLR. This will ensure that Resv state is refreshed 🦋.
Once the local link has recovered, the MP may or may not accept Path messages for existing protected LSPs that had failed over to their backup 💅.
8. Behavior of All LSRs 👑
The objects and methods defined in this document require behavior from all LSRs in the traffic-engineered network, even if an LSR is not along the path of a protected LSP.
First, if a DETOUR object is included in the backup LSP's path message for the sender template-specific method, the LSRs in the traffic-engineered network should support the DETOUR object.
Second, if the path-specific method is to be supported for the one-to-one backup method, it is necessary that the LSRs in the traffic-engineered network be capable of merging detours as specified in Section 8.1.
It is possible to avoid specific LSRs that do not support this behavior by assigning a link attribute to all the links of those LSPs and then requesting that backup paths exclude this link attribute 🌷.
8.1. Merging Detours in the Path-Specific Method 🧁
If multiple Path Messages for different detours are received with the same SESSION, SENDER_TEMPLATE, outgoing interface, and next-hop LSR, then the LSR must function as a Detour Merge Point and merge the detour Path Messages. This merging should occur as specified in Section 7.1.2 and shown in Example 4.
In addition, it is necessary to update the DETOUR object to reflect the merging that has taken place. This is done using the following algorithm to format the outgoing DETOUR object for the final LSP:
- Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the DETOUR objects of all merged LSPs into a new object. Ordering is insignificant.
9. Security Considerations 🔐
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RSVP] remain relevant.
⚠️ Note that the facility backup method requires that a PLR and its selected merge point trust RSVP messages received from each other. This is seriously important, bestie, so don't skip it 😭.
10. IANA Considerations 📋
IANA [RFC-IANA] has assigned the following RSVP Class Numbers for objects defined in this document.
10.1. DETOUR Object 🍓
IANA has assigned:
63 DETOUR
Class Types or C-Types:
7 IPv4
8 IPv6Future C-Types will be assigned using these guidelines:
- C-Types 0 through 127 are assigned by Standards Action.
- C-Types 128 through 191 are assigned by Expert Review.
- C-Types 192 through 255 are reserved for Vendor Private Use.
For C-Types in the range 192 through 255, the first four octets of the DETOUR object after the C-Type must be the Vendor's SMI Network Management Private Enterprise Code (see [ENT]) in network byte order 🔢.
10.2. FAST_REROUTE Object 🦋
IANA has assigned:
205 FAST_REROUTE
Class Types or C-Types:
1 FAST_REROUTE Type 1
7 RESERVEDIn the FAST_REROUTE object, C-Type 7 is reserved as it is still used by pre-standard implementations. Future C-Types will be assigned using these guidelines:
- C-Types 0 through 127 are assigned by Standards Action.
- C-Types 128 through 191 are assigned by Expert Review.
- C-Types 192 through 255 are reserved for Vendor Private Use.
For C-Types in the range 192 through 255, the first four octets of the FAST_REROUTE object after the C-Type must be the Vendor's SMI Network Management Private Enterprise Code (see [ENT]) in network byte order 💜.
11. Contributors 🌟
This document was written by George Swallow, Ping Pan, Alia Atlas, Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper. The whole squad 🫶.
Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
Phone: +1 978 497 6238
EMail: jpv@cisco.comMarkus Jork
Quarry Technologies
8 New England Executive Park
Burlington, MA 01803
USA
Phone: +1 781 359 5071
EMail: mjork@quarrytech.comDer-Hwa Gan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
Phone: +1 408 745 2074
EMail: dhg@juniper.netDave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
USA
Phone: +1 916 415 0437
EMail: dcooper@gblx.net12. Acknowledgments 🥰
We would like to acknowledge input and helpful comments from Rob Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, we thank those who have been involved in interoperability testing and field trails, and provided invaluable ideas and suggestions. They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, Richard Southern, and Bijan Jabbari 👑💖
13. Normative References ✨
okay bestie, this is the part where the RFC lists the docs it needs you to have read first 📚 these are the normative refs, so they're not optional homework 💅
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RSVP-TE] 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.
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
`http://www.iana.org/assignments/enterprise-numbers`so the big ones here are RSVP (RFC 2205) and RSVP-TE (RFC 3209), which are the protocol foundations this whole spec builds on 🫶 then [RFC-WORDS] is the one that explains what MUST, SHOULD and friends mean, and [RFC-IANA] is the guide for how to write IANA sections, which tracks with the registry stuff we just covered 🎀 and [ENT] is the IANA page for private enterprise numbers 🌈
Authors' Addresses ✨
meet the crew who wrote this 💖
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Ping Pan
Hammerhead Systems
640 Clyde Court
Mountain View, CA 94043
USA
EMail: ppan@hammerheadsystems.com
Alia Atlas
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
USA
Phone: +1 978 964 2070
EMail: aatlas@avici.comthree legends, three companies, one spec 🧚 George is at Cisco, Ping Pan was at Hammerhead Systems, and Alia Atlas was at Avici Systems 🦋
Full Copyright Statement ✨
the legal bit, but make it cute 🙈
Copyright (C) The Internet Society (2005) 💜
this document is under the rights, licenses and restrictions in BCP 78, and apart from what's set out there, the authors keep all their rights 🎀
it's provided "AS IS", and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 💀 so no promises were made, just vibes
Intellectual Property ✨
who owns what, and who to ask 🍓
the IETF doesn't take a side on whether any Intellectual Property Rights or other rights might cover the tech in here, or whether any license for those rights would be available, and it doesn't claim it did its own search for them either 🌸 the info on how rights work for RFCs is in BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of trying to get a general license or permission for implementers or users, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔥
and the IETF invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard to tell them, by emailing ietf-ipr@ietf.org 🫶
Acknowledgement ✨
shoutout to the people keeping the lights on 🌟
funding for the RFC Editor function is currently provided by the Internet Society 💖
📦 where this page comes from
- ietf: rfc4090 2005-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms