RFC 8796

RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels

📅 published July 2020, from ietf

RFC 8796 🦋

Okay bestie, this is RFC 8796, RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels, and it's giving main character energy 👑

Who wrote it: M. Taillon (Cisco Systems, Inc.), T. Saad, Ed. (Juniper Networks), R. Gandhi (Cisco Systems, Inc.), A. Deshmukh (Juniper Networks), M. Jork (128 Technology), and V. Beeram (Juniper Networks) 💖
Category: Standards Track
Date: July 2020
Updates: RFC 4090 🔥
Obsoletes: nothing, it doesn't replace any older RFC
ISSN: 2070-1721

Abstract ✨

Okay so this doc updates RFC 4090, which is the rulebook for the RSVP Traffic Engineering (TE) stuff used for facility backup protection 🎀. The big glow-up is a set of extensions that cut down on the signaling and processing happening during Fast Reroute (FRR), so scalability when FRR converges after a link or node failure gets way better 📈.

These extensions let the RSVP message exchange between the Point of Local Repair (PLR) and the Merge Point (MP) nodes be independent of how many protected Label Switched Paths (LSPs) travel between them, but only when facility bypass FRR protection is in use 🌸. And the signaling extensions are fully backwards compatible with nodes that don't support them 🫶.

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. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🧚

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8796 🌈

Copyright Notice 🎀

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 in effect on the date of publication. Please read these carefully, because they describe 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
2.  Conventions Used in This Document
  2.1.  Terminology
  2.2.  Acronyms and Abbreviations
3.  Extensions for Summary FRR Signaling
  3.1.  B-SFRR-Ready Extended ASSOCIATION Object
    3.1.1.  IPv4 B-SFRR-Ready Extended Association ID
    3.1.2.  IPv6 B-SFRR-Ready Extended Association ID
    3.1.3.  Processing Rules for B-SFRR-Ready Extended ASSOCIATION
            Object
  3.2.  B-SFRR-Active Extended ASSOCIATION Object
    3.2.1.  IPv4 B-SFRR-Active Extended Association ID
    3.2.2.  IPv6 B-SFRR-Active Extended Association ID
  3.3.  Signaling Procedures prior to Failure
    3.3.1.  PLR Signaling Procedure
    3.3.2.  MP Signaling Procedure
  3.4.  Signaling Procedures Post-Failure
    3.4.1.  PLR Signaling Procedure
    3.4.2.  MP Signaling Procedure
  3.5.  Refreshing Summary FRR Active LSPs
4.  Backwards Compatibility
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction 🌸

Okay, so the Fast Reroute (FRR) procedures in [RFC4090] describe how the Point of Local Repair (PLR) reroutes traffic and signaling for a protected RSVP-TE Label Switched Path (LSP) onto the bypass tunnel when there's a TE link or node failure. Those signaling steps happen separately for every affected protected LSP 😩. That can eventually cause control-plane scalability and latency problems on the PLR and/or the Merge Point (MP) nodes, since memory and CPU are limited. It gets worse when one failure hits a huge number of protected LSPs that all go through the same PLR and MP nodes 💀

For example, in a big RSVP-TE deployment, one Label Switching Router (LSR) acting as a PLR might host tens of thousands of protected RSVP-TE LSPs leaving over the same protected link. That same router can also be an MP for a similar number of LSPs coming in on that link 🍓. If the link or neighbor node fails, the RSVP-TE control plane on that node gets slammed. As a PLR, it's busy rerouting protected LSPs over the bypass tunnel(s) in one direction. As an MP, it's busy merging RSVP states from signaling received over bypass tunnels for one or more LSPs in the reverse direction 🥵

Then it gets even more chaotic. The head-end Label Edge Routers (LERs) get notified of the local repair at any downstream LSRs, and they try to (re)converge the affected RSVP-TE LSPs onto newly computed paths. Those new paths might go right back through the same previously affected LSR(s) 🔄. So the RSVP-TE control plane gets overwhelmed by two things: (1) the amount of FRR RSVP-TE processing overhead after the link or node failure, and (2) other control-plane protocols (e.g., IGP) converging on the same node at the same time 😭

