Refresh-Interval Independent RSVP Fast Reroute Facility Protection
updates
- rfc-4090 — Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Extracted elements (28)
A five-part solution structure is chosen: MP determination via B-SFRR-Ready + Node-ID Hello, failure-driven LSP state cleanup, Conditional PathTear for downstream signaling, Remote PathTear for PLR-to-MP direct teardown, and backward compatibility — each targeting a distinct stale-state scenario identified in Section 3.
RFC 4090 facility backup protection implicitly relies on short refresh timeouts for stale state cleanup. At long refresh intervals (order of minutes, as recommended by RFC 8370), stale states can linger causing scalability problems. This document introduces explicit teardown messages (Conditional PathTear and Remote PathTear) to eliminate this dependency.
The CONDITIONS object Class-Num follows the 10bbbbbb pattern (Class 135) so that routers not supporting the object will ignore it but still process the PathTear as a normal PathTear without generating an error, enabling backward compatibility.
RI-RSVP-FRR extensions are enabled per-LSP direction only when all relevant neighbors support them: for link protection, NHOP/PHOP must support; for node protection, both NHOP+NNHOP (downstream) or PHOP+PPHOP (upstream) must support. This allows incremental deployment scoped to network regions.
A node supporting facility backup protection (RFC 4090) MUST NOT set the RI-RSVP flag (I-bit) unless it supports all the extensions specified in this document. Setting the I-bit without full RI-RSVP-FRR support may result in lingering stale states and disruption of normal FRR operations.
A router that is not an MP MUST send a Conditional PathTear (containing the CONDITIONS object) if the PHOP link or adjacency goes down and the ingress requested node protection AND no PathTear was received from the upstream node.
An implementation supporting RI-RSVP-FRR MUST set the RI-RSVP Capable flag in the CAPABILITY object in Hello messages as specified in RFC 8370. Every RI-RSVP-FRR node MUST support backward compatibility procedures for LSP subsets traversing non-RI-RSVP-FRR nodes.
Each node along an LSP supporting these extensions MUST include its router ID in the Node-ID sub-object of the RRO in the Resv message. If the PLR in a different IGP area has not included a Node-ID sub-object, the router MUST execute backward compatibility procedures rather than MP procedures.
For Node-ID-based Hello sessions between non-immediate neighbors (PLR and MP), the router MUST set TTL to 255 in all outgoing Node-ID-based Hello messages. The default hello interval MUST be set to the default specified in RFC 8370.
If a node finds PHOP or PPHOP (for node-protected LSPs) does not support RI-RSVP-FRR extensions, it MUST reduce the refresh period in TIME_VALUES to the default short refresh interval and MUST NOT execute MP procedures from Section 4.3.
If a node finds that NHOP or NNHOP (for node-protected LSPs) does not support RI-RSVP-FRR extensions, it MUST reduce the refresh period in TIME_VALUES to the default short refresh interval and MUST NOT send Remote PathTear or Conditional PathTear to the downstream node.
If an LSP is preempted on an LP-MP or NP-MP after PHOP link failure but before backup LSP signaling completes, the node MUST send a normal PathTear and delete both PSB and RSB states, since preemption invalidates its MP role.
If local repair fails on the PLR after a failure, the PLR MUST send a Remote PathTear to the MP to clean up LSP state from the PLR to the egress. The TTL in the Remote PathTear message MUST be set to 255.
In parallel with creating NP-bypass or LP-bypass tunnels, the PLR MUST initiate a Node-ID-based Hello session to the NNHOP or NHOP node respectively to detect MP node failure and determine RI-RSVP capability. If the MP has not set the I-bit in the CAPABILITY object in Hello messages, the PLR MUST execute backward compatibility procedures.
The PLR MUST include its router ID in a Node-ID sub-object in the RRO carried in subsequent Path messages for the LSP, placing the Node-ID sub-object after the IPv4/IPv6 address or unnumbered interface ID sub-object.
The PLR MUST select the router ID of the NNHOP or NHOP node from the Node-ID sub-object in the RRO carried in the most recent Resv message. If the NP-MP in a different IGP area has not included a Node-ID sub-object, the PLR MUST execute backward compatibility procedures.
When a PLR detects a change in the Resv RRO indicating its former NP-MP is no longer on the LSP path, the PLR MUST send a Remote PathTear directly to its former NP-MP to trigger state cleanup.
When a router detects PHOP link or PHOP node failure for an LSP and is NOT an MP for the LSP, it MUST send a Conditional PathTear and delete the PSB and RSB states corresponding to the LSP.
When an NP-MP receives a Conditional PathTear, it MUST NOT delete the LSP state; it MUST check for a previously included B-SFRR-Ready object from the PHOP, remove it, and trigger a Path downstream. When a non-NP-MP receives a Conditional PathTear, it MUST delete LSP state and propagate a normal PathTear downstream.
When the PLR associates a bypass to a protected LSP, it MUST include a B-SFRR-Ready Extended ASSOCIATION object and trigger a Path message, setting the Association Source to its Node-ID address.
The CONDITIONS object (Class Number 135, C-type 1) is added to a PathTear to make it conditional. It contains a 32-bit Flags field with a Merge-point condition (M) bit at bit 31; when M=1, the PathTear MUST be processed according to the receiver's role as MP or not.
IANA added CLASS NUMBER 135 with Class Name 'CONDITIONS' to the 'Class Names, Class Numbers, and Class Types' registry in the RSVP Parameters registry group. A subregistry 'CONDITIONS Object Flags' was also added, with bit 31 (value 0x0001) assigned as the Merge-point flag. New C-types and flag registrations require IETF Review.
Because Node-ID Hello sessions are extended to non-immediate neighbors (TTL=255), implementations SHOULD provide options to configure per-neighbor or global Node-ID authentication keys, and SHOULD enable authentication for Hello messages received with TTL > 1. Implementations SHOULD also limit the number of Node-ID Hello sessions establishable on a router.
When using RSVP cryptographic authentication (RFC 2747), more robust algorithms such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 SHOULD be used when computing the keyed message digest where possible.
Once a router concludes it is the MP for a RI-RSVP-FRR-capable PLR, it MUST create a 'remote' path state for the LSP. This remote state is considered automatically deleted upon: receiving a Path message with no matching B-SFRR-Ready object, the Node-ID adjacency going down, receiving backup LSP signaling, receiving a PathTear, or a local policy/exception event.
When an NP-MP detects PHOP link or node failure, or receives a Conditional PathTear, it MUST retain PSB and RSB states until: the remote Node-ID adjacency with the PPHOP PLR goes down, a normal or Remote PathTear is received for its PSB, or a ResvTear is received for its RSB.
When the PHOP link fails on an LP-MP, the LP-MP MUST retain PSB and RSB states until: the Node-ID signaling adjacency with the PHOP PLR goes down, a normal or Remote PathTear is received for its PSB, or a ResvTear is received for its RSB. On PHOP node failure, the LP-MP MUST send a normal PathTear and delete states.
The CONDITIONS object is a 64-bit structure: a 16-bit Length field, an 8-bit Class field (value 135), an 8-bit C-type field (value 1), and a 32-bit Flags field where bit 31 is the Merge-point (M) bit and bits 0-30 are reserved (MUST be zero on transmission, ignored on receipt).