This document defines RSVP, a resource reservation setup protocol
designed for an integrated services Internet [RSVP93, RFC 1633]. The
RSVP protocol is used by a host to request specific qualities of
service from the network for particular application data streams or
flows. RSVP is also used by routers to deliver quality-of-service
(QoS) requests to all nodes along the path(s) of the flows and to
establish and maintain state to provide the requested service. RSVP
requests will generally result in resources being reserved in each
node along the data path.
RSVP requests resources for simplex flows, i.e., it requests
resources in only one direction. Therefore, RSVP treats a sender as
logically distinct from a receiver, although the same application
process may act as both a sender and a receiver at the same time.
RSVP operates on top of IPv4 or IPv6, occupying the place of a
transport protocol in the protocol stack. However, RSVP does not
transport application data but is rather an Internet control
protocol, like ICMP, IGMP, or routing protocols. Like the
implementations of routing and management protocols, an
implementation of RSVP will typically execute in the background, not
in the data forwarding path, as shown in Figure 1.
RSVP is not itself a routing protocol; RSVP is designed to operate
with current and future unicast and multicast routing protocols. An
RSVP process consults the local routing database(s) to obtain routes.
In the multicast case, for example, a host sends IGMP messages to
join a multicast group and then sends RSVP messages to reserve
resources along the delivery path(s) of that group. Routing
protocols determine where packets get forwarded; RSVP is only
concerned with the QoS of those packets that are forwarded in
accordance with routing.
In order to efficiently accommodate large groups, dynamic group
membership, and heterogeneous receiver requirements, RSVP makes
receivers responsible for requesting a specific QoS [RSVP93]. A QoS
request from a receiver host application is passed to the local RSVP
process. The RSVP protocol then carries the request to all the nodes
(routers and hosts) along the reverse data path(s) to the data
source(s), but only as far as the router where the receiver's data
path joins the multicast distribution tree. As a result, RSVP's
reservation overhead is in general logarithmic rather than linear in
the number of receivers.
Quality of service is implemented for a particular data flow by
mechanisms collectively called "traffic control". These mechanisms
include (1) a packet classifier, (2) admission control, and (3) a
"packet scheduler" or some other link-layer-dependent mechanism to
determine when particular packets are forwarded. The "packet
classifier" determines the QoS class (and perhaps the route) for each
packet. For each outgoing interface, the "packet scheduler" or other
link-layer-dependent mechanism achieves the promised QoS. Traffic
control implements QoS service models defined by the Integrated
Services Working Group.
During reservation setup, an RSVP QoS request is passed to two local
decision modules, "admission control" and "policy control".
Admission control determines whether the node has sufficient
available resources to supply the requested QoS. Policy control
determines whether the user has administrative permission to make the
reservation. If both checks succeed, parameters are set in the
packet classifier and in the link layer interface (e.g., in the
packet scheduler) to obtain the desired QoS. If either check fails,
the RSVP program returns an error notification to the application
process that originated the request.
RSVP protocol mechanisms provide a general facility for creating and
maintaining distributed reservation state across a mesh of multicast
or unicast delivery paths. RSVP itself transfers and manipulates QoS
and policy control parameters as opaque data, passing them to the
appropriate traffic control and policy control modules for
interpretation. The structure and contents of the QoS parameters are
documented in specifications developed by the Integrated Services
Working Group; see [RFC 2210]. The structure and contents of the
policy parameters are under development.
Since the membership of a large multicast group and the resulting
multicast tree topology are likely to change with time, the RSVP
design assumes that state for RSVP and traffic control state is to be
built and destroyed incrementally in routers and hosts. For this
purpose, RSVP establishes "soft" state; that is, RSVP sends periodic
refresh messages to maintain the state along the reserved path(s).
In the absence of refresh messages, the state automatically times out
and is deleted.
In summary, RSVP has the following attributes:
RSVP makes resource reservations for both unicast and many-to-
many multicast applications, adapting dynamically to changing
group membership as well as to changing routes.
RSVP is simplex, i.e., it makes reservations for unidirectional
data flows.
RSVP is receiver-oriented, i.e., the receiver of a data flow
initiates and maintains the resource reservation used for that
flow.
RSVP maintains "soft" state in routers and hosts, providing
graceful support for dynamic membership changes and automatic
adaptation to routing changes.
RSVP is not a routing protocol but depends upon present and
future routing protocols.
RSVP transports and maintains traffic control and policy control
parameters that are opaque to RSVP.
RSVP provides several reservation models or "styles" (defined
below) to fit a variety of applications.
RSVP provides transparent operation through routers that do not
support it.
RSVP supports both IPv4 and IPv6.
Further discussion on the objectives and general justification for
RSVP design are presented in [RSVP93] and [RFC 1633].
The remainder of this section describes the RSVP reservation
services. Section 2 presents an overview of the RSVP protocol
mechanisms. Section 3 contains the functional specification of RSVP,
while Section 4 presents explicit message processing rules. Appendix
A defines the variable-length typed data objects used in the RSVP
protocol. Appendix B defines error codes and values. Appendix C
defines a UDP encapsulation of RSVP messages, for hosts whose
operating systems provide inadequate raw network I/O support.
