Manual RSVP Reservations | Handling Queuing and Congestion

Problem

You want to manually reserve bandwidth through your network to support a real-time application that isn't able to dynamically create new reservations as required.

Solution

In this example, we will assume that we have a host device, acting as the sender, with IP address 192.168.100.202 and a second host, acting as the receiver, with IP address 192.168.9.100. The first host is connected to FastEthernet0/0 Router1:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip address 192.168.100.21 255.255.255.0
Router1(config-if)#ip rsvp bandwidth 128 56
Router1(config-if)#exit
Router1(config)#interface Serial0/0
Router1(config-if)#no ip address
Router1(config-if)#encapsulation frame-relay
Router1(config-if)#fair-queue 64 256 37
Router1(config-if)#ip rsvp bandwidth
Router1(config-if)#exit
Router1(config)#interface Serial0/0.1 point-to-point
Router1(config-subif)#ip address 192.168.55.9 255.255.255.252
Router1(config-subif)#frame-relay interface-dlci 904
Router1(config-fr-dlci)#ip rsvp bandwidth 128 56
Router1(config-subif)#exit
Router1(config)#ip rsvp sender 192.168.9.100 192.168.100.202 UDP 1300 1300 192.168.100.202 FastEthernet0/0 55 1
Router1(config)#end
Router1#

The second host is connected to the Ethernet0/0 interface on Router4, which is several hops away:

Router4# configure terminal
Router4(config)#interface Ethernet0/0
Router4(config-if)#ip address 192.168.9.3 255.255.255.0
Router4(config-if)#ip rsvp bandwidth 128 56
Router4(config-if)#exit
Router4(config)#interface Serial0/0
Router4(config-if)#no ip address
Router4(config-if)#encapsulation frame-relay
Router4(config-if)#fair-queue 64 256 37
Router4(config-if)#ip rsvp bandwidth
Router4(config-if)#exit
Router4(config)#interface Serial0/0.1 point-to-point
Router4(config-subif)#ip address 192.168.56.5 255.255.255.252
Router4(config-subif)#frame-relay interface-dlci 107
Router4(config-fr-dlci)#ip rsvp bandwidth 128 56
Router4(config-subif)#exit
Router4(config)#ip rsvp reservation 192.168.9.100 192.168.100.202 UDP 1300 1300 192.168.9.100 Ethernet0/0 FF RATE 55 1
Router4(config)#end
Router4#

Discussion

It is worthwhile to review how RSVP works before looking at the mechanics of this recipe. A host that wants to send a data stream to a particular destination address or multicast group first makes an RSVP request to its first-hop router. This request asks for a particular set of QoS parameters, such as application bandwidth requirements, and specifies the destination IP address. Each router decides whether it can meet the requirement, accepting or rejecting the reservation. They then make the same request of the next hop router along the path to the destination. Once all of the routers between the source and destination have reserved the appropriate resources, the original host can begin transmitting application data, using the reserved resources along the entire data path.

The method is identical for unicast and multicast reservation requests, with each router relaying the request to a downstream peer until all of the destinations have been reached. Note that RSVP is inherently unidirectional. That is, it requests resources for sending data from a particular source to a particular destination or multicast group. If you want to reserve network resources to support a two-way unicast application, both the sender and the receiver must separately initiate requests.

RESV and PATH messages

There are two general message types in RSVP, PATH, and RESV. The initial request begins with a PATH message. The PATH message describes the specific flow that will use this reservation. So it includes the source and destination IP addresses, as well as the IP Protocol, such as TCP or UDP, and any port numbers. The PATH message also includes the requested average bit rate and burst size.

The PATH message is received by an upstream router, or perhaps the ultimate destination. If it is received by an intermediate router, this router must analyze the request and decide whether it can honor it. Ultimately, if the request is accepted, the router will create a new PATH message, requesting the same resource reservation from the next upstream router, but specifying itself as the source.

PATH messages always flow from the requester toward the destination.

RESV messages flow the opposite direction. The RESV CONFIRM messages describe the actual detailed bit rate and delay characteristics required to fulfill the PATH request. If an upstream router doesn't have the necessary resource to fulfill the request, it responds with an RESV ERROR message.

In Cisco router configuration, you can configure static PATH requests by using the ip rsvp sender and sender-host commands. And you can make static reservations, which will be described to upstream routers in RESV messages, using the ip rsvp reserveration and reservation-host commands. We will describe all of these commands below.

Two service types

There are two distinct types of service that a host can specify in an RSVP request. The first is called Controlled Load Service, which is specified in RFC 2211, and the second, called either Guaranteed Quality of Service or, more accurately, Guaranteed Bit Rate Service, is specified in RFC 2212.

Controlled Load Service, in a nutshell, means that the network behaves as if each segment were completely unloaded and therefore uncongested, but with bandwidth limited to the requested amount. Cisco routers implement this type of service by isolating the different flows and employing queuing mechanisms that mimic this type of response.

Guaranteed Bit Rate Service is somewhat more complicated. This service means that the network will mathematically guarantee the worst-case end-to-end queuing delay. There are two things to note about this description, however. First, it only guarantees the worst-case latency, not the average latency. The second is that, despite this, it is possible to make an estimate of the jitter, as this is governed by the worst-case latency. As long as the worst-case latency is small, then the jitter can be effectively minimized by employing small amounts of buffering on the end devices.

Controlled Load Service is well suited to many TCP applications, which tend to behave well until they encounter congestion and dropped packets. Conversely, Guaranteed Bit Rate Service tends to be a better choice for real-time voice and video applications.

The examples

Everything we have described so far implies that the source and destination host devices or applications are making the RSVP requests. However, this is not necessarily the case. In fact, many applications that require this type of QoS support do not have RSVP capabilities. So, in this recipe, we show how to configure the routers themselves to initiate requests on behalf of the hosts.

For a description of the interface configurations, please refer to Recipe 11.10. That recipe also contains information about the basic RSVP configurations used on the routers between Router1 and Router4 (which we have mysteriously decided to call Router2 and Router3).

The ip rsvp sender command tells the router to act as if it is periodically receiving RSVP PATH requests from the specified source device:

Router1(config)#ip rsvp sender 192.168.9.100 192.168.100.202 UDP 1300 1300 192.168.100.202 FastEthernet0/0 55 1

You use this command as a proxy for a real device that is unable to send real RSVP PATH requests. So it includes all of the information that appears in a PATH request packet.

The first several arguments of this command specify the IP flow that will be using this reservation. The first two arguments specify the source and destination IP addresses, respectively. Then we have stipulated that it will use the UDP protocol with source and destination ports both equal to 1300.

The next two arguments, 192.168.100.202 and FastEthernet0/0, specify the previous-hop IP address and interface, respectively. Because we put this command on the first hop router, they may seem redundant, but actually we could put this command anywhere in the network to simulate an upstream source device.

The last two arguments request an average bit rate of 55 kbps and a burst of 1 kbyte.

Then, on the other router, we have configured a corresponding command that simulates a device sending RSVP RESV messages back toward the source:

Router4(config)#ip rsvp reservation 192.168.9.100 192.168.100.202 UDP 1300 1300 192.168.9.100 Ethernet0/0 FF RATE 55 1

Many of the arguments of this command are identical to what we saw a moment ago for the sender command. We specified the same IP addresses and UDP port numbers to define the flow. And the last two arguments just duplicate the average bit rate and burst size from the previous discussion.

The differences are where the sender command specified the previous-hop IP address and interface, here we specify the next-hop IP address and interface. Then we have two new keywords, FF and RATE.

The FF keyword indicates that this is a Fixed Filter style reservation. There are three available styles of reservation. Fixed Filter means that this reservation is for a particular flow specification only. No other applications or sessions are permitted to use it. We could have instead specified either SE or WF.

SE indicates that the router will use a Shared Explicit filter for the reservation. This means that the receiving device is specifying a list of source devices and indicating that they may all share the same reservation.

And WF means that the reservation can be shared by a Wildcard Filter. This effectively means that any source can take part in this reservation.

Finally, the RATE keyword in the ip rsvp reservation command tells the network to use Guaranteed Bit Rate service type. The other option here is LOAD, which indicates a Controlled Load service type. The receiver makes this service type request, which is why it only appears in the ip rsvp reservation command, and not in the ip rsvp sender command.

There are several useful commands for looking at the RSVP reservations. You can look at the current status of any PATH and RESV messages passing through your network with the show ip rsvp sender and show ip rsvp reservation commands. These commands give the full details on every such RSVP exchange, whether it originates with a static command on the router, as in this recipe, or a dynamically generate request from a real host:

Router1#show ip rsvp sender
To From Pro DPort Sport Prev Hop I/F BPS
192.168.9.100 192.168.100.202 UDP 1300 1300 192.168.100.202 Fa0/0 55K
Router1#show ip rsvp reservation
To From Pro DPort Sport Next Hop I/F Fi Serv BPS
192.168.9.100 192.168.100.202 UDP 1300 1300 192.168.55.10 Se0/0.1 FF RATE 55K

Router1#

So if we go to another router in the path and enter these commands again, we see the same information:

Router2#show ip rsvp sender
To From Pro DPort Sport Prev Hop I/F BPS
192.168.9.100 192.168.100.202 UDP 1300 1300 192.168.55.9 Se0/0.1 55K
Router2#show ip rsvp reservation
To From Pro DPort Sport Next Hop I/F Fi Serv BPS
192.168.9.100 192.168.100.202 UDP 1300 1300 192.168.101.7 Fa0/0 FF RATE 55K

Router2#