Brigham Young University Brigham Young University
BYU ScholarsArchive BYU ScholarsArchive
Faculty Publications
1993-09-01
RSVP: A New Resource ReSerVation Protocol RSVP: A New Resource ReSerVation Protocol
Daniel Zappala
daniel_zappala@byu.edu
Stephen Deering
Deborah Estrin
Scott Shenker
Lixia Zhang
Follow this and additional works at: https://scholarsarchive.byu.edu/facpub
Part of the Computer Sciences Commons
Original Publication Citation Original Publication Citation
Lixia Zhang , Steve Deering, Deborah Estrin, Scott Shenker and Daniel Zappala, "RSVP: A
Resource ReSerVation Protocol", IEEE Network, September 1993.
BYU ScholarsArchive Citation BYU ScholarsArchive Citation
Zappala, Daniel; Deering, Stephen; Estrin, Deborah; Shenker, Scott; and Zhang, Lixia, "RSVP: A New
Resource ReSerVation Protocol" (1993).
Faculty Publications
. 706.
https://scholarsarchive.byu.edu/facpub/706
This Peer-Reviewed Article is brought to you for free and open access by BYU ScholarsArchive. It has been
accepted for inclusion in Faculty Publications by an authorized administrator of BYU ScholarsArchive. For more
information, please contact ellen_amatangelo@byu.edu.
RSVP:
A
NEW
RESOURCE
RESERVATION
PROTOCOL
Lixia Zhang, Stephen Deering, Deborah Estrin,
Scott
Shenker, and Daniel Zappala
Originally published in
IEEE
Network Magazine
September
1993
-
Volume
7,
Number
5
he origin of the RSVP protocol can be traced
back to
1991,
when a team of network
researchers, including myself, started playing
with a number of packet scheduling algo-
rithms
on
the DARTNET (DARPA Testbed
NETwork), a network testbed made of open source,
workstation-based routers. Because scheduling algo-
rithms simply shuffle packet processing orders accord-
ing to some established rates or priorities for different
data flows, to test a scheduling algorithm requires set-
ting up the appropriate control state at each router
along the data flow paths.
I
was challenged to design a
set-up protocol that could support both unicast and
many-to-many multicast applications. That effort led to
the birth of RSVP.
As a signaling protocol designed specifically to run over
IP, RSVP distinguishes itself from previous signaling pro-
tocols in several fundamental ways. The most profound
ones include a soft-state approach, two-way signaling mes-
sage exchanges, receiver-based resource reservation, and
being independent from all other related components in a
QOS
support architecture, such as flow-specification,
admission control, scheduling algorithm, and routing. As
stated in the article, “RSVP is primarily a vehicle used by
applications to communicate their requirements to the net-
work in a robust and efficient way, independent of the spe-
cific requirements.”
It has been more than
10 years since the original idea
was first conceived. Over this time period many people
contributed to the effort that has evolved RSVP from a lab
toy to a Proposed Internet Standard Protocol. Other more
recent protocol developments, such as MPLS (Multi-Pro-
tocol Label Switching), VPN (Virtual Private Network),
and
OTN
(Optical Transport Network), to name a few,
have adopted or considered
RSVP
for their own signaling
use.
I
was stunned by RSVP’s rapid adoption and develop-
ment of usage. The protocol has moved
on
with a life of its
own. I have learned many lessons from observing which
features in the original design worked and which didn’t.
Among these lessons,
I
noticed that the proposal of sup-
porting flexible resource reservations by individual users is
yet to prove useful, and that the decision to make
RSVP
a
generic messenger, which simply carries “a bag of bits” to
pass to routers along the way, has proven to be a right one,
which promoted the adoption of RSVP for various purpos-
es other than
QOS
support.
The effort that started RSVP design is but the first step
in developing signaling protocols for the Internet.
Although the debate
on
which kinds of
QOS
support the
Internet would need continues, various signaling needs
demand a generic signaling protocol. Independent from
whether RSVP would be the lasting one to fulfill that
important role, I believe the basic principles and lessons
we have gained from RSVP development will extend
beyond the protocol itself into new protocol designs for
the future Internet.
AUTHOR‘S
INTRODUCTION
116
IEEE
Communications
Magazine
50th
Anniversary Commemorative
IssuelMay
2002
.
he current Internet architecture,
embodied in the Internet Protocol (IP)
network protocol, offers a very simple
service model: point-to-point best-effort
service. In recent years, several new
classes of distributed applications have
been developed, such as remote video,
T
multimedia conferencing, data fusion,
visualization, and virtual reality. It is becoming
increasingly clear that the Internet’s primitive
service model is inadequate for these new appli-
cations. This inadequacy stems from the failure
of
the point-to-point best-effort service model
to address two application requirements. First,
many of these applications are very sensitive to
the quality of service their packets receive. For
a network to deliver the appropriate quality of
service, it must go beyond the best-effort service
model and allow flows (which is the generic
term we will use to identify data traffic streams
in the network) to reserve network resources.
Second, these new applications are not solely
point-to-point, with a single sender and a single
receiver of data; instead, they are often multi-
point-to-multipoint, with several senders and
receivers
of
data. Multipoint-to-multipoint com-
munication occurs, for example, in multiparty
conferencing where each participant is both a
sender and a receiver of data, and also in
remote learning applications, although in the
latter case there are typically many more
receivers than senders.
In recent years there has been a flurry
of
research activity devoted to the development of
new network architectures and service models to
accommodate these new application require-
ments. Even though fundamental differences
exist between the proposed architectures, there
is widespread agreement that any new architec-
ture capable of accommodating multicast and a
variety of qualities of service can be divided into
five distinct components, which we identify and
describe below.
Flow
Specification: The network and the vari-
ous
data flows need a common language, so a
source can tell the network about the traffic
characteristics of its flow and, in turn, the net-
work can specify the quality
of
service to be
delivered to that flow. Thus, the first component
of this new architecture is a flow specification, or
“flowspec,” which describes both the characteris-
tics
of
the traffic stream sent by the source, and
the service requirements of the application. In
some sense, the flowspec is the central compo-
nent of the architecture, since it embodies the
service interface that applications interact with;
the details
of
all of the other components
of
the
architecture are hidden from applications. Two
proposals for a flowspec are described in the lit-
erature
[l,
21.
Routing: The network must decide how to
transport packets from the source to the
receiver
of
the flow (or receivers of the flow,
in the case of multicast). Thus, the second
component of the architecture is a routing
protocol that provides quality unicast and mul-
ticast paths. There are many approaches to
unicast routing, and several different
approaches to multicast routing exist as well
[2-41.
None of the current proposals have yet
dealt sufficiently with the interaction between
routing and quality of service constraints; that
is the subject of future research.
Resource Reservation: For the network to
deliver a quantitatively specified quality of ser-
vice (e.g., a bound on delay) to a particular flow,
it is usually necessary to set aside certain
resources, such as a share
of
bandwidth or a
number of buffers, for that flow. This ability to
create and maintain resource reservations on
each link along the transport path is the third
component of the architecture. Two approaches
to resource reservation are described elsewhere
[2,
51;
in this article, we describe another.
Admission Control: Because a network’s re-
sources are finite, it cannot grant all resource
reservation requests. In order to maintain the
network load at a level where all quality of ser-
vice commitments can be met, the network archi-
tecture must contain an admission control
algorithm that determines which reservation
requests to grant and which to deny, thereby
maintaining the network load at an appropriate
level. Two such admission control algorithms are
described in the literature
[6,
71.
Packet Scheduling: After every packet trans-
mission, a network switch must decide whether
or not to transmit the next packet, and which is
next. These decisions are controlled by the pack-
et scheduling algorithm, which lies at the heart
of any network architecture because it deter-
mines the qualities of service the network can
provide. There are many proposed packet
scheduling algorithms.
A
few examples are cited
here
[S-121.
In this article, we present our proposal for the
third component of the architecture, a new
resource Reservation Protocol (RSVP). Similar
to previous work on resource reservation proto-
cols, e.g., ST-I1
[2],
RSVP is a simplex protocol,
Le., it reserves resources in one direction. How-
ever, several novel features in the RSVP design
lead to the unique flexibility and scalability of the
protocol. RSVP is receiver-oriented: the receiver
of the data flow is responsible for the initiation
of the resource reservation. This design decision
enables RSVP to accommodate heterogeneous
receivers in a multicast group. Specifically, each
receiver may reserve a different amount
of
resources, may receive different data streams
sent
to
the same multicast group, and may
“switch channels” from time to time (Le., change
which data streams it wishes to receive) without
changing its reservation. RSVP also provides sev-
eral reservation styles that allow applications to
specify how reservations for the same multicast
group should be aggregated at the intermediate
switches. This feature results in more efficient
utilization of network resources. Finally, by using
“soft-state” in the switches, RSVP supports
dynamic membership changes and automatically
adapts to routing changes. These features enable
RSVP
to
deal gracefully and efficiently with large
multicast groups. While the motivation for RSVP
arose within the Internet context, our design is
intended to be fully general.
This article is organized as follows. We first
list our design goals, and then discuss the basic
design principles used to meet these goals.
A
more detailed description of the protocol opera-
In
recent years,
several new classes
of
distributed
applications have
been developed,
such
as.
remote
video, multimedia
conferencing, data
fusion, visualization,
and virtual reality.
It
is
becoming
increasingly clear
that the Internet‘s
primitive service
model is inadequate
for
these new
applications.
117
IEEE
Communications
Magazine
50th
Anniversary Commemorabe Issue/May
2002
The strawman
proposal here
is
incapable
of
dealing
with the receivers
individually, and
so
cannot address these
heterogeneous
needs. Therefore,
our
first design goal
for
RSVP
is to
pro-
vide the ability for
heterogeneous
receivers
to
make
reservations
specifically tailored
to their own needs.
tion is then given, followed by a simple example
of how the protocol would work. Next, the cur-
rent state
of
our RSVP implementation is
described. We delay consideration of related
work until later, and follow that with a discus-
sion of unresolved issues. Finally, we conclude
with a brief summary.
RSVP
DESIGN
GOALS
In the traditional point-to-point case, one obvi-
ous
reservation paradigm would have the sender
transmit a reservation request toward the receiv-
er, with the switches along the path either admit-
ting or rejecting the flow. For the point-to-
multipoint case, one may trivially extend this
paradigm to have the sender transmit the reser-
vation request along a multicast routing tree to
each
of
the receivers. When we have multipoint-
to-multipoint data transmissions, the straightfor-
ward extension of this paradigm would be to
have each sender transmit a reservation request
along its own multicast tree to each receiver.
However, the special properties of having multi-
ple, heterogeneous receivers and/or multiple
senders pose serious challenges that are not
addressed by this simple extension of the basic
reservation paradigm. We outline these various
challenges below and detail how they are not
met by the strawman proposal of straightfor-
wardly extending the basic paradigm. In the pro-
cess, we identify the seven goals that guided the
design of RSVP.
In a wide-area internetwork such as the Inter-
net, receivers and paths to reach receivers can have
very different properties from one another. In par-
ticular, one must not assume that all the receivers
of
a multicast group possess the same capacity for
processing incoming data, nor even necessarily
desire or require the same quality
of
service from
the
network. For instance,
a
source may
be
sending
a layered encoding of a video signal. Certain
receivers decoding in software would only have
sufficient processing power to decode the low-reso-
lution signal, while those receivers with hardware
decoding, or more processing power, could decode
the entire signal. Furthermore, the paths to reach
the receivers may not have the same capacity. In
the layered encoding example above, certain
receivers might only have low-bandwidth paths
between them and the source and
so
could only
receive the low-resolution signal. The strawman
proposal above is incapable of dealing with the
receivers individually, and
so cannot address these
heterogeneous needs. Therefore, our first design
goal for RSVP is to provide the ability for hetero-
geneous receivers to make reservations specifically
tailored to their
own needs.
The presence of multiple receivers raises
another issue: the membership in a multicast
group can be dynamic. The strawman proposal
would have to reinitiate the reservation protocol
every time a new member joined or an existing
member left the multicast group. Reinitiation of
the reservation protocol
is
particularly burden-
some for large groups because the larger the
group size, the more frequent are changes in
group membership.
So
our second design goal
for RSVP is to deal gracefully with changes in
the multicast group membership.
The strawman proposal deals with multiple
senders by having each sender make an indepen-
dent resource reservation along its own multicast
routing tree. This approach results in resources
being reserved along multiple, independent
trees, even though the branches of different
trees often share common links. Although appro-
priate for some applications, in other cases this
duplication can lead to a significant wasting
of
resources. For example, in an audio conference
with several people, usually only one person, or
at most a few people, talk at any one time
because of the normal dynamics of human con-
versation. Thus, instead of reserving enough
bandwidth for every potential speaker to speak
simultaneously, in many circumstances it is ade-
quate to reserve only enough network resources
to handle a few simultaneous audio channels.
Our third design goal for RSVP is to allow end
users
to
specify their application needs,
so
the
aggregate resources reserved for a multicast
group can more accurately reflect the resources
actually needed by that group.
Furthermore, in a multiparty conference a
receiver may only wish to (or be able to) watch
one or a few other participants at a time but
would like the possibility
of
switching among
various participants. The simple approach
of
delivering the data streams from all the sources
and then dropping the undesired ones at the
receiver does not address network resource
usage considerations (e.g., efficient use of limit-
ed bandwidth, or reducing the charges incurred
for bandwidth usage). A receiver should be able
to control which packets are carried on its
reserved resources, not only what gets displayed
on
its
local screen. Moreover, a receiver should
be able to switch among sources without the risk
of having the change request denied, as could
occur if a new reservation request had to be sub-
mitted
in
order
to
“switch channels.”
Our fourth
design goal for RSVP is to enable this channel-
changing feature.
RSVP
is
not a routing protocol and should
avoid replicating any routing functions. RSVP’s
task is
to
establish and maintain resource reser-
vations over a path or a distribution tree, inde-
pendent of how the path or tree was created. In
a large internetwork with a volatile topology and
load, these routes may change from time to
time. Adapting to such changes in topology and
load is the explicit job of the routing protocol; it
would be expensive and complicated to replicate
such functions in RSVP. At the same time, how-
ever, RSVP should be able to cope with the
resulting routing changes. Our fifth design goal
is that RSVP should deal gracefully with such
changes in routes, automatically reestablishing
the resource reservations along the new paths as
long as adequate resources are available.
The strawman proposal does not deal grace-
fully with changes in routes, because there
is
no
mechanism to discover the change and trigger a
new resource reservation request. One could
introduce such a mechanism by having each
source periodically refresh its reservation over
the multicast routing tree. However, in large
multicast groups such refreshing would lead to
S
messages arriving at every receiver during every
refresh period, where
S
is the number
of
sources.
118
IEEE
Communications
Magazine
50th Anniversoty Commemorative
Issue/May
2002
Our sixth design goal is
to
control protocol over-
head. By this we mean both avoiding the explo-
sion in protocol overhead when group size gets
large, and also incorporating tunable parameters
so
that the amount of protocol overhead can
be
adjusted.
Our last design goal is not specific to the
problem at hand hut rather is
a
general matter
of modular design. We hope to make the gen-
eral design of RSVP relatively independent of
the architectural components listed in the first
section
of
this article. Clearly a particular
implementation of RSVP will be tied quite
closely to the flowspec and interfaces used by’
the routing and admission control algorithms.
However, the general protocol design should
be independent of these. In particular, our pro-
tocol should be capable of establishing reserva-
tions across networks that implement different
routing algorithms, such
as
IP unicast routing,
1P multicast routing
(41,
the recently proposed
core-based tree (CBT) multicast routing
[3],
or
some future routing protocols. This design goal
makes RSVP deployable in many contexts. For
optimally efficient routing decisions, however,
routing selection and resource reservation
should be integrated,
so
the choice of route
can depend
on
the quality of service requested,
and the stability of the route can he main-
tained over the duration of the reservation.
Such
an
integration would lead to more coordi-
nation bctwccn the choice
of
which resources
to reserve and the mechanics of establishing
the reservation (which is RSVP’s main focus).
This integration is something that requires fur-
ther research.
In
summary, we have identified seven impor-
tant design goals (see box this page). RSVP is
primarily a vehicle used by applications to com-
municate their requirements to the network in
a robust and efficient way, independent of the
specific requirements. RSVP delivers resource
reservation requests to the relevant switches
but plays
no
other role in providing network
services. Thus, RSVP communicates require-
ments for
a
wide range
of
network services but
does not directly provide them. For instance,
the synchronization requirements of flows
or
the need for reliable multicast delivery could be
expressed
in
the flowspec that is distributed by
RSVP and then realized by the switches. Simi-
larly, the flowspec could
also
carry around
information about advance reservations (reser-
vations made for
a future time) and preempt-
able reservations (reservations that a receiver is
willing to have preempted). RSVP is capable
of
supporting the delivery
of
these and other ser-
vices, whenever these network services rely only
on the state being established at the individual
switches along the paths determined by the
routing algorithm. Thus, although we described
RSVP as
a
resource reservation protocol,
it
can
he seen more generally as a “switch-state estab-
lishment” protocol.
’
BASIC,
DESIGN
PRINClPlfS
To achieve the seven design goals, we used six
basic design principles (see box this page). These
principles are now described.
The Seven Design
Goals
of
RSVP
*
Accommodate heterogeneous receivers.
*
Exploit the resource needs
of
different applications in order to use
*
Mow receivers to switch channels.
Adapt to changes
in
the underlying unicast and multicast routes.
Adapt to changing multicast group membership.
network resources efficiently.
Controlprotocol overhead
so
that it does not grow linearly (or worse)
with the number
of
participants.
-
Make
the
design modular to accommodate heterogeneous underlying
technologies.
The
Six
Design Principles
of
RSVP
Receiver-initiated reservation.
Sepaiating reservation from packet filtering.
.
Providing different reservation styles.
*
Maintaining “soft-state” in the network.
-
Protocol overhead control.
-
Modularity.
RECEIVER-INITIATED RESERVAIIDN
The strawman proposal discussed in the previous
section
-
and
all
existing resource reservation
protocols
-
are designed around the principle
that the data source initiates the reservation
request.
In
contrast, RSVP adopts a novel receiv-
er-initiated design principle. Receivers choose
the level of resources reserved and are reSpOnSi-
hle for initiating and keeping the reservation
active as
long
as
they want to receive the data.
We describe the motivation for this receiver-ini-
tiated approach below.
A source can always transmit data, whether
or not adequate resources exist in the network
to deliver the data. The receiver knows its own
capacity limitations. Furthermore, the receiver is
the only one who experiences, and thus
is
direct-
ly concerned with, the quality of service of the
incoming packets. Additionally,
if
network charg-
ing is deployed in the future, the receiver would
likely be the party paying for the requested qual-
ity of service. Thus, it should be the receiver who
decides which resources should be reserved.
One could imagine the receivers send this
information to the source, which would use this
information in sending out the reservation
request.
To
handle heterogeneous requests,
however, the sender would have to bundle all
requests together and pass them to the network,
and the network would determine how much
resource to reserve
on
which links, according to
the location
of
individual receivers. For large
multicast groups, this will likely cause a multicast
implosion at the sender. This implosion problem
becomes more serious when the multicast group
membership changes dynamically and the reser-
vation has to he periodically renewed. Consider,
as an extreme example, a cable TV firm broad-
casting several channels of programs. While
there are relatively few sources, there are per-
haps hundreds
of
thousands
of
receivers, each
watching only one or a few channels at a time.
In
the strawman proposal, whenever any individ-
ual receiver wants to switch between channels, it
I
IEEE
Communirotions Mngozine
Soh
AnniveMV Cnmmemomfiue Inee/Mny
2002
119