RSVP

ReSerVation setup Protocol

New RSVP Release version 3.2 - See Below

WHAT IS RSVP?

RSVP is a network control protocol that will allow Internet applications to obtain special qualities-of-service (QoS's) for their data flows. This will generally (but not necessarily) require reserving resources along the data path(s). RSVP is a component of the future "integrated services" Internet, which will provide both best-effort and realtime qualities of service [ RSVP93, ISInt93 ] .

When an application in a host (end system) requests a specific QoS for its data stream, RSVP is used to deliver the request to each router along the path(s) of the data stream and to maintain router and host state to provide the requested service. Although RSVP was developed for setting up resource reservations, it is readily adaptable to transport other kinds of metwork control information along data flow paths.

WHERE IS RSVP BEING DEVELOPED AND STANDARDIZED?

RSVP design has been a joint effort involving Xerox PARC , MIT, the USC Information Sciences Institute , and USC Computer Science Department . There is an RSVP working group of the IETF to agree on an Internet standard specification for RSVP.

IETF RSVP WORKING GROUPS

   RSVP Mailing list: rsvp@isi.edu.  
           To join list, send request to rsvp-request@isi.edu

   RSVP WG Co-chairs: Bob Braden (braden@isi.edu) and
                      Lixia Zhang (lixia@parc.xerox.com)

   Most recent protcol specification document: See bibliography below

   The job of the RSVP working group dovetails, and sometimes overlaps,
   the area covered by the Integrated Services (int-serv) working group.
   If you join the RSVP mailing list, we recommend you also join the
   int-serv mailing list:

   Int-serv Mailing list: int-serv@isi.edu.
            To join list, send request to int-serv-request@isi.edu

   Int-serv WG Co-chairs: Craig Partridge (craig@aland.bbn.com),
                          Dave Clark (ddc@lcs.mit.edu),
                          Scott Shenker (shenker@parc.xerox.com),
                          John Wroclawski (jtw@lcs.mit.edu)

RSVP BIBLIOGRAPHY

[SPEC95] Braden, R., Zhang, L., Berson, S., Herzog, S., Wroclawski, J., Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification (also in postscript) Internet Draft.

[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, September 1993.

[RSVP94] Braden, R. and L. Zhang, "RSVP: A Resource ReSerVation Protocol", Connexions, ? 1994.

[MITZ94a] Mitzel, D., Estrin, D., Shenker, S., and L. Zhang, "An Architectural Comparison of ST-II and RSVP", Proceedings of Infocomm '94.

[MITZ94b] Mitzel, D., Shenker, S., "Asymptotic Resource Consumption in Multicast Reservation Styles", Proceedings of ACM SIGCOMM '94.

[MITZ95] Mitzel, D., Estrin, D. Shenker, S., Zhang, L. "A Study of Reservation Dynamics in Integrated Services Packet Networks", Submitted for publication.

[ISInt93] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview" RFC1633, ISI, MIT, and PARC, June 1994.

[BAKE95] Baker, F., "RSVP Cryptographic Authentication," Internet Draft.

[BAKE95] Baker, F., Krawczyk, J. "RSVP Management Information Base," Internet Draft.

[HERZ95] Herzog, S.,
"Building Blocks for Accounting and Access Control in RSVP," Pre-Internet Draft.

[HERZ95] Herzog, S., Shenker, S., Estrin, D.,
"Sharing the Cost of Multicast Trees: An Axiomatic Analysis", Proceedings of SIGCOMM '95.

WHAT DOES RSVP DO?

RSVP supports multicast or unicast simplex data delivery

RSVP is fundamentally designed for multicasting as well as unicasting, and it treats data flow as one directional. It distinguishes the roles of data sender (e.g., hosts H1, H2) from data receiver (hosts H3, H4, H5), although in many cases the same application will play both roles.

RSVP handles heterogeneous receivers

Different hosts on the same multicast delivery tree may have different capabilities and therefore need different QoS.

RSVP is receiver-oriented.

To efficiently handle heterogeneous receivers and dynamic group membership, RSVP makes receivers responsible for requesting resource reservations. Each receiver can request a QoS that is tailored to its particular requirement, by sending RSVP reservation messages upstream towards the senders.

This figure shows RSVP reservation messages flowing upstream. Just as the data branches out in routers R1, R3, and R4, so the reservation messages going upstream are "merged". Thus, a single reservation message need only flow upstream until it is merged with another reservation.

RSVP adapts to changing group membership as well as changing routes.

For dynamic adaptability and robustness, RSVP maintains ``soft state'' in the routers. The only permanent state is in the end systems, which periodically send their RSVP control messages to refresh the router state. In the absence of refresh, RSVP state in routers will time out and be deleted.

RSVP is not a routing protocol.

The RSVP daemon consults the local routing protocol(s) to obtain routes. RSVP is designed to operate with existing and future unicast and multicast routing protocols. Thus, a host sends IGMP messages to join a multicast group, but it uses RSVP messages to reserve resources along the delivery path(s) from that group.

Further discussion on the objectives and general justification for RSVP design are presented in [ RSVP93 , ISInt93 ].

HOW DOES RSVP WORK?

As shown in this figure, each router in the path capable of resource reservation will pass incoming data packets to a Packet Classifier and then queue them in a Packet Scheduler. The Packet Classifier determines the route and the QoS class for each packet. The Scheduler allocates a particular outgoing link for packet transmission (it may also allocate other system resources (e.g., CPU time and/or buffers).

A QoS request originating in an application is passed to the RSVP implementation (shown as a user daemon in the figure above) and RSVP passes the request to all the nodes along the reverse data path(s) to the destination(s). At each node, RSVP applies a local decision procedure called admission control to the QoS request, and if admission control succeeds, it sets the parameters to the Classifier and Packet Scheduler to obtain the desired QoS. If admission control fails at any node, RSVP returns an error indication to the application.

RSVP reserves resources for simplex data streams, i.e., it reserves resources in only one direction on a link, so that a sender is logically distinct from a receiver. However, the same application may act as both sender and receiver.

RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast delivery paths. RSVP transfers reservation parameters as opaque data (except for certain well-defined operations on the data), which it simply passes to admission control and to the Packet Scheduler and Classifier for interpretation.

RSVP and related software

Click here for the current release of RSVP software (based on the July '95 version of the spec) plus supporting tools and applications. An early access experimental release of Solaris RSVP/CBQ (also based on the July '95) version of the spec) has been made available by Sun Microsystems (note that the file is 12MB).