| RFC 8796 | RSVP-TE Summary FRR | July 2020 |
| Taillon, et al. | Standards Track | [Page] |
This document updates RFC 4090 for the Resource Reservation Protocol (RSVP)Traffic Engineering (TE) procedures defined for facilitybackup protection. The updates include extensions that reduce the amount ofsignaling and processing that occurs during Fast Reroute (FRR); as a result,scalability when undergoing FRR convergence after a link or node failure isimproved. These extensions allow the RSVP message exchange between thePoint of Local Repair (PLR) and the Merge Point (MP) nodes to be independent of thenumber of protected Label Switched Paths (LSPs) traversing between them whenfacility bypass FRR protection is used. The signaling extensions are fullybackwards compatible with nodes that do not support them.¶
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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc8796.¶
Copyright (c) 2020 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License.¶
The Fast Reroute (FRR) procedures defined in[RFC4090] describe themechanisms for the Point of Local Repair (PLR) to reroute traffic and signalingof a protected RSVP-TE Label Switched Path (LSP) onto the bypass tunnel in theevent of a TE link or node failure. Such signaling procedures are performedindividually for each affected protected LSP. This may eventually lead tocontrol-plane scalability and latency issues on the PLR and/or the Merge Point(MP) nodes due to limited memory and CPU processing resources. This conditionis exacerbated when the failure affects a large number of protected LSPs thattraverse the same PLR and MP nodes.¶
For example, in a large-scale deployment of RSVP-TE LSPs, a single Label Switching Router (LSR) acting as a PLR node may host tens of thousands of protectedRSVP-TE LSPs egressing the same protected link and also act as an MP node fora similar number of LSPs that ingress on the same link. In the event of thefailure of the link or neighbor node, the RSVP-TE control plane of the node(when acting as a PLR node) becomes busy rerouting protected LSPs over thebypass tunnel(s) in one direction and (when acting as an MP node) becomes busymerging RSVP states from signaling received over bypass tunnels for one ormore LSPs inthe reverse direction. Subsequently, the head-end Label Edge Routers (LERs)that are notified of the local repair at any downstream LSRs will attempt to(re)converge the affected RSVP-TE LSPs onto newly computed paths -- possiblytraversing the same previously affected LSR(s). As a result, the RSVP-TEcontrol plane becomes overwhelmed (1) by the amount of FRR RSVP-TE processingoverhead following the link or node failure and (2) due to other control-planeprotocols (e.g., IGP) that undergo convergence on the same node at thesame time.¶
Today, each protected RSVP-TE LSP is signaled individually over the bypasstunnel after FRR. The changes introduced in this document allow the PLR node toassign multiple protected LSPs to a bypass tunnel group and to communicate thisassignment to the MP, such that upon failure, the signaling over the bypasstunnel happens on one or more bypass tunnel groups. This document defines newextensions that¶
As defined in[RFC2961], summary refresh procedures use MESSAGE_ID torefresh the RSVP Path and Resv states to help with scaling. The Summary FRRprocedures introduced in this document build on those concepts to allow theMESSAGE_ID(s) to be exchanged on one or more per-bypass tunnel assignment groups andcontinue touse summary refresh procedures while reducing the amount of messaging that occursafter rerouting signaling over the bypass tunnel post-FRR.¶
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.¶
It is assumed that the reader is familiar with the terms and abbreviations used in[RFC3209] and[RFC4090].¶
The following abbreviations are also used in this document:¶
The RSVP ASSOCIATION object is defined in[RFC4872] as a means to associateLSPs with each other. For example, in the context of one or more GMPLS-controlled LSPs,the ASSOCIATION object is used to associate a recovery LSP with the LSP(s) itis protecting. The Extended ASSOCIATION object is introduced in[RFC6780]to expand on the possible usage of the ASSOCIATION object and generalize thedefinition of the Extended Association ID field.¶
This document defines the use of the Extended ASSOCIATION object to carry theSummary FRR information and associate the protected LSP or LSPs with the bypasstunnel that protects them. Two new Association Types for the ExtendedASSOCIATION object, and new Extended Association IDs, are defined in thisdocument to describe the Bypass Summary FRR Ready (B-SFRR-Ready) and BypassSummary FRR Active (B‑SFRR-Active) associations.¶
The PLR node creates and manages the Summary FRR LSP groups (identified byBypass_Group_Identifiers) and shares the group identifiers with the MP viasignaling.¶
A PLR nodeSHOULD assign the same Bypass_Group_Identifier to allprotected LSPs provided that the protected LSPs:¶
This minimizes the number of bypass tunnel Summary FRR groups and optimizes theamount of signaling that occurs between the PLR and the MP nodes after FRR.¶
A PLR node that supports Summary FRR procedures adds an Extended ASSOCIATIONobject with a B-SFRR-Ready Extended Association ID in the RSVP Path message ofthe protected LSP. The PLR node adds the protected LSP Bypass_Group_Identifier,information from the assigned bypass tunnel, and a MESSAGE_ID object into theB-SFRR-Ready Extended Association ID. The MP uses the information contained inthe received B-SFRR-Ready Extended Association ID to refresh and merge theprotected LSP Path state after FRR occurs.¶
An MP node that supports Summary FRR procedures adds the B-SFRR-Ready ExtendedASSOCIATION object and respective Extended Association ID in the RSVP Resvmessage of the protected LSP to acknowledge the PLR's bypass tunnel assignmentand provide the MESSAGE_ID object that the MP node will use to refresh theprotected LSP Resv state after FRR occurs.¶
The MP maintains the PLR node group assignments learned from signaling andacknowledges the group assignments to the PLR node via signaling. Once the PLRnode receives the group assignment acknowledgment from the MP, the FRRsignaling can proceed based on Summary FRR procedures as described in thisdocument.¶
The B-SFRR-Active Extended ASSOCIATION object with Extended Association ID issent by the PLR node after activating the Summary FRR procedures. TheB-SFRR-Active Extended ASSOCIATION object with Extended Association ID is sentwithin the RSVP Path message of the bypass tunnel to inform the MP node thatone or more groups of protected LSPs protected by the bypass tunnel are nowbeing rerouted over the bypass tunnel.¶
The Extended ASSOCIATION object is populated using the rules defined below toassociate a protected LSP with the bypass tunnel that is protecting it whenSummary FRR procedures are enabled.¶
The Association Type, Association ID, and Association SourceMUST be set asdefined in[RFC4872] for the ASSOCIATION object. More specifically:¶
| Value | Type |
|---|---|
| 5 | Bypass Summary FRR Ready Association (B-SFRR-Ready) |
The Extended ASSOCIATION object's Global Association SourceMUST be setaccording to the rules defined in[RFC6780].¶
The B-SFRR-Ready Extended Association ID is populated by the PLR node whenperforming Bypass Summary FRR Ready association for a protected LSP. The rulesgoverning its population are described in the subsequent sections.¶
The IPv4 Extended Association ID for the B-SFRR-Ready AssociationType is carried inside the IPv4 Extended ASSOCIATION object and hasthe 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bypass_Tunnel_ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bypass_Source_IPv4_Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bypass_Destination_IPv4_Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bypass_Group_Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MESSAGE_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 bits¶
The bypass tunnel identifier.¶
16 bits¶
Reserved for future use.MUST be set to zero when sending and ignored on receipt.¶
32 bits¶
The bypass tunnel source IPv4 address.¶
32 bits¶
The bypass tunnel destination IPv4 address.¶
32 bits¶
The bypass tunnel group identifier that is assigned to the LSP.¶
The IPv6 Extended Association ID for the B-SFRR-Ready AssociationType is carried inside the IPv6 Extended ASSOCIATION object and hasthe 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bypass_Tunnel_ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Bypass_Source_IPv6_Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Bypass_Destination_IPv6_Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bypass_Group_Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MESSAGE_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 bits¶
The bypass tunnel identifier.¶
16 bits¶
Reserved for future use.MUST be set to zero when sending and ignored on receipt.¶
128 bits¶
The bypass tunnel source IPv6 address.¶
128 bits¶
The bypass tunnel destination IPv6 address.¶
32 bits¶
The bypass tunnel group identifier that is assigned to the LSP.¶
A PLR node assigns a bypass tunnel and Bypass_Group_Identifier for eachprotected LSP. The same Bypass_Group_Identifier is used for the set ofprotected LSPs that share the same bypass tunnel, traverse the same egress link,and are not already rerouted. The PLR nodeMUST generate a MESSAGE_ID objectwith Epoch and Message_Identifier set according to[RFC2961]. The MESSAGE_IDobject FlagsMUST be cleared when transmitted by the PLR node and ignoredwhen received at the MP node.¶
A PLR nodeMUST generate a new Message_Identifier each time the contents of theB-SFRR-Ready Extended Association ID change (e.g., when the PLR nodechanges the bypass tunnel assignment).¶
A PLR node notifies the MP node of the bypass tunnel assignment via adding aB-SFRR-Ready Extended ASSOCIATION object and Extended Association ID in the RSVP Pathmessage for the protected LSP, using the procedures described inSection 3.3.¶
An MP node acknowledges the assignment to the PLR node by signaling the B-SFRR-ReadyExtended ASSOCIATION object and Extended Association ID within the RSVP Resv message ofthe protected LSP. With the exception of the MESSAGE_ID object, all otherfields from the received B-SFRR-Ready Extended Association ID in the RSVP Pathmessage are copied into the B-SFRR-Ready Extended Association ID to be added inthe Resv message. The MESSAGE_ID object is set according to[RFC2961].The MESSAGE_ID object FlagsMUST be cleared when transmitted by the MP node and ignoredwhen received at the PLR node. A new Message_IdentifierMUST be used to acknowledge anupdated PLR node's assignment.¶
A PLR node considers the protected LSP as Summary FRR capable only if all thefields in the B-SFRR-Ready Extended Association ID that are sent in the RSVPPath message match the fields received in the RSVP Resv message (with the exceptionof the MESSAGE_ID). If the fields do not match or if the B-SFRR-Ready ExtendedASSOCIATION object is absent in a subsequent refresh, the PLR nodeMUSTconsider the protected LSP as not Summary FRR capable.¶
A race condition may arise for a previously Summary FRR-capable protected LSPwhen the MP node triggers a refresh that does not contain the B-SFRR-ReadyExtended ASSOCIATION object, while at the same time the PLR triggers SummaryFRR procedures due to a fault occurring concurrently. In this case, it ispossible that the PLR triggers Summary FRR procedures on the protected LSPbefore it can receive and process the refresh from the MP node. As a result,the MP will receive an Srefresh with a Message_Identifier that is not associatedwith any state. As per[RFC2961], this resultsin the MP generating an Srefresh NACK for this Message_Identifier and sending it back to the PLR. ThePLR processes the Srefresh NACK, replays the full Path state associated withthe Message_Identifier, and subsequently recovers from this condition.¶
The Extended ASSOCIATION object for the B-SFRR-Active Association Type is populatedby a PLR node to indicate to the MP node (the bypass tunnel destination) that oneor more groups of Summary FRR‑capable protected LSPs that are being protected by thebypass tunnel are being rerouted over the bypass tunnel.¶
The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP Pathmessage of the bypass tunnel and signaled downstream towards the MP (the bypass tunneldestination).¶
The Association Type, Association ID, and Association SourceMUST be set asdefined in[RFC4872] for the ASSOCIATION object. More specifically:¶
| Value | Type |
|---|---|
| 6 | Bypass Summary FRR Active Association (B-SFRR-Active) |
The IPv4 Extended Association ID for the B-SFRR-Active Association Type iscarried inside the IPv4 Extended ASSOCIATION object and has the followingformat:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 bits¶
Number of Bypass_Group_Identifier fields.¶
16 bits¶
Reserved for future use.¶
32 bits each¶
A Bypass_Group_Identifier that was previously signaled by the PLRusing the Extended ASSOCIATION object in the B-SFRR-Ready ExtendedAssociation ID. One or more Bypass_Group_IdentifiersMAY be included.¶
Class 3, as defined by[RFC2205]¶
Replacement RSVP_HOP object to be applied to all LSPs associatedwith each of the following Bypass_Group_Identifiers. This correspondsto C-Type = 1 for IPv4 RSVP_HOP.¶
Class 5, as defined by[RFC2205]¶
Replacement TIME_VALUES object to be applied to all LSPs associatedwith each of the preceding Bypass_Group_Identifiers after receivingthe B-SFRR-Active Extended ASSOCIATION object.¶
The IPv6 Extended Association ID for the B-SFRR-Active Association Type iscarried inside the IPv6 Extended ASSOCIATION object and has the followingformat:¶
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 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 bits¶
Number of Bypass_Group_Identifier fields.¶
16 bits¶
Reserved for future use.¶
32 bits each¶
A Bypass_Group_Identifier that was previously signaled by the PLRusing the Extended ASSOCIATION object in the B-SFRR-Ready ExtendedAssociation ID. One or more Bypass_Group_IdentifiersMAY be included.¶
Class 3, as defined by[RFC2205]¶
Replacement RSVP_HOP object to be applied to all LSPs associatedwith each of the following Bypass_Group_Identifiers. This correspondsto C-Type = 2 for IPv6 RSVP_HOP.¶
Class 5, as defined by[RFC2205]¶
Replacement TIME_VALUES object to be applied to all LSPs associatedwith each of the following Bypass_Group_Identifiers after receivingthe B-SFRR-Active Extended ASSOCIATION object.¶
Before Summary FRR procedures can be used, a handshakeMUST be completedbetween the PLR and MP nodes. This handshake is performed using the Extended ASSOCIATIONobject that carries the B-SFRR-Ready Extended Association ID in both the RSVPPath and Resv messages of the protected LSP.¶
The facility backup method introduced in[RFC4090] takes advantage of MPLS labelstacking (the PLR node imposes additional MPLS labels post-FRR) to allow rerouting ofprotected traffic over the backup path. The backup path may have stricter MTUrequirements; due to label stacking at the PLR node, the protected traffic may exceedthe backup path MTU. It is assumed that the operator engineers their network toallow rerouting of protected traffic and the additional label stacking at thePLR node in order to not exceed the backup path MTU.¶
When using the procedures defined in this document, the PLR nodeMUST ensure that thebypass tunnel assignment can satisfy the protected LSP MTU requirements post-FRR. This prevents any packets from being dropped due to exceeding the MTU sizeof the backup path after traffic is rerouted onto the bypass tunnel post-failure.Section 2.6 of [RFC3209] describes a mechanism to determine whethera node needs to fragment or drop a packet when it exceeds the path MTUdiscovered using RSVP signaling on the primary LSP path. A PLR can leveragethe RSVP-discovered path MTU on the backup and primary LSP paths to ensurethat the MTUis not exceeded before or after rerouting the protected traffic onto thebypass tunnel.¶
The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR node in the RSVPPath message of the protected LSP to record the bypass tunnel assignment. Thisobject is updated every time the PLR node updates the bypass tunnelassignment. This results in triggering an RSVP Path change message.¶
Upon receiving an RSVP Resv message with a B-SFRR-Ready Extended ASSOCIATIONobject, the PLR node checks to see if the expected subobjects from the B-SFRR-ReadyExtended Association ID are present. If present, the PLR node determines if the MP hasacknowledged the current PLR node's assignment.¶
To be a valid acknowledgment, the received B-SFRR-Ready Extended Association IDcontents within the RSVP Resv message of the protected LSPMUST match thelatest B-SFRR-Ready Extended ASSOCIATION object and Association ID contentsthat the PLR node had sent within the RSVP Path message (with the exception of theMESSAGE_ID).¶
Note that when forwarding an RSVP Resv message upstream, the PLR nodeSHOULD removeany/all B-SFRR-Ready Extended ASSOCIATION objects whose Bypass_Source_IPv4_Address orBypass_Source_IPv6_Address field matches any of the PLR node addresses.¶
Upon receiving an RSVP Path message with a B-SFRR-Ready Extended ASSOCIATIONobject, an MP node processes all (there may be multiple PLR nodes for a single MP node)B-SFRR-Ready Extended ASSOCIATION objects that have the MP node address as thebypass destination address in the Extended Association ID.¶
The MP node first ensures the existence of the bypass tunnel and that theBypass_Group_Identifier is not already FRR Active. That is, an LSP cannot joina group that is already FRR rerouted.¶
The MP node builds a mirrored Summary FRR group database per PLR node byassociating the Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Addressthat is carried in the IPv4 or IPv6 B‑SFRR-Ready Extended Association IDs,respectively.¶
The MESSAGE_ID is extracted and recorded for the protected LSP Pathstate. The MP node signals a B-SFRR-Ready Extended ASSOCIATION object andExtended Association ID in the RSVP Resv message of the protected LSP. With theexception of the MESSAGE_ID objects, all other fields of the receivedB-SFRR-Ready Extended ASSOCIATION object in the RSVP Path message are copiedinto the B-SFRR-Ready Extended ASSOCIATION object to be added in the Resvmessage. 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-ReadyExtended ASSOCIATION object from one or more different upstream PLR nodes. In this case,the MP node is expected to save all the received MESSAGE_IDs received from the differentupstream PLR nodes. After a failure, the MP node determines and activates thestate(s) associated with the Bypass_Group_Identifier(s) received in the RSVPPath message containing the B-SFRR-Active Extended ASSOCIATION object that issignaled over the bypass tunnel from the PLR node, as described inSection 3.4.¶
When forwarding an RSVP Path message downstream, the MP nodeSHOULD remove any/allB-SFRR-Ready Extended ASSOCIATION objects whose Bypass_Destination_IPv4_Address orBypass_Destination_IPv6_Address field matches any of the MP node addresses.¶
Upon detection of a fault (egress link or node failure), the PLR node will firstperform the object modification procedures described bySection 6.4.3 of [RFC4090] for all affected protected LSPs. For the Summary FRR-capable LSPsthat are assigned to the same bypass tunnel, a common RSVP_HOP andSENDER_TEMPLATEMUST be used.¶
The PLR nodeMUST signal non-Summary FRR-capable LSPs over the bypass tunnel beforesignaling the Summary FRR-capable LSPs. This is needed to allow for the casewhere the PLR node recently changed a bypass assignment and the MP has notprocessed the change yet.¶
The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP Pathmessage of the bypass tunnel to reroute the RSVP state of Summary FRR-capable LSPs.¶
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 theB-SFRR-Active Extended ASSOCIATION object in the RSVP Path message of theRSVP session of the bypass tunnel.¶
The RSVP_HOP_Object field in the B-SFRR-Active Extended Association ID is setto a common object that will be applied to all LSPs associatedwith the Bypass_Group_Identifiers that are carried in the B-SFRR-ActiveExtended Association ID.¶
The PLR node adds the Bypass_Group_Identifier(s) of any group or groups that have commongroup attributes, including the tunnel sender address, to the same B-SFRR-ActiveExtended Association ID. Note that multiple ASSOCIATION objects, each carrying aB-SFRR-Active Extended Association ID, can be carried within a single RSVP Pathmessage of the bypass tunnel and sent towards the MP as described in[RFC6780].¶
Any previously received MESSAGE_IDs from the MP are 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.¶
Upon receiving an RSVP Path message with a B-SFRR-Active Extended ASSOCIATIONobject, the MP performs normal merge point processing for each protected LSPassociated with each Bypass_Group_Identifier, as if it had received anindividual RSVP Path message for that LSP.¶
For each Summary FRR-capable LSP that is being merged, the MP first modifies the Pathstate as follows:¶
A failure during merge processing of any individual rerouted LSPMUSTresult in an RSVP PathErr message.¶
An individual RSVP Resv message for each successfully merged SummaryFRR LSP is not signaled. The MP nodeSHOULD immediately use summaryrefresh procedures to refresh the protected LSP Resv state.¶
The refreshing of Summary FRR Active LSPs is performed using summaryrefresh as defined by[RFC2961].¶
The (Extended) ASSOCIATION object is defined in[RFC4872] with a class numberin the form 11bbbbbb, where b=0 or 1. This ensures compatibility withnodes that do not provide support, in accordance with the procedures specified inSection 3.10 of [RFC2205] regarding unknown-class objects.Such nodes will ignore the object and forward it without any modification.¶
This document updates an existing RSVP object -- the Extended ASSOCIATION object as described inSection 3. Thus, in the event of theinterception of a signaling message, slightly more information could be deducedabout the state of the network than was previously the case.¶
When using the procedures defined in this document, FRR signaling for reroutingof the states of one or more protected LSPs onto the bypass tunnel can be performed on a groupof protected LSPs with a single RSVP message. This allows an intruder topotentially impact and manipulate a set of protected LSPs that are assigned tothe same bypass tunnel group. Note that such an attack is possible even withoutthe mechanisms defined in this document, albeit at an extra cost resultingfrom the excessive per-LSP signaling that will occur.¶
Existing mechanisms for maintaining the integrity and authenticity of RSVPmessages[RFC2747] can be applied. Other considerations mentionedin[RFC4090] and[RFC5920] also apply.¶
IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry. The "Association Type" subregistry is includedin this registry.¶
This registry has been updated with the new Association Types for the Extended ASSOCIATION objects defined in this documentas follows:¶
| Value | Name | Reference |
|---|---|---|
| 5 | B-SFRR-Ready Association | Section 3.1 |
| 6 | B-SFRR-Active Association | Section 3.2 |
The authors would like to thankAlexander Okonnikov,Loa Andersson,Lou Berger,Eric Osborne,Gregory Mirsky,andMach Chen for reviewing and providing valuablecomments on this document.¶