Techniques to Improve the Scalability of RSVP-TE Deployments
Extracted elements (24)
Per-Peer Flow Control requires RI-RSVP as a prerequisite because its back-pressure mechanism (detecting congestion via missing ACKs) only works reliably when acknowledgements are mandatory and the refresh interval is large enough to make ACK absence meaningful.
RI-RSVP eliminates RSVP's reliance on periodic refreshes and refresh timeouts by increasing the refresh interval to a large value (tens of minutes). This removes the dominant source of processing overhead in large-scale RSVP-TE deployments while preserving full functionality through complementary mechanisms.
The 30-second refresh interval for unacknowledged Path/Resv messages (uR) deliberately reuses the traditional RFC 2205 default refresh interval, because the large 20-minute RI-RSVP refresh interval is unsuitable for timely recovery of unacknowledged state.
The recommended node hello interval of 9 seconds was chosen to produce a hello timeout of 31.5 seconds (3.5 × 9), aligning with typical IGP hello timeout values and matching the overall rapid retransmit phase duration achieved by Retry-Limit 7.
Both RI-RSVP and Per-Peer Flow Control are fully backward compatible and can be deployed incrementally. If a peer does not signal the corresponding capability bit, the feature is not activated for that peer and traditional RSVP behavior is used.
Per-Peer Flow Control requires RI-RSVP as a prerequisite; an implementation MUST support RI-RSVP before enabling Per-Peer Flow Control.
A Per-Peer Flow Control implementation MUST indicate support via the CAPABILITY object in Hello messages by setting Bit Number 27 (0x0010), the Per-Peer Flow-Control Capable (F-bit), and MUST also set the Refresh-Reduction-Capable bit in all RSVP-TE message headers.
A Per-Peer Flow Control implementation MUST treat lack of ACKs from a peer as an indication of that peer's RSVP-TE control-plane congestion, and MUST throttle RSVP-TE messages to the affected peer on a per-peer basis.
A Per-Peer Flow Control implementation SHOULD prioritize Hello messages and ACKs over other RSVP messages, and SHOULD prioritize Tear/Error messages over trigger Path/Resv messages when peer congestion is detected.
A Per-Peer Flow Control implementation SHOULD use a Retry Limit (Rl) value of 7 (rather than RFC 2961's suggested value of 3) to align the retransmit phase duration (~31.5 seconds) with the hello timeout.
An implementation supporting RI-RSVP or Per-Peer Flow Control MUST indicate support for RSVP Refresh Overhead Reduction extensions as specified in RFC 2961, support receipt of all RFC 2961 messages, and initiate all RFC 2961 mechanisms by default.
An RI-RSVP implementation MUST couple individual LSP state with the state of the corresponding RSVP-TE signaling adjacency; upon detecting adjacency failure, the speaker MUST treat all Path and Resv states learned via that adjacency as timed out.
An RI-RSVP implementation MUST indicate support via the CAPABILITY object in Hello messages by setting Bit Number 28 (0x0008), the RI-RSVP Capable (I-bit).
An RI-RSVP implementation MUST make the default refresh interval (R) a large value, with 20 minutes RECOMMENDED, to eliminate refresh-based state synchronization overhead.
An RI-RSVP implementation MUST use a separate shorter refresh interval for unacknowledged Path/Resv (uR) messages, with a default of 30 seconds RECOMMENDED, ensuring unacknowledged state is refreshed promptly despite the large general refresh interval.
An RI-RSVP implementation MUST use Hello sessions based on Node-ID for detection of RSVP-TE signaling adjacency failures, with a recommended node hello interval of 9 seconds (yielding a hello timeout of ~31.5 seconds).
Any node setting the I-bit in its CAPABILITY object MUST also set the Refresh-Reduction-Capable bit in the common header of all RSVP-TE messages. If a peer sets the I-bit but not the Refresh-Reduction-Capable bit, RI-RSVP functionality MUST NOT be activated for that peer.
Nodes receiving a non-out-of-order message containing a MESSAGE_ID object with the ACK_Desired flag set MUST respond with a MESSAGE_ID_ACK object. This upgrades the RFC 2961 SHOULD to a MUST for implementations supporting these techniques.
Per-Peer Flow-Control functionality MUST NOT be activated with a peer that does not indicate support. If a peer has not indicated capability, it SHOULD NOT be assumed that the peer will always acknowledge MESSAGE_ID objects with ACK_Desired set.
The RI-RSVP functionality MUST NOT be activated with a peer that does not indicate support for it. If deactivated, the implementation MUST fall back to the traditional smaller refresh interval per RFC 2205.
The Per-Peer Flow-Control Capable flag is Bit Number 27 (hex value 0x0010), called the F-bit, set in the CAPABILITY object carried in Hello messages to advertise Per-Peer Flow Control support.
The RI-RSVP Capable flag is Bit Number 28 (hex value 0x0008), called the I-bit, set in the CAPABILITY object carried in Hello messages to advertise RI-RSVP support.
IANA assigned two new bit flags in the 'Capability Object values' subregistry within the 'Resource Reservation Protocol (RSVP) Parameters' registry: Bit 28 (0x0008) for RI-RSVP Capable (I) and Bit 27 (0x0010) for Per-Peer Flow-Control Capable (F).
This document introduces no new security issues. The security considerations of RFC 2205 (RSVP), RFC 3209 (RSVP-TE), and RFC 5920 (Security Framework for MPLS and GMPLS Networks) remain applicable.