2.7.14 Resource Reservation Setup Protocol (rsvp)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 18-Oct-99


Lixia Zhang <lixia@cs.ucla.edu>
Bob Braden <braden@isi.edu>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:rsvp@isi.edu
To Subscribe: rsvp-request@isi.edu
Archive: ftp://ftp.isi.edu/rsvp/rsvp.mail

Description of Working Group:

RSVP is a resource reservation setup protocol for the Internet. Its major features include: (1) the use of ``soft state'' in the routers, (2) receiver-controlled reservation requests, (3) flexible control over sharing of reservations and forwarding of subflows, and (4) the use of IP multicast for data distribution.

The primary purpose of this working group is to evolve the RSVP specification and to introduce it into the Internet standards track. The working group will also serve as a meeting place and forum for those developing and experimenting with RSVP implementations.

The task of the RSVP Working Group, creating a robust specification for real-world implementations of RSVP, will require liaison with two other efforts: (1) continuing research and development work on RSVP in the DARTnet research community, and (2) the parallel IETF working group that is considering the service model for integrated service. Although RSVP is largely independent of the service model, its design does depend upon the overall integrated service architecture and the requirements of real-time applications. As an additional task, RSVP will maintain coordination with the IPng-related working groups.

Goals and Milestones:



Hold BOF on RSVP at Houston IETF meeting.



Prepare new draft of RSVP Protocol in time for Seattle IETF meeting, following e-mail review and possible MBONE meetings.



Submit the RSVP specification to the IESG for consideration as a Prototype RFC. Begin revision based on experience.



Release revised specification.



Submit RSVP specification to IESG for Proposed Standard status.


Request For Comments:







Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification



RSVP Management Information Base using SMIv2



RSVP Extensions for IPSEC Data Flows



Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment



Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules

Current Meeting Report

RSVP Working Group Meeting Minutes
Tuesday, November 11, 1999

1. Working group status

Bob Braden reported on the status of the working group. The plan is (still) to finish the work on RSVP refresh overhead reduction extensions before terminating the working group. Discussions may continue on the mailing list (rsvp@isi.edu) afterwards, and a new working group may be constituted as the need rises.

Braden stated his belief that the refresh reduction extensions represent a fundamental change to the way that RSVP works, and therefore they need to be designed with some care.

The primary issue at the meeting was to move the refresh overhead reduction mechanisms towards Proposed Standard. Secondarily, the meeting also considered the issue of RSVP proxies.

2. RSVP Receiver Proxies

Silvano Gai reported on draft-sgai-rsvp-proxy-00.txt "RSVP Receiver Proxy". Application developers need a mechanism to signal the network with user identity, application identification, traffic classification information, etc., and get back policy information, perhaps including a diffserv code point (DSCP). One way to meet this need would be to install a "RSVP proxy" in the first-hop router. This proxy could automatically generate RESV messages for certain sessions (selection based on policy) in response to PATH messages. A few missing pieces needed to make RSVP proxy work are being standardized by other working groups: the Null Service by the ISSLL WG, and flexible policy mechanisms by the RAP WG. A related draft ``COPS Extensions for RSVP Receiver Proxy Support'' draft-nitsan-cops-rsvp-proxy-00.txt was presented to the RAP WG.

Discussion centered on whether RSVP proxy requires any standardization effort from the RSVP WG. RSVP Proxies do not modify the RSVP protocol; they only change the way the protocol is used. After some discussion the working group reached consensus to move draft-sgai-rsvp-proxy-00.txt to an RSVP Working Group Informational RFC. Further discussion of this proposal should take place both on the RSVP mailing list and in the RAP working group. A Last Call for it will be issued in both working groups.

3. Presentations and discussions on RSVP refresh overhead reduction

The "RSVP refresh overhead reduction" extensions have two functions:
(1) reliable delivery of RSVP messages and
(2) reducing the overhead due to RSVP refresh messages. Reliable delivery will prevent delays in establishing, changing, or tearing down RSVP state caused by loss of an RSVP control message. Refresh overhead reduction will reduce both network bandwidth and message processing. The two functions are included in one extension package because the refresh reduction mechanisms require reliable delivery.

At Oslo IETF the WG reached a consensus to move these extensions forward. Since then, a number of details of the proposed mechanisms were changed and a few new proposals were made. The goal of this meeting was to reach closure on which mechanisms should be move to Proposed Standard status.

3.1 Berger Draft

Lou Berger reported the changes in draft-ietf-rsvp-refresh-reduct-01.txt "RSVP Refresh Reduction Extensions". This draft:

(1) broke Message_ID class to 3 classes for message ID, message ID ACK, and message ID list;
(2) added discussion of bundling time delays, including the limits suggested by Tommasi;
(3) added IPv6 CTypes; and
(4) clarified the transmission mechanism of Srefresh messages for multicast RSVP sessions.

Berger presented two options for (4):

(a) Send a separate Srefresh message to the session address for each multicast session.
(b) Multicast Srefresh messages for multicast path state to an all-RSVP-nodes multicast address.

Option (b) will always result in lower bandwidth for RSVP messages, since it allows all multicast destinations to be included in the same Srefresh message. However, processing overhead is a more complex tradeoff between options (a) and (b). Option (b) will require additional processing to do an RPF check for each received message ID, but option (b) also requires that fewer SRefresh messages be processed.

The consensus was to include only (the simpler) one of these options in the spec. There was a weak consensus (silence) for (a).

3.2 Tommasi Draft: Compressed List Descriptors (CLD)

Franco Tommasi presented the difference between approaches described in his draft, draft-tommasi-rsvp-enhan-scalab-01.txt "Some extensions to enhance the scalability of the RSVP protocol", and the Berger draft. The differences center on the way that summary refresh IDs are represented. The Tommasi draft represents Summary refresh IDs using Compressed List Descriptors (CLDs), which allow IDs that are clustered to be represented in a very compact encoding. This encoding can reduce the number of bytes in a summary refresh message.

Another difference is in the reliability mechanisms for summary refresh messages. The Tommasi draft allows both the normal "weak" refresh and also a "strong refresh"; the latter uses sequence numbers to ensure that all parts of a summary refresh are received.

Finally, the Tommasi draft allows messages to be sent with an "urgent" bit, which is analogous to TCP's Push bit; it will terminate the bundling wait and force immediate forwarding of a Bundle message containing the urgent data.

The discussion following Tommasi's presentation concluded that the CLDs may be a good idea. In order benefit from CLDs, the refresh IDs need to be assigned in sequential order (or any method producing good clustering of message IDs). There was a concern with refresh ID wraparound if sequential numbering were used. The urgent bit scheme, however, raised a big concern. If all the messages are considered urgent, policing for urgent bits would be needed, leading to further complication. One suggestion, which was generally accepted, would consider the urgent bit as a hint which could be ignored by a node.

The WG consensus is to consider the CLD and (optional) urgent bit schemes when finalizing the Berger draft for standardization.

3.3 Hierarchical Summary Refresh

George Swallow presented draft-swallow-rsvp-hierarchical-refresh-00.txt "RSVP Hierarchical Summary Refresh", which further extends the proposed summary refresh mechanism to allow a hierarchy of summary refresh messages. That is, an entire summary refresh (Srefresh) message can itself be refreshed using a single unique message ID in another Srefresh message, providing a further reduction in the number of refresh messages. If a node receives an unknown message ID, that node will return a NACK to trigger the retransmission of all the state (be it an Srefresh message or raw RSVP state) represented by the unknown message ID.

It was suggested that the potential savings from this second-level summary might seldom be reached due to the rate of change of reservations. Swallow postulated an MPLS environment where RSVP state seldom changes, and typically all RSVP state changes if any does. In such an environment, message processing costs could be substantially reduced with his proposal. However RSVP as a general signaling protocol must consider usage in general cases. The WG consensus was that the potential overhead reduction provided by this scheme does not warrant the addition of its complexity to the RSVP spec at this time.

3.4 Using Session State Checksum as the State ID

A major concern with the scheme described in the current Berger draft is that, once the RSVP state between two routers gets out of sync, the error will never be noticed or corrected. To overcome this problem Lixia Zhang described a scheme suggested by Will Leland: instead of using a sequential number to represent the state of each RSVP session, a router can use a computed checksum based on the current session state variables. This checksum computation can be carried out by a background process at each router that periodically goes through all the RSVP sessions to update the checksum. When a router receives a session ID that disagrees with the locally computed session ID, it should send a NACK to trigger the raw RSVP state being retransmitted.

This scheme provides strong checking on RSVP state consistency between routers. One major objection to this approach is that different vendors have different RSVP implementations. Being able to compare the checksum between two routers means standardizing the internal representations of RSVP session state, a step which was considered too costly. A compromise was suggested to ease this concern: let each router keep a checksum of its state as a local variable that is recomputed periodically, and whenever the checksum changes, the router triggers a retransmission of the full RSVP state.

4. Discussion of "Refresh Reduction" Extensions

There was consensus to move the refresh reduction draft towards Proposed Standard as soon as possible. Specific changes recommended were:

There was also general agreement that the UCLA proposal "RSVP Refresh Overhead Reduction by State Compression" (draft-wang-rsvp-state-compression-02.txt) should be published as an Experimental RFC.


None received.