Cover V10, I01


RSVP: Signaling Quality of Service

Ron McCarty

The convergence of voice and data networks has created many efforts to guarantee adequate bandwidth with minimal delay for voice applications within IP networks.

This month I'll examine the Resource reSerVation Protocol (RSVP). RSVP is a signaling protocol designed for IP networks that allocates quality of service agreements based upon application requirements. RSVP is defined by RFC 2205, but has various support documents available from the RSVP IETF working group's web site at:
Although RSVP at first seems complex, the protocol is relatively simple when compared to more complex signaling, such as those used by telephone networks (SS7), the time division multiplexing portion of telephone networks (Q.931), or ATM. An understanding of RSVP will help determine where and when the protocol can be deployed in your network. The IETF RSVP working group provides information concerning the logical architecture of RSVP routers. Although important, there is more confusion concerning the protocol than the architecture, so I'll cover it here. Additionally, because signaling is new to many network administrators, an overview of RSVP will provide a better understanding of signaling in general, and the challenges of implementing signaling in IP networks -- networks that have traditionally been best effort.

Why Signal Quality of Service?

By signaling (and agreeing) to the Quality of Service (QoS) requests, all nodes partaking in the RSVP request are agreeing to the bandwidth and delay requirements during the application's use. Unlike typical IP-oriented mechanisms (which rely on the type of service (ToS)), or DiffServ bits (which rely on traffic shaping and intelligent queuing, where multiple client requests can still overwhelm the routers involved), RSVP will not grant additional sessions if the QoS requirement cannot be met. However, this does not mean that vendors will not use the same mechanisms because queuing traffic shaping and drop algorithms are needed for both solutions.

The telephone system is a good analogy for these two types of solutions. Using ToS and DiffServ is similar to using a party line -- if everyone speaks at once, not everyone will be understood. A signal protocol, however, is similar to a dedicated link -- you'll receive a busy signal if someone is using the link when you are making the call. (For further discussion of Quality of Service, refer to Gil Held's series of articles, beginning with the September 2000 issue of Sys Admin.)

A Closer Look

The RSVP sender and receiver signals the network for the path and QoS features required for the application. This path is referred to as an RSVP session. The session is identified by the sender's IP address, the protocol ID (which is 46 for RSVP, as defined by the Internet Assigned Numbers authority), and the destination port (with TCP and UDP both being supported). The session is actually created using two messages: PATH and RESV. The source node sends a PATH message to the destination, which helps determine the RSVP nodes involved. As each node inspects the packet, the node determines its RSVP neighbors. This PATH message takes the same path as other IP traffic. RSVP nodes set the previous hop (PHOP) bits in the PATH message to its address, which is used by the next RSVP node to identify its upstream neighbor, as previously mentioned. The QoS parameters required by the sender are also carried in the PATH message.

Upon receipt of the PATH message, the destination node (the receiver) then signals a reservation request with a RESV message. Thus, the receiver signals the reservation request.

Unlike the PATH message, the RESV message destination IP address actually contains the address of the RSVP upstream router, which was determined using the PHOP. Each hop along the way will use the PHOP to ensure that the same path from source to destination is also used for the return path for the RESV message. The RSVP node will then track the session and use the session table to base routing decisions on, as opposed to the "normal" routing table. This will not seem intuitive for experienced IP network administrators, but remember that symmetrical paths and state tables are much easier to manage and are almost a requirement for signaling.

RFC 2205 defines RSVP message formats, but a closer look within this context will reinforce the principals of the protocol. Here is the 32-bit header format:

  • Version, 4 bits

These 4 bits define the version of RSVP used. Currently the value is 1, but will change with future versions.

  • Flags, 4 bits

Currently not used.

  • Message type, 8 bits

We've covered the PATH and RESV messages that are defined as 1 and 2, respectively. Other message types are: PathErr (3), ResvErr (4), PathTear (5), ResvTear (6), and ResvConf (7). The PathTear and ResvTear are covered below.

  • Checksum, 16 bits

The checksum is used to ensure the packet has been received intact. The checksum does not have to be used and has the value 0 if it isn't used.

QoS Request

The QoS request in the RSVP is not defined by the IETF Working Group. However, it is defined by the Integrated Services IETF working group, and more specifically, RFC 2210 ("The Use of RSVP with IETF Integrated Services"), and RFC 2212, ("Specification of Guaranteed Quality of Service"). The two are not bundled together, thus allowing greater flexibility to the Internet community and network designers.

The signaling that specifies the sender's QoS requirements for the QoS is made up of two elements that are sent with the PATH messages: the sender TSPEC (sender traffic specification) and the ADSPEC. The sender TSPEC describes the amount of traffic. The ADSPEC specifies the QoS characteristics, such as bit rate, latency, number of hops, and so on. The receiver's QoS attributes are signaled much like the sender's, by using a receiver TSPEC and ADSPEC in much the same way. However, the RESV message contains these QoS attributes.

Ending Sessions and Soft States

RSVP simulates keep-alive timers used in other networking topologies through the use of soft states. Should RSVP messages concerning a session not be received within a predefined interval (the "cleanup timeout"), then the router will delete the reservation state. This ensures that resources are returned to the router for further assignment should a node or network failure cause a new path around the failure.

Additionally, closure of sessions can also be signaled using tear messages. If a reservation (RESV) is to be closed, then an RESV tear down is sent from the destination to the source, hop-by-hop, once again using the PHOP to ensure the RESV tear down follows the same path as the RESV.

The PATH tear down is initiated by the sender of the data flow and travels to the source using the normal routing mechanism based upon the destination IP address.

Integration with Current Networks

Although RSVP adds functionality to IP, it does not require changes to the IP protocol. RSVP does ensure the return path or reservation path based upon the information gained from the PATH determination, but it is not a routing protocol and can, like any other IP protocol, take advantage of routing protocols. (With the requirement that the RESV message uses the IP address of the PHOP as the destination -- not the ultimate destination, which is the source of the data stream and the original PATH request.)

Since migration to RSVP cannot be a major migration effort for many networks, RSVP neighbors do not need to be directly connected. Additionally, RFC 2746 ("RSVP Operation Over IP Tunnels") defines RSVP in IP over IP tunnels with support for three distinct link types for supporting best effort, data flow QoS tunnels, and QoS tunnels with individual data flow QoS agreements.

Since many applications do not know the QoS requirements and are not RSVP aware, the RSVP working group is also working on RSVP proxies. Although the RSVP proxy specification is still in draft, RSVP proxies will likely play a major role in early implementations and acceptance of RSVP.

These solutions may not provide complete QoS throughout a network, but they do provide the network management some added flexibility to phase in the technology.


Convergence of voice and data networks creates many solutions to providing QoS over IP networks. RSVP is receiving wider vendor support and will be deployed in networks requiring QoS features. Understood correctly, RSVP can help you integrate services into your network. I hope this month's column has removed some of the mystique from RSVP.

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty works for Lucent Technologies as a senior systems engineer on a customer team responsible for a major telecommunications carrier. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: