The Resource Reservation Protocol is a Transport Layer protocol designed to
reserve resources across a network for an integrated services Internet. RSVP
operates over an IPv4 or IPv6 Internet Layer and provides receiver-initiated
setup of resource reservations for multicast or unicast data flows with
scaling and robustness. It does not transport application data but is
similar to a control protocol, like Internet Control Message Protocol or
Internet Group Management Protocol. RSVP is described in RFC 2205.
RSVP can be used by either hosts or routers to request or deliver specific
levels of quality of service for application data streams or flows. RSVP
defines how applications place reservations and how they can relinquish
the reserved resources once the need for them has ended. RSVP operation will
generally result in resources being reserved in each node along a path.
RSVP is not a routing protocol and was designed to interoperate with current
and future routing protocols. RSVP by itself is rarely deployed in
telecommunications networks today but the traffic engineering extension of
RSVP, or RSVP-TE, is becoming more widely accepted nowadays in many
QoS-oriented networks. Next Steps in Signaling is a replacement for RSVP.
Main attributes RSVP requests resources for simplex
flows: a traffic stream in only one direction from sender to one or more
receivers. RSVP is not a routing protocol but works
with current and future routing protocols.
RSVP is receiver oriented: in that the receiver of a data flow initiates and
maintains the resource reservation for that flow.
RSVP maintains "soft state" of the host and routers' resource reservations,
hence supporting dynamic automatic adaptation to network changes.
RSVP provides several reservation styles and allows for future styles to be added
to protocol revisions to fit varied applications.
RSVP transports and maintains traffic and policy control parameters that are
opaque to RSVP. History and related standards
The basic concepts of RSVP were originally proposed in [RSVP93].
RSVP is described in a series of RFC documents from the IETF:
RFC 2205: The version 1 functional specification was described in RFC 2205
by IETF. Version 1 describes the interface to admission control that is
based "only" on resource availability. Later RFC2750 extended the admission
control support. RFC 2210 defines the use of RSVP with
controlled-load RFC 2211 and guaranteed RFC 2212 QoS control services. More
details in Integrated Services. Also defines the usage and data format of the
data objects defined by RSVP in RFC 2205.
RFC 2211 specifies the network element behavior required to deliver
Controlled-Load services. RFC 2212 specifies the network element
behavior required to deliver guaranteed QoS services.
RFC 2750 describes a proposed extension for supporting generic policy based
admission control in RSVP. The extension included a specification of policy
objects and a description on handling policy events..
RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels".
RFC 3473, "Generalized Multi-Protocol Label Switching Signaling Resource
ReserVation Protocol-Traffic Engineering Extensions".
RFC 3936, "Procedures for Modifying the Resource reSerVation Protocol",
describes current best practices and specifies procedures for modifying RSVP.
RFC 4495, "A Resource Reservation Protocol Extension for the Reduction of
Bandwidth of a Reservation Flow", extends RSVP to enable the bandwidth of
an existing reservation to be reduced instead of tearing down the reservation.
RFC 4558, "Node-ID Based Resource Reservation Protocol Hello: A
Clarification Statement". Key concepts
The two key concepts of RSVP reservation model are flowspec and filterspec:
= Flowspec = RSVP reserves resources for a flow. A
flow is identified by the destination address, the protocol identifier, and,
optionally, the destination port. In multiprotocol label switching a flow is
defined as a label switched path. For each flow RSVP also identifies the
particular quality of service required by the flow although it does not
understand the specific information of the flow QoS. This QoS specific
information is called a flowspec and RSVP passes the flowspec from the
application to the hosts and routers along the path. Those systems then
analyse the flowspec to accept and reserve the resources. A flowspec
consists of: Service class
Reservation spec - defines the QoS Traffic spec - describes the data flow
= Filterspec = The filterspec defines the set of
packets that shall be affected by a flowspec. A filterspec typically selects
a subset of all the packets processed by a node. The selection can depend on any
attribute of a packet. The currently defined RSVP reservation
styles are: Fixed filter - reserves resources for a
specific flow. Shared explicit - reserves resources for
several flows and all share the resources
Wildcard filter - reserves resources for a general type of flow without
specifying the flow; all flows share the resources
An RSVP reservation request consists of a flowspec and a filterspec and the pair
is called a flowdescriptor. The effects at the node of each spec are that while
the flowspec sets the parameters of the packet scheduler at a node, the
filterspec sets the parameters at the packet classifier.
Messages There are two primary types of messages:
Path messages The path message is sent from the sender
host along the data path and stores the path state in each node along the path.
The path state includes the IP address of the previous node, and some data
objects: sender template to describe the format
of the sender data sender tspec to describe the traffic
characteristics of the data flow adspec that carries advertising data.
Reservation messages The resv message is sent from the
receiver to the sender host along the reverse data path. At each node the IP
destination address of the resv message will change to the address of the next
node on the reverse path and the IP source address to the address of the
previous node address on the reverse path.
The resv message includes the flowspec data object that identifies the
resources that the flow needs. The data objects on RSVP messages can be
transmitted in any order. For the complete list of RSVP messages and date
objects see RFC 2205. Operation
An RSVP host that needs to send a data flow with specific QoS will transmit an
RSVP path message every 30 seconds that will travel along the unicast or
multicast routes pre-established by the working routing protocol. If the path
message arrives at a router that does not understand RSVP, that router
forwards the message without interpreting the contents of the message
and will not reserve resources for the flow.
Those who want to listen to them send a corresponding resv message which then
traces the path backwards to the sender. The resv message contains the flow
specs. When a router receives the RSVP resv message it will:
Make a reservation based on the request parameters. For this the admission
control and policy control process the request parameters and can either
instruct the packet classifier to correctly handle the selected subset of
data packets or negotiate with the upper layer how the packet handling should be
performed. If they cannot support the reservation being requested, they send a
reject message to let the listener know about it.
Forward the request upstream. At each node the resv message flowspec can be
modified by a forwarding node. The routers then store the nature of the
flow, and also police it. This is all done in soft state, so if nothing is
heard for a certain length of time, then the reader will time out and the
reservation will be cancelled. This solves the problem if either the sender
or the receiver crash or are shut down incorrectly without first cancelling the
reservation. The individual routers may, at their option, police the traffic to
check that it conforms to the flow specs.
The resv message also has FilterSpec object; it defines the packets that will
receive the requested QoS defined in the flowspec. A simple filter spec could be
just the sender’s IP address and optionally its UDP or TCP port.
Other features Integrity - RSVP messages are appended
with a message digest created by combining the message contents and a
shared key using a message digest algorithm. The key can be distributed
and confirmed using 2 message types: integrity challenge request and
integrity challenge response. Error reporting - when a node detects an
error, an error message is generated with an error code and is propagated
upstream on the reverse path to the sender.
Information on RSVP flow - two types of diagnostic messages allow a network
operator to request the RSVP state information on a specific flow.
Diagnostic facility - An extension to the standard which allows a user to
collect information about the RSVP state along a path. RFC2745 - RSVP Diagnostic
Messages References
John Evans; Clarence Filsfils. Deploying IP and MPLS QoS for Multiservice
Networks: Theory and Practice. Morgan Kaufmann. ISBN 0-12-370549-5.
External links "Resource Reservation Protocol". Cisco.
Retrieved 2011-02-16. Naveen Joy, RSVP provides quality of
service, Network World, retrieved 2012-02-14
"RSVP Project". USC Information Science Institute. Retrieved 2011-02-16.
= RFCs = RFC 2205
RFC 2210 RFC 2211
RFC 2212