RFC 2961
RSVP Refresh Overhead Reduction Extensions
Part 1 of 8 🎀
RFC 2961: RSVP Refresh Overhead Reduction Extensions 💖
okay bestie, RFC 2961 is giving Standards Track energy 🎀. It came out in April 2001 and was written by L. Berger (LabN Consulting, LLC), D. Gan and P. Pan (Juniper Networks, Inc.), G. Swallow (Cisco Systems, Inc.), and F. Tommasi and S. Molendini (University of Lecce) 🧚. It's a proper Internet standards track doc, so it's official, but the content is actually iconic ✨.
Status of this Memo 📜
this doc is an Internet standards track protocol spec for the Internet community, and it literally wants your discussion and suggestions for improvements 💬. To check the standardization state and status of this protocol, look at the current edition of "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌍.
Copyright Notice ©️
Copyright (C) The Internet Society (2001). All Rights Reserved. 🫶
Abstract ✨
okay so this doc describes a bunch of mechanisms that cut down the processing overhead of refresh messages 💅. They also get rid of the state synchronization latency you get when an RSVP (Resource ReserVation Protocol) message gets lost 😭, and they can refresh state without sending whole refresh messages when you want that 🦋. The same extensions also support reliable RSVP message delivery on a per hop basis 🔥. And the best part: these extensions present no backwards compatibility issues 👑.
Table of Contents 🌸
1 Introduction and Background ................................2
1.1 Trigger and Refresh Messages ...............................4
2 Refresh-Reduction-Capable Bit ..............................4
3 RSVP Bundle Message ........................................5
3.1 Bundle Header ..............................................5
3.2 Message Formats ............................................6
3.3 Sending RSVP Bundle Messages ...............................7
3.4 Receiving RSVP Bundle Messages .............................8
4 MESSAGE_ID Extension .......................................8
4.1 Modification of Standard Message Formats ...................9
4.2 MESSAGE_ID Objects ........................................10
4.3 MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects ................11
4.4 Ack Message Format ........................................11
4.5 MESSAGE_ID Object Usage ...................................12
4.6 MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage ....14
4.7 Multicast Considerations ..................................15
4.7.1 Reference RSVP/Routing Interface ..........................16
4.8 Compatibility .............................................16
5 Summary Refresh Extension .................................17
5.1 MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects ..........18
5.2 Srefresh Message Format ...................................24
5.3 Srefresh Message Usage ....................................25
5.4 Srefresh NACK .............................................28
5.5 Preserving RSVP Soft State ................................28
5.6 Compatibility .............................................29
6 Exponential Back-Off Procedures ...........................29
6.1 Outline of Operation ......................................30
6.2 Time Parameters ...........................................30
6.3 Retransmission Algorithm ..................................31
6.4 Performance Considerations ................................31
7 Acknowledgments ...........................................31
8 Security Considerations ...................................32
9 References ................................................32
10 Authors' Addresses ........................................33
11 Full Copyright Statement...................................341. Introduction and Background 🌈
okay so standard RSVP [RFC2205] keeps state alive by generating RSVP refresh messages 💌. Refresh messages do two jobs: they sync state between RSVP neighbors, and they recover from lost RSVP messages 🔄. Using refresh messages to cover all those possible failures has caused a few operational problems 😩. One problem is scaling, and the other is the reliability and latency of RSVP Signaling 🫠.
The scaling problems come from how many resources RSVP needs (processing and memory) to run ⚙️. Those resource requirements go up in proportion to the number of sessions 📈. Every session needs RSVP Path and Resv messages to be generated, sent, received, and processed once per refresh period 🔁. So supporting a large number of sessions, and the big pile of refresh messages that comes with them, is a real scaling problem 💀.
The reliability and latency problem shows up when a non-refresh RSVP message gets lost in transit 🙈. Standard RSVP [RFC2205] recovers from a lost message through RSVP refresh messages 🫤. So when RSVP messages get lost, the end-to-end latency of RSVP signaling becomes tied to the refresh interval of whichever node(s) experienced the loss ⏳. When signaling is limited by the refresh interval, the delay to set up or change a reservation can be too long for some applications 😭.
One way to tackle the refresh volume problem is to increase the refresh period, "R" as defined in Section 3.7 of [RFC2205] 📅. Bumping up R gives a linear improvement on transmission overhead, but the trade-off is that it takes longer to synchronize state 🐢.
One way to tackle the reliability and latency of RSVP Signaling is to decrease the refresh period R ⚡. Lowering R makes it more likely that state gets installed even when messages are lost, but the cost is a higher refresh message rate and more processing work 💸.
There's also the issue of how long it takes to deallocate resources after a tear message is lost 🫥. RSVP doesn't retransmit ResvTear or PathTear messages 🙅♀️. So if the only tear message that got sent is lost, resources only get deallocated once the "cleanup timer" interval has passed, and that can leave resources allocated for way longer than needed 🕰️. Even if you adjust the refresh period, the "cleanup timer" still has to expire, because tear messages aren't retransmitted 🥲.
The extensions in this document fix both the refresh volume and the reliability issues without just changing the refresh rate 💫. Together they're called the "Refresh Overhead Reduction" or the "Refresh Reduction" extensions 🧚. A Bundle message is defined to reduce overall message handling load 📦. A MESSAGE_ID object is defined so the receiver can more easily spot an unchanged message, which cuts down refresh message processing 👀. A MESSAGE_ACK object is defined that can detect message loss and support reliable RSVP message delivery on a per hop basis 🫶. And a summary refresh message is defined so state can be refreshed without sending whole refresh messages, while RSVP still knows when state is lost and can adjust to routing changes 🦋.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖.
1.1. Trigger and Refresh Messages 🎯
This document sorts RSVP messages into two types: trigger and refresh messages ✨. Trigger messages are the RSVP messages that advertise state or any other info that hasn't been sent before 📣. That includes messages advertising new state, a route change that alters a reservation path, or a modification to an existing RSVP session or reservation 🛤️. Trigger messages also cover messages that carry changes in non-RSVP processed objects, like changes in the Policy or ADSPEC objects 🧩.
Refresh messages represent state that was already advertised 🔁. They contain exactly the same objects and the same information as a previously sent message, and they go over the same path 🛣️. Only Path and Resv messages can be refresh messages 💜. Refresh messages are identical to the matching previously sent message, with a few possible exceptions 🙈. Specifically, the checksum field, the flags field and the INTEGRITY object may be different in refresh messages 🫣.
2. Refresh-Reduction-Capable Bit 🔥
To say you support the refresh overhead reduction extensions, a new capability bit gets added to the common RSVP header, which is defined in [RFC2205] 🎀.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | Msg Type | RSVP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | (Reserved) | RSVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Flags field here is 4 bits 🧃. The bit that matters is 0x01, which is the Refresh (overhead) reduction capable bit 🦋. When it's set, it means this node is willing and able to receive all the messages and objects described in this document 🫶. That covers the Bundle message in Section 3, the MESSAGE_ID objects and Ack messages in Section 4, and the MESSAGE_ID LIST objects and Srefresh message in Section 5 💅. This bit only means something between RSVP neighbors 👯♀️.
Nodes that support the refresh overhead reduction extensions also have to watch for when a next hop stops sending RSVP messages with the Refresh-Reduction-Capable bit set 👀. To cover this, nodes supporting these extensions MUST examine the flags field of each received RSVP message 🔍. If the flag changes from indicating support to indicating non-support, then, unless configured otherwise, Srefresh messages (described in Section 5) MUST NOT be used for subsequent state refreshes to that neighbor, and Bundle messages (Section 3) MUST NOT be sent to that neighbor 🚫. Also, a node that supports reliable RSVP message delivery (Section 4) but not Bundle and Srefresh messages will not set the Refresh-Reduction-Capable bit 🙅♀️.
3. RSVP Bundle Message 📦
okay so an RSVP Bundle message is made of a bundle header, followed by a body with a variable number of standard RSVP messages inside 🧁. A Bundle message is how you aggregate multiple RSVP messages into a single PDU 🍓. The term "bundling" is used so nobody confuses it with RSVP reservation aggregation 💖. The next subsections define the bundle header format and the rules for putting standard RSVP messages into the message ✨.
3.1. Bundle Header ✨
okay bestie, the bundle header is literally the RSVP common header in a new outfit 💅 It has the same layout as the one in [RFC2205], so if you know that one you already know this one 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | Msg type | RSVP checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | (Reserved) | RSVP length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field does 🎀
- Vers (4 bits): the protocol version number. It's version
1. 🌸 - Flags (4 bits): this one is a little bag of bits 🧚
0x01: Refresh (overhead) reduction capable. See Section 2 for the details.0x02-0x08: Reserved.
- Msg type (8 bits): it's
12for Bundle. ✨ - RSVP checksum (16 bits): this is the one's complement of the one's complement sum of the entire message, with the checksum field set to zero while the checksum is being worked out. An all-zero value means no checksum was sent 🙈 Since the sub-messages can carry their own checksum and the INTEGRITY object for authentication, this field MAY be set to zero. Heads up though: if the checksum isn't computed, the bundle header isn't covered by any checksum at all 😭 And if the checksum is computed, the sub-messages MAY set their own checksum to zero.
- Send_TTL (8 bits): the IP TTL value the message was sent with. RSVP uses this to spot a non-RSVP hop by comparing the Send_TTL with the IP TTL on the received message 👑
- RSVP length (16 bits): the total length of this RSVP Bundle message in bytes. That includes the bundle header and every sub-message that follows 💜
3.2. Message Formats
okay so an RSVP Bundle message must contain at least one sub-message 🍓 A sub-message MAY be any message type, except for another Bundle message. No bundles inside bundles, bestie 💀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Flags | 12 | RSVP checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | (Reserved) | RSVP length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// First sub-message //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// More sub-messages.. //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.3. Sending RSVP Bundle Messages
Okay, real talk: support for RSVP Bundle messages is optional 🌈 Bundling is a total scaling glow-up, since it cuts processing overhead and bandwidth use. But a node isn't required to bundle every standard RSVP message. The one hard rule is that a node MUST always be ready to receive standard RSVP messages ✨
Bundles can only go to RSVP neighbors that support bundling 🦋 There are two ways to find that out: (1) manual configuration, and (2) watching for the Refresh-Reduction-Capable bit (see Section 2) in the RSVP messages you receive. And if the RSVP neighbor doesn't support Bundle messages, Bundle messages MUST NOT be used. No exceptions, periodt 🙅♀️
RSVP Bundle messages travel hop by hop between RSVP-capable nodes as "raw" IP datagrams with protocol number 46 🧚 The IP source address is an address local to the system that made the Bundle message. The IP destination address is the RSVP neighbor the sub-messages are meant for.
Bundle messages SHOULD NOT be sent with the Router Alert IP option in their IP headers. Why? Because Bundle messages are addressed straight to RSVP neighbors, so they don't need it 💅
Each RSVP Bundle message MUST occupy exactly one IP datagram, which is about 64K bytes 🍓 If it's bigger than the MTU, IP fragments it and the recipient node puts it back together. Implementations may choose to cap each Bundle message at the MTU of the outgoing link, like 1500 bytes. Implementations SHOULD also limit how long a message gets delayed so it can be bundled. The limits can differ for trigger messages and standard refresh messages. Trigger messages SHOULD be delayed a minimal amount of time, while refresh messages may be delayed up to their refresh interval. Also, messages about the same Resv or Path state should not be delayed at different intervals, so the ordering stays intact 🫶
If the RSVP neighbor isn't known, or changes in next hops can't be identified through routing, Bundle messages MUST NOT be used 😭 Heads up that when the routing next hop isn't RSVP capable, it usually won't be possible to spot next-hop changes.
Any message that the RSVP neighbor in a Bundle message's destination address will handle can go in the same message 💖 That covers all the RSVP messages that would go out a point-to-point link. It also covers any message, like a Resv, addressed to the same destination address. Path and PathTear messages count too, but only when the next hop is known to be the destination and next-hop changes can be detected. Path and PathTear messages for multicast sessions MUST NOT be sent in Bundle messages when the outgoing link isn't a point-to-point link, or when the next hop doesn't support the refresh overhead reduction extensions. Those are the rules, bestie 👑
3.4. Receiving RSVP Bundle Messages
If the local system doesn't recognize a Bundle message, or doesn't want to accept one, the received messages shall be discarded without any further analysis 🙈
Next up, the receiver compares the Send_TTL that a Bundle message was sent with against the IP TTL it was received with 🔍 If a non-RSVP hop is detected, the number of non-RSVP hops gets recorded, and it's used later when processing the sub-messages.
Then the receiver checks the version number and the checksum of the RSVP Bundle message. If there's any mismatch, the message gets discarded 💀
After that, the receiver starts unpacking the individual sub-messages 🎀 Each sub-message has its own complete message length and authentication information. Except for using the Send_TTL from the Bundle header, each sub-message gets processed as if it had arrived on its own ✨
4. MESSAGE_ID Extension 🆔
Three new objects are defined as part of the MESSAGE_ID extension: the MESSAGE_ID object, the MESSAGE_ID_ACK object, and the MESSAGE_ID_NACK object 🦋 The first two are used for acknowledgments and reliable RSVP message delivery. The last one supports the summary refresh extension described in Section 5. The MESSAGE_ID object can also give a quick heads-up that the message carrying it is a refresh message, which the receiving node can use to cut down on refresh processing 💜
Message identification and acknowledgment happen on a per-hop basis 🌸 Every type of MESSAGE_ID object has a message identifier in it. The identifier MUST be unique on a per-object-generator's-IP-address basis. You can include no more than one MESSAGE_ID object in an RSVP message. Each message with a MESSAGE_ID object may be acknowledged with a MESSAGE_ID_ACK object, when it's indicated. MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be piggy-backed on unrelated RSVP messages, or sent in RSVP Ack messages. RSVP messages carrying any of the three object types may be included in a bundle message, and when they are, each object gets treated as if it were in a standard, non-bundled RSVP message 🧚
4.1. Modification of Standard Message Formats
The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be included in the standard RSVP messages, as defined in [RFC2205] 🎀 Here's the placement drama: when they're included, one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK objects MUST immediately follow the INTEGRITY object. If there's no INTEGRITY object, they MUST immediately follow the message or sub-message header instead. Only one MESSAGE_ID object MAY be included in a message or sub-message, and it MUST come after any MESSAGE_ID_ACK or MESSAGE_ID_NACK objects that are present. If there are no MESSAGE_ID_ACK or MESSAGE_ID_NACK objects, the MESSAGE_ID object MUST immediately follow the INTEGRITY object. And if there's no INTEGRITY object either, the MESSAGE_ID object MUST immediately follow the message or sub-message header 💅
The ordering of the ACK objects for all standard RSVP messages goes like this 👑
<Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]4.2. MESSAGE_ID Objects
The MESSAGE_ID Class is 23 🌈
MESSAGE_ID object
The MESSAGE_ID object is identified by Class = MESSAGE_ID Class, C_Type = 1 🍓 Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Let's go through the fields 🦋
- Flags (8 bits)
0x01= ACK_Desired flag. This one says the sender is asking the receiver to send an acknowledgment for the message 🙌
- Epoch (24 bits): a value that shows when the Message_Identifier sequence has reset. It SHOULD be randomly generated each time a node reboots or the RSVP agent restarts. The value SHOULD NOT be the same as the one used when the node was last operational. And this value MUST NOT be changed during normal operation 🫶
- Message_Identifier (32 bits): when it's combined with the message generator's IP address, this field uniquely identifies a message 💖 The values here change incrementally, and they only go down when the Epoch changes or when the value wraps around.
4.3. MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects ✨
okay bestie, these are the little receipts 🧾 that say "yep, got your message." Here's how the MESSAGE_ID_ACK object is laid out 💅
MESSAGE_ID_ACK Class = 24
MESSAGE_ID_ACK object
Class = MESSAGE_ID_ACK Class, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags: 8 bits 🚩
No flags are currently defined. This field MUST be zero on transmission and ignored on receipt.
Epoch: 24 bits 🕰️
This is the Epoch field copied from the message being acknowledged.
Message_Identifier: 32 bits 🔢
This is the Message_Identifier field copied from the message being acknowledged.
MESSAGE_ID_NACK object
Class = MESSAGE_ID_ACK Class, C_Type = 2
Definition is the same as the MESSAGE_ID_ACK object.The MESSAGE_ID_NACK object is literally the same thing, just with C_Type = 2 instead of 1 🙈
4.4. Ack Message Format 📬
Ack messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK objects. They MUST NOT contain any MESSAGE_ID objects. Ack messages are sent between neighboring RSVP nodes. The IP destination address of an Ack message is the unicast address of the node that generated the message(s) being acknowledged. For messages with RSVP_HOP objects, such as Path and Resv messages, the address is found in the RSVP_HOP object. For other messages, such as ResvConf, the associated IP address is the source address in the IP header. The IP source address is an address of the node that sends the Ack message.
Here's the Ack message format 🎀
<ACK Message> ::= <Common Header> [ <INTEGRITY> ]
<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]For Ack messages, the Msg Type field of the Common Header MUST be set to 13. 🔥
Section 4.6 gives you the tea on when an Ack message should be used and when MESSAGE_ID objects should be sent piggy-backed in other RSVP messages 🫖
4.5. MESSAGE_ID Object Usage 🧠
okay this section is the main character of the whole MESSAGE_ID thing 👑 The MESSAGE_ID object may be included in any RSVP message other than the Ack and Bundle messages. It's always generated and processed over a single hop between RSVP neighbors. The IP address of the object generator (the node that creates the object) is represented in a per-RSVP-message-type-specific fashion. For messages with RSVP_HOP objects, such as Path and Resv messages, the generator's IP address is found in the RSVP_HOP object. For other messages, such as ResvConf, the generator's IP address is the source address in the IP header.
Quick heads-up, MESSAGE_ID objects can only be used in Bundle sub-messages, but not in a Bundle message 🙅♀️ As is always the case with the Bundle message, each sub-message is processed as if it was received individually. That includes processing of MESSAGE_ID objects.
The Epoch field 🕰️
The Epoch field contains a generator-selected value. It's used to indicate when the sender resets the values used in the Message_Identifier field. On startup, a node SHOULD randomly select a value to be used in the Epoch field. The node SHOULD ensure that the selected value is not the same as was used when the node was last operational. The value MUST NOT be changed unless the node or the RSVP agent is restarted.
The Message_Identifier field 🔢
The Message_Identifier field contains a generator-selected value. This value, when combined with the generator's IP address, identifies a particular RSVP message and the specific state information it represents. The combination of Message_Identifier and Epoch can also be used to detect out-of-order messages. When a node is sending a refresh message with a MESSAGE_ID object, it SHOULD use the same Message_Identifier value that was used in the RSVP message that first advertised the state being refreshed. When a node is sending a trigger message, the Message_Identifier value MUST have a value that is greater than any other value previously used with the same Epoch field value. A value is considered to have been used when it has been sent in any message using the associated IP address with the same Epoch field value.
The ACK_Desired flag 🙋♀️
The ACK_Desired flag is set when the MESSAGE_ID object generator wants a MESSAGE_ID_ACK object sent in response to the message. This info can be used to ensure reliable delivery of RSVP messages in the face of network loss. Nodes setting the ACK_Desired flag SHOULD retransmit unacknowledged messages at a more rapid interval than the standard refresh period, until the message is acknowledged or until a "rapid" retry limit is reached. Rapid retransmission rate MUST be based on the exponential exponential back-off procedures defined in section 6 (yes, the RFC really does say "exponential exponential" 💀). The ACK_Desired flag will typically be set only in trigger messages. The ACK_Desired flag MAY be set in refresh messages. Issues related to multicast sessions are covered in a later section.
Checking for out-of-order messages 🔍
Nodes processing incoming MESSAGE_ID objects SHOULD check to see if a newly received message is out of order and can be ignored. Out-of-order messages SHOULD be ignored, i.e., silently dropped. Out-of-order messages can be identified by examining the values in the Epoch and Message_Identifier fields. To determine ordering, the received Epoch value must match the value previously received from the message sender. If the values differ then the receiver MUST NOT treat the message as out of order. When the Epoch values match and the Message_Identifier value is less than the largest value previously received from the sender, then the receiver SHOULD check the value previously received for the state associated with the message. This check should be performed for any message that installs or changes state (this includes at least Path, Resv, PathTear, ResvTear, PathErr and ResvErr). If no local state information can be associated with the message, the receiver MUST NOT treat the message as out of order. If local state can be associated with the message and the received Message_Identifier value is less than the most recently received value associated with the state, the message SHOULD be treated as being out of order.
Note that the 32-bit Message_Identifier value MAY wrap 🌀 To cover the wrap case, the following expression may be used to test if a newly received Message_Identifier value is less than a previously received value:
if ((int) old_id - (int) new_id > 0) {
new value is less than old value;
}Refresh vs. new state 🔄
MESSAGE_ID objects of messages that are not out of order SHOULD be used to help determine if the message represents new state or a state refresh. Note that state is only refreshed in Path and Resv messages. If the received Epoch value differs from the value previously received from the message sender, the message is a trigger message and the receiver MUST fully process the message. If a Path or Resv message contains the same Message_Identifier value that was used in the most recently received message for the same session and, for Path messages, SENDER_TEMPLATE, then the receiver SHOULD treat the message as a state refresh. If the Message_Identifier value is greater than the most recently received value, the receiver MUST fully processes the message. When fully processing a Path or Resv message, the receiver MUST store the received Message_Identifier value as part of the local Path or Resv state for future reference.
Acknowledging 🫶
Nodes receiving a non-out-of-order message containing a MESSAGE_ID object with the ACK_Desired flag set SHOULD respond with a MESSAGE_ID_ACK object. Note that MESSAGE_ID objects received in messages containing errors (i.e., messages that are not syntactically valid) MUST NOT be acknowledged. PathErr and ResvErr messages SHOULD be treated as implicit acknowledgments ✨
4.6. MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage 💌
The MESSAGE_ID_ACK object is used to acknowledge receipt of messages containing MESSAGE_ID objects that were sent with the ACK_Desired flag set. A MESSAGE_ID_ACK object MUST NOT be generated in response to a received MESSAGE_ID object when the ACK_Desired flag is not set.
The MESSAGE_ID_NACK object is used as part of the summary refresh extension. How MESSAGE_ID_NACK objects get generated and processed is covered in more detail in Section 5.4 🧚
MESSAGE_ID_ACK and MESSAGE_ID_NACK objects MAY be sent in any RSVP message that has an IP destination address matching the generator of the associated MESSAGE_ID object. This means the objects will not typically be included in the non-hop-by-hop Path, PathTear and ResvConf messages. When no appropriate message is available, one or more objects SHOULD be sent in an Ack message. Implementations SHOULD include MESSAGE_ID_ACK and MESSAGE_ID_NACK objects in standard RSVP messages when possible.
Timing the piggy-backing ⏱️
Implementations SHOULD limit the amount of time that an object is delayed in order to be piggy-backed or sent in an Ack message. Different limits may be used for MESSAGE_ID_ACK and MESSAGE_ID_NACK objects. MESSAGE_ID_ACK objects are used to detect link transmission losses. If an ACK object is delayed too long, the corresponding message will be retransmitted. To avoid such retransmission, ACK objects SHOULD be delayed a minimal amount of time. A delay time equal to the link transit time MAY be used. MESSAGE_ID_NACK objects may be delayed an independent and longer time, although additional delay increases the amount of time a desired reservation is not installed 🐢
4.7. Multicast Considerations 📡✨
okay so Path and PathTear messages can be sent to IP multicast destination addresses 💅 when the destination is multicast, one single message with one single MESSAGE_ID object might get received by multiple RSVP next hops at once 😭 and when the ACK_Desired flag is set in this situation, ack handling gets way more complicated 🫶
there are a few issues we need to sort out here 🌸 ACK implosion, how many acks to expect, and how to handle new receivers 💀
ACK implosion is when every receiver responds to the MESSAGE_ID object at roughly the same moment 🙈 that can lead to a potentially huge pile of MESSAGE_ID_ACK objects all getting delivered to the message generator at the same time. to fix this, the receiver MUST wait a random interval before acknowledging a MESSAGE_ID object received in a message destined to a multicast address 🎀 the random interval SHOULD be between zero (0) and a configured maximum time. the configured maximum SHOULD be set in proportion to the refresh and "rapid" retransmission interval, i.e., such that the maximum time before sending an acknowledgment does not result in retransmission 🦋 and just so we're clear, ACK implosion is being handled by spreading the acknowledgments out in time, not by ACK suppression ✨
a more fundamental question is how many acknowledgments the upstream node (aka the message generator) should expect 🧚 the answer is the same as the number of RSVP next hops 💖 in the router-to-router case, you can often get the number of next hops from routing 🍓 but when hosts are either the upstream node or the next hops, that number usually isn't readily available 😩 another situation where you typically won't know the number of RSVP next hops is when there are non-RSVP routers sitting between the message generator and the RSVP next hops 🙈
so when the number of next hops is unknown, the message generator SHOULD only expect a single response 🫠 what this means in practice is special retransmission handling until the message reaches at least one next hop, and after that, standard RSVP refreshes take over 💅 refresh messages will synchronize state with any next hops that didn't receive the original message 💜
4.7.1. Reference RSVP/Routing Interface 🗺️
when you're using the MESSAGE_ID extension with multicast sessions, it's preferable for RSVP to get the number of next hops from routing and to be notified whenever that number changes 🔥 the interface between routing and RSVP is purely an implementation issue, but since RSVP [RFC2205] describes a reference routing interface, here's a version of the RSVP/routing interface updated to provide number of next hop information 🌈 see [RFC2205] for the previously defined parameters and function descriptions 📖
- Route Query
Mcast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag )
-> [ IncInterface, ] OutInterface_list,
NHops_list- Route Change Notification
Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
[ IncInterface, ] OutInterface_list,
NHops_listNHops_list gives the number of multicast group members reachable via each OutInterface_list entry 🍒
4.8. Compatibility 🤝
all nodes sending messages with the Refresh-Reduction-Capable bit set will support the MESSAGE_ID Extension 💖 there aren't any backward compatibility issues with the MESSAGE_ID Class for nodes that don't set the Refresh-Reduction-Capable bit, so no drama there 🫶 the MESSAGE_ID Class has an assigned value of the form 0bbbbbbb 🔢 per RSVP [RFC2205], classes with values of this form must be rejected with an "Unknown Object Class" error by nodes that don't support the class 🚫 when the receiver of a MESSAGE_ID object doesn't support the class, a matching error message gets generated 😬 the generator of the MESSAGE_ID object sees the error and then MUST re-send the original message without the MESSAGE_ID object 🔁 in this case the message generator MAY still choose to retransmit messages at the "rapid" retransmission interval ⏱️ and lastly, since the MESSAGE_ID_ACK class can only be issued in response to the MESSAGE_ID object, there are no possible issues with this class or Ack messages ✨ a node MAY support the MESSAGE_ID Extension without supporting the other refresh overhead reduction extensions 🌸
5. Summary Refresh Extension 🌟
the summary refresh extension lets you refresh RSVP state without sending standard Path or Resv messages 🦋 the perks are that it cuts down on how much information has to be transmitted and processed to keep RSVP state synchronized 📉 the best part is that it keeps RSVP's ability to handle non-RSVP next hops and to adjust to routing changes, which is so important 👑 this extension can't be used with Path or Resv messages that contain any change from previously transmitted messages (aka trigger messages) 🚫
the summary refresh extension builds on the MESSAGE_ID extension we already defined 💜 only state that was previously advertised in Path and Resv messages containing MESSAGE_ID objects can be refreshed through the summary refresh extension 🎀
it uses the objects and the ACK message from the MESSAGE_ID extension, plus a brand new Srefresh message 🧚 the new message carries a list of Message_Identifier fields that correspond to the Path and Resv trigger messages that set up the state 🍓 those Message_Identifier fields are carried in one of three Srefresh related objects: the MESSAGE_ID LIST object, the MESSAGE_ID SRC_LIST object, and the MESSAGE_ID MCAST_LIST object 🫶
the MESSAGE_ID LIST object is used to refresh all Resv state and the Path state of unicast sessions 💅 it's made up of a list of Message_Identifier fields that were originally advertised in MESSAGE_ID objects. the other two objects are used to refresh Path state of multicast sessions 📡 a node receiving a summary refresh for multicast path state will sometimes need source and group information, and these two objects provide exactly that 🔥 they differ in what information they contain and how they're sent 😌 both carry Message_Identifier fields and corresponding source IP addresses 🌈 the MESSAGE_ID SRC_LIST is sent in messages addressed to the session's multicast IP address 🦋 the MESSAGE_ID MCAST_LIST object adds the group address and is sent in messages addressed to the RSVP next hop 💖 the MESSAGE_ID MCAST_LIST is normally used on point-to-point links 🔗
when an RSVP node gets an Srefresh message, it matches each listed Message_Identifier field with installed Path or Resv state 🔍 all the matching state is updated as if a normal RSVP refresh message had been received ✨ if matching state can't be found, the Srefresh message sender gets notified via a refresh NACK 🙅♀️
a refresh NACK is sent via the MESSAGE_ID_NACK object 💀 as described in the previous section, the rules for sending a MESSAGE_ID_NACK object are the same as the rules for sending a MESSAGE_ID_ACK object 🫶 this includes sending the MESSAGE_ID_NACK object piggy-backed in unrelated RSVP messages or in RSVP ACK messages 🎀
5.1. MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects 🍭
MESSAGE_ID LIST object 🌸
MESSAGE_ID_LIST Class = 25
Class = MESSAGE_ID_LIST Class, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields work like this 🧁
- Flags: 8 bits. No flags are currently defined. This field MUST be zero on transmission and ignored on receipt. 🙅♀️
- Epoch: 24 bits. The Epoch field from the MESSAGE_ID object corresponding to the trigger message that advertised the state being refreshed. 🕰️
- Message_Identifier: 32 bits. The Message_Identifier field from the MESSAGE_ID object corresponding to the trigger message that advertised the state being refreshed. One or more Message_Identifiers may be included. 🆔
IPv4/MESSAGE_ID SRC_LIST object 🌐
Class = MESSAGE_ID_LIST Class, C_Type = 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_ |
| Message_Identifier_Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_ |
| Message_Identifier_Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where a Source_Message_Identifier_Tuple looks like this 👯♀️
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv6/MESSAGE_ID SRC_LIST object 💜
Class = MESSAGE_ID_LIST Class, C_Type = 3
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6_Source_ |
|---|
| Message_Identifier_Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// : //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6_Source_ |
|---|
| Message_Identifier_Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Okay so here's the layout for the IPv6 source version, and it's giving very organized 🎀✨ Each IPv6 Source_Message_Identifier_Tuple is its own little bundle, and you just stack as many as you need in a row 🧚
Where a IPv6 Source_Message_Identifier_Tuple consists of:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Source_IP_Address |
|---|
| (16 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits 💅
No flags are currently defined. This field MUST be zero on transmission and ignored on receipt. Bestie, that MUST is non-negotiable 🙈
Epoch: 24 bits 🌸
The Epoch field from the MESSAGE_ID object corresponding to the trigger message that advertised the state being refreshed. So it's the Epoch that came with the trigger message, lowkey the receipt for the state you're refreshing 💜
Message_Identifier 🦋
The Message_Identifier field from the MESSAGE_ID object corresponding to the trigger message that advertised the Path state being refreshed. One or more Message_Identifiers may be included. Each Message_Identifier MUST be followed by the source IP address corresponding to the sender described in the Path state being refreshed. ✨
Source_IP_Address 🍓
The IP address corresponding to the sender of the Path state being refreshed.
IPv4/MESSAGE_ID MCAST_LIST object 🌈
Class = MESSAGE_ID_LIST Class, C_Type = 4
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast_ |
|---|
| Message_Identifier_ |
| Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// : //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast_ |
|---|
| Message_Identifier_ |
| Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where a Multicast_Message_Identifier_Tuple consists of:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_IP_Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6/MESSAGE_ID MCAST_LIST object 👑
Class = MESSAGE_ID_LIST Class, C_Type = 5
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Multicast_ |
|---|
| Message_Identifier_ |
| Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// : //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Multicast_ |
|---|
| Message_Identifier_ |
| Tuple |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where a IPv6 Multicast_Message_Identifier_Tuple consists of:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Source_IP_Address |
|---|
| (16 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Destination_IP_Address |
|---|
| (16 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits 💖
No flags are currently defined. This field MUST be zero on transmission and ignored on receipt. Same rule as before, no cap 🫶
Epoch: 24 bits ✨
The Epoch field from the MESSAGE_ID object corresponding to the trigger message that advertised the state being refreshed.
Message_Identifier: 32 bits 🔥
The Message_Identifier field from the MESSAGE_ID object corresponding to the trigger message that advertised the Path state being refreshed. One or more Message_Identifiers may be included. Each Message_Identifier MUST be followed by the source IP address corresponding to the sender of the Path state being refreshed, and the destination IP address of the session. Two addresses per ID, iykyk 🦋
Source_IP_Address 🌸
The IP address corresponding to the sender of the Path state being refreshed.
Destination_IP_Address 🧚
The destination IP address corresponding to the session of the Path state being refreshed. Periodt 💅
5.2. Srefresh Message Format ✨
okay bestie, Srefresh messages are the little carriers of our MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST objects 🎀 A MESSAGE_ID LIST and a MESSAGE_ID MCAST_LIST MAY ride in the same Srefresh message together 💖 But a MESSAGE_ID SRC_LIST can not be combined with the other objects in there, sorry girl 🙈 And one Srefresh message MAY refresh both Path and Resv state at once, which is so efficient it's giving 🔥
Srefresh messages carrying Message_Identifier fields for Path state are usually sent to the destination IP address in the matching SESSION objects 🦋 The destination IP address MAY be switched to the RSVP next hop, but only when that next hop is known to be RSVP capable AND either (a) the session is unicast or (b) the outgoing interface is a point-to-point link 💅 Srefresh messages carrying Message_Identifier fields for Resv state, though, MUST be sent to the Resv state's previous hop. No exceptions, periodt 👑
Srefresh messages sent to a multicast session's destination IP address MUST contain MESSAGE_ID SRC_LIST objects, and they MUST NOT include any MESSAGE_ID LIST or MESSAGE_ID MCAST_LIST objects 🌸 Srefresh messages sent to the RSVP next hop MAY contain either or both of MESSAGE_ID LIST and MESSAGE_ID MCAST_LIST, but they MUST NOT include any MESSAGE_ID SRC_LIST objects 🧚
The source IP address of an Srefresh message is the address of the node that made it ✨ That source IP address MUST match the address associated with the MESSAGE_ID objects when they were included in a standard RSVP message. The source address tied to a MESSAGE_ID object depends on the RSVP message type, which is lowkey a whole vibe 🌈 For messages with RSVP_HOP objects, like Path and Resv messages, the address lives in the RSVP_HOP object. For other messages, like ResvConf messages, it's the source address in the IP header 🫶
Srefresh messages addressed to a session's destination IP address MUST be sent with the Router Alert IP option in their IP headers 🔥 Srefresh messages addressed directly to RSVP neighbors SHOULD NOT be sent with the Router Alert IP option in their IP headers, so don't overdo it 💜
Each Srefresh message MUST occupy exactly one IP datagram 💅 If it's bigger than the MTU, IP fragments it and the recipient puts it back together 😭 Srefresh messages MAY be sent inside RSVP Bundle messages. Honestly that's not really expected, since a single Srefresh message can already carry a whole list of Message_Identifier fields inside one object 🍓 Implementations may choose to cap each Srefresh message at the MTU size of the outgoing link, e.g., 1500 bytes 🎀
The Srefresh message format is:
<Srefresh Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<srefresh list> | <source srefresh list>
<srefresh list> ::= <MESSAGE_ID LIST> | <MESSAGE_ID MCAST_LIST>
[ <srefresh list> ]
<source srefresh list> ::= <MESSAGE_ID SRC_LIST>
[ <source srefresh list> ]For Srefresh messages, the Msg Type field of the Common Header MUST be set to 15. That's the number, bestie, don't get creative 👑
5.3. Srefresh Message Usage 🦋
An Srefresh message may be generated to refresh Resv and Path state 💖 If an Srefresh message is refreshing some particular state, then the standard refresh message for that same state SHOULD be suppressed, so you're not sending duplicates 🙈 Using Srefresh message based refreshes does NOT change a state's refresh interval, btw ✨
When generating an Srefresh message, a node SHOULD refresh as much Path and Resv state as it possibly can, by packing in the information from as many MESSAGE_ID objects as possible 🔥 Only the information from MESSAGE_ID objects that meet the source and destination IP address restrictions from Sections 5.2 may go into the same Srefresh message 💅 Figuring out which Resv state can be refreshed by the same Srefresh message is pretty straightforward. Figuring out which Path state fits is a little more complex 🌸
Only state that was previously advertised in Path and Resv messages containing MESSAGE_ID objects can be refreshed through an Srefresh message 🧚 Srefresh message based refreshes must keep the same state synchronization properties as Path or Resv message based refreshes. So, specifically, using Srefresh messages MUST NOT lead to state timing out at the RSVP next hop 😭 The period for refreshing state with Srefresh messages MAY be shorter than the period used for Path or Resv message based refreshes, but it MUST NOT be longer 🌈
How you trigger Srefresh based refreshes is totally implementation specific 🫶 Some options are triggering an Srefresh message based on each state's refresh period, or, per interface, periodically generating Srefresh messages to refresh all state that hasn't been refreshed within its refresh interval. Other approaches are also possible 💜 A default Srefresh message generation interval of 30 seconds is suggested for nodes that don't dynamically calculate a generation interval 🍓
When generating an Srefresh message, there are two ways to figure out which Path state can be refreshed in a specific message 🎀 In both cases, the refresh interval and source IP address restrictions from above still have to be followed. The primary method is to only include sessions that share the same destination IP address in the same Srefresh message 👑
The secondary method is an optimization 💅 It MAY be used when the next hop is known to support RSVP AND either (a) the session is unicast or (b) the outgoing interface is a point-to-point link. It MUST NOT be used when the next hop is not known to support RSVP, or when the outgoing interface goes to a multi-access network and the session is to a multicast address 😭 Using this method MAY be configured administratively 🦋 When you use it, the destination address in the IP header of the Srefresh message is usually the next hop's address. When the method is administratively configured, the destination address should be the well known group address 224.0.0.14 ✨ When the outgoing interface is a point-to-point link, all Path state for sessions advertised out that interface SHOULD be included in the same Srefresh message 🔥 When the outgoing interface is not a point-to-point link, all unicast session Path state SHOULD be included in the same Srefresh message 🌸
Figuring out which Resv state can go into a single Srefresh message is based simply on the source and destination IP addresses 💖 Any state that was previously advertised in Resv messages with the same IP addresses as the Srefresh message MAY be included 🧚
After you've picked out the Path and Resv state for a particular Srefresh message, the message generator adds MESSAGE_ID information that matches each identified state's previously used object 🫶 For all Resv state, and for Path state of unicast sessions, the information goes into a MESSAGE_ID LIST object with a matching Epoch value. (Note that only one Epoch value will be in use during normal operation 🌈) If there's no matching object, a new MESSAGE_ID LIST object gets created 💅
Path state of multicast sessions can be added to the same message when the destination address of the Srefresh message is the RSVP next hop AND the outgoing interface is a point-to-point link 🦋 In that case, the information goes into a MESSAGE_ID MCAST_LIST object with a matching Epoch value. If no matching object exists, a new MESSAGE_ID MCAST_LIST object gets created 💜 When the destination address of the message is a multicast address, the identified information goes into a MESSAGE_ID SRC_LIST object with a matching Epoch value. If there's no matching object, a new MESSAGE_ID SRC_LIST object gets created 🍓 Once the Srefresh message is fully composed, the message generator sends it out the proper interface 👑
Upon receiving an Srefresh message, the node MUST try to find matching installed Path or Resv state 🔥 Matching is based on the source address in the IP header of the Srefresh message, the object type, and each Message_Identifier field 🌸 If matching state is found, then the receiving node MUST update that state's information as if a standard refresh message had arrived 💖 If matching state can't be identified, then an Srefresh NACK MUST be generated for the unmatched Message_Identifier field 🧚 Message_Identifier fields received in MESSAGE_ID LIST objects may correspond to any Resv state, or to Path state of unicast sessions. Message_Identifier fields received in MESSAGE_ID SRC_LIST or MESSAGE_ID MCAST_LIST objects correspond to Path state of multicast sessions 🫶
There's one more check, bestie 🙈 A NACK might need to be generated for unmatched Message_Identifier fields tied to Path state of multicast sessions, meaning the fields that came in MESSAGE_ID SRC_LIST or MESSAGE_ID MCAST_LIST objects. The receiving node has to check whether it would forward data packets from the source tied to the unmatched field. This check, commonly known as an RPF check, is done using the source and group information in the MESSAGE_ID SRC_LIST and MESSAGE_ID MCAST_LIST objects 🌈 In both objects, the IP address of the source sits right after its Message_Identifier field. In MESSAGE_ID MCAST_LIST objects, the group address sits right after the source IP address. In MESSAGE_ID SRC_LIST objects, the group address is the message's destination IP address 💅 The receiving node only generates an Srefresh NACK when it would forward packets to that group from the listed sender. So if the node would forward multicast data packets from a listed sender and there's a matching unmatched Message_Identifier field, then an appropriate Srefresh NACK MUST be generated 🦋 If the node would NOT forward packets to that group from a listed sender, the unmatched Message_Identifier field is silently ignored 💜
5.4. Srefresh NACK
Okay so Srefresh NACKs are basically the "um, I have no idea what this is 🙈" replies 💅. They get sent when a Message_Identifier field that showed up in a MESSAGE_ID LIST, SRC_LIST, or MCAST_LIST object doesn't match any installed state. This can happen for a bunch of reasons, like a route change, for example 🦋. An Srefresh NACK gets packed into a MESSAGE_ID_NACK object, and when you build one, the epoch and Message_Identifier fields of the MESSAGE_ID_NACK object MUST have the same value as was received, no edits allowed 💖. MESSAGE_ID_NACK objects get sent the way Section 4.6 describes.
When a MESSAGE_ID_NACK object shows up, it basically means the generator doesn't have any installed state that matches it 😭. So the receiver goes digging through its installed Path or Resv state, using the Epoch and Message_Identifier values in the object. If it finds a match, it MUST transmit that matching state via a standard Path or Resv message, periodt 🔥. If it can't find any installed state, then no action is required ✨.
5.5. Preserving RSVP Soft State
Let's talk about soft state 🌸. RSVP uses soft state to handle a huge pile of potential errors, and it does this by periodically sending a full picture of installed state in Resv and Path messages 🧚. Srefresh messages are used in place of those periodic standard Path and Resv refresh messages. This is great for scaling and covers common network stuff like packet loss or routing change, but it doesn't give you exactly the same error recovery. One example is internal corruption of state: standard messages could potentially fix that, but Srefresh messages can't ✨. This section recommends two methods that help better preserve RSVP's soft state error recovery mechanism, and both of them work with existing protocol messages 🎀.
The first mechanism uses a checksum or other algorithm to catch a change in internal state that nobody noticed. It does NOT protect against internal state corruption 🙅♀️. It only covers the case where a trigger message should have been sent but wasn't. When a node sends a Path or Resv trigger message, it should run a checksum or other algorithm, such as [MD5], over the internal state and store the result. Which algorithm you use is an administrative decision. Periodically, the node should rerun the algorithm and compare the new result with the stored one. If the values differ, then a corresponding standard Path or Resv refresh message should be sent, and the new value should be stored. The recomputation period should be set based on the computation resources of the node and the reliability requirements of the network 💜.
The second mechanism is simpler: just periodically send standard Path and Resv refresh messages 🌈. Because it uses standard refresh messages, it can recover from the same set of errors as standard RSVP, which is so iconic 👑. To gain the benefits of the summary refresh extension with this mechanism, the period for standard refresh messages must be longer than the interval at which Srefresh messages are generated. When a standard refresh message gets sent, a corresponding summary refresh SHOULD NOT be sent during that same refresh period 🫶. And if a node supports periodic standard refresh messages while Srefreshes are in use, the frequency of standard refresh messages relative to summary refreshes SHOULD be configurable by the network administrator ⭐.
5.6. Compatibility
Nodes that support the summary refresh extension advertise it using the Refresh-Reduction-Capable bit in the RSVP message header 💅. That's how nodes that support the extension find each other 🦋. When it isn't known whether a next hop supports the extension, standard Path and Resv message based refreshes MUST be used 🫠. Also note that when the routing next hop doesn't support RSVP, it won't always be possible to tell whether the RSVP next hop supports the summary refresh extension 🙈. So when the routing next hop isn't RSVP capable, the Srefresh message based refresh SHOULD NOT be used. A node MAY be administratively configured to use Srefresh messages in all cases, but only when all RSVP nodes in a network are known to support the summary refresh extension ✨. This is useful because in that mode, the extension properly adjusts to non-RSVP next hops and to changes in routing, which is giving main character energy 👑.
Per section 2, nodes that support the summary refresh extension must also take care to recognize when a next hop stops sending RSVP messages with the Refresh-Reduction-Capable bit set 🎀.
6. Exponential Back-Off Procedures
This section is based on [Pan] and gives procedures for exponential back-off when retransmitting messages that are waiting for an acknowledgment, see Section 4.5 💖. Implementations MUST use the described procedures or their equivalent 🔥.
6.1. Outline of Operation
Here's one possible way to do exponential back-off retransmission of an unacknowledged RSVP message 🧚. When a node sends one of these messages, it inserts a MESSAGE_ID object with the ACK_Desired flag set. The sending node keeps retransmitting the message until a message acknowledgment comes back or the message has been sent a maximum number of times 😭. When a receiving node gets the message, it acknowledges the arrival by sending back a message acknowledgment (that is, a corresponding MESSAGE_ID_ACK object). Once the sending node receives that acknowledgment, retransmission of the message stops 🌸. The gap between retransmissions is controlled by a rapid retransmission timer. That timer starts at a small interval and grows exponentially until it hits a threshold 🦋.
6.2. Time Parameters
The procedures here use the following time parameters, and all of them are per interface 🎀.
Rapid retransmission interval Rf: Rf is the initial retransmission interval for unacknowledged messages. After the message is sent for the first time, the sending node schedules a retransmission after Rf seconds. The value of Rf could be as small as the round trip time (RTT) between a sending and a receiving node, if that's known ⏱️.
Rapid retry limit Rl: Rl is the maximum number of times a message will be transmitted without being acknowledged 🛑.
Increment value Delta: Delta controls how fast the sender increases the retransmission interval. The ratio of two successive retransmission intervals is (1 + Delta) 📈.
Suggested defaults are an initial retransmission timeout (Rf) of 500ms, a power of 2 exponential back-off (Delta = 1), and a retry limit (Rl) of 3 💜.
6.3. Retransmission Algorithm
After a sending node transmits a message containing a MESSAGE_ID object with the ACK_Desired flag set, it should immediately schedule a retransmission after Rf seconds 🌈. If a corresponding MESSAGE_ID_ACK object arrives earlier than Rf seconds, then retransmission SHOULD be canceled 🙌. Otherwise, the node retransmits the message after (1 + Delta)*Rf seconds. This staged retransmission keeps going until either an appropriate MESSAGE_ID_ACK object is received or the rapid retry limit, Rl, has been reached 💅.
A sending node can use the following algorithm when it transmits a message containing a MESSAGE_ID object with the ACK_Desired flag set:
Prior to initial transmission initialize: Rk = Rf and Rn = 0
while (Rn++ < Rl) {
transmit the message;
wake up after Rk seconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged or no reply from receiver for too long: */ do any
needed clean up; exit;Asynchronously, when a sending node receives a corresponding MESSAGE_ID_ACK object, it changes the retry count, Rn, to Rl 🫶.
Note that the transmitting node does not advertise its use of these exponential back-off procedures via the TIME_VALUE object 🤫.
6.4. Performance Considerations
Exponential back-off retransmission is a brand-new and seriously significant addition to RSVP 🔥. It'll be important to review related operations and performance experience before this document advances to Draft Standard 📚. Reviewing experience with multicast will be especially important, along with any ACK implosion problems that actually get encountered 😭.
7. Acknowledgments
This document represents ideas and comments from the MPLS-TE design team and participants in the RSVP Working Group's interim meeting 🫶. Thanks to Bob Braden, Lixia Zhang, Fred Baker, Adrian Farrel, Roch Guerin, Kireeti Kompella, David Mankins, Henning Schulzrinne, Andreas Terzis, Lan Wang and Masanobu Yuhara for their specific feedback on the various versions of the document 💖.
Portions of this work are based on work done by Masanobu Yuhara and Mayumi Tomikawa [Yuhara] 🌸.
8. Security Considerations
No new security issues are raised in this document 🔒. For a general discussion of RSVP security issues, see [RFC2205] 💅.
9. References
[Pan] Pan, P., Schulzrinne, H., "Staged Refresh Timers for RSVP," Global Internet'97, Phoenix, AZ, November 1997. http://www.cs.columbia.edu/~pingpan/papers/timergi.pdf
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin , "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997.
[Yuhara] Yuhara, M., and M Tomikawa, "RSVP Extensions for ID-based Refreshes", Work in Progress.
10. Authors' Addresses
Lou Berger
LabN Consulting, LLC
Phone: +1 301 468 9228
EMail: lberger@labn.net
Der-Hwa Gan
Juniper Networks, Inc.
1194 N. Mathilda Avenue,
Sunnyvale, CA 94089
Voice: +1 408 745 2074
Email: dhg@juniper.net
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Ping Pan
Juniper Networks, Inc.
1194 N. Mathilda Avenue,
Sunnyvale, CA 94089
Voice: +1 408 745 3704
Email: pingpan@juniper.net
Franco Tommasi
University of Lecce, Fac. Ingegneria
Via Monteroni 73100 Lecce, ITALY
EMail: franco.tommasi@unile.it
Simone Molendini
University of Lecce, Fac. Ingegneria
Via Monteroni 73100 Lecce, ITALY
EMail: molendini@ultra5.unile.it11. Full Copyright Statement ✨
Copyright (C) The Internet Society (2001). All Rights Reserved. 🎀
Okay so the vibe here is: you can totally share this doc with your friends 💌 and copy it, and you can even write your own stuff that comments on it, explains it, or helps people actually build it 💖 as long as you keep this copyright notice and this paragraph on every copy and every derivative work 🫶. BUT the document itself can't be changed in any way, like you can't take off the copyright notice or the references to the Internet Society or other Internet organizations 🙅♀️. The exceptions are: you need to change it to develop Internet standards (and then the procedures for copyrights in the Internet Standards process must be followed 📜), or you need to translate it into a language that isn't English 🌍.
The permissions here are perpetual 🦋, which means they will never be revoked by the Internet Society or its successors or assigns. Forever and ever, no cap 👑.
This document and the information in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 💜 Shoutout to them for keeping the lights on for the RFC Editor, periodt 🙌✨
📦 where this page comes from
- ietf: rfc2961 2001-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms