RSVP can be used byhosts androuters to request or deliver specific levels ofquality of service (QoS) for applicationdata streams. RSVP defines how applications place reservations and how they can relinquish the reserved resources once no longer required. RSVP operations will generally result in resources being reserved in each node along a path. RSVP is not arouting protocol but was designed to interoperate with current and future routing protocols.
RSVP requests resources forsimplex flows: a traffic stream in only one direction from sender to one or more receivers.[2]
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 maintainssoft state (the reservation at each node needs a periodic refresh) of the host and routers' resource reservations, hence supporting dynamic automatic adaptation to network changes.
RSVP provides several reservation styles (a set of reservation options) and allows for future styles to be added in protocol revisions to fit varied applications.
RSVP transports and maintains traffic and policy control parameters that are opaque to RSVP.[further explanation needed]
The basic concepts of RSVP were originally proposed in 1993.[3]
RSVP is described in a series of RFC documents from the IETF:
RFC 2205: The version 1 functional specification was described in RFC 2205 (Sept. 1997) byIETF. Version 1 describes the interface to admission (traffic) control that is based "only" on resource availability. LaterRFC2750 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 inIntegrated Services. Also defines the usage and data format of the data objects (that carry resource reservation information) 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 genericpolicy based admission control in RSVP. The extension included a specification of policy objects and a description on handling policy events. (January 2000).
RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (December 2001).
RFC 3936, "Procedures for Modifying theResource reSerVationProtocol (RSVP)" (October 2004), describes current best practices and specifies procedures for modifying RSVP.
RFC 4495, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow" (May 2006), 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 (RSVP) Hello: A Clarification Statement" (June 2006).
RSVP reserves resources for a flow. A flow is identified by the destination address, the protocol identifier, and, optionally, the destination port. InMultiprotocol Label Switching (MPLS) a flow is defined as alabel-switched path (LSP). For each flow, RSVP also identifies the particularquality of service (QoS) required by the flow. This QoS information is called aflowspec and RSVP passes theflowspec from the application to the hosts and routers along the path. Those systems then analyse theflowspec to accept and reserve the resources.Aflowspec consists of:
Thefilterspec defines the set of packets that shall be affected by aflowspec (i.e., the data packets to receive the QoS defined by the flowspec). Afilterspec typically selects a subset of all the packets processed by a node. The selection can depend on any attribute of a packet (e.g., the sender IP address and port).
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 aflowspec and afilterspec and the pair is called aflowdescriptor. Theflowspec sets the parameters of the packet scheduler at a node and thefilterspec sets the parameters at the packet classifier.
Thepath message is sent from the sender host along the data path and stores thepath state in each node along the path.
Thepath state includes the IP address of the previous node, and some data objects:
sender template to describe the format of the sender data in the form of a Filterspec[4]
sender tspec to describe the traffic characteristics of the data flow
adspec that carries advertising data (see RFC 2210 for more details).
Reservation messages (resv)
Theresv message is sent from the receiver to the sender host along the reverse data path. At each node the IP destination address of theresv 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.
Theresv message includes theflowspec 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 data objects, see RFC 2205.
An RSVP host that needs to send a data flow with specific QoS will transmit an RSVPpath message every 30 seconds that will travel along the unicast or multicast routes pre-established by the working routing protocol. If thepath 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 correspondingresv (short forreserve) message, which then traces the path back to the sender. Theresv message contains aflowspec. Theresv message also has afilterspec 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. When a router receives the RSVPresv message it will:
Make a reservation based on the request parameters.Admission control processes the request parameters and can either instruct thepacket 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 be supported, a reject message is sent to let the listener know.
Forward the request upstream (in the direction of the sender). At each node theflowspec in theresv message can be modified by a forwarding node (e.g., in the case of a multicast flow reservation, the reservation requests can be merged).
The routers then store the nature of the flow and optionally set uppolicing according to the flowspec for it.
If nothing is heard for a certain length of time, the reservation will time out and will be canceled. This solves the problem if either the sender or the receiver crashes or is shut down without first canceling the reservation.
RSVP messages are appended with a message digest created by combining the message contents and a shared key using a message digest algorithm (commonlyMD5). The key can be distributed and confirmed using two message types:integrity challenge request andintegrity 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 that allows a user to collect information about the RSVP state along a path.[5]
