As per Relevance of the word reservation, we have this rfc below:
Network Working Group R. Braden, Ed
Request for Comments: 2205
Category: Standards Track L.
S.
S.
IBM
S.
Univ. of
September 1997
Resource ReSerVation Protocol (RSVP) --
Version 1 Functional
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo describes version 1 of RSVP, a resource reservation
protocol designed for an integrated services Internet. RSVP
receiver-initiated setup of resource reservations for multicast
unicast data flows, with good scaling and robustness properties
Braden, Ed., et. al. Standards Track [Page 1]
RFC 2205 RSVP September 1997
Table of
1. Introduction ................................................... 4
1.1 Data Flows ................................................. 7
1.2 Reservation Model .......................................... 8
1.3 Reservation Styles .........................................11
1.4 Examples of Styles .........................................14
2. RSVP Protocol Mechanisms .......................................19
2.1 RSVP Messages ..............................................19
2.2 Merging Flowspecs ..........................................21
2.3 Soft State .................................................22
2.4 Teardown ...................................................24
2.5 Errors .....................................................25
2.6 Confirmation ...............................................27
2.7 Policy Control .............................................27
2.8 Security ...................................................28
2.9 Non-RSVP Clouds ............................................29
2.10 Host Model ................................................30
3. RSVP Functional Specification ..................................32
3.1 RSVP Message Formats .......................................32
3.2 Port Usage .................................................47
3.3 Sending RSVP Messages ......................................48
3.4 Avoiding RSVP Message Loops ................................50
3.5 Blockade State .............................................54
3.6 Local Repair ...............................................56
3.7 Time Parameters ............................................57
3.8 Traffic Policing and Non-Integrated Service Hops ...........58
3.9 Multihomed Hosts ...........................................59
3.10 Future Compatibility ......................................61
3.11 RSVP Interfaces ...........................................63
4. Acknowledgments ................................................76
APPENDIX A. Object Definitions ....................................77
APPENDIX B. Error Codes and Values ................................92
APPENDIX C. UDP Encapsulation .....................................98
APPENDIX D. Glossary .............................................102
REFERENCES .......................................................111
SECURITY CONSIDERATIONS ..........................................111
AUTHORS' ADDRESSES ...............................................112
Braden, Ed., et. al. Standards Track [Page 2]
RFC 2205 RSVP September 1997
What's
This revision contains the following very minor changes from the ID14
version
o For clarity, each message type is now defined separately
Section 3.1.
o We added more precise and complete rules for accepting
messages for unicast and multicast destinations (
3.1.3).
o We added more precise and complete rules for processing
forwarding PathTear messages (Section 3.1.5).
o A note was added that a SCOPE object will be ignored if
appears in a ResvTear message (Section 3.1.6).
o A note was added that a SENDER_TSPEC or ADSPEC object will
ignored if it appears in a PathTear message (Section 3.1.5).
o The obsolete error code Ambiguous Filter Spec (09)
removed, and a new (and more consistent) name was given
error code 08 (Appendix B).
o In the generic interface to traffic control, the Adspec
added as a parameter to the AddFlow and ModFlow
(3.11.2). This is needed to accommodate a node that
the slack term (S) of Guaranteed service
o An error subtype was added for an Adspec error (Appendix B).
o Additional explanation was added for handling a
object (Section 3.1.4).
o The rules for forwarding objects with unknown class type
clarified
o Additional discussion was added to the Introduction and
Section 3.11.2 about the relationship of RSVP to the
layer. (Section 3.10).
o Section 2.7 on Policy and Security was split into
sections, and some additional discussion of security
included
o There were some minor editorial improvements
Braden, Ed., et. al. Standards Track [Page 3]
RFC 2205 RSVP September 1997
1.
This document defines RSVP, a resource reservation setup
designed for an integrated services Internet [RSVP93, RFC 1633].
RSVP protocol is used by a host to request specific qualities
service from the network for particular application data streams
flows. RSVP is also used by routers to deliver quality-of-
(QoS) requests to all nodes along the path(s) of the flows and
establish and maintain state to provide the requested service.
requests will generally result in resources being reserved in
node along the data path
RSVP requests resources for simplex flows, i.e., it
resources in only one direction. Therefore, RSVP treats a sender
logically distinct from a receiver, although the same
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
transport protocol in the protocol stack. However, RSVP does
transport application data but is rather an Internet
protocol, like ICMP, IGMP, or routing protocols. Like
implementations of routing and management protocols,
implementation of RSVP will typically execute in the background,
in the data forwarding path, as shown in Figure 1.
RSVP is not itself a routing protocol; RSVP is designed to
with current and future unicast and multicast routing protocols.
RSVP process consults the local routing database(s) to obtain routes
In the multicast case, for example, a host sends IGMP messages
join a multicast group and then sends RSVP messages to
resources along the delivery path(s) of that group.
protocols determine where packets get forwarded; RSVP is
concerned with the QoS of those packets that are forwarded
accordance with routing
In order to efficiently accommodate large groups, dynamic
membership, and heterogeneous receiver requirements, RSVP
receivers responsible for requesting a specific QoS [RSVP93]. A
request from a receiver host application is passed to the local
process. The RSVP protocol then carries the request to all the
(routers and hosts) along the reverse data path(s) to the
source(s), but only as far as the router where the receiver's
path joins the multicast distribution tree. As a result, RSVP'
reservation overhead is in general logarithmic rather than linear
the number of receivers
Braden, Ed., et. al. Standards Track [Page 4]
RFC 2205 RSVP September 1997
HOST
_____________________________ ____________________________
| _______ | | |
| | | _______ | | _______ |
| |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Polcy|| || <--> -->Polcy||
| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
| |data | | |_____|| ||__.____| | | |_____||
|===|===========|==|==========| |===|==========|==|==========|
| | --------| | _____ | | | --------| | _____ |
| | | | ---->Admis|| | | | | ---->Admis||
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>
| |______| |________| |data | |______| |________| |
| | | |
|_____________________________| |____________________________|
Figure 1: RSVP in Hosts and
Quality of service is implemented for a particular data flow
mechanisms collectively called "traffic control". These
include (1) a packet classifier, (2) admission control, and (3)
"packet scheduler" or some other link-layer-dependent mechanism
determine when particular packets are forwarded. The "
classifier" determines the QoS class (and perhaps the route) for
packet. For each outgoing interface, the "packet scheduler" or
link-layer-dependent mechanism achieves the promised QoS.
control implements QoS service models defined by the
Services Working Group
During reservation setup, an RSVP QoS request is passed to two
decision modules, "admission control" and "policy control".
Admission control determines whether the node has
available resources to supply the requested QoS. Policy
Braden, Ed., et. al. Standards Track [Page 5]
RFC 2205 RSVP September 1997
determines whether the user has administrative permission to make
reservation. If both checks succeed, parameters are set in
packet classifier and in the link layer interface (e.g., in
packet scheduler) to obtain the desired QoS. If either check fails
the RSVP program returns an error notification to the
process that originated the request
RSVP protocol mechanisms provide a general facility for creating
maintaining distributed reservation state across a mesh of
or unicast delivery paths. RSVP itself transfers and manipulates
and policy control parameters as opaque data, passing them to
appropriate traffic control and policy control modules
interpretation. The structure and contents of the QoS parameters
documented in specifications developed by the Integrated
Working Group; see [RFC 2210]. The structure and contents of
policy parameters are under development
Since the membership of a large multicast group and the
multicast tree topology are likely to change with time, the
design assumes that state for RSVP and traffic control state is to
built and destroyed incrementally in routers and hosts. For
purpose, RSVP establishes "soft" state; that is, RSVP sends
refresh messages to maintain the state along the reserved path(s).
In the absence of refresh messages, the state automatically times
and is deleted
In summary, RSVP has the following attributes
o RSVP makes resource reservations for both unicast and many-to
many multicast applications, adapting dynamically to
group membership as well as to changing routes
o RSVP is simplex, i.e., it makes reservations for
data flows
o RSVP is receiver-oriented, i.e., the receiver of a data
initiates and maintains the resource reservation used for
flow
o RSVP maintains "soft" state in routers and hosts,
graceful support for dynamic membership changes and
adaptation to routing changes
o RSVP is not a routing protocol but depends upon present
future routing protocols
o RSVP transports and maintains traffic control and policy
parameters that are opaque to RSVP
Braden, Ed., et. al. Standards Track [Page 6]
RFC 2205 RSVP September 1997
o RSVP provides several reservation models or "styles" (
below) to fit a variety of applications
o RSVP provides transparent operation through routers that do
support it
o RSVP supports both IPv4 and IPv6.
Further discussion on the objectives and general justification
RSVP design are presented in [RSVP93] and [RFC 1633].
The remainder of this section describes the RSVP
services. Section 2 presents an overview of the RSVP
mechanisms. Section 3 contains the functional specification of RSVP
while Section 4 presents explicit message processing rules.
A defines the variable-length typed data objects used in the
protocol. Appendix B defines error codes and values. Appendix
defines a UDP encapsulation of RSVP messages, for hosts
operating systems provide inadequate raw network I/O support
1.1 Data
RSVP defines a "session" to be a data flow with a
destination and transport-layer protocol. RSVP treats
session independently, and this document often omits the
qualification "for the same session".
An RSVP session is defined by the triple: (DestAddress,
[, DstPort]). Here DestAddress, the IP destination address of
data packets, may be a unicast or multicast address.
is the IP protocol ID. The optional DstPort parameter is
"generalized destination port", i.e., some further
point in the transport or application protocol layer.
could be defined by a UDP/TCP destination port field, by
equivalent field in another transport protocol, or by
application-specific information
Although the RSVP protocol is designed to be easily extensible
greater generality, the basic protocol documented here
only UDP/TCP ports as generalized ports. Note that it is
strictly necessary to include DstPort in the session
when DestAddress is multicast, since different sessions can
have different multicast addresses. However, DstPort is
to allow more than one unicast session addressed to the
receiver host
Braden, Ed., et. al. Standards Track [Page 7]
RFC 2205 RSVP September 1997
Figure 2 illustrates the flow of data packets in a single
session, assuming multicast data distribution. The
indicate data flowing from senders S1 and S2 to receivers R1, R2,
and R3, and the cloud represents the distribution mesh created
multicast routing. Multicast distribution forwards a copy of
data packet from a sender Si to every receiver Rj; a
distribution session has a single receiver R. Each sender Si
be running in a unique Internet host, or a single host may
multiple senders distinguished by "generalized source ports".
Senders
_____________________
( ) ===> R
S1 ===> ( Multicast )
( ) ===> R
( distribution )
S2 ===> ( )
( by Internet ) ===> R
(_____________________)
Figure 2: Multicast Distribution
For unicast transmission, there will be a single destination
but there may be multiple senders; RSVP can set up
for multipoint-to-single-point transmission
1.2 Reservation
An elementary RSVP reservation request consists of a "flowspec
together with a "filter spec"; this pair is called a "
descriptor". The flowspec specifies a desired QoS. The
spec, together with a session specification, defines the set
data packets -- the "flow" -- to receive the QoS defined by
flowspec. The flowspec is used to set parameters in the node'
packet scheduler or other link layer mechanism, while the
spec is used to set parameters in the packet classifier.
packets that are addressed to a particular session but do
match any of the filter specs for that session are handled
best-effort traffic
The flowspec in a reservation request will generally include
service class and two sets of numeric parameters: (1) an "Rspec
(R for `reserve') that defines the desired QoS, and (2) a "Tspec
(T for `traffic') that describes the data flow. The formats
contents of Tspecs and Rspecs are determined by the
service models [RFC 2210] and are generally opaque to RSVP
Braden, Ed., et. al. Standards Track [Page 8]
RFC 2205 RSVP September 1997
The exact format of a filter spec depends upon whether IPv4
IPv6 is in use; see Appendix A. In the most general
[RSVP93], filter specs may select arbitrary subsets of the
in a given session. Such subsets might be defined in terms
senders (i.e., sender IP address and generalized source port),
terms of a higher-level protocol, or generally in terms of
fields in any protocol headers in the packet. For example,
specs might be used to select different subflows of
hierarchically-encoded video stream by selecting on fields in
application-layer header. In the interest of simplicity (and
minimize layer violation), the basic filter spec format defined
the present RSVP specification has a very restricted form:
IP address and optionally the UDP/TCP port number SrcPort
Because the UDP/TCP port numbers are used for
classification, each router must be able to examine these fields
This raises three potential problems
1. It is necessary to avoid IP fragmentation of a data flow
which a resource reservation is desired
Document [RFC 2210] specifies a procedure for
using RSVP facilities to compute the minimum MTU over
multicast tree and return the result to the senders
2. IPv6 inserts a variable number of variable-length Internet
layer headers before the transport header, increasing
difficulty and cost of packet classification for QoS
Efficient classification of IPv6 data packets could
obtained using the Flow Label field of the IPv6 header.
details will be provided in the future
3. IP-level Security, under either IPv4 or IPv6, may encrypt
entire transport header, hiding the port numbers of
packets from intermediate routers
A small extension to RSVP for IP Security under IPv4 and IPv
is described separately in [RFC 2207].
RSVP messages carrying reservation requests originate at
and are passed upstream towards the sender(s). Note: in
document, we define the directional terms "upstream" vs
"downstream", "previous hop" vs. "next hop", and "
interface" vs "outgoing interface" with respect to the
of data flow
Braden, Ed., et. al. Standards Track [Page 9]
RFC 2205 RSVP September 1997
At each intermediate node, a reservation request triggers
general actions, as follows
1. Make a reservation on a
The RSVP process passes the request to admission control
policy control. If either test fails, the reservation
rejected and the RSVP process returns an error message to
appropriate receiver(s). If both succeed, the node sets
packet classifier to select the data packets defined by
filter spec, and it interacts with the appropriate link
to obtain the desired QoS defined by the flowspec
The detailed rules for satisfying an RSVP QoS request
upon the particular link layer technology in use on
interface. Specifications are under development in the
Working Group for mapping reservation requests into
link layer technologies. For a simple leased line,
desired QoS will be obtained from the packet scheduler in
link layer driver, for example. If the link-layer
implements its own QoS management capability, then RSVP
negotiate with the link layer to obtain the requested QoS
Note that the action to control QoS occurs at the place
the data enters the link-layer medium, i.e., at the
end of the logical or physical link, although an
reservation request originates from receiver(s) downstream
2. Forward the request
A reservation request is propagated upstream towards
appropriate senders. The set of sender hosts to which
given reservation request is propagated is called the "scope
of that request
The reservation request that a node forwards upstream
differ from the request that it received from downstream,
two reasons. The traffic control mechanism may modify
flowspec hop-by-hop. More importantly, reservations
different downstream branches of the multicast tree(s)
the same sender (or set of senders) must be " merged"
reservations travel upstream
When a receiver originates a reservation request, it can
request a confirmation message to indicate that its request
(probably) installed in the network. A successful
request propagates upstream along the multicast tree until
reaches a point where an existing reservation is equal or
Braden, Ed., et. al. Standards Track [Page 10]
RFC 2205 RSVP September 1997
than that being requested. At that point, the arriving request
merged with the reservation in place and need not be
further; the node may then send a reservation confirmation
back to the receiver. Note that the receipt of a confirmation
only a high-probability indication, not a guarantee, that
requested service is in place all the way to the sender(s),
explained in Section 2.6.
The basic RSVP reservation model is "one pass": a receiver sends
reservation request upstream, and each node in the path
accepts or rejects the request. This scheme provides no easy
for a receiver to find out the resulting end-to-end service
Therefore, RSVP supports an enhancement to one-pass service
as "One Pass With Advertising" (OPWA) [OPWA95]. With OPWA,
control packets are sent downstream, following the data paths,
gather information that may be used to predict the end-to-end QoS
The results ("advertisements") are delivered by RSVP to
receiver hosts and perhaps to the receiver applications.
advertisements may then be used by the receiver to construct,
to dynamically adjust, an appropriate reservation request
1.3 Reservation
A reservation request includes a set of options that
collectively called the reservation "style".
One reservation option concerns the treatment of reservations
different senders within the same session: establish a "distinct
reservation for each upstream sender, or else make a
reservation that is "shared" among all packets of
senders
Another reservation option controls the selection of senders;
may be an "explicit" list of all selected senders, or a "wildcard
that implicitly selects all the senders to the session. In
explicit sender-selection reservation, each filter spec must
exactly one sender, while in a wildcard sender-selection no
spec is needed
Braden, Ed., et. al. Standards Track [Page 11]
RFC 2205 RSVP September 1997
Sender || Reservations
Selection || Distinct |
_________||__________________|____________________
|| | |
Explicit || Fixed-Filter | Shared-Explicit |
|| (FF) style | (SE) Style |
__________||__________________|____________________|
|| | |
Wildcard || (None defined) | Wildcard-Filter |
|| | (WF) Style |
__________||__________________|____________________|
Figure 3: Reservation Attributes and
The following styles are currently defined (see Figure 3):
o Wildcard-Filter (WF)
The WF style implies the options: "shared" reservation
"wildcard" sender selection. Thus, a WF-style
creates a single reservation shared by flows from
upstream senders. This reservation may be thought of as
shared "pipe", whose "size" is the largest of the
requests from all receivers, independent of the number
senders using it. A WF-style reservation is
upstream towards all sender hosts, and it
extends to new senders as they appear
Symbolically, we can represent a WF-style reservation
by
WF( * {Q})
where the asterisk represents wildcard sender selection and
represents the flowspec
o Fixed-Filter (FF)
The FF style implies the options: "distinct" reservations
"explicit" sender selection. Thus, an elementary FF-
reservation request creates a distinct reservation for
packets from a particular sender, not sharing them with
senders' packets for the same session
Braden, Ed., et. al. Standards Track [Page 12]
RFC 2205 RSVP September 1997
Symbolically, we can represent an elementary FF
request by
FF( S{Q})
where S is the selected sender and Q is the
flowspec; the pair forms a flow descriptor. RSVP
multiple elementary FF-style reservations to be requested
the same time, using a list of flow descriptors
FF( S1{Q1}, S2{Q2}, ...)
The total reservation on a link for a given session is
`sum' of Q1, Q2, ... for all requested senders
o Shared Explicit (SE)
The SE style implies the options: "shared" reservation
"explicit" sender selection. Thus, an SE-style
creates a single reservation shared by selected
senders. Unlike the WF style, the SE style allows a
to explicitly specify the set of senders to be included
We can represent an SE reservation request containing
flowspec Q and a list of senders S1, S2, ... by
SE( (S1,S2,...){Q} )
Shared reservations, created by WF and SE styles, are
for those multicast applications in which multiple data
are unlikely to transmit simultaneously. Packetized audio is
example of an application suitable for shared reservations;
a limited number of people talk at once, each receiver might
a WF or SE reservation request for twice the bandwidth
for one sender (to allow some over-speaking). On the other hand
the FF style, which creates distinct reservations for the
from different senders, is appropriate for video signals
The RSVP rules disallow merging of shared reservations
distinct reservations, since these modes are
incompatible. They also disallow merging explicit
selection with wildcard sender selection, since this might
an unexpected service for a receiver that specified
selection. As a result of these prohibitions, WF, SE, and
styles are all mutually incompatible
Braden, Ed., et. al. Standards Track [Page 13]
RFC 2205 RSVP September 1997
It would seem possible to simulate the effect of a WF
using the SE style. When an application asked for WF, the
process on the receiver host could use local state to create
equivalent SE reservation that explicitly listed all senders
However, an SE reservation forces the packet classifier in
node to explicitly select each sender in the list, while a
allows the packet classifier to simply "wild card" the
address and port. When there is a large list of senders, a
style reservation can therefore result in considerably
overhead than an equivalent SE style reservation. For
reason, both SE and WF are included in the protocol
Other reservation options and styles may be defined in the future
1.4 Examples of
This section presents examples of each of the reservation
and shows the effects of merging
Figure 4 illustrates a router with two incoming interfaces
labeled (a) and (b), through which flows will arrive, and
outgoing interfaces, labeled (c) and (d), through which data
be forwarded. This topology will be assumed in the examples
follow. There are three upstream senders; packets from sender S
(S2 and S3) arrive through previous hop (a) ((b), respectively).
There are also three downstream receivers; packets bound for R
(R2 and R3) are routed via outgoing interface (c) ((d),
respectively). We furthermore assume that outgoing interface (d
is connected to a broadcast LAN, i.e., that replication occurs
the network; R2 and R3 are reached via different next hop
(not shown).
We must also specify the multicast routes within the node
Figure 4. Assume first that data packets from each Si shown
Figure 4 are routed to both outgoing interfaces. Under
assumption, Figures 5, 6, and 7 illustrate Wildcard-Filter
Fixed-Filter, and Shared-Explicit reservations, respectively
Braden, Ed., et. al. Standards Track [Page 14]
RFC 2205 RSVP September 1997
________________
(a)| | (c
( S1 ) ---------->| |----------> ( R1 )
| Router | |
(b)| | (d) |---> ( R2 )
( S2,S3 ) ------->| |------|
|________________| |---> ( R3 )
|
Figure 4: Router
For simplicity, these examples show flowspecs as one-
multiples of some base resource quantity B. The "Receives"
shows the RSVP reservation requests received over
interfaces (c) and (d), and the "Reserves" column shows
resulting reservation state for each interface. The "Sends
column shows the reservation requests that are sent upstream
previous hops (a) and (b). In the "Reserves" column, each
represents one reserved "pipe" on the outgoing link, with
corresponding flow descriptor
Figure 5, showing the WF style, illustrates two
situations in which merging is required. (1) Each of the two
hops on interface (d) results in a separate RSVP
request, as shown; these two requests must be merged into
effective flowspec, 3B, that is used to make the reservation
interface (d). (2) The reservations on the interfaces (c) and (d
must be merged in order to forward the reservation
upstream; as a result, the larger flowspec 4B is
upstream to each previous hop
Braden, Ed., et. al. Standards Track [Page 15]
RFC 2205 RSVP September 1997
|
Sends | Reserves
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{4B} ) <- (b) | (d) | * {3B}| (d) <- WF( *{3B} )
| |_______| <- WF( *{2B} )
Figure 5: Wildcard-Filter (WF) Reservation
Figure 6 shows Fixed-Filter (FF) style reservations. For
outgoing interface, there is a separate reservation for
source that has been requested, but this reservation will
shared among all the receivers that made the request. The
descriptors for senders S2 and S3, received through
interfaces (c) and (d), are packed (not merged) into the
forwarded to previous hop (b). On the other hand, the
different flow descriptors specifying sender S1 are merged
the single request FF( S1{4B} ) that is sent to previous hop (a).
|
Sends | Reserves
|
| ________
FF( S1{4B} ) <- (a) | (c) | S1{4B} | (c) <- FF( S1{4B}, S2{5B} )
| |________|
| | S2{5B} |
| |________|
---------------------|---------------------------------------------
| ________
<- (b) | (d) | S1{3B} | (d) <- FF( S1{3B}, S3{B} )
FF( S2{5B}, S3{B} ) | |________| <- FF( S1{B} )
| | S3{B} |
| |________|
Figure 6: Fixed-Filter (FF) Reservation
Braden, Ed., et. al. Standards Track [Page 16]
RFC 2205 RSVP September 1997
Figure 7 shows an example of Shared-Explicit (SE)
reservations. When SE-style reservations are merged,
resulting filter spec is the union of the original filter specs
and the resulting flowspec is the largest flowspec
|
Sends | Reserves
|
| ________
SE( S1{3B} ) <- (a) | (c) |(S1,S2) | (c) <- SE( (S1,S2){B} )
| | {B} |
| |________|
---------------------|---------------------------------------------
| __________
<- (b) | (d) |(S1,S2,S3)| (d) <- SE( (S1,S3){3B} )
SE( (S2,S3){3B} ) | | {3B} | <- SE( S2{2B} )
| |__________|
Figure 7: Shared-Explicit (SE) Reservation
The three examples just shown assume that data packets from S1,
S2, and S3 are routed to both outgoing interfaces. The top
of Figure 8 shows another routing assumption: data packets from S
and S3 are not forwarded to interface (c), e.g., because
network topology provides a shorter path for these senders
R1, not traversing this node. The bottom part of Figure 8
WF style reservations under this assumption. Since there is
route from (b) to (c), the reservation forwarded out interface (b
considers only the reservation on interface (d).
Braden, Ed., et. al. Standards Track [Page 17]
RFC 2205 RSVP September 1997
_______________
(a)| | (c
( S1 ) ---------->| >-----------> |----------> ( R1 )
| > |
| > |
(b)| > | (d
( S2,S3 ) ------->| >-------->--> |----------> ( R2, R3 )
|_______________|
Router
|
Sends | Reserves
|
| _______
WF( *{4B} ) <- (a) | (c) | * {4B}| (c) <- WF( *{4B} )
| |_______|
|
-----------------------|----------------------------------------
| _______
WF( *{3B} ) <- (b) | (d) | * {3B}| (d) <- WF( * {3B} )
| |_______| <- WF( * {2B} )
Figure 8: WF Reservation Example -- Partial
Braden, Ed., et. al. Standards Track [Page 18]
RFC 2205 RSVP September 1997
2. RSVP Protocol
2.1 RSVP
Previous Incoming Outgoing
Hops Interfaces Interfaces
_____ _____________________ _____
| | data --> | | data --> | |
| A |-----------| a c |--------------| C |
|_____| Path --> | | Path --> |_____|
<-- Resv | | <-- Resv _____
_____ | ROUTER | | | |
| | | | | |--| D |
| B |--| data-->| | data --> | |_____|
|_____| |--------| b d |-----------|
| Path-->| | Path --> | _____
_____ | <--Resv|_____________________| <-- Resv | | |
| | | |--| D' |
| B' |--| | |_____|
|_____| | |
Figure 9: Router Using
Figure 9 illustrates RSVP's model of a router node. Each
flow arrives from a "previous hop" through a
"incoming interface" and departs through one or more "
interface"(s). The same interface may act in both the
and outgoing roles for different data flows in the same session
Multiple previous hops and/or next hops may be reached through
given physical interface; for example, the figure implies that
and D' are connected to (d) with a broadcast LAN
There are two fundamental RSVP message types: Resv and Path
Each receiver host sends RSVP reservation request (Resv)
upstream towards the senders. These messages must follow
the reverse of the path(s) the data packets will use, upstream
all the sender hosts included in the sender selection.
create and maintain "reservation state" in each node along
path(s). Resv messages must finally be delivered to the
hosts themselves, so that the hosts can set up appropriate
control parameters for the first hop. The processing of
messages was discussed previously in Section 1.2.
Braden, Ed., et. al. Standards Track [Page 19]
RFC 2205 RSVP September 1997
Each RSVP sender host transmits RSVP "Path" messages
along the uni-/multicast routes provided by the
protocol(s), following the paths of the data. These Path
store "path state" in each node along the way. This path
includes at least the unicast IP address of the previous hop node
which is used to route the Resv messages hop-by-hop in the
direction. (In the future, some routing protocols may
reverse path forwarding information directly, replacing
reverse-routing function of path state).
A Path message contains the following information in addition
the previous hop address
o Sender
A Path message is required to carry a Sender Template,
describes the format of data packets that the sender
originate. This template is in the form of a filter
that could be used to select this sender's packets
others in the same session on the same link
Sender Templates have exactly the same expressive power
format as filter specs that appear in Resv messages
Therefore a Sender Template may specify only the sender
address and optionally the UDP/TCP sender port, and
assumes the protocol Id specified for the session
o Sender
A Path message is required to carry a Sender Tspec,
defines the traffic characteristics of the data flow that
sender will generate. This Tspec is used by traffic
to prevent over-reservation, and perhaps
Admission Control failures
o
A Path message may carry a package of OPWA
information, known as an "Adspec". An Adspec received in
Path message is passed to the local traffic control,
returns an updated Adspec; the updated version is
forwarded in Path messages sent downstream
Braden, Ed., et. al. Standards Track [Page 20]
RFC 2205 RSVP September 1997
Path messages are sent with the same source and
addresses as the data, so that they will be routed
through non-RSVP clouds (see Section 2.9). On the other hand
Resv messages are sent hop-by-hop; each RSVP-speaking
forwards a Resv message to the unicast address of a previous
hop
2.2 Merging
A Resv message forwarded to a previous hop carries a flowspec
is the "largest" of the flowspecs requested by the next hops
which the data flow will be sent (however, see Section 3.5 for
different merging rule used in certain cases). We say
flowspecs have been "merged". The examples shown in Section 1.4
illustrated another case of merging, when there are
reservation requests from different next hops for the same
and with the same filter spec, but RSVP should install only
reservation on that interface. Here again, the
reservation should have an effective flowspec that is
"largest" of the flowspecs requested by the different next hops
Since flowspecs are opaque to RSVP, the actual rules for
flowspecs must be defined and implemented outside RSVP proper
The comparison rules are defined in the appropriate
service specification document. An RSVP implementation will
to call service-specific routines to perform flowspec merging
Note that flowspecs are generally multi-dimensional vectors;
may contain both Tspec and Rspec components, each of which
itself be multi-dimensional. Therefore, it may not be possible
strictly order two flowspecs. For example, if one request
for a higher bandwidth and another calls for a tighter
bound, one is not "larger" than the other. In such a case
instead of taking the larger, the service-specific
routines must be able to return a third flowspec that is at
as large as each; mathematically, this is the "least upper bound
(LUB). In some cases, a flowspec at least as small is needed
this is the "greatest lower bound" (GLB) GLB (Greatest
Bound).
The following steps are used to calculate the effective
(Re, Te) to be installed on an interface [RFC 2210]. Here Te
the effective Tspec and Re is the effective Rspec
Braden, Ed., et. al. Standards Track [Page 21]
RFC 2205 RSVP September 1997
1. An effective flowspec is determined for the
interface. Depending upon the link-layer technology,
may require merging flowspecs from different next hops;
means computing the effective flowspec as the LUB of
flowspecs. Note that what flowspecs to merge is
by the link layer medium (see Section 3.11.2), while how
merge them is determined by the service model in use [
2210].
The result is a flowspec that is opaque to RSVP but
consists of the pair (Re, Resv_Te), where is Re is
effective Rspec and Resv_Te is the effective Tspec
2. A service-specific calculation of Path_Te, the sum of
Tspecs that were supplied in Path messages from
previous hops (e.g., some or all of A, B, and B' in
9), is performed
3. (Re, Resv_Te) and Path_Te are passed to traffic control
Traffic control will compute the effective flowspec as
"minimum" of Path_Te and Resv_Te, in a service-
manner
Section 3.11.6 defines a generic set of service-specific calls
compare flowspecs, to compute the LUB and GLB of flowspecs, and
compare and sum Tspecs
2.3 Soft
RSVP takes a "soft state" approach to managing the
state in routers and hosts. RSVP soft state is created
periodically refreshed by Path and Resv messages. The state
deleted if no matching refresh messages arrive before
expiration of a "cleanup timeout" interval. State may also
deleted by an explicit "teardown" message, described in the
section. At the expiration of each "refresh timeout" period
after a state change, RSVP scans its state to build and
Path and Resv refresh messages to succeeding hops
Path and Resv messages are idempotent. When a route changes,
next Path message will initialize the path state on the new route
and future Resv messages will establish reservation state there
the state on the now-unused segment of the route will time out
Thus, whether a message is "new" or a "refresh" is
separately at each node, depending upon the existence of state
that node
Braden, Ed., et. al. Standards Track [Page 22]
RFC 2205 RSVP September 1997
RSVP sends its messages as IP datagrams with no
enhancement. Periodic transmission of refresh messages by
and routers is expected to handle the occasional loss of an
message. If the effective cleanup timeout is set to K times
refresh timeout period, then RSVP can tolerate K-1 successive
packet losses without falsely deleting state. The network
control mechanism should be statically configured to grant
minimal bandwidth for RSVP messages to protect them
congestion losses
The state maintained by RSVP is dynamic; to change the set
senders Si or to change any QoS request, a host simply
sending revised Path and/or Resv messages. The result will be
appropriate adjustment in the RSVP state in all nodes along
path; unused state will time out if it is not explicitly
down
In steady state, state is refreshed hop-by-hop to allow merging
When the received state differs from the stored state, the
state is updated. If this update results in modification of
to be forwarded in refresh messages, these refresh messages
be generated and forwarded immediately, so that state changes
be propagated end-to-end without delay. However, propagation of
change stops when and if it reaches a point where merging
no resulting state change. This minimizes RSVP control
due to changes and is essential for scaling to large
groups
State that is received through a particular interface I*
never be forwarded out the same interface. Conversely, state
is forwarded out interface I* must be computed using only
that arrived on interfaces different from I*. A trivial
of this rule is illustrated in Figure 10, which shows a
router with one sender and one receiver on each interface (
assumes one next/previous hop per interface). Interfaces (a)
(c) serve as both outgoing and incoming interfaces for
session. Both receivers are making wildcard-style reservations
in which the Resv messages are forwarded to all previous hops
senders in the group, with the exception of the next hop
which they came. The result is independent reservations in
two directions
There is an additional rule governing the forwarding of
messages: state from Resv messages received from
interface Io should be forwarded to incoming interface Ii only
Path messages from Ii are forwarded to Io
Braden, Ed., et. al. Standards Track [Page 23]
RFC 2205 RSVP September 1997
________________
a | |
( R1, S1 ) <----->| Router |<-----> ( R2, S2 )
|________________|
Send |
|
WF( *{3B}) <-- (a) | (c) <-- WF( *{3B})
|
Receive |
|
WF( *{4B}) --> (a) | (c) --> WF( *{4B})
|
Reserve on (a) | Reserve on (c
__________ | __________
| * {4B} | | | * {3B} |
|__________| | |__________|
|
Figure 10: Independent
2.4
RSVP "teardown" messages remove path or reservation
immediately. Although it is not necessary to explicitly tear
an old reservation, we recommend that all end hosts send
teardown request as soon as an application finishes
There are two types of RSVP teardown message, PathTear
ResvTear. A PathTear message travels towards all
downstream from its point of initiation and deletes path state,
well as all dependent reservation state, along the way.
ResvTear message deletes reservation state and travels towards
senders upstream from its point of initiation. A
(ResvTear) message may be conceptualized as a reversed-sense
message (Resv message, respectively).
A teardown request may be initiated either by an application in
end system (sender or receiver), or by a router as the result
state timeout or service preemption. Once initiated, a
request must be forwarded hop-by-hop without delay. A
message deletes the specified state in the node where it
received. As always, this state change will be
immediately to the next node, but only if there will be a
change after merging. As a result, a ResvTear message will
the reservation state back (only) as far as possible
Braden, Ed., et. al. Standards Track [Page 24]
RFC 2205 RSVP September 1997
Like all other RSVP messages, teardown requests are not
reliably. The loss of a teardown request message will not cause
protocol failure because the unused state will eventually time
even though it is not explicitly deleted. If a teardown
is lost, the router that failed to receive that message will
out its state and initiate a new teardown message beyond the
point. Assuming that RSVP message loss probability is small,
longest time to delete state will seldom exceed one
timeout period
It should be possible to tear down any subset of the
state. For path state, the granularity for teardown is a
sender. For reservation state, the granularity is an
filter spec. For example, refer to Figure 7. Receiver R1
send a ResvTear message for sender S2 only (or for any subset
the filter spec list), leaving S1 in place
A ResvTear message specifies the style and filters; any
is ignored. Whatever flowspec is in place will be removed if
its filter specs are torn down
2.5
There are two RSVP error messages, ResvErr and PathErr.
messages are very simple; they are simply sent upstream to
sender that created the error, and they do not change path
in the nodes though which they pass. There are only a
possible causes of path errors
However, there are a number of ways for a syntactically
reservation request to fail at some node along the path. A
may also decide to preempt an established reservation.
handling of ResvErr messages is somewhat complex (Section 3.5).
Since a request that fails may be the result of merging a
of requests, a reservation error must be reported to all of
responsible receivers. In addition, merging
requests creates a potential difficulty known as the "
reservation" problem, in which one request could deny service
another. There are actually two killer-reservation problems
1. The first killer reservation problem (KR-I) arises when
is already a reservation Q0 in place. If another
now makes a larger reservation Q1 > Q0, the result of
Q0 and Q1 may be rejected by admission control in
upstream node. This must not deny service to Q0.
Braden, Ed., et. al. Standards Track [Page 25]
RFC 2205 RSVP September 1997
The solution to this problem is simple: when
control fails for a reservation request, any
reservation is left in place
2. The second killer reservation problem (KR-II) is
converse: the receiver making a reservation Q1 is
even though Admission Control is failing for Q1 in some node
This must not prevent a different receiver from
establishing a smaller reservation Q0 that would succeed
not merged with Q1.
To solve this problem, a ResvErr message
additional state, called "blockade state", in each
through which it passes. Blockade state in a node
the merging procedure to omit the offending flowspec (Q1
the example) from the merge, allowing a smaller request to
forwarded and established. The Q1 reservation state is
to be "blockaded". Detailed rules are presented in
3.5.
A reservation request that fails Admission Control
blockade state but is left in place in nodes downstream of
failure point. It has been suggested that these
downstream from the failure represent "wasted" reservations
should be timed out if not actively deleted. However,
downstream reservations are left in place, for the
reasons
o There are two possible reasons for a receiver persisting in
failed reservation: (1) it is polling for
availability along the entire path, or (2) it wants to
the desired QoS along as much of the path as possible
Certainly in the second case, and perhaps in the first case
the receiver will want to hold onto the reservations it
made downstream from the failure
o If these downstream reservations were not retained,
responsiveness of RSVP to certain transient failures would
impaired. For example, suppose a route "flaps" to
alternate route that is congested, so an existing
suddenly fails, then quickly recovers to the original route
The blockade state in each downstream router must not
the state or prevent its immediate refresh
o If we did not refresh the downstream reservations, they
time out, to be restored every Tb seconds (where Tb is
blockade state timeout interval). Such intermittent
might be very distressing for users
Braden, Ed., et. al. Standards Track [Page 26]
RFC 2205 RSVP September 1997
2.6
To request a confirmation for its reservation request, a
Rj includes in the Resv message a confirmation-request
containing Rj's IP address. At each merge point, only the
flowspec and any accompanying confirmation-request object
forwarded upstream. If the reservation request from Rj is
to or smaller than the reservation in place on a node, its Resv
not forwarded further, and if the Resv included a confirmation
request object, a ResvConf message is sent back to Rj. If
confirmation request is forwarded, it is forwarded immediately
and no more than once for each request
This confirmation mechanism has the following consequences
o A new reservation request with a flowspec larger than any
place for a session will normally result in either a
or a ResvConf message back to the receiver from each sender
In this case, the ResvConf message will be an end-to-
confirmation
o The receipt of a ResvConf gives no guarantees. Assume
first two reservation requests from receivers R1 and R
arrive at the node where they are merged. R2,
reservation was the second to arrive at that node,
receive a ResvConf from that node while R1's request has
yet propagated all the way to a matching sender and may
fail. Thus, R2 may receive a ResvConf although there is
end-to-end reservation in place; furthermore, R2 may
a ResvConf followed by a ResvErr
2.7 Policy
RSVP-mediated QoS requests allow particular user(s) to
preferential access to network resources. To prevent abuse,
form of back pressure will generally be required on users who
reservations. For example, such back pressure may be
by administrative access policies, or it may depend upon some
of user feedback such as real or virtual billing for the "cost"
a reservation. In any case, reliable user identification
selective admission will generally be needed when a reservation
requested
The term "policy control" is used for the mechanisms required
support access policies and back pressure for RSVP reservations
When a new reservation is requested, each node must answer
questions: "Are enough resources available to meet this request?"
Braden, Ed., et. al. Standards Track [Page 27]
RFC 2205 RSVP September 1997
and "Is this user allowed to make this reservation?" These
decisions are termed the "admission control" decision and
"policy control" decision, respectively, and both must
favorable in order for RSVP to make a reservation.
administrative domains in the Internet may have
reservation policies
The input to policy control is referred to as "policy data",
RSVP carries in POLICY_DATA objects. Policy data may
credentials identifying users or user classes, account numbers
limits, quotas, etc. Like flowspecs, policy data is opaque
RSVP, which simply passes it to policy control when required
Similarly, merging of policy data must be done by the
control mechanism rather than by RSVP itself. Note that the
points for policy data are likely to be at the boundaries
administrative domains. It may therefore be necessary to
accumulated and unmerged policy data upstream through
nodes before reaching one of these merge points
Carrying user-provided policy data in Resv messages presents
potential scaling problem. When a multicast group has a
number of receivers, it will be impossible or undesirable to
all receivers' policy data upstream. The policy data will have
be administratively merged at places near the receivers, to
excessive policy data. Further discussion of these issues and
example of a policy control scheme will be found in [PolArch96].
Specifications for the format of policy data objects and
processing rules for them are under development
2.8
RSVP raises the following security issues
o Message integrity and node
Corrupted or spoofed reservation requests could lead to
of service by unauthorized parties or to denial of
caused by locking up network resources. RSVP
against such attacks with a hop-by-hop
mechanism using an encrypted hash function. The mechanism
supported by INTEGRITY objects that may appear in any
message. These objects use a keyed cryptographic
technique, which assumes that RSVP neighbors share a secret
Although this mechanism is part of the base
specification, it is described in a companion
[Baker96].
Braden, Ed., et. al. Standards Track [Page 28]
RFC 2205 RSVP September 1997
Widespread use of the RSVP integrity mechanism will
the availability of the long-sought key management
distribution infrastructure for routers. Until
infrastructure becomes available, manual key management
be required to secure RSVP message integrity
o User
Policy control will depend upon positive authentication
the user responsible for each reservation request.
data may therefore include cryptographically protected
certificates. Specification of such certificates is a
issue
Even without globally-verifiable user certificates, it may
possible to provide practical user authentication in
cases by establishing a chain of trust, using the hop-by-
INTEGRITY mechanism described earlier
o Secure data
The first two security issues concerned RSVP's operation.
third security issue concerns resource reservations
secure data streams. In particular, the use of IPSEC (
Security) in the data stream poses a problem for RSVP:
the transport and higher level headers are encrypted, RSVP'
generalized port numbers cannot be used to define a
or a sender
To solve this problem, an RSVP extension has been defined
which the security association identifier (IPSEC SPI) plays
role roughly equivalent to the generalized ports [RFC 2207].
2.9 Non-RSVP
It is impossible to deploy RSVP (or any new protoco