RSVP (ReSerVation Protocol)

RSVP, which enables non-QoS technologies such as Ethernet and IP to make QoS requests of the network, is an IETF Internet-Draft that has received a lot of attention. Specifically, the protocol lets end stations request specific QoS levels for QoS-enabled applications. For example, for a video conferencing application, a request could include information that defines the maximum frame transmission rate, the maximum frame jitter, and the maximum end-to-end delay.

When an end station makes an RSVP request for an application, each router situated between it and the source makes note of the QoS request and attempts to honor it. As the request travels through the routers to the source, it merges with requests from other end stations (see Figure). If a router can't comply with the request-that is, if it can't guarantee the bandwidth or performance - the requesting station receives an error message, the equivalent of a busy signal on the voice network.

As you can see from all of these conditional statements, nothing is absolutely guaranteed with IP-based networks, even with an additional protocol like RSVP. For example, if a router refuses an RSVP request because it has already allocated its RSVP bandwidth, the packets associated with the request get dumped.

Another potential downside of RSVP is cost. Because the protocol requires each router to understand and support QoS requests, you might have to invest in firmware or even hardware upgrades to enable it.

RSVP could also lead to a perceived degradation of some network services. In a non-RSVP network, an application might run slowly or badly - but at least it'll run. In an RSVP network, the application might not run at all if there's not enough bandwidth to support it. Similarly, if high-priority requests consume all the allotted bandwidth, a router could dump nonprioritized flows. If you end up with an "arms race", where many nonbandwidth-sensitive applications claim to be high priority anyway, you'll see no real benefits.

Another potential caveat is that routing protocols such as OSPF and Border Gateway Protocol (BGP) do not currently support RSVP - and, ideally, they should, because a QoS request is actually made after a route is chosen for a particular data flow. It would be far better for an RSVP priority level to be taken into account before a route was chosen. Once the IETF's QoS Routing Working Group finishes its Internet-Draft for RSVP, it will begin working with the Working Groups for OSPF and BGP to integrate the routing protocols with RSVP.

Another criticism of RSVP is its inability to scale. Some industry watchers have warned that the protocol might not be suitable for large enterprise networks, specifically because each and every router along a particular path must support it. Given that requirement, using RSVP successfully over the public Internet could prove challenging.

Another router-based method for handling QoS requests is multiple queues. Routers that support this scheme identify flows that are tagged as high priority and move them to fast queues to expedite transmission.

Along these lines, the IETF's Integrated Services Working Group is debating how to use the 8-bit Type of Service (ToS) field in an IP packet header to tag traffic with different service levels. Currently, this field prioritizes traffic according to which end station initiated the flow, rather than the type of flow itself. If used in this new way, the TOS field would tell network devices that certain types of packets should receive a certain level of service. [Editor's note: Ultimately the Differentiated Services (diffserv) Working Group elaborated new standards for the TOS field (now renamed the differentiated services or DS field) in RFC2474 and RFC2475.]

The ReSerVation Protocol (RSVP) is a signaling protocol that provides reservation setup and control to enable the integrated services [IntServ], which is intended to provide the closest thing to circuit emulation on IP networks. RSVP is the most complex of all the QoS technologies, for applications (hosts) and for network elements (routers and switches). As a result, it also represents the biggest departure from standard "best-effort" IP service and provides the highest level of QoS in terms of service guarantees, granularity of resource allocation and detail of feedback to QoS-enabled applications and users.

Here is a simplified overview of how the protocol works, as illustrated in Figure 1:

• Senders characterize outgoing traffic in terms of the upper and lower bounds of bandwidth, delay, and jitter. RSVP sends a PATH message from the sender that contains this traffic specification (TSpec) information to the (unicast or multicast receiver(s)) destination address. Each RSVP-enabled router along the downstream route establishes a "path-state" that includes the previous source address of the PATH message (i.e. the next hop "upstream" towards the sender).
• To make a resource reservation, receivers send a RESV (reservation request) message "upstream". In addition to the TSpec, the RESV message includes a request specification (Rspec) that indicates the type of Integrated Services required-either Controlled Load or Guaranteed--and a filter specification (filter spec) that characterizes the packets for which the reservation is being made (e.g. the transport protocol and port number). Together, the RSpec and filter spec represent a flow-descriptor that routers use to identify each reservation (a.k.a., a "flow" or a "session").
• When each RSVP router along the upstream path receives the RESV message, it uses the admission control process to authenticate the request and allocate the necessary resources. If the request cannot be satisfied (due to lack of resources or authorization failure), the router returns an error back to the receiver. If accepted, the router sends the RESV upstream to the next router.
• When the last router receives the RESV and accepts the request, it sends a confirmation message back to the receiver (note: the "last router" is either closest to the sender or at a reservation merge point for multicast flows).
• There is an explicit tear-down process for a reservation when sender or receiver ends an RSVP session.

