For previous articles, see http://www.netcraftsmen.net/welcher/papers/index.htm . 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.
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:
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:
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.
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
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]
interface ethernet 2
ip rsvp bandwidth 15000 1000
ip rsvp udp-multicast 224.0.0.20
ip rsvp neighbors 1
ip rsvp reservation 224.250.0.2 130.240.1.1 UDP 20 30 130.240.4.1
Eth1 se load 100 60
ip rsvp reservation 224.250.0.2 130.240.2.1 TCP 20 30 130.240.4.1
Eth1 se load 150 65
ip rsvp reservation 224.250.0.3 0.0.0.0 UDP 20 0 130.240.4.1
Eth1 wf rate 300 60
ip rsvp reservation 224.250.0.3 0.0.0.0 UDP 20 0 130.240.4.1 Eth1
wf rate 350 65
ip rsvp sender 224.250.0.1 130.240.2.1 udp 20 30 130.240.2.1
loopback 1 50 5
ip rsvp sender 224.250.0.2 130.240.2.1 udp 20 30 130.240.2.1 loopback
1 50 5
ip rsvp sender 224.250.0.2 130.240.2.28 udp 20 30 130.240.2.28
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:
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 nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .