Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs)
updates
- rfc-4090 — Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Extracted elements (24)
Bidirectional GMPLS bypass tunnels are defined to originate on the downstream PLR (not the upstream PLR) because the downstream PLR has the local policy information about provisioned bypass tunnels and always initiates the bypass tunnel assignment. The upstream PLR simply reflects the assignment in the reverse direction.
The BYPASS_ASSIGNMENT subobject is only carried in RSVP Path messages (never Resv) and only inserted by the downstream PLR, reflecting the document's choice that downstream PLRs initiate bypass assignments and upstream PLRs (downstream MPs) react by reflecting the assignment in the reverse direction rather than independently assigning their own.
The PRR concept and two-phase co-routing restoration procedure are introduced because asymmetric paths taken by bidirectional LSP signaling (upstream and downstream PLRs independently triggering FRR under node protection) can cause RSVP soft-state timeout at intermediate nodes, tearing down the protected LSP. RFC 6378 Protection State Coordination addresses traffic disruption but not this control-plane timeout issue.
Asymmetry in bypass tunnel assignments (e.g., upstream PLR receiving both link-protection and node-protection assignments from different downstream PLRs) can be avoided by using the 'node protection desired' flag in the SESSION_ATTRIBUTE object; when set, all PLRs assign node-protection bypass tunnels. Any residual asymmetry at failure time is corrected by the co-routing restoration procedure in Section 5.2.2.
Nodes not supporting the BYPASS_ASSIGNMENT subobject will ignore it but forward it without modification per RFC 3209, preserving backward compatibility. Nodes not supporting the new FRR Bypass Assignment Error Notify message will similarly ignore and forward it.
When using GMPLS out-of-band signaling, after a link failure RSVP messages are rerouted over control channels to the MPs (not over the bypass tunnel itself), unlike in-band signaling where messages flow through the bypass tunnel. The RSVP soft-state timeout problem after node-protection FRR is equally applicable to out-of-band signaling; however, unidirectional link failures do not cause soft-state timeout with out-of-band signaling.
If the upstream PLR cannot find a matching bypass tunnel identified in the BYPASS_ASSIGNMENT subobject, it SHOULD send a Notify message with Error Code 44 'FRR Bypass Assignment Error' and Sub-code 1 'Bypass Tunnel Not Found' to the downstream PLR. Upon receiving this error, the downstream PLR SHOULD remove the bypass tunnel assignment and select an alternate.
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 with Error Code 44 and Sub-code 2 'One-to-One Bypass Already in Use' to the downstream PLR.
The BYPASS_ASSIGNMENT subobject MUST NOT be changed by downstream LSRs and MUST NOT be added to a Resv RRO; it SHOULD be inserted into the Path RRO by the downstream PLR and SHOULD NOT be inserted by a node that is not a downstream PLR.
The FRR Bypass Assignment Error (Error Code 44) MUST NOT be sent in a Path Error message; it does not cause the protected LSP to be torn down.
The Label subobject MUST also be added (per RFC 3209) when the BYPASS_ASSIGNMENT subobject is included in the Path RRO.
To identify protected LSP packets through a bypass tunnel for optional data-plane co-routing restoration, Penultimate Hop Popping (PHP) of the bypass tunnel MUST be disabled.
When the BYPASS_ASSIGNMENT subobject is added in the Path RRO, the IPv4 or IPv6 subobject containing the Node-ID address MUST also be added, the Node-ID address MUST match the source address of the bypass tunnel selected, and the BYPASS_ASSIGNMENT subobject MUST be added immediately after the Node-ID address.
When the procedures defined in this document are in use, the BYPASS_ASSIGNMENT subobject MUST be added by each downstream PLR in the RSVP Path RRO message of the GMPLS signaled bidirectional protected LSP to record the downstream bidirectional bypass tunnel assignment.
BYPASS_ASSIGNMENT subobject for the RSVP RECORD_ROUTE Object (RRO): carried only in RSVP Path messages, it records the downstream PLR's bidirectional bypass tunnel assignment (Tunnel ID and destination address) to coordinate the same bypass tunnel in the reverse direction at the upstream PLR.
FRR Bypass Assignment Error Notify message: uses Error Code 44 in the ERROR_SPEC Object (C-Type 6) carried in RSVP Notify message (Type 21). Sub-codes are 0 (Bypass Assignment Cannot Be Used), 1 (Bypass Tunnel Not Found), and 2 (One-to-One Bypass Already in Use). Sent from upstream PLR to downstream PLR.
Point of Remote Repair (PRR): a downstream MP that, upon receiving the protected LSP's rerouted Path message via a bypass tunnel, assumes the role of upstream PLR and triggers reroute of traffic and signaling in the upstream direction to restore co-routing. This role is introduced to solve RSVP soft-state timeout after node-protection FRR.
IANA assigned two new subobject types in the 'Class Type 21 ROUTE_RECORD - Type 1 Route Record' subregistry of the RSVP Parameters registry: Type 38 (BYPASS_ASSIGNMENT IPv4, carried in Path only) and Type 39 (BYPASS_ASSIGNMENT IPv6, carried in Path only), both referencing RFC 8271.
IANA extended the 'Error Codes and Globally-Defined Error Value Sub-Codes' subregistry with Error Code 44 'FRR Bypass Assignment Error' and three sub-codes: 0 (Bypass Assignment Cannot Be Used), 1 (Bypass Tunnel Not Found), 2 (One-to-One Bypass Already in Use).
The BYPASS_ASSIGNMENT subobject in an intercepted RSVP signaling message reveals additional information about the LSP's FRR protection (bypass tunnel IDs and destination addresses), but this is judged a minor risk as the information is available by other means. A randomly forged address in the subobject causes the MP to silently ignore it (no matching local tunnel found), limiting attack impact.
Node-protection FRR for bidirectional GMPLS LSPs operates in two phases: Phase 1 — downstream PLR and upstream PLR independently fast-reroute data traffic onto their respective bypass tunnels; Phase 2 — downstream MP (promoted to PRR) finds the reverse bypass tunnel terminating on the downstream PLR and reroutes upstream traffic and Resv signaling onto it, restoring co-routing. If no reverse bypass tunnel is found in Phase 2, the PRR tears down the protected LSP.
Revertive behavior after FRR (local revertive mode): downstream PLR resumes Path messages and traffic over the restored link; upstream PLR resumes traffic toward downstream PLR; PRR resumes Resv and traffic over the restored path, each stopping bypass tunnel use once the restored link is confirmed.
BYPASS_ASSIGNMENT IPv4 RRO subobject (Type 38): 8 bytes total — 1-byte Type (38), 1-byte Length (8), 2-byte Bypass Tunnel ID, 4-byte IPv4 Bypass Destination Address.
BYPASS_ASSIGNMENT IPv6 RRO subobject (Type 39): 20 bytes total — 1-byte Type (39), 1-byte Length (20), 2-byte Bypass Tunnel ID, 16-byte IPv6 Bypass Destination Address.