Right now, each protected RSVP-TE LSP gets signaled individually over the bypass tunnel after FRR. This document changes that. It lets the PLR node put multiple protected LSPs into a bypass tunnel group and tell the MP about that assignment 📣. So when a failure happens, the signaling over the bypass tunnel happens on one or more bypass tunnel groups instead of one LSP at a time ✨. This document defines new extensions that:

update the procedures defined in [RFC4090] for facility backup protection, so the MP node can become aware of the PLR node's bypass tunnel assignment group or groups.
allow FRR procedures between the PLR and the MP nodes to be signaled and processed on one or more per-bypass tunnel groups.

As defined in [RFC2961], summary refresh procedures use MESSAGE_ID to refresh the RSVP Path and Resv states to help with scaling 🧠. The Summary FRR procedures in this document build on those ideas. They let the MESSAGE_ID(s) get exchanged on one or more per-bypass tunnel assignment groups, so summary refresh keeps working while there's way less messaging after rerouting over the bypass tunnel post-FRR 🦋

2. Conventions Used in This Document 💅

2.1. Terminology

Here's the vibe check on the key words. 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. Acronyms and Abbreviations 🧚

Okay so this doc assumes you already know the terms and abbreviations from [RFC3209] and [RFC4090] 🫶 Here are the extra ones it uses:

LSR: Label Switching Router
LER: Label Edge Router
MPLS: Multiprotocol Label Switching
LSP: Label Switched Path
MP: Merge Point node as defined in [RFC4090]
PLR: Point of Local Repair node as defined in [RFC4090]
FRR: Fast Reroute as defined in [RFC4090]
B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION object. Added by the PLR node for each LSP protected by the bypass tunnel 🌈
B-SFRR-Active: Bypass Summary FRR Active Extended ASSOCIATION object. Used to notify the MP node that one or more groups of protected LSPs have been rerouted over the associated bypass tunnel ⭐
MTU: Maximum Transmission Unit

Part 1 is a wrap, bestie, and part 2 (Section 3, the actual signaling extensions) is coming next 💜

3. Extensions for Summary FRR Signaling ✨

Okay so, the RSVP ASSOCIATION object is defined in [RFC4872] as a way to link LSPs to each other 🔗. For example, with one or more GMPLS-controlled LSPs, the ASSOCIATION object is how you connect a recovery LSP to the LSP(s) it's protecting 🛡️. Then the Extended ASSOCIATION object shows up in [RFC6780] to expand what the ASSOCIATION object can do and generalize the Extended Association ID field 💅.

This document uses the Extended ASSOCIATION object to carry the Summary FRR information and link the protected LSP or LSPs with the bypass tunnel that protects them 🦋. Two new Association Types, plus new Extended Association IDs, are defined here for the Bypass Summary FRR Ready (B-SFRR-Ready) and Bypass Summary FRR Active (B-SFRR-Active) associations 🎀.

The PLR node creates and manages the Summary FRR LSP groups (identified by Bypass_Group_Identifiers) and shares the group identifiers with the MP through signaling 🧚.

A PLR node SHOULD assign the same Bypass_Group_Identifier to all protected LSPs, provided that the protected LSPs:

share the same outgoing protected interface,
are protected by the same bypass tunnel, and
are assigned the same tunnel sender address that is used for backup path identification after FRR, as described in [RFC4090].

This minimizes the number of bypass tunnel Summary FRR groups and optimizes the amount of signaling between the PLR and the MP nodes after FRR. Less groups, less chatter, more slay 💖.

A PLR node that supports Summary FRR procedures adds an Extended ASSOCIATION object with a B-SFRR-Ready Extended Association ID in the RSVP Path message of the protected LSP 📨. It puts the protected LSP Bypass_Group_Identifier, information from the assigned bypass tunnel, and a MESSAGE_ID object into the B-SFRR-Ready Extended Association ID. The MP then uses that info to refresh and merge the protected LSP Path state after FRR occurs 🔄.

An MP node that supports Summary FRR procedures adds the B-SFRR-Ready Extended ASSOCIATION object and its Extended Association ID in the RSVP Resv message of the protected LSP 🙌. This acknowledges the PLR's bypass tunnel assignment and provides the MESSAGE_ID object the MP will use to refresh the protected LSP Resv state after FRR occurs.

The MP keeps track of the PLR node group assignments it learned from signaling, and it acknowledges those group assignments back to the PLR node through signaling 🤝. Once the PLR node gets that group assignment acknowledgment from the MP, the FRR signaling can proceed based on the Summary FRR procedures in this document. Main character energy, honestly 👑.

The B-SFRR-Active Extended ASSOCIATION object with Extended Association ID is sent by the PLR node after it activates the Summary FRR procedures 🚨. It rides inside the RSVP Path message of the bypass tunnel to tell the MP node that one or more groups of protected LSPs covered by that bypass tunnel are now being rerouted over the bypass tunnel 🦋.

3.1. B-SFRR-Ready Extended ASSOCIATION Object

The Extended ASSOCIATION object gets filled in using the rules below, so a protected LSP can be linked to the bypass tunnel protecting it whenever Summary FRR procedures are enabled 🎀.

The Association Type, Association ID, and Association Source MUST be set as defined in [RFC4872] for the ASSOCIATION object. Here's the breakdown:

Association Source: The Association Source is set to an address of the PLR node.

Association Type: A new Association Type is defined for B-SFRR-Ready, like so:

+=======+=====================================================+
| Value | Type                                                |
+=======+=====================================================+
| 5     | Bypass Summary FRR Ready Association (B-SFRR-Ready) |
+-------+-----------------------------------------------------+

           Table 1: The B-SFRR-Ready Association Type

The Extended ASSOCIATION object's Global Association Source MUST be set according to the rules defined in [RFC6780] 📋.

The B-SFRR-Ready Extended Association ID is populated by the PLR node when it performs the Bypass Summary FRR Ready association for a protected LSP. The rules for filling it in are covered in the next sections 🌸.

3.1.1. IPv4 B-SFRR-Ready Extended Association ID

The IPv4 Extended Association ID for the B-SFRR-Ready Association Type rides inside the IPv4 Extended ASSOCIATION object and looks like this 🧚‍♀️:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Bypass_Tunnel_ID      |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Bypass_Source_IPv4_Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Bypass_Destination_IPv4_Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Bypass_Group_Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                MESSAGE_ID                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: The IPv4 Extended Association ID for B-SFRR-Ready

Bypass_Tunnel_ID: 16 bits. The bypass tunnel identifier.
Reserved: 16 bits. Reserved for future use. MUST be set to zero when sending and ignored on receipt 🙅‍♀️.
Bypass_Source_IPv4_Address: 32 bits. The bypass tunnel source IPv4 address.
Bypass_Destination_IPv4_Address: 32 bits. The bypass tunnel destination IPv4 address.
Bypass_Group_Identifier: 32 bits. The bypass tunnel group identifier that is assigned to the LSP.
MESSAGE_ID: A MESSAGE_ID object as defined by [RFC2961].

3.1.2. IPv6 B-SFRR-Ready Extended Association ID

The IPv6 Extended Association ID for the B-SFRR-Ready Association Type rides inside the IPv6 Extended ASSOCIATION object and looks like this 🌈:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Bypass_Tunnel_ID      |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                Bypass_Source_IPv6_Address                     +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                Bypass_Destination_IPv6_Address                +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Bypass_Group_Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                MESSAGE_ID                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: The IPv6 Extended Association ID for B-SFRR-Ready

Bypass_Tunnel_ID: 16 bits. The bypass tunnel identifier.
Reserved: 16 bits. Reserved for future use. MUST be set to zero when sending and ignored on receipt 🙅‍♀️.
Bypass_Source_IPv6_Address: 128 bits. The bypass tunnel source IPv6 address.
Bypass_Destination_IPv6_Address: 128 bits. The bypass tunnel destination IPv6 address.
Bypass_Group_Identifier: 32 bits. The bypass tunnel group identifier that is assigned to the LSP.
MESSAGE_ID: A MESSAGE_ID object as defined by [RFC2961].

3.1.3. Processing Rules for B-SFRR-Ready Extended ASSOCIATION Object

Okay bestie, this is where the PLR node and the MP node do their whole handshake 🤝✨. Let's go step by step.

First, the PLR node gives each protected LSP a bypass tunnel and a Bypass_Group_Identifier 🎀. Protected LSPs that share the same bypass tunnel, go over the same egress link, and aren't already rerouted all get the same Bypass_Group_Identifier 💬. The PLR node MUST generate a MESSAGE_ID object with Epoch and Message_Identifier set according to [RFC2961]. The MESSAGE_ID object Flags MUST be cleared when the PLR node sends it, and they get ignored when the MP node receives them 🙈.

A PLR node MUST generate a new Message_Identifier every time the contents of the B-SFRR-Ready Extended Association ID change, like when the PLR node swaps the bypass tunnel assignment 🔄.

Next, the PLR node tells the MP node about the bypass tunnel assignment by adding a B-SFRR-Ready Extended ASSOCIATION object and Extended Association ID to the RSVP Path message for the protected LSP. It uses the procedures described in Section 3.3 to do this 💅.

Then the MP node replies by sending the B-SFRR-Ready Extended ASSOCIATION object and Extended Association ID back inside the RSVP Resv message of the protected LSP. This is its acknowledgment 🫶. Every field from the Path message's B-SFRR-Ready Extended Association ID gets copied over into the one going in the Resv message, except for the MESSAGE_ID object. That one is set according to [RFC2961] instead. The MESSAGE_ID object Flags MUST be cleared when the MP node sends them, and they get ignored when the PLR node receives them. Also, a new Message_Identifier MUST be used to acknowledge an updated PLR node assignment 🌈.

Now for the big check. A PLR node only considers the protected LSP as Summary FRR capable if every field in the B-SFRR-Ready Extended Association ID it sent in the RSVP Path message matches what it got back in the RSVP Resv message. The MESSAGE_ID is the one exception. If the fields don't match, or if the B-SFRR-Ready Extended ASSOCIATION object is missing from a later refresh, the PLR node MUST consider the protected LSP as not Summary FRR capable 💀.

There's also a lowkey tricky race condition 👀. A protected LSP that was already Summary FRR capable can get caught in a moment where the MP node sends a refresh without the B-SFRR-Ready Extended ASSOCIATION object, and at the exact same time the PLR runs Summary FRR procedures because of a fault. So the PLR might trigger Summary FRR before it gets to read that refresh. That means the MP gets an Srefresh with a Message_Identifier that isn't tied to any state. Per [RFC2961], the MP then generates an Srefresh NACK for that Message_Identifier and sends it back to the PLR. The PLR handles the Srefresh NACK, replays the full Path state tied to that Message_Identifier, and recovers from the whole thing 🦋. Honestly, so resilient.

3.2. B-SFRR-Active Extended ASSOCIATION Object

The Extended ASSOCIATION object for the B-SFRR-Active Association Type is filled in by a PLR node. Its job is to let the MP node (the bypass tunnel destination) know that one or more groups of Summary FRR-capable protected LSPs being protected by the bypass tunnel are getting rerouted over that bypass tunnel 🚇✨.

This B-SFRR-Active Extended ASSOCIATION object rides in the RSVP Path message of the bypass tunnel, and it gets signaled downstream toward the MP node (the bypass tunnel destination) 🧚.

The Association Type, Association ID, and Association Source MUST be set as defined in [RFC4872] for the ASSOCIATION object. Here's the breakdown 💖:

Association Source:

The Association Source is set to an address of the PLR node 📍.

