Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs)
updates
Extracted elements (27)
A unique Extended Association ID is required per LSP pair (rather than relying on the base Association Object alone) because restoration LSPs and protected LSPs at the same midpoint can carry identical base ASSOCIATION Objects, causing incorrect LSP pairing during fast reroute bypass assignment.
Bypass tunnels for protected co-routed associated bidirectional LSPs are required to themselves be co-routed associated bidirectional tunnels, ensuring that after fast reroute the traffic flows on co-routed paths in both forward and reverse directions.
RSVP association signaling is used instead of GMPLS extensions to achieve co-routed bidirectional LSPs, allowing operators to leverage existing TE and fast reroute mechanisms without deploying GMPLS in their networks.
The downstream PLR is designated as the initiator of bypass tunnel assignment (not the upstream PLR) so that there is a single authoritative source for the bypass coordination, with the upstream PLR only reflecting the assigned bypass tunnel for the reverse LSP.
No new signaling messages are defined; all procedures reuse messages from RFC 8271. Nodes not supporting the updated procedures will cause traffic to flow on asymmetric paths after fast reroute.
The bypass tunnel coordination procedure may be used for protected associated bidirectional LSPs that are not co-routed, but requires that the downstream PLR/MP pair of the forward LSP matches the upstream MP/PLR pair of the reverse LSP.
The fast reroute procedure for unidirectional LSPs defined in RFC 4090 and the procedure when using unidirectional bypass tunnels are not modified by this document; this document only extends procedures for bidirectional associated LSPs.
Unlike GMPLS LSPs, asymmetry of forward and reverse LSP paths after fast reroute does not result in RSVP soft-state timeout with associated bidirectional LSPs, because upstream and downstream PLRs trigger fast reroute independently.
After fast reroute, the downstream MP node MUST trigger the procedure to restore co-routing and reroute the protected reverse LSP RSVP Path messages and traffic over the bypass tunnel on which the forward LSP traffic is received.
For node protection bypass tunnels, after restoring co-routing, the upstream PLR node SHOULD start sending RSVP Path messages and traffic for the reverse LSP over the original link when it receives unmodified RSVP Path messages for the protected forward LSP over it.
For single-sided provisioned bidirectional LSPs, the remote endpoint MUST copy the contents of the received Extended ASSOCIATION Object including the Extended Association ID into the RSVP Path message of the reverse LSP.
If the bypass tunnel cannot be used as described in RFC 8271 Section 4.5.3, the upstream PLR SHOULD send a Notify message with Error Code 44 and Sub-code 'Bypass Assignment Cannot Be Used' (value 0) to the downstream PLR.
If the indicated forward bypass tunnel or the associated reverse bypass tunnel is not found, the upstream PLR SHOULD send a Notify message with Error Code 'FRR Bypass Assignment Error' (value 44) and Sub-code 'Bypass Tunnel Not Found' (value 1) to the downstream PLR.
In the Extended Association ID format examples (both IPv4 and IPv6), the Reserved flags MUST be set to 0 on transmission.
In the one-to-one backup method, if the associated bidirectional bypass tunnel is already in use at the upstream PLR, it SHOULD send a Notify message with Error Code 44 and Sub-code 'One-to-One Bypass Already in Use' (value 2) to the downstream PLR.
Operators wishing to use the co-routing fast reroute function SHOULD ensure that it is supported on all nodes on the LSP path; unsupporting nodes can cause traffic to flow on asymmetric paths after fast reroute.
The BYPASS_ASSIGNMENT and Node-ID address subobjects MUST be added by the downstream PLR node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of the forward LSP to indicate the local bypass tunnel assignment.
The upstream PLR node MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the RSVP Path message of the reverse LSP; only the downstream PLR initiates bypass tunnel assignment.
The upstream PLR node MUST NOT initiate the bypass tunnel assignment; it only reflects the associated bypass tunnel assignment for the reverse-direction LSP based on the downstream PLR's indication.
To associate LSPs unambiguously at a midpoint node, the endpoint node MUST signal the Extended ASSOCIATION Object and add a unique Extended Association ID for each associated forward and reverse LSP pair forming the bidirectional LSP.
Notify messages using Error Code 'FRR Bypass Assignment Error' (value 44) with sub-codes 0 (Cannot Be Used), 1 (Not Found), and 2 (One-to-One Already in Use) from RFC 8271 are used to communicate bypass assignment failures from upstream PLR to downstream PLR.
The BYPASS_ASSIGNMENT IPv4 subobject (value 38) and IPv6 subobject (value 39), defined in RFC 8271, are used to coordinate bypass tunnel assignment between PLR nodes in the forward and reverse directions of an associated bidirectional LSP.
The Extended ASSOCIATION Object (RFC 6780) carries a unique Extended Association ID to unambiguously identify associated forward and reverse LSP pairs at midpoint nodes, distinguishing protected LSPs from restoration LSPs that share identical base Association Objects.
The REVERSE_LSP Object (RFC 7551) is inserted in the RSVP Path message by the originating endpoint in single-sided provisioning, causing the remote endpoint to create and signal the corresponding reverse TE tunnel.
This document updates signaling mechanisms from RFC 4090 and RFC 7551 but introduces no additional security considerations beyond those already covered in RFC 4090, RFC 7551, RFC 8271, and the MPLS/GMPLS security framework RFC 5920.
The IPv4 Extended Association ID format contains: a 32-bit IPv4 LSP Source Address, a 16-bit Reserved field (must be zero), a 16-bit LSP ID of the forward LSP, followed by a variable-length Extended Association ID inserted by the endpoint node.
The IPv6 Extended Association ID format contains: a 128-bit IPv6 LSP Source Address (16 bytes), a 16-bit Reserved field (must be zero), a 16-bit LSP ID of the forward LSP, followed by a variable-length Extended Association ID inserted by the endpoint node.