Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
updates
Extracted elements (26)
Prior GMPLS Graceful Restart mechanisms (RFC 3473) do not support full recovery of Path state on ingress nodes, nor recovery of all RSVP objects (e.g., ERO, Protection, Admin Status, Session Attribute). The extensions in this document fill that gap by having the downstream neighbor return the last received Path message to the restarting node.
The previously transmitted ERO cannot always be reconstructed from the data plane: an ingress may have derived it from path computation, and a transit node may have expanded loose hops. Recovering the ERO from the downstream neighbor minimizes subsequent changes to downstream LSP state.
The Capability object uses Class-Number 134 (form 10bbbbbb), so nodes that do not support it will silently discard it and revert to RFC 3473 recovery procedures. This ensures backward compatibility: neither a non-supporting restarting node nor a non-supporting downstream neighbor will send or expect RecoveryPath messages.
A downstream RSVP neighbor MUST send a RecoveryPath message for each LSP associated with the restarting node for which it has sent a Resv message, after detecting restart capability per Section 4.4. If the restarting node's R-bit is absent or cleared, the neighbor SHOULD NOT send RecoveryPath messages.
A restarting node MUST NOT create data/forwarding plane state as the result of any of the extensions defined in this document; these extensions are solely for control plane state recovery.
After a resynchronized LSP is identified, the restarted node MUST send a trigger Path message downstream; the ERO in that Path message SHOULD match the ERO received in the RecoveryPath message to avoid triggering unnecessary reprocessing at downstream nodes.
All nodes supporting these extensions MUST be able to transmit and properly receive and process RecoveryPath messages, and MUST be able to set both the T and R bits. Both T and R bits SHOULD be set (1) by default; when transmission is disabled, T MUST be zero; when reception is not desired, R MUST be zero.
All RecoveryPath messages SHOULD be sent at least once within approximately 1/2 of the Recovery Time advertised by the restarted neighbor. If many LSPs must be recovered, messages SHOULD be spread across that 1/2 Recovery Time interval to avoid CPU overload on the restarted node.
At the end of the Recovery Period, any state installed from RecoveryPath messages that is not resynchronized SHOULD be discarded. Path messages carrying a Recovery_Label that remain unresynchronized MUST be treated as received during the Recovery Period and processed per RFC 3473.
Each RecoveryPath-related Srefresh MESSAGE_ID LIST object MUST have the RecoveryPath Flag set (1). Path state updated after the restart (detected by matching Epoch in the latest Hello message) MUST NOT be included in such Srefresh messages.
If the downstream RSVP neighbor receives a Capability object with the R-bit set but without the Restart_Cap object, it MUST process the Hello message as if the R-bit is cleared (0), preventing inadvertent RecoveryPath procedures without proper graceful restart advertisement.
In the RecoveryPath message's sender descriptor, the Recovery Label object MUST be included with the label value copied from the Label object in the most recent Resv message sent to the restarted node. MESSAGE_ID, MESSAGE_ID_ACK, MESSAGE_ID_NACK, and Integrity objects are not copied but regenerated fresh.
The destination address in the IP header of a RecoveryPath message MUST be the same as the destination address used in the IP header of the corresponding Resv message last generated by the sending node.
Upon receiving a MESSAGE_ID NACK with the RecoveryPath Flag set, the downstream RSVP neighbor MUST generate a RecoveryPath message per Section 4.5.1 for the matching received Path message. If no matching Path message is found, the NACK is ignored.
Upon receiving an Srefresh with the RecoveryPath Flag set, if matching transmitted Path state is found, the restarted node MUST generate a trigger Path message per Section 4.5.2.2. If no match is found, the restarted node MUST generate a MESSAGE_ID NACK with the RecoveryPath Flag set (1).
When both the R-bit and S-bit are set in the restarted node's Capability object, the downstream RSVP neighbor MUST follow the Srefresh generation procedures in Section 5.3.1. If the S-bit is cleared, it MUST revert to normal RecoveryPath procedures in Section 4.5.1. If R-bit is cleared but S-bit is set, it MUST treat the S-bit as cleared.
A new flag bit 0x02 (RecoveryPath Flag) is added to the Flags field of the MESSAGE_ID_ACK, MESSAGE_ID_NACK, and MESSAGE_ID LIST objects defined in RFC 2961. When set, it indicates the object carries MESSAGE_ID information related to Path messages recoverable via RecoveryPath messages.
RecoveryPath Summary Refresh extends the RFC 2961 Summary Refresh mechanism to allow selective transmission of RecoveryPath messages. The restarting node sets both R-bit and S-bit in the Capability object; the downstream neighbor then sends Srefresh messages identifying previously received Path state (rather than previously transmitted state) via MESSAGE_ID LIST objects with the RecoveryPath Flag set.
The Capability object is carried in RSVP Hello messages. Absence of the Capability object MUST be treated as if all three bits (T, R, S) are cleared (0). The Hello message format is extended to: <Hello Message> ::= <Common Header> [<INTEGRITY>] <HELLO> [<RESTART_CAP>] [<CAPABILITY>].
The RecoveryPath message uses the same format as a Path message (RFC 3473) but is assigned a new message type number 30, allowing it to be identified independently. Its syntax is: <RecoveryPath Message> ::= <Path Message>.
IANA assigned Class-Number 134 (form 10bbbbbb) to the new Capability Object and message type 30 to the RecoveryPath message. A new 32-bit name space within the Capability Object was created; new bit assignments require IETF Consensus per RFC 2434. Three bits are initially defined: T (RecoveryPath Transmit Enabled), R (RecoveryPath Desired), S (RecoveryPath Srefresh Capable).
If an RSVP agent restarts due to external attack, neighboring agents incur additional processing overhead for RecoveryPath handling, potentially impairing their other control plane functions. This impact can be minimized by advertising a large enough Recovery Time, spreading RecoveryPath message transmission across the recovery interval.
The extensions assume a full trust model between RSVP neighbors: while protocol exchanges can be secured via RFC 2747 cryptographic authentication, no mechanism verifies that restart information is correctly mapped from pre-restart exchanges. This is considered acceptable because the same trust model underlies normal protocol operation.
The procedures cannot be used to create false forwarding state: a restarting node that receives a RecoveryPath message not matching existing forwarding state MUST NOT create or modify forwarding state to match, and SHOULD log such an event as a potential attack indicator.
During the Recovery Period, when the restarting node receives both a RecoveryPath message and a corresponding Path message with a Recovery Label, it locates forwarding state using the RSVP HOP and Recovery Label objects from each. If complete forwarding state is found, the LSP transitions to 'resynchronized' and a trigger Path message MUST be sent downstream; if not found, the Path message is treated as a new LSP setup request.
The Capability object uses Class-Number 134 (form 10bbbbbb) and C-Type 1. It is a 32-bit field carried in Hello messages, containing three defined bits: RecoveryPath Transmit Enabled (T, bit 2), RecoveryPath Desired (R, bit 1), and RecoveryPath Srefresh Capable (S, bit 0); remaining bits are Reserved and MUST be zero.