2.7.8 Resource Reservation Setup Protocol (rsvp)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

Chair(s):

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

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn.romanow@eng.sun.com>

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:

Done

  

Hold BOF on RSVP at Houston IETF meeting.

Done

  

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2205

PS

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

RFC2206

PS

RSVP Management Information Base using SMIv2

RFC2207

PS

RSVP Extensions for IPSEC Data Flows

RFC2208

PS

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

RFC2209

PS

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

Current Meeting Report

Minutes of the Resource Reservation Setup Protocol Working Group Meeting

Reported by: Bob Braden/USC-ISI

I. Status Report: Bob Braden, Scott Bradner

The Transport Area director Scott Bradner briefly presented the current status of the RSVP Internet Drafts. Contrary to previous report, a few minor issues had held up the IESG approval of these documents as Proposed Standards. The only issue still open at the time of the meeting concerned the IPSEC Extension document: the IESG requested a more explicit statement of how the VDstPort field should be assigned. The proposed fix was to include an "IANA Considerations" section, specifying a division of the field values into fixed and dynamically assigned ranges, with directions to the IANA on how to assign values from the fixed range. There being no objection from the document authors or from the Working Group, this proposal was adopted. As a result, the RSVP documents should all advance into the standards track.

The RAPI application interface, defined in the ISI interface, has been submitted to XOPEN for possible standardization by that body. This was initiated and is being pursued by Don Hoffman of Sun. An XOPEN draft has been produced and is waiting editing.

A first stage of a survey of current and planned implementations of RSVP and integrated services has been completed. This initial effort was substantial, and has more than 20 entries. We are grateful to Gene Gaines and Luca Salgarelli for the work they have put into this. The draft has been distributed on the rsvp-test mailing list, and it is planned to be available on a Web page.

II. Status of Tunneling and Diagnosis Drafts: Lixia Zhang

The diagnostic message specification has gone through another cycle of cleanup and has two new object types added:

· In response to comments received from Memphis meeting, a new SELECT object is defined to allow a diagnostic requester to specify the types of RSVP objects to be collected in the diagnostic reply. This new SELECT object consists of a list of [C-Class, C-type] pairs.
· In order to be able to perform diagnosis recursively over an RSVP tunnel, a new TUNNEL object is defined that consists of two session objects. This object is used when the path of an RSVP session contains one or more IP-in-IP tunnels and both ends of a tunnel support RSVP tunneling. The first session object specifies the end-to-end RSVP session S1, and the second one specifies the RSVP session over the tunnel S2 that S1 maps to (that is, over the tunnel S1's flow is supported by S2's reservation). When an RSVP diagnostic request is received by an Rexit router, Rexit attaches to the DREQ a TUNNEL object. Thus the diagnostic client can easily identify the existence of RSVP tunneling, and invoke RSVP diagnosis over the RSVP tunnel session whenever needed.

Lixia Zhang also reported the status of specification and implementation of RSVP over IP-in-IP tunnels. We are finishing a new version of the specification taking into account the input from Memphis IETF, in particular some valuable comments from Tim O'Malley. UCLA is finishing the first prototype implementation that runs on freeBSD 2.2.2, with IP- in-IP tunnel code from University of Portland, and using CBQ for packet scheduling. Our implementation supports both automatic RSVP tunnel session setup by end-to-end RSVP sessions and configured RSVP sessions over the tunnel for aggregate traffic flow. We plan to release the code before December IETF.

We also learned recently that KDD R & D Lab in Japan has carried out a second, independent implementation for RSVP over IP tunnels. The implementation runs on freeBSD 2.2.1, using a simplified version of WFQ for packet scheduling.

III. Future of RSVP Working Group: Discussion

As co-chair, Bob Braden reviewed the history, goals, and accomplishments of the RSVP working group. In summary, the goals of the working group have basically been met, and most of the protocol documents under development will soon be Proposed Standards.

The Working Group then agreed to go dormant, until the time comes to consider the documents for Draft Standard. The rsvp and rsvp-test mailing lists will remain in place for discussion of the protocols and implementations.

IV. Routing and Reservations: Roch Guerin

Roch Guerin summarized the Internet Draft: "Extended RSVP-routing Interface" (draft-guerin-ext-rsvp-routing-intf-00.txt). He suggested that RSVP should support service differentiation by path, i.e., the path should be determined in part by the service requested. For this purpose, he suggested that the RSVP/routing interface be broadened, so that (1) RSVP will pass *all* information that might possibly be relevant to QoS routing, including the IP and transport headers, T_specs, and Adspecs, and (2) there will be a more general event notification mechanism between RSVP and routing.

Guerin also discussed the draft "Setting up Reservations on Explicit Paths Using RSVP (draft-guerin-expl-path-rsvp-00.txt). RSVP can be extended to support explicit routing of data, by carrying opaque routing objects.

Brief audience discussion pointed out that RSVP may not always be in use when service differentiation by path is required. It was also suggested that higher-level architectural issues should be considered before detailed RSVP-specific features are defined.

V. RSVP Experience in Commercial Internet Trials: Mark Baugher

Mark Baugher gave a very interesting report on a joint effort by Cisco, Intel, and MCI to evaluate commercial feasibility of Internet multimedia services. These tests were conducted over the MCI SMDS service and over the internal Intel ATM testbed. During these trials, RSVP was successfully tested on the MCI SMDS testbed.

A total of six application tools from three vendors/sources were converted to use RSVP. They found that about one person-month was typically required to design, implement, and test RSVP support in an application. He noted that application developers often implemented the wrong data rate for their applications, so that some mechanism for rate adjustment is necessary.

Among his conclusions were: (1) better workload generators and tools are needed for testing end-to-end delay; and (2) multicasting through firewalls in a major problem.

Slides

RSVP Overview (Status, Issues, etc.)
Extended RSVP - Routing Interface
Commercial Internet Multimedia Trials (Preliminary Results)
An Update on RSVP Diagnosis
Reservations on Explicit Paths with RSVP

Attendees List

go to list

Previous PageNext Page