The Resource Reservation Protocol

End-to-end QoS over the Internet has long been a goal of those desiring optimized services over this public medium, but the fact that systems on a public network cannot be as tightly controlled as those on a private one has made this quest daunting.

One of the more promising approaches to this problem is the IETF's Resource Reservation Protocol (RSVP). Its version 1 functional specification is found in RFC 2205 (1997); RFC 2750 (2000) contains updates to the standard.

RSVP was designed to signal QoS requirements across Internet connections. RSVP is an IP-based, hop-by-hop protocol that provides devices throughout the path of a data flow with information on the QoS requirements of that particular flow.

The protocol's ultimate goal is to reserve resources so that applications can get the amount of bandwidth they need. In this resource reservation approach, bandwidth management policy can be applied via policy objects, further increasing the efficiency of resource allocation. In effect, RSVP is a method for overlaying a circuit-switched network onto a packet-switched IP network. Due to IP's design, networks based on this protocol place the responsibility for maintaining the state of connections solely on end devices, whereas RSVP requires that each intermediate router maintain connection state information.

The RSVP protocol is part of the IETF's Integrated Services (IntServ) architecture (described in Informational RFC 1633, drafted in 1994), which enables heterogeneous devices to communicate about QoS requirements.

IntServ provides a protocol for signaling the QoS requirements of applications, and incorporates specifications for describing service requirements and related functionality of devices and other network elements that support QoS. IntServ is geared toward supporting real-time data such as voice and video.

Priority Mail

RSVP can be used with unicast and multicast traffic. In multicast traffic, one sender (source of a data flow) forwards a copy of each data packet to multiple receivers. One rationale for making the reservations receiver-based lies in the importance of support for multicast traffic. This type of traffic often involves reservation requests from receivers with very different characteristicsthus, a protocol was needed that would support diverse requests .

Due to the complexity of multicast flows, reservations must be merged. In multicast traffic, packets that must be delivered to different next -hop nodes are replicated. In RSVP, reservation requests must be merged at each replication point. In effect, multiple reservation requests are combined at this merge point and then forwarded as a single reservation request.

This relates to the concept of distinct reservations and shared reservations, which are both supported by RSVP. In distinct reservations, a single reservation is made for each upstream sender in a session. In shared reservations, a number of senders in a multicast flow use the reservation. (Receiver or destination nodes or endpoints are referred to as downstream; sender or source nodes or endpoints are referred to as upstream.)

There are subcategories of reservation styles. In the Wildcard-Filter (WF)-style reservation request, a single reservation is generated and shared among all data flows from all upstream senders. In the Fixed-Filter (FF)-style reservation, a distinct reservation is generated for each sender. In the Shared-Explicit (SE)-style reservation, selected upstream senders share a single reservation. These reservation styles help to optimize reservation handling from different senders in the same session.

The Message Is The Medium

RSVP is executed via a series of messages. A standard RSVP packet header consists of a 4-bit Version field denoting the protocol's version number, accompanied by an unspecified 4-bit Flags field. Eight-bit-long fields include a Reserved field, a Send TTL field indicating the message's sent time-to-live value, and a Message Type field containing the message's function. The Checksum and Length fields, both 16 bits, yield a standard TCP/UDP checksum, and the total length of the common header and the variable-length objects that follow, respectively (see Figure 1).

Figure 1: The RSVP message header includes various fields that denote characteristics such as the message's function, its time-to-live value, the protocol's version number, a TCP/IP checksum, and the total length of the common header.

The header is followed by a set of objects, which includes the information needed to describe and characterize that particular message. These objects are divided into classes, and each class of objects can contain multiple types that characterize the data's format in greater detail.

There are two strains of RSVP: Native and UDP-encapsulated. In Native RSVP, the header and payload are encapsulated in an IP datagram, with the protocol number 46. UDP-encapsulated RSVP can enable end systems to communicate with first-hop and last-hop routers, if these systems aren't RSVP-enabled.

In RSVP, a Path message is transmitted from a sender downstream to a receiver (or multiple receivers). Path messages store path information in every node along a traffic path; at a minimum, a Path message contains the IP address of each previous hop along that path. These IP addresses establish the path for transmitting subsequent reservation request (Resv) messages.

The Path message contains a Session object, which includes destination address and port information, and a Previous Hop (PHOP) object, which identifies the previous router in the direction of the traffic flow.

In addition, the Path message contains a Sender Template and a Sender traffic specification (Tspec) object. The Sender Template contains filter specifications (Filter Specs ) and identifies the format of the traffic that the sender will originate. (The Filter Spec, in combination with the session information, defines the set of packets that will receive the QoS specified in the flow specification, or Flowspec. The Flowspec defines the QoS to be applied to a particular data flow.)

The Sender Tspec characterizes the traffic flow that the sender intends to generate, in terms of attributes such as bandwidth parameters, jitter, and delay.

The Path message may also contain an Adspec object, which describes the type of services, service-specific performance characteristics, and amount of resources available for a particular reservation. The Adspec is sent to the local- traffic-control process at every node or router in a path for updating; the updated version is then sent downstream in the Path message.

The Path message may also contain a Policy Data object, which includes policy information pertaining to the source or the previous hop of a specific data flow. The policy control process uses policy data to establish authorization and usage feedback for a particular data flow.

Upon receiving the Path message, downstream RSVP-enabled routers invoke a Path state, which, at a minimum, includes the IP address of the PHOP node. This information is used to send Resv messages in the reverse direction on a hop-by-hop basis. The Path state informs devices along the path of adjacent RSVP nodes on a particular flow.

Return To Sender?

The receiver makes the reservation request by transmitting a Resv message in the upstream direction (ultimately to the data source). The Resv message includes a reservation specification or Rspec, that specifies what type of service is requiredGuaranteed or Controlled Load. Guaranteed service provides a connection like a virtual circuit, whereas Controlled Load service exceeds a best-effort service but isn't up to par with a Guaranteed service.

Resv messages include information about the reservation styles, as well as a Flow Descriptor, which consists of the Flowspec object and the Filter Spec object.

The Flowspec establishes the desired QoS and related parameters for the packet scheduling process. The Filter Spec performs the same function in the packet classification process.

Upon receiving the Resv message, RSVP-enabled routers or nodes invoke an admission control process to indicate whether those nodes can provide the requested QoS. If this process is successful, the Resv message is sent to the next router.

RSVP-enabled routers along the path schedule and prioritize packets according to the request. These systems send incoming data packets to a packet classifier; the messages are then queued in a packet scheduler. A packet filter assigns or maps packets to specific service classes, defining the route and QoS class for these packets. The packet scheduler enforces resource allocation and selects packets for transmission (see Figure 2).

Figure 2: This diagram represents the implementation of RSVP in hosts and routers. On each end of this equation, stringent policy control and admission control are crucial to deliver the desired level of service. Packets must be classified and scheduled, and queued in the packet scheduler as necessary.

After the last router along the path grants the request, a reservation confirmation (ResvConf) message notifies the receiver that the request was successful. RSVP is a soft-state protocol, so the reservations must periodically be refreshed. This soft-state characteristic helps to accommodate changes in routing, and changes in multicast group membership.

Sessions are terminated by teardown messages that cancel out the path or reservation states from nodes or devices upon receipt. PathTear messages are created by the senders (or via RSVP's time-out function) in any node on the path, and sent to all receivers. Sent by the specific node that created it, the message then cancels out path state in every node along that path. ResvTear messages cancel out reservation states in these nodes or devices.

In the event of admission control failure, an error message is sent back to the originator of the request. If any device along a path can't execute a Path state, it sends a Path Error (PathErr) message back to the sender. If a reservation state can't be invoked, the device sends a Reservation Error (ResvErr) message to the sender.

Mixed Delivery

RSVP can be combined with other QoS protocols and technologies, such as Differentiated Services (DiffServ) and Multi-protocol Label Switching (MPLS). While DiffServ marks and prioritizes traffic, RSVP secures the resources necessary to transmit that traffic. Also, RSVP contains very specific provisions for policy support. It's also compatible with MPLS, in that MPLS is capable of assigning labels in accordance to RSVP Flowspecs.

On the downside, RSVP's sophistication and complexity can impair performance on backbone routers. Thus, it's simply too involved to reasonably apply to certain applications, and is often best substituted with other protocols, such as DiffServ, on the network backbone.

Resources

The following books provide detailed overviews of RSVP and its relationships with other network elements and protocols:

Inside the Internet's Resource ReSerVation Protocol , by David Durham and Raj Yavatkar, John Wiley & Sons (ISBN: 0-471-32214-8)

Internet Performance Survival Guide , by Geoff Huston, John Wiley & Sons (ISBN: 0-471-37808-9)

A white paper called "QoS Protocols and Architectures," located at www.stardust.com/qos/whitepapers/protocols.htm, contains an excellent explanation of protocols such as RSVP, Integrated Services (IntServ), and Differentiated Services (DiffServ).

This tutorial, number 157, by Elizabeth Clark, was originally published in the August 2001 issue of Network Magazine.