RSVP Refresh Reduction RSVP Refresh Reduction

4.4.12 RSVP Refresh Reduction RSVP Refresh Reduction

As mentioned earlier, one of the consequences of RSVP being a soft-state protocol is that messages must be periodically exchanged to keep the state active and the reservations in place. One concern with this is that considerable bandwidth and processing capabilities may be used up in simply keeping state active, reducing the capability to establish new state promptly and even, perhaps, affecting the ability to forward data. Refresh reduction is based not on removing the require- ment to refresh RSVP state, nor on changing the interval between refreshes. Instead, the focus is on reducing the amount of processing required by both the sender and the receiver of a state refresh message and minimizing the number of bytes that must be sent between the nodes.

RFC 2961 describes a small set of extensions to RSVP to facilitate refresh reduc- tion. These extensions arise from heated debates within the IETF, both about the need for any changes and about the best way to address the issue. In the end, three procedures were standardized: the first and second are independent (although they may be used together), but the third builds on the second.

All three extensions are treated as a single functional block and are used between a pair of RSVP routers only if both support them. This support is signaled in a new flag setting in the flags field in the Session Object. 0×01 is used to indicate support of all the refresh reduction extensions. Indicating support of the extensions does not mean that an RSVP router needs to use all or any of them in

4.4

112

112 CHAPTER 4CHAPTER 4 IP Service Management

messages that it sends, but it must be able to process all of them if it receives them.

The first extension allows multiple RSVP messages to be packaged together as a bundle within a single IP message. A new RSVP message type, 12, indicates a Bundle message. A Bundle message is built of an RSVP message header followed by one or more RSVP messages. The number of bundled RSVP messages is not indicated, but the length of the Bundle message itself indicates whether there is more data, and hence another message, when processing of one bundled message has completed. The main advantages of message bundling are a small reduction in the number of bytes transmitted between RSVP routers, and a reduction in processing, especially through the IP stack—a clutch of refresh messages may be collected together into a single bundle and sent at the same time. The format of a Bundle message is shown in Figure 4.35.

When an RSVP node receives a Path or a Resv message it needs to distinguish three cases. The message may be for a new flow, it may be a change to an existing flow (e.g., modifying the bandwidth required for a flow), or it may be a refresh. New flows are easily distinguished because there is no matching stored Path or Resv state. Modification requests can be distinguished from state refresh messages because they contain changes in one or more of the parameters when compared with the previous message received. This means that each time a refresh message is received, an RSVP router must compare it fully with the previ- ous message; since the order of objects in a message may vary without affecting the meaning, the receiver cannot simply compare the whole message as a block of memory, but must compare the objects one by one. This introduces a consider- able overhead in processing, which is addressed in the refresh reduction exten- sions by placing a message identifier on each message. The Message Identifier Object, shown in Figure 4.36, includes a monotonic increasing message identifier number and an epoch that is used to disambiguate different instances of an adja- cent node so that there is no confusion about the reuse of message ID values if a

IP packet IP packet IP header RSVP header _header RSVP RSVP message RSVP message Bundle message Bundle message RSVP objects _header RSVP RSVP message RSVP message RSVP objects FIGURE 4.35 FIGURE 4.35

The Bundle message encapsulates one or more RSVP messages in a single IP message using an additional RSVP message header.

node is restarted. The epoch can be a random number or a function of real time.

If the message identifier on a message is identical to that previously received, no further checking is required: the message is a refresh. If the message identifier is lower than that previously received, the message is an old message that has been delayed in the network and can be ignored. If the message number is greater than that previously received, the message must be examined more closely and may be a refresh or a modification. The Message Identifier Object may be carried on every RSVP message. It serves both the purpose of ensuring acknowledged delivery of messages and of flagging Path and Resv messages as refreshes, as shown in Figures 4.37 and 4.38.

Message identifiers uniquely identify individual messages and make it possible to formally acknowledge the receipt of a message. The Message Identifier Object contains a flag (0×01) that requests the receiver to acknowledge receipt. This acknowledgment is carried in a Message Ack Object, as shown in Figure 4.39. The object contains the message identifier of the acknowledged message and may be carried one at a time or as a series in any message that flows in the opposite direc- tion, as indicated for Path and Resv messages in Figures 4.37 and 4.38.

0 0 1

Length 12= _{(message ID)}C-Num = 23 C-Type 1=

Epoch Flags 234567890123 1 2 3 4 5 6 7 8 9 0 1 23456789 0 1 Message ID FIGURE 4.36 FIGURE 4.36

RSVP Message Identifier Object.

< Path Message > ::= < Common Header > [< INTEGRITY >] [[ < MESSAGE_ID_ACK > < MESSAGE_ID_NACK > ]...] [ < MESSAGE_ID > ] < SESSION > < RSVP_HOP > < TIME_VALUES > [ < POLICY_DATA > ] < sender descriptor > FIGURE 4.37 FIGURE 4.37

Formal definition of the RSVP Path message for refresh reduction showing the optional inclusion of Message ID and Message ID Acknowledgment Objects.

4.4

114

114 CHAPTER 4CHAPTER 4 IP Service Management

If there is no message being sent in the opposite direction, the receiver must still acknowledge the received message identifier as soon as possible. It can do this by sending an Acknowledgment message that simply carries the acknowl- edged message identifiers, as shown in Figure 4.40.

The sender of a message carrying a message identifier that has requested acknowledgment retransmits the message periodically until it is acknowledged or

< Resv Message > ::= < Common Header >

[ < POLICY_DATA > ] < STYLE > < flow descriptor list > [< INTEGRITY >] [[ < MESSAGE_ID_ACK > < MESSAGE_ID_NACK > ]. . . ] [ < MESSAGE_ID > ] < SESSION > < RSVP_HOP > < TIME_VALUES > [ < RESV_CONFIRM > ] [ < SCOPE > ] FIGURE 4.38 FIGURE 4.38

Formal definition of the RSVP Resv message for refresh reduction showing the optional inclusion of Message ID and Message ID Acknowledgment Objects.

0 0 1

Length = 12 _{(Message Ack)}C-Num = 24 C-Type = 1_(Ack)

Epoch Flags = 0 234567890123 1 2 3 4 5 6 7 8 9 0 1 23456789 0 1 Message ID FIGURE 4.39 FIGURE 4.39

The RSVP Message Ack Object.

< Ack Message > ::= < Common Header > [< INTEGRITY >]

[[ < MESSAGE_ID_ACK > < MESSAGE_ID_NACK > ]. . . ] < MESSAGE_ID_ACK > < MESSAGE_ID_NACK >

FIGURE 4.40 FIGURE 4.40

until it decides that there is a problem with the link or with the receiving node. Retransmission is relatively frequent (roughly every half a second), so it is impor- tant not to swamp the system with retransmissions. RFC 2961 suggests that the sender should apply an exponential back-off, doubling the time between retrans- missions at each attempt. It also suggests that a message should be transmitted a maximum of three times even if it is not acknowledged (i.e., one transmission and two retransmissions).

The third extension for refresh reduction recognizes that once a message identifier has been assigned to a state message, it is not necessary to retransmit the whole message—only the message identifier needs to be sent to keep the state alive. The Summary Refresh (Srefresh) message shown in Figure 4.41 is used to send a list of message identifiers in this fashion. The Srefresh message itself does not carry a message identifier in its own right, but each of the identifiers that it does carry can be accepted or rejected, although usually no specific acknowledge- ment is requested, so only rejections are sent. A rejection uses the Message Nack object, which has C-Type of 2 but is otherwise identical to a Message Ack object. The Message Nack allows some message identifiers out of the set on the Srefresh to be rejected without rejecting all of them. The rejection is necessary if the receiver does not match the message identifier against a stored value—it cannot use the Srefresh to establish new state since the message does not carry the full Path or Resv information.

Message Nack Objects can be carried within the other messages such as the Path and Resv messages shown in Figures 4.37 and 4.38. Alternatively, the Acknowledgment message shown in Figure 4.40 may be used. If the Srefresh is received and accepted, a single Message Ack carrying the message ID of the Srefresh message acknowledges all of the message IDs carried in the Srefresh list. If one or more message IDs in the Srefresh list is rejected, the message itself must still be acknowledged and Message Nacks must be used to reject each unaccept- able message ID. There is no need to acknowledge individual message IDs from within the Srefresh list.

< 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 > ]

FIGURE 4.41 FIGURE 4.41

Formal definition of the RSVP Srefresh message. 4.4

116

116 CHAPTER 4CHAPTER 4 IP Service Management

The basic Srefresh contains a Message ID List Object, as shown in Figure 4.42. The object lists a series of message IDs for state that is being refreshed, but recognizes that the epoch value does not need to be repeated for each message ID.

The Srefresh message is complicated considerably by multicast issues. It is possible that a downstream node will receive a refresh of Path state from multiple upstream interfaces and care must be taken to send the acknowledgments to the right place and only as frequently as is actually required. The Source Message List Object and Message ID Multicast List Object shown in Figure 4.43 allow a single Srefresh message to refresh state with reference to source and destination addresses—the addresses shown may be IPv4 or IPv6 depending on the object’s C-Type (2 or 3 for Source Message List, 4 or 5 for Message ID Multicast List). Note that this format is considerably suboptimal since the addresses must be repro- duced for each message ID.

All three refresh reduction procedures can be combined with Acknowledge- ment and Srefresh messages being bundled along with other messages.