Background

The fundamental design of the ReSerVation Protocol (RSVP) is based upon research performed in 1992-1993 by a collaboration that included Lixia Zhang (Xerox PARC), Deborah Estrin (USC/ISI), Scott Shenker (Xerox PARC), Sugih Jamin (USC/Xerox PARC), and Daniel Zappala (USC). Sugih Jamin developed the first prototype implementation of RSVP and successfully demonstrated it in May 1993.

Beginning in 1993, the Information Sciences Institute (ISI) was funded by the US Defense Research Projects Agency (DARPA) to perform research, development, and technology transfer on RSVP. The general thrust of this project was to move RSVP forward from a set of research ideas into Internet practice.

During the initial RSVP project (April 1993 - June 1995), ISI developed a research prototype RSVP daemon, wrote successive drafts of an RSVP protocol spec, and introduced RSVP into the IETF standardization process. The project's final technical report "The Design of the RSVP Protocol" ( Postscript) summarizes the RSVP protocol as of July 1995.

Since July 1995, ISI has been continuing RSVP development and technology transfer under a follow-on contract. This contract, which originally carried the project title "RSVP2", was later renamed to "RSVPTNT" when it was moved underneath the "TNT" umbrella contract at DARPA's request.

Important pieces of the RSVP protocol and of the reference implementation distributed by ISI have been developed or are under development by other organizations. John Wroclawski and others at MIT contributed the Tcl-based application interface to RSVP that ISI distributes with the MBONE interfaces. Don Hoffman contributed to the API definition. Lixia Zhang and Andreas Terzis (UCLA) designed and implemented the Diagnostic facility. JJ Krawczyk (Bay Networks), Lixia Zhang, and others have worked on defining a recursive application of RSVP for reservations within IP tunnels. Fred Baker (Cisco) contributed the MD5 Integrity mechanism and the RSVP MIB. Lou Berger (Fore Systems) and Tim O'Malley (BBN) developed the IPSEC support option.

RSVP Objectives

The general objective of RSVP is to provide an efficient, robust, and flexible, robust signaling protocol for Internet QoS, supporting both multicast and unicast data flows. In particular, RSVP was designed to sets up reservations for integrated services. RSVP must support the full range of unicast and multicast routing protocols present and future, and it must scale well (as well as IP multicast routing) for large multicast delivery groups. It must accommodate a wide range of heterogeneous service requests and network capabilities. It must be easily extensible and incrementally deployable in the Internet. Finally, it must support all the requirements of integrated service models under development.

Approach

The original RSVP conception by Lixia Zhang et al included two highly innovative features: receiver initiation and soft state. To allow scaling to large groups of receivers and to support heterogeneity, RSVP provides receiver-initiated reservations. To provide robust and flexible service, RSVP sets up `soft state' in the nodes, periodically refreshing state which will otherwise time out.

To support the range of routing protocols and services, RSVP's functions have been carefully limited and appropriate interfaces to routing and to traffic control have been defined. To provide generality and extensibility, an RSVP protocol packet is simply a container for a variable set of variable-length typed `objects'. To allow incremental deployment, RSVP is designed to automatically `tunnel' through arbitrary clouds of routers that do not yet implement it.

ISI's RSVPTNT Project

Principal Investigators:

• Herbert Schorr ([email protected])
  
• Robert Braden ([email protected])
  
• Deborah Estrin ([email protected])
  

The primary objectives for this project are: maturing the base RSVP protocol specification and working through the IETF to make it a Proposed Standard, creating a reference implementation that also includes experimental protocol features, and performing research on the interactions with routing, on access control and accounting, and on aggregation of state.

Project Accomplishments

1. The major RSVP-related protocol specification documents achieved Proposed Standard status in the IETF, and they were published as RFCs. Bob Braden (ISI) and Lixia Zhang (UCLA) co-chaired the working group. The one omission was the MD5 Integrity spec, which needs a little more work before it can reach Proposed Standard.

2. ISI brought its prototype RSVP implementation up-to-date with the published standards, and honed it to the point where we claim that it is a reference implementation. We incorporated many fixes and improvements to the code suggested by others or developed at ISI.

   The ISI reference implementation, available from ftp://ftp.isi.edu/rsvp/release directory, contains code for a workstation used as a host or router. It includes an RSVP daemon program 'rsvpd', an RSVP API, RSVP interfaces for some of the MBONE tools, and some test tools. This code has been developed under SunOS and FreeBSD, but it has been ported to a variety of other system platforms. Some of the code was contributed by other organizations, including MIT, Sun Microsystems, and BBN, and many organizations have supplied fixes for bugs. Contact Bob Braden ([email protected]) for more information.

   Note that RSVP is really only useful if there is also traffic control in the forwarding path, including a classifier, a packet scheduler, and admission control. The ISI distribution does not include traffic control.

3. We completed an initial design of routing services required by RSVP, and partially prototyped them. We also demonstrated alternate path joining and route pinning under DVMRP. The prototype of route change notification demonstrated the feasibility of event-triggered refreshes to provide rapid response to changes without high overhead in a soft state protocol. We further demonstrated through simulation the feasibility of scaleable multicast alternate path routing for reservations.

4. We developed an initial framework for access control and accounting with RSVP, separating the policy model from the implementation mechanism. Introduced into the RSVP working group, this work was later passed to a new working group, RAP.

5. Allison Mankin's group with help from RSVPTNT personnel demonstrated the use of RSVP for setting up ATM SVCs. Reservation requests for an IP multicast session resulted in setting up a point-to-multipoint SVC. The ATM setup as using a prototype MARS resolution server. This work was largely under Sprint funding.

6. Working with Don Hoffman (Sun Microsystems), ISI refined the definition of an API for RSVP, implemented it in the ISI prototype, and helped to create an X/Open standards document describing the API.

The ISI projects on RSVP have led to two PhD theses. Shai Herzog (ISI) developed accounting and access control mechanisms for reservations. Daniel Zappala (ISI) did his research on scaleable multicast alternate path routing for RSVP. Deborah Estrin supervised both.

Recent and Current Project Tasks

1. Performing simulations to understand the feasibility of RSVP state aggregation to reduce the amount of RSVP and traffic control state in backbone networks, and develop RSVP protocol mechanisms for this purpose. Support aggregation of multicast sessions.

2. Prototyping our RSVP/routing architecture, including route pinning and alternate path routing, for the multicast routing protocol PIM.

3. Developing and documenting an architecture for advance reservations based upon RSVP.

4. Implement support for IPv6 in the ISI prototype of RSVP, in the RSVP API, and in the routing interface. Test it in CAIRN.

5. Implement security features in the ISI RSVP code and test in CAIRN. These features include the hashed MD5 integrity mechanism and support for IPSEC (IP security).

6. Make some performance measurements on the ISI reference implementation.

7. Investigate some of the remaining protocol issues in RSVP, and make recommendations to the RSVP working group. These issues include the MD5 Integrity mechanism and the Killer Reservation problem.