2.7.12 Resource Reservation Setup Protocol (rsvp)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 11-Feb-99


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

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

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.

Nov 94


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

Mar 95


Release revised specification.

Jul 95


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 Minutes
44th IETF in Minneapolis, MN
Jeff Kann

Thursday March 18, 1300-1500
RSVP Working Group Minutes

A. Last-Call Status Report -- Chairs

RAP Documents Related to RSVP
- Shai Herzog believes that the issues raised about the RAP RSVP extensions document have all been resolved. Some of them concerned structuring the document and had no impact on the content of this draft. He posted a new version with some style changes.
- The meeting consensus was to allow one additional week after IETF to ensure that all comments have been addressed, before closing this WG last call on the RSVP-related RAP documents.

RSVP Integrity
- Following the agreement at the previous meeting, the RSVP integrity spec was augmented with an appendix supplied by Peter Ford, concerning key management issues for edge networks. The meeting consensus was to let this document begin WG last call after IETF.

RSVP Diagnostics
- Although the WG had agreed to proceed with WG last call on the Diagnostics spec after the previous (Orlando) meeting, an implementation of the spec later revealed some problems. The spec was fixed, and the consensus of the meeting was to let this document begin WG last call after IETF.

RSVP Tunnels
- Lixia Zhang said that the latest draft resolves the issues raised at the last meeting by John Wroclawski, and it also contains additional clarification.
- Braden noted that the mechanism for RSVP tunneling is similar to that of Fred Baker's aggregation draft and to the MPLS tunnel draft (both discussed later in the meeting). However, although it might eventually be possible to re-modularize these documents to build on a common mechanism, we are not yet ready to do that. In the meantime, the tunnel spec, which seems to solve a problem for some (e.g., mobile QoS), should go forward.
- The meeting consensus was to let this document begin WG last call right after IETF.

B. RSVP for Qualitative Applications -- Yoram Bernet

The goal is to provide QoS for applications that cannot quantify their exact needs. Flowspecs do not carry user-generated parameters.

DCLASS Object -- Yoram Bernet
- A new DCLASS object is sent in RESV messages inside diffserv regions. Boundary routers will perform admissional control and assigns the DCLASS object to the message. Two upper bits of the object class type is chosen to make it a unknown object type for backwards compatibility (forwarded if unrecognized). The question was raised on whether the DCLASS should be in the Intserv/Diffserv architecture draft.
- Bernet described a DCLASS enhancement table, which maps a router's interfaces to a given DSCP and rate. Although this is a simple approach, it provides some mechanism to do admission control for intserv/ diffserv boundaries.

DCLASS is analogous to TCLASS object in the SBM.
- There were questions about how well we can do admissional control at the boundaries. Lixia said that DCLASS object format standardization is a valid topic in the the RSVP working group, but issues of traffic control are outside our charter.

What about multicast? This needs further thought.

C. RSVP Aggregation -- Fred Baker

This draft describes a specific mechanism to achieve RSVP aggregation, based upon earlier work by Roch Guerin. The present draft is solving a somewhat different problem than the tunnels spec, since the latter has pre-configured egress points while the present spec allows discovery of the egress points.

It creates a new session and filter spec for the aggregated reservation, but classification within the aggregating region is performed using the DSCP. When PATH message arrives the Egress router, it sends a PATH_ERR message to ingress router with DSCP; ingress router then sends aggregate PATH, and egress then sends aggregate RESV message towards ingress router.

Bob Braden asked why the decision was made at the egress instead of ingress router and he also wondered where the DLCASS object is used in the scheme. Fred answered that the DCLASS object is being used to specify the MF (DSCP) classification, and as a consistency check.

Michael Speer asked about the more difficult multicast aggregation, which was discussed in a draft by Steve Berson. The answer was that multicast introduces heterogenity, which requires some micro-flow (MF) classification at certain branch points within the cloud.

There was discussion by Baker, Yoram Bernet, John Wroclawski, and Bob Braden about the relationship of this draft to the tunnel spec. They are closely related, especially if you think of the tunnel draft as a collection of tools rather than a single mechanism.

The chairs believe that this draft is being taken up by the ISSLL working group.

D. RSVP Extensions for LSP (MPLS) Tunnels -- George Swallow, Lou Berger

Swallow explained the scope of this spec as:

The advantages of using RSVP for this application are:

The MPLS additions to RSVP are:

- Class = SESSION, C-Type = LSP_TUNNEL_IPv4

Berger summarized changes in the current draft.

- Eliminated extra refresh needed prior to setting last_refresh
- Last_refresh can only be set where HELLO being exchanged with RSVP next_hop.

- Eliminated tracking of per LIH state
- Still tracks neighboring RSVP node state
- When out-of-sync state detected, all neighbor state expired and must be refreshed

It has been agreed that the next version of the LSP Tunnels spec will separate the refresh reduction extension, which is independent of MPLS, from the rest, which is MPLS-dependent. There is some urgency among vendors to reach a quick agreement on the refresh reduction. Meanwhile, Lixia Zhang and her students are investigating an alternative approach to refresh reduction, which will support partial refresh.

The plan is to hold an interim RSVP WG meeting, probably at Cisco during April, to try to reach agreement on this spec, hopefully combining the Berger and the Zhang approaches.

E. RSVP Tunnel draft update -- Andreas Terzis

Andrea Terzis gave a very brief summary of the final update to the RSVP tunnel draft.

- Mapping between e2e and tunnel sessions is now initiated by e2e RESV messages, to be consistent with the int-serv model.
- The tunnel spec briefly distinguishes two different forms of "multicasting" with tunnels. In a "multicast" tunnel, a packet is actually multicast to all egress routers. In a "point-to-multipoint" tunnel, a data packet is replicated at the ingress router, which unicasts a copy (through a tunnel) to each egress router. A complication of the latter form is that the destination address cannot be used within the tunnel for classification.

F. Working Group Charter Revision -- Chairs

The chairs, in consultation with the Area Director, have decided that it is time for the RSVP working group to terminate. It has accomplished its major goals, and the primary specifications are or soon will be Proposed Standards. Industry is now busy implementing and testing the results. Meanwhile, there is a lack of energy in the current RSVP group for substantive new protocol design work.

There is also considerable confusion over the basic design goals of diffserv and intserv, and how the pieces of Internet QoS will fit together. It is time to take stock, perhaps have some new BOFs, and generate new working groups with new foci. There is also a problem of availability of chairs.

Michael Speer asked about whether RSVP should go to Draft Standard soon. Fred Baker replied that it seems to be premature talking about draft standard since we are still expecting the first router vendor and also the windows NT to ship.

Braden noted that the RSVP mailing list will continue indefinitely. The RSVP WG previously went dormant for awhile, and it appears to be time to kill it now. Lixia Zhang does not think the WG has spent enough effort on the aggregation issue, but this is mostly individual efforts at present. John Wroclawski noted that the ISSLL working group is expected to carry on the aggregation work. However, the RSVP protocol itself appears unlikely to change in the near future.

The Area Director Scott Bradner stated that he believes it is rational for the RSVP WG to terminate in the near future. We can schedule a meeting it Oslo, and cancel it if none is needed.

G. Short Reports

Processing Rules -- Bob Lindell

The Informational RFC on the RSVP processing rules contains errors. He has drafted a major revision of this spec. His goals were to:

His work has also revealed some minor protocol issues, in particular:

- (John Wroclawski noted that the int-serv Adspec is not expected to change frequently, but some hold-down and/or granularity control would be advisable).

SCRAPI (Simplified API) Version 2 -- Bob Lindell

Lindell described a new version of the simplified API for RSVP, called SCRAPI. It refined the error model and removed the TTL parameter.

Open issues include how to compute a reasonable approximation to a token bucket depth with parameters that a typical application is likely to know.

Yoram Bernet mentioned the alternative Winsock API, and Michael Speer proposed a simplified interface using the Winsock API as a starting point.

Java API -- Pete St. Piere

Sun has developed a Java library for RSVP API. St Piere asked whether working group memebers are willing to act as the "experts group" for draft review.


Aggregate RSVP
Extensions to RSVP for LSP Tunnels
RSVP Message Processing Rules
SCRAPI Applications Programming Interface for RSVP
Update on RSVP Tunnels