Configuring RSVP

• Data traffic seldom needs reserved bandwidth because internetworks provide datagram services for data traffic. This asynchronous packet switching may not need guarantees of service quality. End-to-end controls between data traffic senders and receivers help ensure adequate transmission of bursts of information.

• Real-time traffic (that is, voice or video information) experiences problems when operating over datagram services. Because real-time traffic sends an almost constant flow of information, the network "pipes" must be consistent. Some guarantee must be provided that service between real-time hosts will not vary. Routers operating on a first-in, first-out (FIFO) basis risk unrecoverable disruption of the real-time information that is being sent.

Data applications, with little need for resource guarantees, frequently demand relatively lower bandwidth than real-time traffic. The almost constant high bit-rate demands of a video conference application and the bursty low bit-rate demands of an interactive data application share available network resources.

RSVP prevents the demands of traffic such as large file transfers from impairing the bandwidth resources necessary for bursty data traffic. When RSVP is used, the routers sort and prioritize packets much like a statistical time-division multiplexer would sort and prioritize several signal sources that share a single channel.

RSVP mechanisms enable real-time traffic to reserve resources necessary for consistent latency. A video conferencing application can use settings in the router to propagate a request for a path with the required bandwidth and delay for video conferencing destinations. RSVP will check and repeat reservations at regular intervals. By this process, RSVP can adjust and alter the path between RSVP end systems to recover from route changes.

• Jitter--A slight time or phase movement in a transmission signal can introduce loss of synchronization or other errors.

• Insufficient bandwidth--Voice calls use a digital signal level 0 (DS-0 at 64 kbps), video conferencing uses T1/E1 (1.544 Mbps or 2.048 Mbps), and higher-fidelity video uses much more.

• Delay variations--If the wait time between when signal elements are sent and when they arrive varies, the real-time traffic will no longer be synchronized and transmission may fail.

• Information loss--When signal elements drop or arrive too late, lost audio causes distortions with noise or crackle sounds. The lost video causes image blurring, distortions, or blackouts.

• RSVP flow--This is a stream that operates "multidestination simplex," because data travels across it in only one direction: from the origin to the targets. Flows travel from a set of senders to a set of receivers. The flows can be merged or left unmerged, and the method of merging them varies according to the attributes of the application using the flow.

• WFQ conversation--This is the traffic for a single transport layer session or network layer flow that crosses a given interface. This conversation is identified from the source and destination address, protocol type, port number, or other attributes in the relevant communications layer.

RSVP allows for hosts to send packets to a subset of all hosts (multicasting). RSVP assumes that resource reservation applies primarily to multicast applications (such as video conferencing). Although the primary target for RSVP is multimedia traffic, a clear interest exists for the reservation of bandwidth for unicast traffic (such as Network File System (NFS) and virtual private network management). A unicast transmission involves a host sending packets to a single host.

RSVP installs a shared reservation using a Wild Card or Shared Explicit style of reservation, with the difference between the two determined by the scope of application (which is either wild or explicit):

• Serial line interfaces--PPP; HDLC; Link Access Procedure, Balanced; High-Speed Serial Interface; and similar serial line interfaces are well modeled by RSVP. The device can, therefore, make guarantees on these interfaces. Nonbroadcast multiaccess (NBMA) interfaces are also most in need of reservations.

• Multiaccess LANs--These data links are not modeled well by RSVP interfaces because the LAN itself represents a queueing system that is not under the control of the device making the guarantees. The device guarantees what load it will offer, but cannot guarantee the competing loads or timings of loads that neighboring LAN systems will offer. The network administrator can use admission controls to control how much traffic is placed on the LAN. The network administrator, however, should focus on the use of admission in network design in order to use RSVP effectively.

The Subnetwork Bandwidth Manager (SBM) protocol is an enhancement to RSVP for LANs. One device on each segment is elected the Designated SBM (DSBM). The DSBM handles all reservations on the segment. This prevents multiple RSVP devices from granting reservations and overcommitting the shared LAN bandwidth. The DSBM can also inform hosts of how much traffic they are allowed to send without valid RSVP reservations.

• Public X.25 networks--It is not clear that rate or delay reservations can be usefully made on public X.25 networks.

You must use a specialized configuration on Frame Relay and ATM networks, as discussed in the next sections.

• Reservations are made for an interface or subinterface. If subinterfaces contain more than one data-link control (DLC), the bandwidth required and the bandwidth reserved may differ. Therefore, RSVP subinterfaces of Frame Relay interfaces must contain exactly one DLC to operate correctly.

• In addition, Frame Relay DLCs have committed information rates (CIR) and burst controls (Bc and Be) that may not be reflected in the configuration and may differ markedly from the interface speed (either adding up to exceed it or being significantly smaller). Therefore, the ip rsvp bandwidth interface configuration command must be entered for both the interface and the subinterface. Both bandwidths are used as admission criteria.

For example, suppose that a Frame Relay interface runs at a T1 rate (1.544 Mbps) and supports several DLCs to remote offices served by 128-kbps and 56-kbps lines. You must configure the amount of the total interface (75 percent of which being 1.158 Mbps) and the amount of each receiving interface (75 percent of which would be 96 and 42 kbps, respectively) that may be reserved. Admission succeeds only if enough bandwidth is available on the DLC (the subinterface) and on the aggregate interface.

• When ATM is configured, it most likely uses a usable bit rate (UBR) or an available bit rate (ABR) virtual channel (VC) connecting individual routers. With these classes of service, the ATM network makes a "best effort" to meet the traffic's bit-rate requirements and assumes that the end stations are responsible for information that does not get through the network.

• This ATM service can open separate channels for reserved traffic having the necessary characteristics. RSVP should open these VCs and adjust the cache to make effective use of the VC for this purpose.

Command	Purpose
ip rsvp bandwidth [interface-kbps] [single-flow-kbps]	Enables RSVP for IP on an interface.

This command starts RSVP and sets the bandwidth and single-flow limits. The default maximum bandwidth is up to 75 percent of the bandwidth available on the interface. By default, the amount reservable by a flow can be up to the entire reservable bandwidth.

On subinterfaces, this command applies the more restrictive of the available bandwidths of the physical interface and the subinterface. For example, a Frame Relay interface might have a T1 connector nominally capable of 1.536 Mbps, and 64-kbps subinterfaces on 128-kbps circuits (64-kbps CIR). RSVP bandwidth can be configured on the main interface up to 1200 kbps, and on each subinterface up to 100 kbps.

Reservations on individual circuits that do not exceed 100 kbps normally succeed. If, however, reservations have been made on other circuits adding up to 1.2 Mbps, and a reservation is made on a subinterface that itself has enough remaining bandwidth, the reservation request will still be refused because the physical interface lacks supporting bandwidth.

However, in some cases, a host will not originate such a message until it has first heard from the router, which it can only do via UDP. You must instruct the router to generate UDP-encapsulated RSVP multicasts whenever it generates an IP-encapsulated multicast.

To specify multicast destinations that should receive UDP-encapsulated messages, use the following command in global configuration mode:

Command	Purpose
ip rsvp udp-multicasts [multicast-address]	Specifies multicast destinations that should receive UDP-encapsulated messages.

Command	Purpose
ip rsvp neighbor access-list-number	Limits which routers may offer reservations.

When this command is configured, only neighbors conforming to the access list are accepted. The access list is applied to the IP header.

Command	Purpose
ip rsvp flow-assist	Enables RSVP to attach itself to NetFlow.

This task is optional for the following reason: When the interface is configured with the ip rsvp svc-required command to use ATM SVCs, RSVP automatically attaches itself to NetFlow to perform packet-flow identification (in which case you need not perform this task). However, if you want to perform IP Precedence-ToS bit setting without using ATM SVCs and without using fair queueing, then you must use the ip rsvp flow-assist command to instruct RSVP to attach itself to NetFlow.

	Command	Purpose
Step 1	ip rsvp precedence {conform precedence-value | exceed precedence-value}	Sets the IP Precedence conform and exceed values.
Step 2	ip rsvp tos {conform tos-value | exceed tos-value}	Sets the ToS conform and exceed values.

The ToS byte in the IP header defines the three high-order bits as IP Precedence bits and the five low-order bits as ToS bits.

The router software checks a packet's source and destination addresses and port numbers to determine if the packet matches an RSVP reservation. If a match exists, as part of its input processing, RSVP checks the packet for conformance to the flowspec of the reservation. During this process, RSVP determines if the packet conforms to or exceeds the flowspec, and it sets the packet's IP header IP Precedence and ToS bits accordingly. These IP Precedence and ToS bit settings are used by per-VC DWRED on the output interface, and they can be used by interfaces on downstream routers.

The combination of scheduling performed by the Enhanced ATM port adapter (PA-A3) and the per-SVC DWRED drop policy ensures that any packet that matches a reservation but exceeds the flowspec (that is, it does not conform to the token bucket for the reservation) is treated as if it were a best-effort packet. It is sent on the SVC for the reservation, but its IP Precedence is marked to ensure that it does not interfere with conforming traffic.

Command	Purpose
snmp-server enable traps rsvp	Sends RSVP notifications.

After you configure the RSVP reservations that reflect your network resource policy, you can verify the resulting RSVP operations by using one or more of the following commands in EXEC mode:

Command	Purpose
show ip rsvp interface [type number]	Displays RSVP-related interface information.
show ip rsvp installed [type number]	Displays RSVP-related filters and bandwidth information.
show ip rsvp neighbor [type number]	Displays current RSVP neighbors.
show ip rsvp sender [type number]	Displays RSVP sender information.
show ip rsvp request [type number]	Displays RSVP request information.
show ip rsvp reservation [type number]	Displays RSVP receiver information.

The router network includes three routers: Router A, Router B, and Router C. The example presumes that the upstream interface Hssi0 of Router A links to the upstream host. Router A and Router B are connected by the downstream interface Ethernet1 of Router A, which links to the upstream interface Ethernet 1 of Router B. Router B and Router C are connected by the downstream interface Hssi0 of Router B, which links to the upstream interface Hssi0 of Router C. The example presumes that the downstream interface Ethernet2 of Router C links to the downstream host.

Typically, an RSVP-capable application running on an end system host on one side of a router network sends out either unicast or multicast RSVP PATH (Set Up) messages to the destination end system or host on the other side of the router network with which it wishes to communicate. The initiating application is referred to as the sender; the target or destination application is called the receiver. In this example, the sender runs on the host upstream from Router A and the receiver runs on the host downstream from Router C. The router network delivers the RSVP PATH messages from the sender to the receiver. The receiver replies with RSVP RESV messages in an attempt to reserve across the network the requested resources that are required between itself and the sender. The RSVP RESV messages specify the parameters for the requisite QoS that the router network connecting the systems should attempt to offer.

This example does not show the host that would run the sender application and the host that would run the receiver application. Normally, the first router downstream from the sender in the router network--in this case, Router A--would receive the RSVP PATH message from the sender. Normally, the last router in the router network--that is, the next hop upstream from the host running the receiver application, in this case, Router C--would receive an RSVP RESV message from the receiver.

Because this example does not explicitly include the hosts on which the sender and receiver applications run, the routers have been configured to act as if they were receiving PATH messages from a sender and RESV messages from a receiver. The commands used for this purpose, allowing RSVP to be more fully illustrated in the example, are the ip rsvp sender command and the ip rsvp reservation command. On Router A, the following command has been issued:

ip rsvp sender 225.1.1.1 12.1.2.1 UDP 7001 7000 12.1.2.1 Hs0 20 1
 

This command causes the router to act as if it were receiving PATH messages destined to multicast address 225.1.1.1 from a source 12.1.2.1. The previous hop of the PATH message is 12.1.2.1, and the message was received on interface Hssi0.

On Router B, the following command has been issued:

ip rsvp reservation 225.1.1.1 12.1.2.1 UDP 7001 7000 9.1.2.1 Et2 FF LOAD 8 1
 

This command causes the router to act as if it were receiving RESV messages for the session with multicast destination 225.1.1.1. The messages request a Fixed Filter reservation to source 12.1.2.1, and act as if they had arrived from a receiver on interface Ethernet2 with address 9.1.2.1.

In the example, the RSVP PATH messages flow in one direction: downstream from the sender, which in this example is Router A. (If the host were to initiate the RSVP PATH message, the message would flow from the host to Router A.) Router A sends the message downstream to Router B, and Router B sends it downstream to Router C. (If the downstream host were the actual receiver, Router C would send the RSVP PATH message downstream to the receiver host.) Each router in the router network must process the RSVP PATH message and route it to the next downstream hop.

The RSVP RESV messages flow in one direction: upstream from the receiver (in this example, Router C), upstream from Router C to Router B, and upstream from Router B to Router A. If the downstream host were the receiver, the message would originate with the host, which would send it to Router C. If the upstream host were the sender, the final destination of the RSVP RESV message would be the upstream host. At each hop, the router receiving the RSVP RESV message must determine whether it can honor the reservation request.

The ip rsvp bandwidth command both enables RSVP on an interface and specifies the amount of bandwidth on the interface that can be reserved (as well as the amount of bandwidth that can be allocated to a single flow). To ensure QoS for the RSVP reservation, WFQ is configured on the interfaces enabled for the reservation.

If the router network is capable of offering the specified (QoS) level of service, then an end-to-end reserved path is established. If not, the reservation attempt is rejected and a reservation error message is sent to the receiver. The ability of each router in the network to honor the requested level of service is verified, link by link, as the RSVP RESV messages are sent across the router network to the sender. However, the data itself for which the bandwidth is reserved travels one way only: from the sender to receiver across an established PATH. Therefore, the QoS is effective in only one direction. This is the common case for one-to-many multicast data flows.

After the three routers in the example are configured, the show ip rsvp sender and show ip rsvp reservation commands will make visible the PATH and RESV state.

Router A

On Router A, RSVP is enabled on interface Ethernet1 with 10 kbps to be reserved for the data transmission. A weighted fair queue is reserved on this interface to ensure RSVP QoS. (On Router A, RSVP is also enabled on interface Hssi0 with 1 kbps reserved, but this bandwidth is used simply for passing messages.)

!
version 12.0
service config
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service udp-small-servers
service tcp-small-servers
!
hostname routerA
!
ip subnet-zero
no ip domain-lookup
ip multicast-routing
ip dvmrp route-limit 20000
!
!
interface Ethernet0
 ip address 2.0.0.193 255.0.0.0
 no ip directed-broadcast
 no ip route-cache
 no ip mroute-cache
 media-type 10BaseT
!
interface Ethernet1
 ip address 11.1.1.2 255.0.0.0
 no ip directed-broadcast
 ip pim dense-mode
 ip rsvp bandwidth 10 10
 fair-queue 64 256 1000
 media-type 10BaseT
!
interface Hssi0
 ip address 12.1.1.1 255.0.0.0
 no ip directed-broadcast
 ip pim dense-mode
 ip rsvp bandwidth 1 1
!
interface ATM0
 no ip address
 no ip directed-broadcast
 shutdown
!
router ospf 100
 network 11.0.0.0 0.255.255.255 area 10
 network 12.0.0.0 0.255.255.255 area 10
!
ip classless
ip rsvp sender 225.1.1.1 12.1.2.1 UDP 7001 7000 12.1.2.1 Hs0 20 1
!
line con 0
 exec-timeout 0 0
 length 0
 transport input none