Figure 1: RSVP "PATH" and "RESV" messages are used to establish a resource reservation between a sender and receiver. There is an explicit tear-down of reservations also (not shown).

RSVP enables Integrated Services, of which there are two fundamentally different types:

• Guaranteed: This comes as close as possible to emulating a dedicated virtual circuit. It provides firm (mathematically provable) bounds on end-to-end queuing delays by combining the parameters from the various network elements in a path, in addition to ensuring bandwidth availability according to the TSpec parameters [IntServ Guaranteed].
• Controlled Load: This is equivalent to "best effort service under unloaded conditions." Hence, it is "better than best-effort," but cannot provide the strictly bounded service that Guaranteed service promises [IntServ Controlled].

Integrated Services use a token-bucket model to characterize its input/output queuing algorithm. A token-bucket is designed to smooth the flow of outgoing traffic, but unlike a leaky-bucket model (which also smoothes the out-flow), the token-bucket model allows for data bursts--higher send rates that last for short periods [Partridge].

Data flows for an RSVP session are characterized by senders in the TSpec (traffic specification) contained in PATH messages, and mirrored in the RSpec (reservation specification) sent by receivers in RESV messages. The token-bucket parameters-bucket rate, bucket depth, and peak rate--are part of the TSpec and RSpec. Here is a complete list of the parameter descriptions [RSVP IntServ, IntServ Parameters, IntServ Controlled]. For both Guaranteed and Controlled Load service, non-conforming (out-of-spec) traffic is treated like non-QoS best-effort traffic:

• Token rate ( r ): The continually sustainable bandwidth (bytes/second) requirements for a flow. This reflects the average data rate into the bucket, and the target shaped data rate out of the bucket.
• Token-bucket depth ( b ): The extent to which the data rate can exceed the sustainable average for short periods of time. More precisely, the amount of data sent cannot exceed rT+b (where T is any time period).
• Peak Rate ( p ): This is set to the maximum send rate (bytes/second) if known and controlled, or to positive infinity if not known (floating point value represented by 255.000…0, as described in RFC 1832). For all time periods (T), the amount of data sent cannot exceed M+pT.
• Minimum policed size ( m ): The (byte) size of the smallest packet (data payload only) generated by the sending application. This is not an absolute number, but in cases where the percentage of small packets is small, this number should be increased to reduce the overhead estimate for this flow (which can affect reservation acceptance). All packets smaller than m are treated as size m and policed accordingly.
• Maximum packet size ( M ): The biggest packet (in bytes). This number should be considered an absolute, since any packets of larger size are considered out of spec and may not receive QoS-controlled service as a result.

In our description of the traffic and reservation specifications, we have omitted details about other RSVP and Integrated Service features such as:

1. ADSpec in a PATH message, which contains information (service, delay, bandwidth estimates, etc.) generated by the data source or any or all network nodes in the downstream path.
2. Reservation styles, which deal with how one reservation interacts with others.
3. Filter-spec which allow characterization of "sub-flows" that could be used in a hierarchically encoded signal for heterogeneous receivers, for example.
4. Policy data, which provides detailed condition information for use in resource reservation policy decisions.

Here is a summary of the more salient characteristics of the RSVP Protocol mechanisms:

• Reservations in each router are "soft," which means they need to be refreshed periodically by the receiver(s).
• RSVP is not a transport, but a network (control) protocol. As such, it does not carry data, but works in parallel with TCP or UDP data "flows."
• Applications require APIs to specify the flow requirements, initiate the reservation request, and receive notification of reservation success or failure after the initial request and throughout a session. To be useful, these APIs also need to include RSVP error information to describe a failure during reservation setup or anytime thereafter during the lifetime of a reservation as conditions change.
• Reservations are receiver-based, in order to efficiently accommodate large heterogeneous (multicast) receiver groups.
• Multicast reservations are "merged" at traffic replication points on their way upstream, which involves complex algorithms that are not well understood yet [RSVP Killers]. We discuss the topic of QoS support for multicast in more detail later in this paper.
• Although RSVP traffic can traverse non-RSVP routers, this creates a "weak-link" in the QoS chain where the service falls-back to "best effort" (i.e. there is no resource allocation across these links).
• There are two types of RSVP Protocols: Native RSVP has an IP Protocol number 46 (for the protocol field of an IP header), and the RSVP header and payload are encapsulated by the (raw) IP header itself. UDP-encapsulated RSVP has its header contained in a UDP datagram. The 802 "Subnet Bandwidth Manager" that we describe later in this paper only supports Native RSVP.

As mentioned already, RSVP provides the highest level of IP QoS available. It allows an application to request QoS with a high level of granularity and with the best guarantees of service delivery possible. This sounds wonderful and leaves one wondering why we need anything else. The reason is that it comes at the price of complexity and overhead, thus is overkill for many applications and (as we describe later) for some portions of the network. Simpler, less fine-tuned methods are needed, and that is what DiffServ provides, as we describe now.

Wed, 23 July, 2003 13:07