RSVP Refresh Overhead Reduction Extensions
updated by
- rfc-5063 — Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
Extracted elements (28)
RSVP messages are categorized as trigger messages (advertising new or changed state) or refresh messages (identical previously-transmitted state). Only Path and Resv messages can be refresh messages. This distinction is the foundation for all optimizations: refresh messages can be replaced by lightweight summary tokens, while trigger messages require reliable delivery.
Srefresh messages do not recover from internal state corruption the way full Path/Resv refreshes do. RFC 2961 recommends two supplementary mechanisms: (1) periodic checksum-based verification of internal state to detect missed trigger messages, and (2) occasional standard refresh messages at a longer interval than Srefresh to provide full error recovery.
Standard RSVP refresh messages create two operational problems: scaling (CPU/memory grows proportionally with session count) and reliability/latency (state synchronization delay is bounded by the refresh interval when messages are lost). Increasing R reduces overhead but worsens latency; decreasing R does the opposite. These extensions address both dimensions without adjusting refresh rate.
Bundle messages MUST NOT be sent to neighbors that do not support bundling. Path and PathTear messages for multicast sessions MUST NOT be included in Bundle messages when the outgoing link is not point-to-point or when the next hop does not support the refresh overhead reduction extensions.
Each RSVP Bundle message MUST occupy exactly one IP datagram (allowing IP fragmentation up to approximately 64 KB). Bundle messages SHOULD NOT carry the Router Alert IP option because they are addressed directly to RSVP neighbors.
For multicast Path messages with ACK_Desired set, receivers MUST wait a random interval before acknowledging to prevent ACK implosion. The random interval SHOULD be between zero and a configured maximum proportional to the refresh and rapid retransmission intervals.
Implementations MUST use the exponential back-off retransmission procedures defined in Section 6 (or equivalent) when retransmitting messages with ACK_Desired set. The retransmission timer is not advertised via the TIME_VALUE object.
Nodes setting the ACK_Desired flag SHOULD retransmit unacknowledged messages more rapidly than the standard refresh period. The rapid retransmission rate MUST use the exponential back-off procedures defined in Section 6. A MESSAGE_ID_ACK MUST NOT be generated when ACK_Desired is not set in the received MESSAGE_ID object.
Nodes supporting refresh overhead reduction MUST examine the Flags field of every received RSVP message. If the Refresh-Reduction-Capable bit transitions from set to clear, Srefresh messages MUST NOT be used and Bundle messages MUST NOT be sent to that neighbor.
The Message_Identifier MUST be unique per generator IP address. For trigger messages the Message_Identifier MUST exceed every previously used value with the same Epoch. The Epoch value MUST NOT be changed except on node or RSVP agent restart.
The Srefresh refresh period MUST NOT be longer than the standard Path/Resv refresh period, and Srefresh use MUST NOT cause state to time out at the RSVP next hop. When Srefresh is used, generation of standard refresh messages for the same state SHOULD be suppressed.
Upon receiving a MESSAGE_ID_NACK object, the receiver MUST transmit the corresponding installed state via a standard Path or Resv message if matching state can be found. This mechanism restores full state when summary refresh loses synchronization.
Upon receiving an Srefresh, the node MUST update matching state and MUST generate an Srefresh NACK for unmatched Message_Identifier fields. For multicast unmatched fields, a NACK MUST be generated only when the node would forward data from the listed sender (RPF check); otherwise the unmatched field is silently ignored.
When a receiver does not support the MESSAGE_ID class (Class 23, form 0bbbbbbb), it returns an 'Unknown Object Class' error per RFC 2205. The generator MUST re-send the original message without the MESSAGE_ID object upon receiving such an error.
Within a message, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects MUST immediately follow the INTEGRITY object (or the message header if no INTEGRITY object is present). The MESSAGE_ID object MUST follow any ACK/NACK objects. Only one MESSAGE_ID object MAY appear per message or sub-message.
A Refresh-Reduction-Capable bit (Flags 0x01) is added to the RSVP common header. When set it indicates the node supports Bundle messages, MESSAGE_ID objects, Ack messages, and Srefresh messages. The bit is meaningful only between RSVP neighbors and must be monitored continuously for capability changes.
Exponential back-off retransmission uses three per-interface parameters: initial retransmission interval Rf (suggested 500 ms), rapid retry limit Rl (suggested 3 transmissions), and increment factor Delta (suggested 1 for power-of-2 doubling). Each successive retransmission waits Rk * (1 + Delta) seconds; receipt of a MESSAGE_ID_ACK cancels further retransmission.
The Ack message (Msg Type 13) carries one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK objects and MUST NOT contain MESSAGE_ID objects. It is addressed to the unicast address of the node that generated the message being acknowledged, found in the RSVP_HOP object for Path/Resv or in the IP source address for other messages.
The RSVP Bundle message (Msg Type 12) aggregates multiple standard RSVP messages into a single IP datagram to reduce per-message processing overhead. Sub-messages may be any type except another Bundle message; each sub-message is processed independently using the Send_TTL from the bundle header.
The Summary Refresh (Srefresh) message (Msg Type 15) refreshes RSVP Path and Resv state by listing Message_Identifier tokens instead of transmitting full Path/Resv messages. The receiver matches each identifier to installed state and updates it as if a standard refresh had arrived; unmatched identifiers elicit a NACK.
RFC 2961 assigns new RSVP object class numbers and message types: MESSAGE_ID Class = 23 (C_Type 1), MESSAGE_ID_ACK Class = 24 (C_Types 1–2 for ACK/NACK), MESSAGE_ID_LIST Class = 25 (C_Types 1–5 for LIST/SRC_LIST/MCAST_LIST in IPv4 and IPv6), Bundle message type = 12, Ack message type = 13, and Srefresh message type = 15.
No new security issues are raised by the RSVP Refresh Overhead Reduction Extensions. Implementers are referred to RFC 2205 for a general discussion of RSVP security considerations. The INTEGRITY object processing rules are preserved and apply normally within Bundle sub-messages.
The Bundle header shares the RSVP common header layout: Vers (4 bits), Flags (4 bits, 0x01 = Refresh-Reduction-Capable), Msg Type (8 bits, value 12), RSVP Checksum (16 bits, MAY be zero since sub-messages carry their own checksums), Send_TTL (8 bits), Reserved (8 bits), RSVP Length (16 bits, total bundle length including header).
The MESSAGE_ID_ACK object (Class 24, C_Type 1) and MESSAGE_ID_NACK object (Class 24, C_Type 2) each contain: Flags (8 bits, MUST be zero on transmission), Epoch (24 bits, copied from the acknowledged message), and Message_Identifier (32 bits, copied from the acknowledged message).
The MESSAGE_ID LIST object (Class 25, C_Type 1) contains Flags (8 bits, MUST be zero), Epoch (24 bits), and one or more Message_Identifier fields (32 bits each) identifying state to be refreshed. Used in Srefresh messages to refresh Resv state and unicast Path state.
The MESSAGE_ID MCAST_LIST object (Class 25, C_Type 4 IPv4 / C_Type 5 IPv6) carries tuples of Message_Identifier, Source_IP_Address, and Destination_IP_Address. Used on point-to-point links addressed directly to the RSVP next hop for multicast Path state refresh; group address is explicit rather than derived from the IP destination.
The MESSAGE_ID object (Class 23, C_Type 1) encodes: Flags (8 bits, 0x01 = ACK_Desired), Epoch (24 bits, randomly selected at startup to indicate Message_Identifier resets), and Message_Identifier (32 bits, monotonically increasing per generator IP address within an Epoch).
The MESSAGE_ID SRC_LIST object (Class 25, C_Type 2 IPv4 / C_Type 3 IPv6) carries tuples of Message_Identifier (32 bits) paired with Source_IP_Address (4 or 16 bytes). Sent to the multicast session's destination address to refresh multicast Path state; each identifier must be followed by the corresponding path sender's source address.