Resource ReSerVation Protocol---RSVP

RSVP Overview

RSVP fulfills the role of a resource reservation setup protocol in an integrated services internetwork.

RSVP is designed with the following goals in mind [ZDESZ93]:

• Accommodate heterogeneous receivers.
• Adapt to changing multicast group memberships.
• Exploit the characteristics of the resource requirements of different applications in order to utilise network resources efficiently.
• Allow receivers to switch channels.
• Adapt dynamically to changes in the underlying unicast and multicast routes.
• Control the protocol overhead so that the complexity grows less than linearly with the number of participants.
• Make the design modular to accommodate heterogeneous underlying network technologies.

The introduction to the Internet draft specifying RSVP [BZBHJ96] suggests how and by whom RSVP is employed:

''The RSVP protocol is used by a host, on behalf of an application data stream, to request a specific quality of service (QoS) from the network for particular data streams or flows. The RSVP protocol is also used by routers to deliver QoS control requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally, although not necessarily, result in resources being reserved in each node along the data path.''

Figure on page visualises how RSVP is integrated into routers and hosts.

 
Figure:  RSVP integration in host and routers.

RSVP handles receiver-initiated resource requests for simplex flows.

In order to scale well for very large, dynamically changing multicast groups, RSVP incrementally builds and destroys  soft state in each network node along the paths of a flow. That is, RSVP periodically sends refresh messages to maintain reservation state along the paths. The absence of a certain number of refresh messages automatically times out and deletes reservation state. The soft-state approach has several consequences:

• The deletion of timed-out state automatically releases resources that do not seem to be used any more.
• The QoS of a flow will automatically recover from route changes if enough capacities are available along the new paths. The state along the abandoned path will be deleted after the expiration of the time-out interval, and new reservations will be set up along the new route by the periodic refresh messages.
• Because of the periodic transmission of refresh messages, RSVP is expected to deal gracefully with occasional packet loss. Hence, no costly reliability enhancements are necessary to transmit RSVP messages.

Although RSVP is located on top of IP in the protocol stack, it is not a transport protocol but operates rather similarly to control protocols such as ICMP. RSVP is also not a routing protocol but is intended to cooperate with unicast and multicast routing protocols. The cooperation between the routing module and the RSVP module of a node allows for  local repair, which means that the routing module in a network node notifies the RSVP module of route changes to RSVP-managed flows, so that the RSVP module can quickly adjust the resource reservations to the new routes.

RSVP Messages and Objects

RSVP is designed to be usable with many QoS control services, which in turn are intended to work with more than one reservation setup mechanism. The role of RSVP consists merely of distributing QoS-control data across the network and of passing these data to the traffic control module on each host along the path.

  Because of the logical separation between QoS control services and the distribution of QoS control information, the RSVP specifications define only the format of RSVP QoS control objects, but the RSVP code treats the contents of these objects as opaque data.

RSVP objects are enclosed in RSVP messages, which are sent hop-by-hop between RSVP-capable routers as raw IP datagrams with protocol number 46. End systems can communicate with the first/last hop routers with UDP-encapsulated RSVP messages if they cannot do raw network I/O.

The direction from the source of a flow (thereafter called the sender) to the sinks of the flow (thereafter called receivers) is called downstream, correspondingly, the opposite direction is correspondingly called upstream.
Figure demonstrates the various directions and message paths.

 
Figure:  RSVP message paths and directions.

[Wro96a] describes how to use a certain subset of the RSVP objects with the Controlled-Load and Guaranteed QoS control services. In particular, the named draft defines the usage and contents of three RSVP object classes:

• FLOWSPEC
• ADSPEC
• SENDER_TSPEC

These objects are encapsulated in the two fundamental RSVP message types, PATH and RESV, which deserve some consideration:

• PATH Messages.
  PATH messages travel downstream from the RSVP sender to the set of receivers, following the same unicast or multicast route as the data packets.
  The PATH messages store   path state in each node along the path. The path state currently consists of the unicast IP address of the previous hop node. This information is used to route RESV messages in the reverse (upstream) direction.

  In addition to the address of the previous hop, the PATH messages contain the following objects:

  • SENDER_TEMPLATE objects. A PATH message must carry a SENDER_TEMPLATE object, which contains the information necessary to identify data packets of the sender of the PATH message. SENDER_TEMPLATE objects are structured in the format of filter specs, which are also used in RESV messages.
    SENDER_TEMPLATE objects are never changed on their way along the path.
  • SENDER_TSPEC objects. SENDER_TSPEC objects are also compulsory, immutable constituents of every PATH message.
    The TSpec describes the bounds of the traffic that the sender expects to generate.
    Receivers can use these estimations when requesting resource reservations.
  • ADSPEC objects. The optional ADSPEC objects gather both information about the properties of the data path---such as available services, delay and bandwidth estimates---as well as parameters required by specific QoS control services.
    ADSPEC objects are generated by data senders or by intermediate network elements, and are modified as they travel from one RSVP-capable node to another. An ADSPEC object advertises the possible service parameters composed of the properties of all previous-hop nodes upstream. The arriving ADSPEC object is combined with the node's own parameters and service conditions, and then forwarded to the next node.
    A receiver can use the ADSPEC information to predict the end-to-end QoS, to choose the most appropriate service and to scale its QoS request according to the current possibilities of the network.
    A receiver can in particular tell from an ADSPEC whether there are any non-RSVP-capable hosts in the path; if this is the case, the values of all parameters should be considered as unreliable, because then there are nodes in the path where the flow will experience only best-effort service.
• RESV Messages.
  RESV messages are sent upstream by receivers who want to establish a reservation for one or more senders. The RESV messages follow exactly the reverse route of the data packets, using the path state created by the PATH messages.
  The fundamental objects contained in RESV messages belong to the FLOWSPEC, FILTER_SPEC, and STYLE classes.

  A receiver, wishing to make a reservation, can use the information contained in previously received ADSPEC and SENDER_TSPEC objects to choose reasonable service parameters values for the TSpec and RSpec in his RESV message; in the same way, the data from SENDER_TEMPLATE objects is used to configure potential FILTER_SPEC objects.

  An RESV message coming in from a downstream node is passed to the admission and policy control modules. If they both grant the service request,  reservation state is set up in the node by passing the FILTER_SPEC object to the packet classifier, and by configuring the packet scheduler with the FLOWSPEC data as described in Section .
  Note that this process does not necessarily produce a new reservation. Depending on the reservation style selected with a STYLE object, the new request might instead be merged or shared with other requests, thereby modifying existing reservations. The effective FLOWSPEC of some mergeable requests is computed by finding the least upper bound (LUB) or greatest lower bound (GLB) that identifies the most demanding request.
  A RESV message with a potentially modified FLOWSPEC is forwarded upstream if the reservation request is not already covered by previous requests from other receivers of the same flow.

  The possible RSVP reservation attributes and styles are listed in Table . Senders, for whose traffic reservations are established, can be selected implicitly by a wildcard , which selects all senders in a session, or  explicitly by a list of all selected senders. When using the explicit sender-selection style, filter specs for each selected sender are needed.
  In addition, either one reservation can be  shared among the flows within a session, or a  distinct reservation is made for each data sender.

 
Table:  RSVP reservation attributes and styles.

   The basic model is a one-pass scheme: receivers send reservation requests upstream where they are either accepted or rejected by the nodes along the reverse data path. However, senders and network elements advertise their traffic characteristics and service capabilities downstream, such that receivers are provided with information about the behaviour of the upstream path elements. The receivers can use this information to parametrise their reservation requests according to the actual flow characteristics and network capacity.
This combined scheme is called One Pass With Advertising (OPWA).

RSVP Interfaces

  RSVP communicates with the various components inside a network node: on a router there must be interfaces for the routing and traffic control modules, whereas on hosts there must exist an interface for applications (an RSVP API) and also---if existing---for traffic control.

From the point of view of an application programmer, the client application programming interface is of major importance. Its main purpose is to pass the data contained in SENDER_TSPEC, ADSPEC, and FLOWSPEC objects between the local RSVP implementation and client applications. The following paragraphs describe the basic functions of an RSVP application interface, using the RSVP implementation developed by the Information Science Institute (ISI) of the University of Santa Cruz as an example.

The ISI implementation consists of an RSVP client library (RAPI), which is linked to application programs, and an RSVP daemon (rsvpd). Figure shows how the different components fit together.
The RAPI library is described in [BH96]; the C function prototypes of the RAPI functions described below are summarised in Appendix .

 
Figure:  ISI RSVP implementation components.

An application calls procedures from the RAPI library, which in turn interacts with the local RSVP daemon through a UNIX domain-socket. The RSVP daemon configures the host's packet filter and packet classifier, and communicates with other RSVP processes by means of normal RSVP messages.

The fundamental functions described in [BH96] are:

• Creation of Sessions.
  The rapi_session() call creates and initialises an API session and returns a session handle for further use. After a successful rapi_session() call, the application may receive up-calls indicating events and errors.
• Specification of Sender Parameters.
  An application that intends to send a flow of data must issue a rapi_sender() call. Thereby, it specifies the parameters of its data flow. The RSVP daemon uses this flowspec to create PATH messages for this flow. Repeated calls of the rapi_sender() function with different parameters simply change the flowspec.
• Creation, Modification, or Deletion of a Reservation.
  The rapi_reserve() function is used to make, modify, or delete a reservation for the flow described in the filter spec argument. The issuing of a rapi_reserve() call triggers the sending of RESV messages by the local RSVP daemon.
• Removal of a Session.
  The state registered with a session is deleted by calling the rapi_release() function. This causes the RSVP daemon to tear down the reservations made on behalf of the released session by sending RESVTEAR messages, and to issue PATHTEAR messages in case the application acted as a data sender.