Resource Reservation Protocol

The Resource Reservation Protocol (RSVP) is a Transport Layer[1] 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 (ICMP) or Internet Group Management Protocol (IGMP). 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 (QoS) 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 (NSIS) is a replacement for RSVP.

Main attributes

  1. RSVP requests resources for simplex 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.
  3. RSVP is receiver oriented: in that the receiver of a data flow initiates and maintains the resource reservation for that flow.
  4. RSVP maintains "soft 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.
  5. RSVP provides several reservation styles (a set of reservation options) and allows for future styles to be added to protocol revisions to fit varied applications.
  6. 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] (Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, September 1993).

RSVP is described in a series of RFC documents from the IETF:

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 (MPLS) a flow is defined as a label switched path (LSP). 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:

  1. Service class
  2. Reservation spec - defines the QoS
  3. Traffic spec - describes the data flow

Filterspec

The filterspec defines the set of packets that shall be affected by a flowspec (i.e. the data packets to receive the QoS defined by the 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 (e.g. the sender IP address and port).

The currently defined RSVP reservation styles are:

  1. Fixed filter - reserves resources for a specific flow.
  2. Shared explicit - reserves resources for several flows and all share the resources
  3. 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:

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:
  1. sender template to describe the format of the sender data in the form of a Filterspec [2]
  2. sender tspec to describe the traffic characteristics of the data flow
  3. adspec that carries advertising data (see RFC 2210 for more details).
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 (short for "Reserve") 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:

  1. 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.
  2. Forward the request upstream (in the direction of the sender). At each node the resv message flowspec can be modified by a forwarding node (e.g. in the case of a multicast flow reservation the reservations requests can be merged).
  3. 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

References

  1. ↑ Garrett, Aviva; Drenan, Gary; Morris, Cris (2002). Juniper Networks Field Guide and Reference. p. 583.
  2. ↑ https://tools.ietf.org/html/rfc2205#section-2

External links

RFCs

This article is issued from Wikipedia - version of the 10/27/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.