line aux 0
line vty 0 4
 login
!
end
 

Router B

On Router B, RSVP is enabled on interface Hssi0 with 20 kbps to be reserved for the data transmission. A weighted fair queue is reserved on this interface to ensure RSVP QoS. (On Router B, RSVP is also enabled on interface Ethernet1 with 1 kbps reserved, but this bandwidth is used simply for passing messages.)

!
version 12.0
service config
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service udp-small-servers
service tcp-small-servers
!
hostname routerB
!
ip subnet-zero
no ip domain-lookup
ip multicast-routing
ip dvmrp route-limit 20000
clock calendar-valid
!
interface Ethernet0
 ip address 2.0.0.194 255.0.0.0
 no ip directed-broadcast
 no ip route-cache
 no ip mroute-cache
 media-type 10BaseT
!
interface Ethernet1
 ip address 11.1.1.1 255.0.0.0
 no ip directed-broadcast
 ip pim dense-mode
 ip rsvp bandwidth 1 1
 media-type 10BaseT
!
interface Hssi0
 ip address 10.1.1.2 255.0.0.0
 no ip directed-broadcast
 ip pim dense-mode
 ip rsvp bandwidth 20 20
 fair-queue 64 256 1000
 hssi internal-clock
!
interface ATM0
 no ip address
 no ip directed-broadcast
 shutdown
!
router ospf 100
 network 10.0.0.0 0.255.255.255 area 10
 network 11.0.0.0 0.255.255.255 area 10
!
ip classless
!
line con 0
 exec-timeout 0 0
 length 0
 transport input none
line aux 0
line vty 0 4
 login
!
end
 

Router C

On Router C, RSVP is enabled on interface Ethernet2 with 20 kbps to be reserved for the data transmission. A weighted fair queue is reserved on this interface to ensure RSVP QoS. (On Router C, RSVP is also enabled on interface Hssi0 with 1 kbps reserved, but this bandwidth is used simply for passing messages.)

!
version 12.0
service config
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service udp-small-servers
service tcp-small-servers
!
hostname routerC
!
ip subnet-zero
no ip domain-lookup
ip multicast-routing
ip dvmrp route-limit 20000
!
interface Ethernet0
 ip address 2.0.0.195 255.0.0.0
 no ip directed-broadcast
 no ip route-cache
 no ip mroute-cache
 media-type 10BaseT
!
interface Ethernet1
 no ip address
 no ip directed-broadcast
 shutdown
 media-type 10BaseT
!
interface Ethernet2
 ip address 9.1.1.2 255.0.0.0
 no ip directed-broadcast
 ip pim dense-mode
 ip rsvp bandwidth 20 20
 fair-queue 64 256 1000
 media-type 10BaseT
!
interface Ethernet3
 no ip address
 no ip directed-broadcast
 shutdown
 media-type 10BaseT
!
interface Ethernet4
 no ip address
 no ip directed-broadcast
 shutdown
 media-type 10BaseT
!
interface Ethernet5
 no ip address
 no ip directed-broadcast
 shutdown
 media-type 10BaseT
!
interface Hssi0
 ip address 10.1.1.1 255.0.0.0
 no ip directed-broadcast
 ip pim dense-mode
 ip rsvp bandwidth 1 1
 hssi internal-clock
!
interface ATM0
 no ip address
 no ip directed-broadcast
 shutdown
!
router ospf 100
 network 9.0.0.0 0.255.255.255 area 10
 network 10.0.0.0 0.255.255.255 area 10
 network 11.0.0.0 0.255.255.255 area 10
!
ip classless
ip rsvp reservation 225.1.1.1 12.1.2.1 UDP 7001 7000 9.1.2.1 Et2 FF LOAD 8 1
!
line con 0
 exec-timeout 0 0
 length 0
 transport input none
line aux 0
line vty 0 4
 login
!
end