Resource Reservation Protocol, RSVP

icon Resource Reservation Protocol, RSVP


This month is the final article in the series on Quality of Service (QoS) in Cisco devices. It's not that we've covered anywhere near everything there is to be said, it's more that it's time to move on to new topics.

For previous articles, see Pete's Articles and Blogs. I'm well aware these brief articles have focussed on configuration, without a lot of explanation, for space reasons. For more discussion, I refer you to the book, Quality of Service: Delivering QoS in the Internet and in Corporate Networks, Paul Ferguson (Cisco) and Geoff Huston, Wiley Press. The book makes it quite clear that QoS is a work in progress, with various schools of thought on what will work at all, as well as what will work best.

About RSVP

Resource Reservation Protocol (RSVP) is a signalling protocol, it does not attempt to control QoS itself: that is the scope of some or possibly several other protocols. RSVP allows end systems to request Quality of Service (QOS) "guarantees" from the network. This is so the participating systems can reserve bandwidth and attempt to provide predictable latency for real-time traffic (voice and video) while maintaining adequate bandwidth for data.

An RSVP sender sends PATH messages downstream towards receivers. Each node along the unicast or multicast path stores information about the flow, based on the sender's TSpec (bit rate, token bucket size). Upon receiving the PATH message, the receiver sends a reservation (Resv) request message back upstream to the sender, reversing the path taken by the PATH messages. The Resv message indicates the desired QoS with an RSpec. The Resv message creates and maintains soft state in the nodes along the path. Without such refreshes, the soft state ages out and is deleted, usually in 30 seconds. This mechanism allows RSVP to adjust and alter the path between RSVP end systems to recover from route changes, and prevents router resources from being tied up due to receivers that quietly vanish.

RSVP flows are "multidestination simplex," since data travels across them in only one direction, from the origin to the targets. Flows travel from a set of senders to a set of receivers. This allows for multicast. Flows can be merged or left unmerged, and the method of merging them varies according to the attributes of the application using the flow.

RSVP is spelled out in the following RFC's:

There are also other RFC's containing SNMP MIB's for Integrated Services, RSVP over ATM, etc.

In Cisco routers, RSVP works in conjunction with weighted fair queuing (WFQ) or random early detection (RED). WFQ flows or conversations are the traffic for a single transport layer session or network layer flow across a given router interface, determined by the source and destination address, protocol type, port number, and other Layer 3 attributes (for IP).

Two different types of multicast flows are a flow that originates from exactly one sender (called a distinct reservation), and a flow that originates from one or more senders (called a shared reservation).

A video application is an example of a distinct reservation. Each sender emits a distinct data stream that requires admission and management, a separate reservation per sender. RSVP refers to such distinct reservations as explicit , and installs it using a Fixed Filter style of reservation. Use of RSVP for unicast applications is generally a degenerate case of a distinct flow.

An audio application might be an example of a shared reservation, even though each sender also emits a distinct data stream that requires admission and management in a queue. The difference is that a limited number of senders are transmitting data at any given time. Such a flow, therefore, does not require a separate reservation per sender. Instead, a single reservation can be applied to any sender within the set of senders. RSVP installs a shared reservation using either a Wild Card or Shared Explicit style of reservation. A Wild Card reserves bandwidth and delay characteristics for any sender, and is limited by the list of source addresses carried in the reservation message. The Shared Explicit style reservation lists sources.

These types of reservations are distinct and cannot be merged: shared, fixed filter, and wild card. We'll see these again in the configuration section below.

The IETF Integrated Services effort has defined type classes of service: controlled load and guaranteed QoS. Controlled load service is essentially best effort service in a lightly loaded network. The flow's TSpec indicates desired bandwidth, but delay and loss levels may not be specified -- maximum levels are implicit the service. Controlled load is somewhat like ATM nrt-VBR or ABR with MCR (minimum cell rate) service. Guaranteed QoS instead tries to deliver traffic with a bandwidth guarantee and specified maximum queuing delay (but not jitter). This is more like ATM's CBR or perhaps rt-VBR. Traffic not conforming to flow specification or requiring IP fragmentation is subject to best-effort delivery, which in ATM is UBR traffic. See RFC's 2211 and 2212, respectively, for details.

There are special planning and design requirements for RSVP. See the IOS manual for details. Some of the questions you must answer:

  • How much bandwidth should RSVP allow per end-user application flow?
  • How much bandwidth is available for RSVP?
  • How much bandwidth must be excluded from RSVP to allow for low-volume data conversations?
  • Are any multi-access LAN's involved? (RSVP does not handle LAN's well: too little control)