Association Type:

A brand new Association Type is defined for B-SFRR-Active, and it looks like this 👑:

  +=======+=======================================================+
  | Value | Type                                                  |
  +=======+=======================================================+
  | 6     | Bypass Summary FRR Active Association (B-SFRR-Active) |
  +-------+-------------------------------------------------------+

             Table 2: The B-SFRR-Active Association Type

Extended Association ID for B-SFRR-Active:

The PLR node fills in the B-SFRR-Active Extended Association ID for the Bypass Summary FRR Active association 🌸. The rules for filling it in are described below.

3.2.1. IPv4 B-SFRR-Active Extended Association ID

For IPv4, the Extended Association ID for the B-SFRR-Active Association Type lives inside the IPv4 Extended ASSOCIATION object. It's laid out like this 🎀:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Num-BGIDs          |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Bypass_Group_Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               :                               |
   //                              :                              //
   |                               :                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Bypass_Group_Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      RSVP_HOP_Object                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      TIME_VALUES                            //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IPv4 tunnel sender address              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 3: The IPv4 Extended Association ID for B-SFRR-Active

Let's break down each field 🍓:

Num-BGIDs: 16 bits

This is the number of Bypass_Group_Identifier fields 🔢.

Reserved: 16 bits

Reserved for future use 🚧.

Bypass_Group_Identifier: 32 bits each

This is a Bypass_Group_Identifier that the PLR node already signaled using the Extended ASSOCIATION object in the B-SFRR-Ready Extended Association ID. One or more Bypass_Group_Identifiers MAY be included 🧃.

RSVP_HOP_Object: Class 3, as defined by [RFC2205]

This is a replacement RSVP_HOP object that gets applied to all LSPs tied to each of the following Bypass_Group_Identifiers. It corresponds to C-Type = 1 for IPv4 RSVP_HOP 🌈.

TIME_VALUES object: Class 5, as defined by [RFC2205]

This is a replacement TIME_VALUES object that gets applied to all LSPs tied to each of the preceding Bypass_Group_Identifiers, after the B-SFRR-Active Extended ASSOCIATION object has been received ⏰.

IPv4 tunnel sender address:

This is the IPv4 address the PLR node sets to identify one or more backup paths, as described in Section 6.1.1 of [RFC4090]. It applies to every group identified by any Bypass_Group_Identifiers carried in the B-SFRR-Active Extended Association ID 🏷️.

3.2.2. IPv6 B-SFRR-Active Extended Association ID

For IPv6, the Extended Association ID for the B-SFRR-Active Association Type lives inside the IPv6 Extended ASSOCIATION object. Here's the layout 🧚‍♀️:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Num-BGIDs          |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Bypass_Group_Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               :                               |
   //                              :                              //
   |                               :                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Bypass_Group_Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      RSVP_HOP_Object                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      TIME_VALUES                            //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       IPv6 tunnel sender address              +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 4: The IPv6 Extended Association ID for B-SFRR-Active

And the fields 🫧:

Num-BGIDs: 16 bits

This is the number of Bypass_Group_Identifier fields 🔢.

Reserved: 16 bits

Reserved for future use 🚧.

Bypass_Group_Identifier: 32 bits each

RSVP_HOP_Object: Class 3, as defined by [RFC2205]

This is a replacement RSVP_HOP object that gets applied to all LSPs tied to each of the following Bypass_Group_Identifiers. It corresponds to C-Type = 2 for IPv6 RSVP_HOP 🌈.

TIME_VALUES object: Class 5, as defined by [RFC2205]

This is a replacement TIME_VALUES object that gets applied to all LSPs tied to each of the following Bypass_Group_Identifiers, after the B-SFRR-Active Extended ASSOCIATION object has been received ⏰.

IPv6 tunnel sender address:

This is the IPv6 address the PLR node sets to identify one or more backup paths, as described in Section 6.1.1 of [RFC4090]. It applies to every group identified by any Bypass_Group_Identifiers carried in the B-SFRR-Active Extended Association ID 💜.

3.3. Signaling Procedures prior to Failure ✨

okay bestie, before Summary FRR can do its thing 💅, a handshake MUST be completed between the PLR and MP nodes 🫶. They do it with the Extended ASSOCIATION object carrying the B-SFRR-Ready Extended Association ID, and it shows up in BOTH the RSVP Path and Resv messages of the protected LSP. main character energy 👑

The facility backup method from [RFC4090] is giving MPLS label stacking vibes 🦋. The PLR node slaps on extra MPLS labels post-FRR so the protected traffic can get rerouted over the backup path. The catch is that the backup path might have stricter MTU requirements, and because of that label stacking at the PLR node, the protected traffic could go over the backup path MTU 😭. So it's assumed the operator engineers their network so that rerouting plus the extra label stacking at the PLR node doesn't exceed the backup path MTU 🎀.

When using the procedures in this document, the PLR node MUST ensure that the bypass tunnel assignment can satisfy the protected LSP MTU requirements post-FRR. This is how we keep packets from getting dropped for being too big for the backup path after traffic gets rerouted onto the bypass tunnel post-failure 🙈. Section 2.6 of [RFC3209] describes a mechanism for figuring out whether a node needs to fragment or drop a packet when it's bigger than the path MTU discovered using RSVP signaling on the primary LSP path. A PLR can use the RSVP-discovered path MTU on both the backup and primary LSP paths to make sure the MTU isn't exceeded before or after rerouting the protected traffic onto the bypass tunnel 🌸.

3.3.1. PLR Signaling Procedure

the B-SFRR-Ready Extended ASSOCIATION object gets added by each PLR node in the RSVP Path message of the protected LSP to record the bypass tunnel assignment 📝. It gets updated every time the PLR node updates the bypass tunnel assignment, and that results in triggering an RSVP Path change message 🔥.

When a PLR node gets an RSVP Resv message with a B-SFRR-Ready Extended ASSOCIATION object, it checks whether the expected subobjects from the B-SFRR-Ready Extended Association ID are there 👀. If they are, the PLR node figures out whether the MP has acknowledged the current PLR node's assignment 💜.

To be a valid acknowledgment, the received B-SFRR-Ready Extended Association ID contents within the RSVP Resv message of the protected LSP MUST match the latest B-SFRR-Ready Extended ASSOCIATION object and Association ID contents that the PLR node had sent within the RSVP Path message (with the exception of the MESSAGE_ID). no cap, this check is everything ✨

Note that when forwarding an RSVP Resv message upstream, the PLR node SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address field matches any of the PLR node addresses 🧹.

3.3.2. MP Signaling Procedure

when an MP node gets an RSVP Path message with a B-SFRR-Ready Extended ASSOCIATION object, it processes all of them (there can be multiple PLR nodes for a single MP node 🧚). It only looks at the ones that have the MP node address as the bypass destination address in the Extended Association ID 💖.

The MP node first makes sure the bypass tunnel exists and that the Bypass_Group_Identifier is not already FRR Active. Basically, an LSP can't join a group that's already FRR rerouted 🙅‍♀️.

The MP node builds a mirrored Summary FRR group database per PLR node by associating the Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address carried in the IPv4 or IPv6 B-SFRR-Ready Extended Association IDs, respectively 🪞.

The MESSAGE_ID is extracted and recorded for the protected LSP Path state 🗂️. Then the MP node signals a B-SFRR-Ready Extended ASSOCIATION object and Extended Association ID in the RSVP Resv message of the protected LSP. Except for the MESSAGE_ID objects, all the other fields of the received B-SFRR-Ready Extended ASSOCIATION object in the RSVP Path message get copied into the B-SFRR-Ready Extended ASSOCIATION object going in the Resv message. The MESSAGE_ID object is set according to [RFC2961] with the Flags cleared 🎀.

Note that an MP may receive more than one RSVP Path message with the B-SFRR-Ready Extended ASSOCIATION object from one or more different upstream PLR nodes. In that case, the MP node is expected to save all the received MESSAGE_IDs from the different upstream PLR nodes 🗃️. After a failure, the MP node determines and activates the state(s) tied to the Bypass_Group_Identifier(s) received in the RSVP Path message containing the B-SFRR-Active Extended ASSOCIATION object that's signaled over the bypass tunnel from the PLR node, as described in Section 3.4 🦋.

When forwarding an RSVP Path message downstream, the MP node SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose Bypass_Destination_IPv4_Address or Bypass_Destination_IPv6_Address field matches any of the MP node addresses 🧹✨.

3.4. Signaling Procedures Post-Failure

okay so the moment a fault shows up (egress link or node failure), the PLR node will first do the object modification procedures described by Section 6.4.3 of [RFC4090] for all affected protected LSPs 🚨. For the Summary FRR-capable LSPs assigned to the same bypass tunnel, a common RSVP_HOP and SENDER_TEMPLATE MUST be used 💅.

The PLR node MUST signal non-Summary FRR-capable LSPs over the bypass tunnel before signaling the Summary FRR-capable LSPs 🧠. This is needed for the case where the PLR node recently changed a bypass assignment and the MP hasn't processed the change yet. ngl, this order matters so much 😭

The B-SFRR-Active Extended ASSOCIATION object gets sent within the RSVP Path message of the bypass tunnel to reroute the RSVP state of Summary FRR-capable LSPs 🦋✨.

3.4.1. PLR Signaling Procedure

after a failure event, when using the Summary FRR path signaling procedures, an individual RSVP Path message is NOT signaled for each Summary FRR LSP 🙅‍♀️. Instead, to reroute Summary FRR LSPs via the bypass tunnel, the PLR node adds the B-SFRR-Active Extended ASSOCIATION object in the RSVP Path message of the RSVP session of the bypass tunnel 🌈.

The RSVP_HOP_Object field in the B-SFRR-Active Extended Association ID is set to a common object that gets applied to all LSPs associated with the Bypass_Group_Identifiers carried in the B-SFRR-Active Extended Association ID 🎀.

The PLR node adds the Bypass_Group_Identifier(s) of any group or groups that have common group attributes, including the tunnel sender address, to the same B-SFRR-Active Extended Association ID 🫶. Note that multiple ASSOCIATION objects, each carrying a B-SFRR-Active Extended Association ID, can be carried within a single RSVP Path message of the bypass tunnel and sent towards the MP as described in [RFC6780] 🧚.

Any previously received MESSAGE_IDs from the MP get activated on the PLR. As a result, the PLR starts sending Srefresh messages containing the specific Message_Identifier(s) for the states to be refreshed 🔄💖.

3.4.2. MP Signaling Procedure

when an MP gets an RSVP Path message with a B-SFRR-Active Extended ASSOCIATION object, it performs normal merge point processing for each protected LSP associated with each Bypass_Group_Identifier, as if it had received an individual RSVP Path message for that LSP 🧩.

For each Summary FRR-capable LSP being merged, the MP first modifies the Path state like this:

The RSVP_HOP object is copied from the RSVP_HOP_Object field in the B-SFRR-Active Extended Association ID 📋.
The TIME_VALUES object is copied from the TIME_VALUES field in the B-SFRR-Active Extended Association ID. The TIME_VALUES object contains the refresh period of the PLR node, and it's used to generate periodic refreshes ⏰. The TIME_VALUES object carried in the B-SFRR-Active Extended Association ID matches the one that would have been exchanged in a full Path message sent to the MP after the failure when no Summary FRR procedures are used 💜.
The tunnel sender address field in the SENDER_TEMPLATE object is copied from the tunnel sender address field of the B-SFRR-Active Extended Association ID 🪪.
The Explicit Route Object (ERO) is modified as per Section 6.4.4 of [RFC4090]. Once those modifications are done, the MP node performs merge processing as per [RFC4090] 🛠️.
Any previously received MESSAGE_IDs from the PLR node get activated. The MP is allowed to send Srefresh messages containing the specific Message_Identifier(s) for the states to be refreshed 🌸.

A failure during merge processing of any individual rerouted LSP MUST result in an RSVP PathErr message 🚫.

An individual RSVP Resv message for each successfully merged Summary FRR LSP is NOT signaled. The MP node SHOULD immediately use summary refresh procedures to refresh the protected LSP Resv state 💅✨.

3.5. Refreshing Summary FRR Active LSPs

the refreshing of Summary FRR Active LSPs is done using summary refresh as defined by [RFC2961] 🔁🦋.

4. Backwards Compatibility

the (Extended) ASSOCIATION object is defined in [RFC4872] with a class number in the form 11bbbbbb, where b=0 or 1 🧸. This keeps things compatible with nodes that don't support it, following the procedures in Section 3.10 of [RFC2205] for unknown-class objects 🫶. Those nodes will ignore the object and forward it without any modification 🌈.

5. Security Considerations

okay this section is serious bestie 😭🚨. This document updates an existing RSVP object -- the Extended ASSOCIATION object as described in Section 3. So if a signaling message gets intercepted, someone could figure out slightly more about the state of the network than they could before 👀.

When using the procedures defined in this document, FRR signaling for rerouting the states of one or more protected LSPs onto the bypass tunnel can be done for a group of protected LSPs with a single RSVP message. This means an intruder could potentially impact and manipulate a set of protected LSPs assigned to the same bypass tunnel group 💀. Note that such an attack is possible even without the mechanisms in this document, just at an extra cost from the excessive per-LSP signaling that would happen 🙈.

Existing mechanisms for maintaining the integrity and authenticity of RSVP messages [RFC2747] can be applied. Other considerations mentioned in [RFC4090] and [RFC5920] also apply 🔐💜.

6. IANA Considerations

IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry 📚. The "Association Type" subregistry is included in this registry.

This registry has been updated with the new Association Types for the Extended ASSOCIATION objects defined in this document, like this 🎀:

           +=======+===========================+=============+
           | Value | Name                      | Reference   |
           +=======+===========================+=============+
           | 5     | B-SFRR-Ready Association  | Section 3.1 |
           +-------+---------------------------+-------------+
           | 6     | B-SFRR-Active Association | Section 3.2 |
           +-------+---------------------------+-------------+

                 Table 3: New Extended ASSOCIATION Object
                            Association Types

7. References ✨

7.1. Normative References

[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. ✨
[RFC2747]: Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, https://www.rfc-editor.org/info/rfc2747. 🔐
[RFC2961]: Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, https://www.rfc-editor.org/info/rfc2961. 🦋
[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. 🌸
[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. ⭐
[RFC4872]: Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, https://www.rfc-editor.org/info/rfc4872. 🧚
[RFC6780]: Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/RFC6780, October 2012, https://www.rfc-editor.org/info/rfc6780. 🍓
[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. 🎀

7.2. Informative References

[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. 🫶

Acknowledgments ✨

Huge thank-yous to Alexander Okonnikov, Loa Andersson, Lou Berger, Eric Osborne, Gregory Mirsky, and Mach Chen 🙌. They reviewed this document and gave really valuable comments, and the whole thing is so much better because of them. Iconic behaviour, honestly. 💅

Contributors 🌈

Nicholas Tan Arista Networks

Email: ntan@arista.com

Authors' Addresses 💜

Mike Taillon Cisco Systems, Inc.

Email: mtaillon@cisco.com

Tarek Saad (editor) 👑 Juniper Networks

Email: tsaad@juniper.net

Rakesh Gandhi Cisco Systems, Inc.

Email: rgandhi@cisco.com

Abhishek Deshmukh Juniper Networks

Email: adeshmukh@juniper.net

Markus Jork 128 Technology

Email: mjork@128technology.com

Vishnu Pavan Beeram Juniper Networks

Email: vbeeram@juniper.net

📦 where this page comes from

ietf: rfc8796 2020-07
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms