Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment
RFC 2208
Network Working Group A. Mankin, Ed.
Request for Comments: 2208 USC/ISI
Category: Informational F. Baker
Cisco Systems
B. Braden
USC/ISI
S. Bradner
Harvard
M. O`Dell
UUNET Technologies
A. Romanow
Sun Microsystems
A. Weinrib
Intel Corporation
L. Zhang
UCLA
September 1997
Resource ReSerVation Protocol (RSVP)
Version 1 Applicability Statement
Some Guidelines on Deployment
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document describes the applicability of RSVP along with the
Integrated Services protocols and other components of resource
reservation and offers guidelines for deployment of resource
reservation at this time. This document accompanies the first
submission of RSVP and integrated services specifications onto the
Internet standards track.
Mankin, Ed., et. al. Informational [Page 1]
RFC 2208 RSVP Applicability and Deployment September 1997
1. Introduction
RSVP [RFC 2205] is a unicast and multicast signalling protocol,
designed to install and maintain reservation state information at
each router along the path of a stream of data. The state handled by
RSVP is defined by services [RFC 2211] and [RFC 2212] specified by
the Integrated Services WG. These services and RSVP are being
introduced to the IETF's standards track jointly. From henceforth,
the acronym RSVP on its own is used as a shorthand for the signalling
protocol combined with the integrated service specifications.
RSVP must be used in conjunction with several additional components,
described in Table 1.
Table 1 Additional Components of Resource Reservation
1. Message formats in which parameters for desired services can be
expressed. A proposed standard set of these formats is specified
in [RFC 2210].
2. Router and host mechanisms (e.g. packet classification and
scheduling, admission control algorithms) to implement one or
both of the models [RFC 2211] and [RFC 2212], which are also
in the standards track.
3. Message formats in which parameters for desired policies for
admission control and resource use can be expressed. A small
common subset of these formats for standards track is in the
RSVP WG's charter. The Policy objects in the RSVP Protocol
Specification are optional only at this time.
4. Diversely located mechanisms implementing desired admission
control policy functions, including authorization and other
security mechanisms.
In the presence of some form of each component in Table 1, RSVP-
enabled applications can achieve differentiated qualities of service
across IP networks. Networked multimedia applications, many of which
require (or will benefit from) a predictable end-user experience, are
likely to be initial users of RSVP-signalled services.
Because RSVP and the integrated services and other components listed
in Table 1 mark a significant change to the service model of IP
networks, RSVP has received considerable interest and press in
advance of its release as a standards track RFC. At present, many
vendors of operating systems and routers are incorporating RSVP and
integrated services into their products for near-future availability.
The goal of this applicability statement is to describe those uses of
Mankin, Ed., et. al. Informational [Page 2]
RFC 2208 RSVP Applicability and Deployment September 1997
the current RSVP specification that are known to be feasible, and to
identify areas of limitation and ongoing chartered work addressing
some of these limitations.
2. Issues Affecting Deployment of RSVP
Wide scale deployment of RSVP must be approached with care, as there
Show full document text