In Frame Relay, RSVP subinterfaces of frame relay circuits must contain exactly one DLC to operate correctly. For safety and proper control, the ip rsvp bandwidth interface configuration command must be entered for both the interface and the subinterface. Both bandwidths are used.

In ATM, RSVP should be allowed to open its own VC's with usable bit rate (UBR) or an available bit rate (ABR) virtual channels.

Configuring RSVP

RSVP is disabled by default. To enable RSVP on an interface:

interface ...
ip rsvp bandwidth [interface-kbps] [single-flow-kbps]

The default maximum bandwidth is 75% of the interface bandwidth. A single flow can reserve up to the entire reservable bandwidth. On subinterfaces, this uses the more restrictive of the available bandwidths of the physical interface and the subinterface.

You can configure the router to behave as though it is periodically receiving an RSVP PATH message from a sender, or previous hop routes containing the indicated attributes:

interface ...
ip rsvp sender session-ip-address sender-ip-address [tcp | udp | ip-protocol] session-dport sender-sport previous-hop-ip-address previous-hop-interface

You can configure the router to behave as though it is continuously receiving an RSVP RESV message from an originator containing the indicated attributes:

interface ...
ip rsvp reservation session-ip-address sender-ip-address [tcp | udp | ip-protocol] session-dport sender-sport next-hop-ip-address next-hop-interface {ff | se | wf} {rate | load} [bandwidth] [ burst-size]

Here {ff | se | wf } refers to the reservation style: Fixed Filter (ff) is single reservation, Shared Explicit (se) is shared reservation, limited scope, and Wild Card (wf) is shared reservation, unlimited scope.

The keyword {rate | load} refers to QOS: guaranteed bit rate service or controlled load service. In both cases, the bit rate and token bucket size is specified.

RSVP control messages are intended to use raw IP packets, but some hosts may not be able to transmit such packets. If RSVP neighbors are seen using UDP encapsulation, the router will automatically generate UDP-encapsulated messages for the neighbors. Some hosts will not originate such messages unless they hear from the router first. To enter a UDP multicast address, use the global command:

interface ...
ip rsvp udp-multicast [multicast-address]

To limit which routers may offer reservations, configure:

interface ...
ip rsvp neighbors access-list-number

Relevant EXEC Mode Commands

show ip rsvp interface [type number]

show ip rsvp installed [type number]

show ip rsvp neighbor [type number]

show ip rsvp sender [type number]

show ip rsvp request [type number]

show ip rsvp reservation [type number]

Sample Configuration

The following shows the various commands in use, in no particular scenario:

interface ethernet 2
ip rsvp bandwidth 15000 1000

ip rsvp udp-multicast
ip rsvp neighbors 1

ip rsvp reservation UDP 20 30 Eth1 se load 100 60
ip rsvp reservation TCP 20 30 Eth1 se load 150 65

ip rsvp reservation UDP 20 0 Eth1 wf rate 300 60
ip rsvp reservation UDP 20 0 Eth1 wf rate 350 65

ip rsvp sender udp 20 30 loopback 1 50 5
ip rsvp sender udp 20 30 loopback 1 50 5
ip rsvp sender udp 20 30 loopback 1 50 5


The first article in this series talked briefly about the various names and acronyms in QoS. As a summary, I've included a drawing and the following:

  • Input to router: Committed Access Rate, CAR, controls the input flow to meet a SLA (QoS) specification (using Precedence bits or QoS group). This might be used at the edge of a carrier or service provider cloud to control excess traffic entering the cloud.
  • Internal to router: CAR spillover to other classes of excess traffic, Policy Routing, IP Precedence bits, QoS groups.
  • Internal to router but propagated via BGP: QPPB.
  • Output queue management: Priority Queuing, Custom Queuing, Weighted Fair Queuing, RSVP, Traffic Shaping
  • Bandwidth and service reservations, in a private network: RSVP.
  • Router mechanism for throttling one data flow to benefit all: Weighted Random Early Detection, WRED: congested output response and congestion prevention.
  • Communicating class of service to other routers: IP Precedence bits.


Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See for more information about NetCraftsmen. . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This email address is being protected from spambots. You need JavaScript enabled to view it. .


Copyright (C)  1999  Peter J. Welcher