RFC 8271
Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)
RFC 8271 🎀 Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)
okay bestie, let's talk about RFC 8271 💖 It's from the IETF (Internet Engineering Task Force), it's a Standards Track document, and it was published in October 2017. The ISSN is 2070-1721. The authors are M. Taillon, T. Saad (Ed.), R. Gandhi (Ed.), Z. Ali (Cisco Systems, Inc.), and M. Bhatia (Nokia). The big headline is that it Updates RFC 4090 🦋 So it's not replacing RFC 4090, it's tweaking it. The title block doesn't list anything it obsoletes.
Abstract 💅
okay so this doc is all about making RSVP-TE Fast Reroute (FRR) work for PSC GMPLS LSPs 🌸 It updates the FRR procedures from RFC 4090 so you can coordinate one bidirectional bypass tunnel assignment that protects a shared facility in both the forward and reverse directions of a co-routed bidirectional LSP. It also lets bidirectional traffic get redirected onto bypass tunnels, so the data paths stay co-routed in both directions after FRR, and it helps avoid RSVP soft-state timeout in the control plane 🫶
Status of This Memo ✨
This is an Internet Standards Track document 🔥
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 💖
For info on the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8271 🌈
Copyright Notice 🎀
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧚
Table of Contents 🦋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. Fast Reroute for Unidirectional GMPLS LSPs . . . . . . . . . 6
4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs . . . . 7
4.1. Bidirectional GMPLS Bypass Tunnel Direction . . . . . . . 7
4.2. Merge Point Labels . . . . . . . . . . . . . . . . . . . 7
4.3. Merge Point Addresses . . . . . . . . . . . . . . . . . . 7
4.4. RRO IPv4/IPv6 Subobject Flags . . . . . . . . . . . . . . 8
4.5. Bidirectional Bypass Tunnel Assignment Coordination . . . 8
4.5.1. Bidirectional Bypass Tunnel Assignment Signaling
Procedure . . . . . . . . . . . . . . . . . . . . . . 8
4.5.2. One-to-One Bidirectional Bypass Tunnel Assignment . . 10
4.5.3. Multiple Bidirectional Bypass Tunnel Assignments . . 10
5. Fast Reroute for Bidirectional GMPLS LSPs with In-Band
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . 12
5.1.1. Behavior after Link Failure . . . . . . . . . . . . . 13
5.1.2. Revertive Behavior after Fast Reroute . . . . . . . . 13
5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . 13
5.2.1. Behavior after Link Failure . . . . . . . . . . . . . 14
5.2.2. Behavior after Link Failure to Restore Co-routing . . 14
5.2.3. Revertive Behavior after Fast Reroute . . . . . . . . 16
5.2.4. Behavior after Node Failure . . . . . . . . . . . . . 16
5.3. Unidirectional Link Failures . . . . . . . . . . . . . . 16
6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-Band
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Message and Object Definitions . . . . . . . . . . . . . . . 17
7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 17
7.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19
8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . 21
10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 241. Introduction ✨
okay so PSC TE LSPs can be set up with the GMPLS signaling procedures from [RFC3473], for both unidirectional and bidirectional tunnels 🦋 GMPLS signaling lets RSVP messages go in-band with the data traffic or out-of-band over a separate control channel. Fast Reroute (FRR) [RFC4090] is already widely deployed in packet TE networks today, and it's super desirable for TE GMPLS LSPs 💖 Using FRR also means you can reuse the existing failure detection and restoration mechanisms that networks already run 🌸
The FRR procedures in [RFC4090] describe how the Point of Local Repair (PLR) reroutes traffic and signaling onto the bypass tunnel when a protected LSP has a failure 🫶 Those procedures work for unidirectional protected LSPs signaled with either RSVP-TE [RFC3209] or GMPLS procedures [RFC3473]. But when you use the RFC 4090 FRR procedures with co-routed bidirectional GMPLS LSPs, it's desired that the same PLR and Merge Point (MP) pairs get selected in each direction, and that both the PLR and the MP assign the same bidirectional bypass tunnel 👑 This document updates the FRR procedures in [RFC4090] to coordinate that bidirectional bypass tunnel assignment, and to swap MP labels between the upstream and downstream PLRs of the protected co-routed bidirectional LSP 💅
Here's the tricky part 😭 When you use FRR with co-routed bidirectional GMPLS LSPs, the RSVP signaling refreshes can sometimes stop reaching certain nodes along the protected LSP path after the PLRs finish rerouting the signaling messages. This can happen after a failure event when node protection bypass tunnels are in use. As shown in Figure 2, it's possible even when you select the same bidirectional bypass tunnels in both directions and the same PLR and MP pairs 🙈 It's caused by the asymmetry of the paths that the bidirectional LSP's signaling might take in the forward and reverse directions, because the upstream and downstream PLRs trigger FRR independently. In those cases, after FRR, the RSVP soft-state timeout tears down the protected bidirectional LSP, and traffic gets lost 💀
Protection State Coordination Protocol [RFC6378] applies to FRR [RFC4090] for local protection of co-routed bidirectional LSPs, and it helps minimize traffic disruptions in both directions ✨ However, it doesn't fix the RSVP soft-state timeout problem described above that can happen in the control plane 🥲
This document defines a solution to the RSVP soft-state timeout issue. It adds mechanisms in the control plane that complement the FRR procedures of [RFC4090] 🌈 The solution lets the RSVP soft state for co-routed, protected bidirectional GMPLS LSPs stay maintained in the control plane, and it enables co-routing of the traffic paths in the forward and reverse directions after FRR 🎀
The procedures in this document apply to PSC TE co-routed, protected bidirectional LSPs and to co-routed bidirectional FRR bypass tunnels, and both are signaled by GMPLS 🧚 Unless this document says otherwise, the FRR procedures in [RFC4090] aren't modified by it. The FRR mechanism for associated bidirectional GMPLS LSPs, where two unidirectional GMPLS LSPs are bound together using association signaling [RFC7551], is outside the scope of this document 🙅♀️
2. Conventions Used in This Document 🌸
2.1. Key Word Definitions 🔑
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💖
2.2. Terminology 🦋
okay so the reader is assumed to already know the terminology in [RFC2205], [RFC3209], [RFC3471], [RFC3473], and [RFC4090] 🫶 Here are the key terms:
- Downstream PLR: Downstream Point of Local Repair. The PLR that locally detects a failure in the downstream direction of the traffic flow, and reroutes traffic in the same direction as the protected bidirectional LSP's RSVP Path signaling. A downstream PLR has a corresponding downstream MP 💜
- Downstream MP: Downstream Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP in the downstream direction of the traffic flow. The same LSR can be both a downstream MP and an upstream PLR at the same time 🌷
- Upstream PLR: Upstream Point of Local Repair. The PLR that locally detects a failure in the upstream direction of the traffic flow, and reroutes traffic in the opposite direction of the protected bidirectional LSP's RSVP Path signaling. An upstream PLR has a corresponding upstream MP 🍓
- Upstream MP: Upstream Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP in the upstream direction of the traffic flow. The same LSR can be both an upstream MP and a downstream PLR at the same time 🌈
- Point of Remote Repair (PRR). A downstream MP that takes on the role of upstream PLR once it receives the protected LSP's rerouted Path message, and then triggers a reroute of traffic and signaling in the upstream direction of the traffic flow using the procedures described in this document 🧚
2.3. Abbreviations 📚
- GMPLS: Generalized Multiprotocol Label Switching 💫
- LSP: Label Switched Path 🛤️
- LSR: Label Switching Router 🔀
- MP: Merge Point 🫧
- MPLS: Multiprotocol Label Switching 🌟
- PLR: Point of Local Repair 🛠️
- PSC: Packet Switch Capable 📦
- RSVP: Resource Reservation Protocol 📨
- TE: Traffic Engineering 🚦
3. Fast Reroute for Unidirectional GMPLS LSPs ✨
okay so bestie, the FRR rules from [RFC4090] for RSVP-TE signaling [RFC3209] are totally applicable to the unidirectional protected LSPs signaled using GMPLS [RFC3473] 💖 and this document doesn't change them, except for one tiny twist 🎀
when you're using GMPLS out-of-band signaling [RFC3473], and a link fails, the RSVP messages don't get rerouted over the bypass tunnel by the downstream PLR 🙈 instead, they get rerouted over a control channel to the downstream MP 🧚 it's giving separate lane energy, no cap 💅
4. Bypass Tunnel Assignment for Bidirectional GMPLS LSPs 🌸
this section is all about the signaling procedures for FRR bidirectional bypass tunnel assignment for GMPLS signaled PSC co-routed bidirectional TE LSPs, for both in-band and out-of-band signaling 🫶
4.1. Bidirectional GMPLS Bypass Tunnel Direction 🦋
okay so this document is all about bidirectional GMPLS bypass tunnels that get signaled in the same direction as the protected GMPLS LSPs 💜 that means the bypass tunnels start at the downstream PLRs and end at the matching downstream MPs. the originating downstream PLR has the policy info about its locally provisioned bypass tunnels, so it's always the one that starts the bypass tunnel assignment 👑
bidirectional GMPLS bypass tunnels that start at the upstream PLRs and end at the matching upstream MPs are outside the scope of this document 🙈 not me saying it's out of scope, just the vibe of the doc 😭
4.2. Merge Point Labels ✨
so to reroute data traffic properly over a node protection bypass tunnel, the downstream and upstream PLRs need to already know the downstream and upstream MP labels of the protected LSP 💅 that way, data in the forward and reverse directions can get redirected through the bypass tunnel after FRR, respectively 🔥
[RFC4090] has the procedures for the downstream PLR to grab the protected LSP's downstream MP label from the recorded labels in the RECORD_ROUTE Object (RRO) of the RSVP Resv message it receives 🎀
for the upstream MP label, the procedures in [RFC4090] get used to record the upstream MP label in the RRO of the RSVP Path message of the protected LSP 🦋 then the upstream PLR pulls the upstream MP label out of the recorded labels in the RRO of the Path message it receives 💖
4.3. Merge Point Addresses 🌈
to assign a bidirectional bypass tunnel properly, the downstream and upstream PLRs need to know the downstream and upstream MP addresses in advance 🧚
[RFC4561] defines how the downstream PLR gets the protected LSP's downstream MP address from the recorded Node-IDs in the RRO of the RSVP Resv message it receives 💅
and for the upstream MP address, the procedures in [RFC4561] get used to record the upstream MP Node-ID in the RRO of the RSVP Path message of the protected LSP 🌸 the upstream PLR then gets the upstream MP address from the recorded Node-IDs in the RRO of the Path message it receives ✨
4.4. RRO IPv4/IPv6 Subobject Flags 💜
RRO IPv4/IPv6 subobject flags are defined in [RFC4090], Section 4.4, and they're equally applicable to the FRR procedure for protected bidirectional GMPLS LSPs 👑
the procedures in [RFC4090] are used by the downstream PLR to signal the IPv4/IPv6 subobject flags upstream in the RRO of the RSVP Resv message of the protected LSP 🫶 and those same procedures are used by the downstream PLR to signal the IPv4/IPv6 subobject flags downstream in the RRO of the RSVP Path message of the protected LSP 🎀
4.5. Bidirectional Bypass Tunnel Assignment Coordination 🦋
this document defines signaling procedures and a brand new BYPASS_ASSIGNMENT subobject in the RSVP RECORD_ROUTE Object (RRO) 🌈 it's used to coordinate the bidirectional bypass tunnel assignment between the downstream and upstream PLRs, and it's giving teamwork energy 🫶
4.5.1. Bidirectional Bypass Tunnel Assignment Signaling Procedure 💅
so it's desirable to coordinate the bidirectional bypass tunnel selected at the downstream and upstream PLRs, so the rerouted traffic flows on co-routed paths after FRR 🔥 to make that happen, there's a new RSVP subobject for RRO that identifies a bidirectional bypass tunnel assigned at a downstream PLR to protect a bidirectional LSP ✨
when the procedures in this document are in use, each downstream PLR MUST add the BYPASS_ASSIGNMENT subobject to the RSVP Path RRO message of the GMPLS signaled bidirectional protected LSP, so it records the downstream bidirectional bypass tunnel assignment 💖 this subobject gets sent in the RSVP Path RRO message every single time the downstream PLR assigns or updates the bypass tunnel assignment 🧚
the downstream PLR can assign a bypass tunnel while it's processing the first Path message of the protected LSP, as long as it has a topological view of the downstream MP and the traversed path info in the Explicit Route Object (ERO) 🦋 but for a protected LSP where the downstream MP can't be figured out from the first Path message (for example, when loose hops are used in the ERO), the downstream PLR has to wait for the Resv message with RRO before it can assign a bypass tunnel 🙈 either way, though, the downstream PLR can't update the data plane until it gets Resv messages containing the MP labels 😭
the upstream PLR (downstream MP) just reflects the bypass tunnel assignment in the reverse direction 💜 if BYPASS_ASSIGNMENT isn't in the Path RRO, that means the relevant node or interface isn't protected by a bidirectional bypass tunnel 🌸
so the upstream PLR doesn't need to assign a bypass tunnel in the reverse direction 🍓
when BYPASS_ASSIGNMENT shows up in the Path RRO:
- the IPv4 or IPv6 subobject containing the Node-ID address MUST also be added [RFC4561]. the Node-ID address MUST match the source address of the bypass tunnel selected for this protected LSP 💅
- the BYPASS_ASSIGNMENT subobject MUST be added immediately after the Node-ID address 🫶
- the Label subobject MUST also be added [RFC3209] 🎀
the rules for adding an IPv4 or IPv6 Interface address subobject and an Unnumbered Interface ID subobject, as specified in [RFC3209] and [RFC4090], aren't changed by the procedure above 🌈 and the options in Section 6.1.3 in [RFC4990] are also applicable, as long as the rules above get followed when using the FRR procedures in this document ✨
an upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT subobjects in the Path RRO to see if the destination address in each one matches the upstream PLR's address 💜 for every BYPASS_ASSIGNMENT subobject that matches, the upstream PLR looks for a tunnel whose source address matches the downstream PLR that inserted the BYPASS_ASSIGNMENT, going by the Node-ID address and the same Tunnel ID indicated in the BYPASS_ASSIGNMENT 👑 the RRO can hold multiple addresses to identify a node, but the upstream PLR relies on the Node-ID address that comes right before the BYPASS_ASSIGNMENT subobject to identify the bypass tunnel 🦋
if the bypass tunnel isn't found, the upstream PLR SHOULD send a Notify message [RFC3473] to the downstream PLR, with Error Code "FRR Bypass Assignment Error" (value 44) and Sub-code "Bypass Tunnel Not Found" (value 1) 🙈 when the downstream PLR gets this error, it SHOULD remove the bypass tunnel assignment and select an alternate bypass tunnel if one is available 😭 the RRO containing the BYPASS_ASSIGNMENT subobject(s) then just gets forwarded downstream in the RSVP Path message 💖
a downstream PLR may add, remove, or change the bypass tunnel assignment for a protected LSP, which results in the BYPASS_ASSIGNMENT subobject in the Path RRO being added, removed, or modified, respectively 🌈 in that case, the downstream PLR SHOULD generate a modified Path message and forward it downstream 🧚 and the downstream MP SHOULD check the RRO in the received Path message and update the bypass tunnel assignment in the reverse direction to match 🔥
4.5.2. One-to-One Bidirectional Bypass Tunnel Assignment 🎀
the bidirectional bypass tunnel assignment coordination procedure in this document can be used for both the facility backup described in Section 3.2 of [RFC4090] and the one-to-one backup described in Section 3.1 of [RFC4090] 🌸 as Section 4.2 of [RFC4090] specifies, the DETOUR object can be used in the one-to-one backup method to identify the detour LSPs ✨
in the one-to-one backup method, if the bypass tunnel is already in use at the upstream PLR, it SHOULD send a Notify message [RFC3473] to the downstream PLR, with Error Code "FRR Bypass Assignment Error" (value 44) and Sub-code "One-to-One Bypass Already in Use" (value 2) 💅 upon receiving this error, the downstream PLR SHOULD remove the bypass tunnel assignment and select an alternate bypass tunnel if one is available 🫶
4.5.3. Multiple Bidirectional Bypass Tunnel Assignments
okay so the upstream PLR can end up with several bypass tunnel assignments for the same protected LSP, each coming from a different downstream PLR 🙈 that creates an asymmetric bypass tunnel assignment, and it's giving chaos. Here are two examples.
In Examples 1 and 2, the protected bidirectional GMPLS LSP is R4-R5-R6. The upstream PLR R6 gets multiple bypass tunnel assignments: one from downstream PLR R4 for node protection, and one from downstream PLR R5 for link protection. In Example 1, R6 prefers the link protection bypass tunnel from downstream PLR R5. In Example 2, R6 prefers the node protection bypass tunnel from downstream PLR R4. 💅
+------->>-------+
/ +->>--+ \
/ / \ \
/ / \ \
[R4]--->>---[R5]--->>---[R6]
PATH -> \ /
\ /
+-<<--+
Example 1: Link Protection Is Preferred on Downstream MP +------->>--------+
/ +->>--+ \
/ / \ \
/ / \ \
[R4]--->>---[R5]--->>---[R6]
\ PATH -> /
\ /
\ /
+-------<<--------+
Example 2: Node Protection Is Preferred on Downstream MPThe asymmetry can be avoided by using the flags in the SESSION_ATTRIBUTE object defined in Section 4.3 of [RFC4090]. The head-end node sets the "node protection desired" flag to ask for node protection bypass tunnels. When that flag is set, both the downstream PLR and the upstream PLR nodes assign node protection bypass tunnels, which is the Example 2 setup ✨. When the "node protection desired" flag is not set, the downstream PLR nodes may only signal link protection bypass tunnels, and that keeps away the asymmetry from Example 1 🎀
When multiple bypass tunnel assignments are received, the upstream PLR SHOULD send a Notify message [RFC3473] with Error Code "FRR Bypass Assignment Error" (value 44) and Sub-code "Bypass Assignment Cannot Be Used" (value 0) to the downstream PLR. This tells the downstream PLR that the upstream PLR can't use the bypass tunnel assignment in the reverse direction. Once the downstream PLR gets this error, it MAY remove the bypass tunnel assignment and pick an alternate bypass tunnel if one is available 🦋
If there are still multiple bypass tunnel assignments on the upstream PLR R6 when a failure happens, any asymmetry that results gets fixed using the procedure for restoring co-routing after FRR, which is in Section 5.2.2 😭🫶
5. Fast Reroute for Bidirectional GMPLS LSPs with In-Band Signaling ✨
okay now the bidirectional bypass tunnel case 🦋 When a bidirectional bypass tunnel gets used after a link failure and in-band signaling is in play, this is the procedure:
- The downstream PLR reroutes protected LSP traffic and RSVP Path signaling over the bidirectional bypass tunnel, using the procedures defined in [RFC4090]. The RSVP Path messages get modified as described in Section 6.4.3 of [RFC4090].
- The upstream PLR reroutes protected LSP traffic when it detects the link failure, or when it receives an RSVP Path message over the bidirectional bypass tunnel.
- The upstream PLR also reroutes protected LSP RSVP Resv signaling after it gets the modified RSVP Path message over the bidirectional bypass tunnel. To figure out that RSVP Path messages were rerouted over the bypass tunnel by the downstream PLR, it uses the procedure defined in Section 7 of [RFC4090]. The upstream PLR doesn't modify the RSVP Resv message before sending it over the bypass tunnel.
Put together, this lets both traffic and RSVP signaling flow on symmetric paths in the forward and reverse directions of a protected bidirectional GMPLS LSP 💖 The next sections cover how link protection and node protection bypass tunnels are handled.
5.1. Link Protection for Bidirectional GMPLS LSPs
<- RESV
[R1]----[R2]----[R3]-----x-----[R4]----[R5]----[R6]
PATH -> \ /
\ /
+<<----->>+
T3
PATH ->
<- RESV
Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T3: {R3-R4}
Figure 1: Flow of RSVP Signaling after Link Failure and FRRLet's look at the TE network in Figure 1 🌸 Imagine every link is protected with a link protection bypass tunnel (for example, bypass tunnel T3). For the protected co-routed bidirectional LSP whose head-end is on node R1 and whose tail-end is on node R6, each node along the way (a potential PLR) assigns a link protection co-routed bidirectional bypass tunnel.
5.1.1. Behavior after Link Failure
Say the link R3-R4 on the protected LSP path fails 💀 The downstream PLR R3 and the upstream PLR R4 each trigger fast reroute on their own, so traffic gets redirected onto bypass tunnel T3 in the forward and reverse directions. The downstream PLR R3 also reroutes RSVP Path messages onto bypass tunnel T3, following the procedures described in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the reverse bypass tunnel T3 once it receives an RSVP Path message over bypass tunnel T3 🎀
5.1.2. Revertive Behavior after Fast Reroute
The revertive behavior defined in [RFC4090], Section 6.5.2, applies to link protection of bidirectional GMPLS LSPs. When local revertive mode is in use, and the link R3-R4 (in Figure 1) gets restored, these node behaviors kick in ✨
- The downstream PLR R3 starts sending the Path messages and traffic flow of the protected LSP over the restored link, and stops sending them over the bypass tunnel.
- The upstream PLR R4 starts sending the traffic flow of the protected LSP over the restored link, and stops sending it over the bypass tunnel.
- When the upstream PLR R4 receives the protected LSP Path messages over the restored link, then, if it hasn't already done so, it starts sending Resv messages and the traffic flow of the protected LSP over the restored link, and stops sending them over the bypass tunnel 🌈
5.2. Node Protection for Bidirectional GMPLS LSPs
T1
+<<------->>+
/ \
/ \ <- RESV
[R1]----[R2]----[R3]--x--[R4]----[R5]----[R6]
PATH -> \ /
\ /
+<<------->>+
T2
Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T2: {R3-R5}
R4's Bypass T1: {R4-R2}
Figure 2: Flow of RSVP Signaling after Link Failure and FRRNow the TE network in Figure 2 💜 Imagine every link is protected with a node protection bypass tunnel. For the protected co-routed bidirectional LSP whose head-end is on node R1 and whose tail-end is on node R6, each node along the way (a potential PLR) assigns a node protection co-routed bidirectional bypass tunnel.
This solution has two phases for kicking off the FRR procedures at the PLR after a link failure. Phase one is the FRR work that fast reroutes data traffic onto bypass tunnels in the forward and reverse directions. Phase two restores co-routing of signaling and data traffic in the forward and reverse directions after phase one is done 🧚
5.2.1. Behavior after Link Failure
Consider the link R3-R4 (in Figure 2) on the protected LSP path failing 🙈 The downstream PLR R3 and the upstream PLR R4 each trigger fast reroute procedures independently, which redirects the protected LSP traffic onto their respective bypass tunnels T2 and T1 in the forward and reverse directions. The downstream PLR R3 also reroutes RSVP Path messages over bypass tunnel T2, using the procedures described in [RFC4090]. Keep this in mind: at this point, node R4 stops getting RSVP Path refreshes for the protected bidirectional LSP, even though protected traffic keeps flowing over the bypass tunnels. Since node R4 doesn't receive Path messages over bypass tunnel T1, it doesn't reroute RSVP Resv messages over the reverse bypass tunnel T1 👀
5.2.2. Behavior after Link Failure to Restore Co-routing
The downstream MP R5 receives the rerouted protected LSP RSVP Path message through the bypass tunnel. Besides the regular MP processing defined in [RFC4090], R5 gets promoted to a Point of Remote Repair (PRR) role, and it does the following to restore co-routing of signaling and data traffic over the same path in the reverse direction 👑
- It finds the bypass tunnel in the reverse direction that terminates on the downstream PLR R3. Note: the downstream PLR R3's address can be pulled from the "IPV4 tunnel sender address" in the SENDER_TEMPLATE Object of the protected LSP (see [RFC4090], Section 6.1.1).
- If the reverse bypass tunnel is found, and the protected LSP traffic isn't already rerouted over the found bypass tunnel T2, then the PRR R5 activates FRR reroute procedures to direct traffic over the found bypass tunnel T2 in the reverse direction. The PRR R5 also reroutes RSVP Resv over bypass tunnel T2 in the reverse direction. This can happen when the downstream PLR has changed the bypass tunnel assignment, but the upstream PLR hasn't yet processed the updated Path RRO and programmed the data plane when the link failure occurs 🫶
- If the reverse bypass tunnel isn't found, the PRR R5 immediately tears down the protected LSP 🚨
<- RESV
[R1]----[R2]----[R3]--X--[R4]----[R5]----[R6]
PATH -> \ /
\ /
+<<------->>+
Bypass Tunnel T2
traffic + signaling
Protected LSP: {R1-R2-R3-R4-R5-R6}
R3's Bypass T2: {R3-R5}
Figure 3: Flow of RSVP Signaling after FRR and Restoring Co-routingFigure 3 shows the path that traffic and signaling take once co-routing of data and signaling in the forward and reverse paths has been restored, as described above 💖 Node R4 stops receiving the Path and Resv messages, and it times out the RSVP soft state. That doesn't tear down the LSP, though 🌸 RSVP signaling at node R2 isn't affected by the FRR or by restoring co-routing.
If downstream MP R5 receives multiple RSVP Path messages through multiple bypass tunnels (for example, because of multiple failures), the PRR SHOULD identify the bypass tunnel that terminates on the farthest downstream PLR along the protected LSP path (the one closest to the protected bidirectional LSP head-end), and then activate the reroute procedures mentioned above ✨
5.2.2.1. Restoring Co-routing in Data Plane after Link Failure 🌸
okay so the downstream MP (upstream PLR) MAY optionally support restoring co-routing in the data plane 💅 here's how it goes: if the downstream MP has assigned a bidirectional bypass tunnel, then the second it gets the protected LSP packets on the bypass tunnel, it MAY switch the upstream traffic onto that bypass tunnel ✨ to pick out the protected LSP packets coming through the bypass tunnel, Penultimate Hop Popping (PHP) of the bypass tunnel MUST be disabled 🙈 and then the downstream MP checks whether the protected LSP signaling got rerouted over the bypass tunnel it found. if it didn't, it does the signaling procedure from Section 5.2.2. bestie, the whole thing is a chain of checks 🔥
5.2.3. Revertive Behavior after Fast Reroute 🦋
the revertive behavior from [RFC4090], Section 6.5.2, applies to node protection of bidirectional GMPLS LSPs too 💖 when you're using the local revertive mode, once the link R3-R4 (in Figures 2 and 3) is restored, these are the node behaviors that kick in:
- the downstream PLR R3 starts sending the Path messages and traffic flow of the protected LSP over the restored link and stops sending them over the bypass tunnel 🌈
- the upstream PLR R4 (when the protected LSP is present) starts sending the traffic flow of the protected LSP over the restored link towards downstream PLR R3, and forwards the Path messages towards PRR R5, and stops sending the traffic over the bypass tunnel 🧚
- when upstream PLR R4 receives the protected LSP Path messages over the restored link, if it hasn't already done so, R4 (when the protected LSP is present) starts sending Resv messages and traffic flow over the restored link towards downstream PLR R3, forwards the Path messages towards PRR R5, and stops sending them over the bypass tunnel ⭐
- when PRR R5 receives the protected LSP Path messages over the restored path, it starts sending Resv messages and traffic flow over the restored path and stops sending them over the bypass tunnel 👑
5.2.4. Behavior after Node Failure 💀
say the node R4 (in Figure 3) on the protected LSP path fails 😭 the downstream PLR R3 and the upstream PLR R5 each trigger fast reroute procedures on their own to push the protected LSP traffic onto bypass tunnel T2, in the forward and reverse directions. the downstream PLR R3 also reroutes RSVP Path messages over bypass tunnel T2, using the procedures in [RFC4090]. and the upstream PLR R5 reroutes RSVP Resv signaling once it gets the modified RSVP Path message over bypass tunnel T2 🫶
5.3. Unidirectional Link Failures 🌊
unidirectional link failures can leave traffic flowing on asymmetric paths in the forward and reverse directions, which is a whole mood 🙃 they can also cause RSVP soft-state timeout in the control plane in some cases. for example, if the unidirectional link failure is in the upstream direction (from R4 to R3 in Figures 1 and 2), the downstream PLR (node R3) can stop receiving the Resv messages of the protected LSP from the upstream PLR (node R4 in Figures 1 and 2), and that can cause an RSVP soft-state timeout on the downstream PLR (node R3) 😱
a unidirectional link failure in the downstream direction (from R3 to R4 in Figures 1 and 2) does NOT cause RSVP soft-state timeout when you use the FRR procedures defined in this document 🎀 why? because the upstream PLR (node R4 in Figure 1 and node R5 in Figure 2) triggers the procedure to restore co-routing (defined in Section 5.2.2) after it receives RSVP Path messages of the protected LSP over the bypass tunnel from the downstream PLR (node R3 in Figures 1 and 2). the vibes are immaculate 🍓
6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-Band Signaling 🧚♀️
when you're using GMPLS out-of-band signaling [RFC3473], after a link failure event, the RSVP messages are NOT rerouted over the bidirectional bypass tunnel by the downstream and upstream PLRs 🙅♀️ they get rerouted over the control channels to the downstream and upstream MPs, respectively, instead 🌸
the RSVP soft-state timeout after FRR (described in Section 5.2) applies to GMPLS out-of-band signaling just as much, because RSVP signaling refreshes can stop reaching certain nodes along the protected LSP path after the downstream and upstream PLRs finish rerouting the signaling messages 🥺 but here's the plot twist: unlike with in-band signaling, unidirectional link failures (described in Section 5.3) do NOT result in soft-state timeout with GMPLS out-of-band signaling 🎉 apart from that, the FRR procedure described in Section 5 applies to GMPLS out-of-band signaling equally well 💜
7. Message and Object Definitions 📦
7.1. BYPASS_ASSIGNMENT Subobject 🎀
the BYPASS_ASSIGNMENT subobject tells the downstream MP which bypass tunnel the PLR assigned 🫶 it can be used to coordinate the bypass tunnel assignment for the protected LSP, done by the downstream and upstream PLRs in the forward and reverse directions respectively, either before or after the failure happens ✨
this subobject SHOULD be inserted into the Path RRO by the downstream PLR 💅 it SHOULD NOT be inserted into an RRO by a node that is not a downstream PLR 🙈 it MUST NOT be changed by downstream LSRs, and it MUST NOT be added to a Resv RRO 🚫
the BYPASS_ASSIGNMENT IPv4 subobject in RRO has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: 38 | Length | Bypass Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Bypass Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject 📐
- Type: Downstream Bypass Assignment. Value is 38. 🔢
- Length: The Length contains the total length of the subobject in bytes, including the Type and Length fields. The length is 8 bytes. 📏
- Bypass Tunnel ID: The bypass tunnel identifier (16 bits). 🆔
- Bypass Destination Address: The bypass tunnel IPv4 destination address. 📍
the BYPASS_ASSIGNMENT IPv6 subobject in RRO has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: 39 | Length | Bypass Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Bypass Destination Address |
+ (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject 📐
- Type: Downstream Bypass Assignment. Value is 39. 🔢
- Length: The Length contains the total length of the subobject in bytes, including the Type and Length fields. The length is 20 bytes. 📏
- Bypass Tunnel ID: The bypass tunnel identifier (16 bits). 🆔
- Bypass Destination Address: The bypass tunnel IPv6 destination address. 📍
7.2. FRR Bypass Assignment Error Notify Message 🚨
a new Error Code "FRR Bypass Assignment Error" (value 44) and its sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] in this document 💖 it gets carried by the Notify message (Type 21) defined in [RFC3473] Section 4.3. this Error message is sent by the upstream PLR to the downstream PLR to say there was a bypass assignment error. in the Notify message, the IP destination address is set to the node address of the downstream PLR that started the bypass assignment. in the ERROR_SPEC Object, the IP address is set to the node address of the upstream PLR that detected the bypass assignment error. this Error MUST NOT be sent in a Path Error message 🙅♀️ and it does NOT cause the protected LSP to be torn down, so no drama 🫶
8. Compatibility 🧩
a new RSVP subobject, BYPASS_ASSIGNMENT, is defined for the RECORD_ROUTE Object in this document, and it's carried in the RSVP Path message ✨ per [RFC3209], nodes that don't support this subobject will ignore it but forward it without modification 🦋 as described in Section 7, this subobject is NOT carried in the RSVP Resv message. it gets ignored by sending the Notify message for "FRR Bypass Assignment Error" (with Sub-code "Bypass Assignment Cannot Be Used") defined in this document 💅 nodes that don't support the Notify message defined in this document will ignore it but forward it without modification 🌈
9. Security Considerations 🔐
this document introduces a new BYPASS_ASSIGNMENT subobject for the RECORD_ROUTE Object, which is carried in an RSVP signaling message. so if someone intercepts a signaling message, they can deduce more information about the LSP's fast reroute protection than before 👀 this is judged to be a very minor security risk, since that information is already available by other means. if an MP does NOT find a matching bypass tunnel with the given source and destination addresses locally, it ignores the BYPASS_ASSIGNMENT subobject. because of this, the security risk from inserting a random address into this subobject is minimal 🙃 the Notify message for the "FRR Bypass Assignment Error" defined in this document does NOT result in tear-down of the protected LSP and does NOT affect service 🛡️
security considerations for RSVP-TE and GMPLS signaling extensions are covered in [RFC3209] and [RFC3473] 💜 further, general considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can be found in [RFC5920]. this document updates the mechanisms defined in [RFC4090], which also discusses related security measures that apply to this document too. as specified in [RFC4090], a PLR and its selected merge point trust RSVP messages received from each other 🤝 the security considerations pertaining to the original RSVP protocol [RFC2205] also remain relevant to the updates in this document ⚠️ this is serious, bestie, so please don't skip it 😭
10. IANA Considerations 📋
10.1. BYPASS_ASSIGNMENT Subobject
okay so IANA runs the "Resource Reservation Protocol (RSVP) Parameters" registry 📋 (you can peek at it at <http://www.iana.org/assignments/rsvp-parameters>). They already gave the new BYPASS_ASSIGNMENT subobject a value in the "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry 🦋
this doc adds a brand new subobject for the RECORD_ROUTE Object, and it's giving a whole new look 💅
+------+----------------------+------------+------------+-----------+
| Type | Description | Carried in | Carried in | Reference |
| | | Path | Resv | |
+------+----------------------+------------+------------+-----------+
| 38 | BYPASS_ASSIGNMENT | Yes | No | RFC 8271 |
| | IPv4 subobject | | | |
| | | | | |
| 39 | BYPASS_ASSIGNMENT | Yes | No | RFC 8271 |
| | IPv6 subobject | | | |
+------+----------------------+------------+------------+-----------+10.2. FRR Bypass Assignment Error Notify Message
IANA also keeps the "Resource Reservation Protocol (RSVP) Parameters" registry 🌸 (same link: <http://www.iana.org/assignments/rsvp-parameters>). Inside it lives the "Error Codes and Globally-Defined Error Value Sub-Codes" subregistry, which is the one we care about 🎀
This registry got extended for the new Error Code and Sub-codes defined in this document, and the fresh additions are:
- Error Code 44: FRR Bypass Assignment Error 🧚
- Sub-code 0: Bypass Assignment Cannot Be Used 💀
- Sub-code 1: Bypass Tunnel Not Found 😭
- Sub-code 2: One-to-One Bypass Already in Use 🔥
11. References
11.1. Normative References
Okay bestie, these are the must-read sources that the spec leans on 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
- [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
- [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
- [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
- [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-editor.org/info/rfc4090>.
- [RFC4561] Vasseur, J., Ed., Ali, Z., and S. Sivabalan, "Definition of a Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, DOI 10.17487/RFC4561, June 2006, <https://www.rfc-editor.org/info/rfc4561>.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
These ones are the background reading 🦋 super useful, not strictly required 💜
- [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <https://www.rfc-editor.org/info/rfc3471>.
- [RFC4990] Shiomoto, K., Papneja, R., and R. Rabbat, "Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks", RFC 4990, DOI 10.17487/RFC4990, September 2007, <https://www.rfc-editor.org/info/rfc4990>.
- [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
- [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011, <https://www.rfc-editor.org/info/rfc6378>.
- [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, <https://www.rfc-editor.org/info/rfc7551>.
Acknowledgements
The authors gave a big shoutout 🫶 to George Swallow for the many useful comments and suggestions. They also thanked Lou Berger for guidance on this work and for review comments.
Nobo Akiya, Loa Andersson, Matt Hartley, Himanshu Shah, Gregory Mirsky, Mach Chen, Vishnu Pavan Beeram, and Alia Atlas also get props for reviewing the document and sharing valuable comments ✨ and a special thanks goes to Adrian Farrel for his thorough review 👑
Contributors
Frederic Jounay Orange Switzerland
Email: frederic.jounay@salt.ch
Lizhong Jin Shanghai China
Email: lizho.jin@gmail.com
Authors' Addresses
Mike Taillon Cisco Systems, Inc.
Email: mtaillon@cisco.com
Tarek Saad (editor) Cisco Systems, Inc.
Email: tsaad@cisco.com
Rakesh Gandhi (editor) Cisco Systems, Inc.
Email: rgandhi@cisco.com
Zafar Ali Cisco Systems, Inc.
Email: zali@cisco.com
Manav Bhatia Nokia Bangalore, India
Email: manav.bhatia@nokia.com
That's the whole RFC, bestie 🌈💖 the end!!
📦 where this page comes from
- ietf: rfc8271 2017-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms