Network Working Group L. Berger Request for Comments: 2961 LabN Consulting, LLC Category: Standards Track D. Gan Juniper Networks, Inc. G. Swallow Cisco Systems, Inc. P. Pan Juniper Networks, Inc. F. Tommasi S. Molendini University of Lecce April 2001 RSVP Refresh Overhead Reduction Extensions Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. The same extensions also support reliable RSVP message delivery on a per hop basis. These extension present no backwards compatibility issues. Berger, et al. Standards Track [Page 1] RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001 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...................................34 1. Introduction and Background Standard RSVP [RFC2205] maintains state via the generation of RSVP refresh messages. Refresh messages are used to both synchronize state between RSVP neighbors and to recover from lost RSVP messages. The use of Refresh messages to cover many possible failures has resulted in a number of operational problems. One problem relates to scaling, another relates to the reliability and latency of RSVP Signaling. Berger, et al. Standards Track [Page 2] RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001 The scaling problems are linked to the resource requirements (in terms of processing and memory) of running RSVP. The resource requirements increase proportionally with the number of sessions. Each session requires the generation, transmission, reception and processing of RSVP Path and Resv messages per refresh period. Supporting a large number of sessions, and the corresponding volume of refresh messages, presents a scaling problem. The reliability and latency problem occurs when a non-refresh RSVP message is lost in transmission. Standard RSVP [RFC2205] recovers from a lost message via RSVP refresh messages. In the face of transmission loss of RSVP messages, the end-to-end latency of RSVP signaling is tied to the refresh interval of the node(s) experiencing the loss. When end-to-end signaling is limited by the refresh interval, the delay incurred in the establishment or the change of a reservation may be beyond the range of what is acceptable for some applications. One way to address the refresh volume problem is to increase the refresh period, "R" as defined in Section 3.7 of [RFC2205]. Increasing the value of R provides linear improvement on transmission overhead, but at the cost of increasing the time it takes to synchronize state. One way to address the reliability and latency of RSVP Signaling is to decrease the refresh period R. Decreasing the value of R increases the probability that state will be installed in the face of message loss, but at the cost of increasing refresh message rate and associated processing requirements. An additional issue is the time to deallocate resources after a tear message is lost. RSVP does not retransmit ResvTear or PathTear messages. If the sole tear message transmitted is lost, then resources will only be deallocated once the "cleanup timer" interval has passed. This may result in resources being allocated for an unnecessary period of time. Note that even when the refresh period is adjusted, the "cleanup timer" must still expire since tear messages are not retransmitted. The extensions defined in this document address both the refresh volume and the reliability issues with mechanisms other than adjusting refresh rate. The extensions are collectively referred to as 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 to reduce refresh message processing by allowing the receiver to more readily identify an unchanged message. A MESSAGE_ACK object is defined which can be used to detect message loss and support reliable RSVP message Berger, et al. Standards Track [Page 3] RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001 delivery on a per hop basis. A summary refresh message is defined to enable refreshing state without the transmission of whole refresh messages, while maintaining RSVP's ability to indicate when state is lost and to adjust to changes in routing. 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 categorizes RSVP messages into two types: trigger and refresh messages. Trigger messages are those RSVP messages that advertise state or any other information not previously transmitted. Trigger messages include 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 include those messages that include changes in non-RSVP processed objects, such as changes in the Policy or ADSPEC objects. Refresh messages represent previously advertised state and contain exactly the same objects and same information as a previously transmitted message, and are sent over the same path. Only Path and Resv messages can be refresh messages. Refresh messages are identical to the corresponding previously transmitted message, with some possible exceptions. Specifically, the checksum field, the flags field and the INTEGRITY object may differ in refresh messages. 2. Refresh-Reduction-Capable Bit To indicate support for the refresh overhead reduction extensions, an additional capability bit is 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 4 bits 0x01: Refresh (overhead) reduction capable Berger, et al. Standards Track [Page 4] RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001 When set, indicates that this node is willing and capable of receiving all the messages and objects described in this document. This includes the Bundle message described in Section 3, the MESSAGE_ID objects and Ack messages described in Section 4, and the MESSAGE_ID LIST objects and Srefresh message described in Section 5. This bit is meaningful only between RSVP neighbors. Nodes supporting the refresh overhead reduction extensions must also take care to recognize when a next hop stops sending RSVP messages with the Refresh-Reduction-Capable bit set. To cover this case, nodes supporting the refresh overhead reduction 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. Note, 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 An RSVP Bundle message consists of a bundle header followed by a body consisting of a variable number of standard RSVP messages. A Bundle message is used to aggregate multiple RSVP messages within a single PDU. The term "bundling" is used to avoid confusion with RSVP reservation aggregation. The following subsections define the formats of the bundle header and the rules for including standard RSVP messages as part of the message. 3.1. Bundle Header 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 format of the bundle header is identical to the format of the RSVP common header [RFC2205]. The fields in the header are as follows: Vers: 4 bits Protocol version number. This is version 1. Berger, et al. Standards Track [Page 5] RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001 Flags: 4 bits 0x01: Refresh (overhead) reduction capable See Section 2. 0x02-0x08: Reserved Msg type: 8 bits 12 = Bundle RSVP checksum: 16 bits The one's complement of the one's complement sum of the entire message, with the checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted. Because individual sub- messages may carry their own checksum as well as the INTEGRITY object for authentication, this field MAY be set to zero. Note that when the checksum is not computed, the header of the bundle message will not be covered by any checksum. If the checksum is computed, individual sub-messages MAY set their own checksum to zero. Send_TTL: 8 bits The IP TTL value with which the message was sent. This is used by RSVP to detect a non-RSVP hop by comparing the Send_TTL with the IP TTL in a received message. RSVP length: 16 bits The total length of this RSVP Bundle message in bytes, including the bundle header and the sub-messages that follow. 3.2. Message Formats An RSVP Bundle message must contain at least one sub-message. A sub-message MAY be any message type except for another Bundle message. Berger, et al. Standards Track [Page 6] RFC 2961 RSVP Refresh Overhead Reduction Extensions April 2001 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 Support for RSVP Bundle messages is optional. While message bundling helps in scaling RSVP, by reducing processing overhead and bandwidth consumption, a node is not required to transmit every standard RSVP message in a Bundle message. A node MUST always be ready to receive standard RSVP messages. RSVP Bundle messages can only be sent to RSVP neighbors that support bundling. Methods for discovering such information inclu