IntServ and RSVP
When it comes to QoS we have two models that we can use:
- DiffServ (Differentiated Services)
- IntServ (Integrated Services)
In short, when using DiffServ we implement QoS on a “hop by hop” basis where we use the ToS byte of IP packets for classification. IntServ is completely different, it’s a signaling process where network flows can request a certain bandwidth and delay that is required for the flow. IntServ is described in RFC 1633 and there are two components:
- Resource reservation
- Admission control
Resource reservation signals the network and requests a certain bandwidth and delay that is required for a flow. When the reservation is successful each network component (mostly routers) will reserve the bandwidth and delay that is required. Admission control is used to permit or deny a certain reservation. If we would allow all flows to make a reservation, we can’t guarantee any service anymore…
When a host wants to make a reservation it will send a RSVP reservation request using a RSVP path message. This message is passed along the route towards the destination. When a router can guarantee the required bandwidth/delay it will forward the message. Once it reaches the destination it will reply with a RSVP resv message. The same process will occur for the opposite direction. Each router will check if they have enough bandwidth/delay for the flow and if so, they will forward the message towards the source of the reservation. Once the host receives the reservation message we are done.
Now this might sound nice but the problem with IntServ is that it’s difficult to scale…each router has to keep track of each reservation for each flow. What if a certain router doesn’t support Intserv or loses it’s reservation information? Currently RSVP is mostly used for MPLS traffic engineering, we use DiffServ for QoS implementations.
RSVP Configuration Example
Anyway let’s take a look at the configuration of RSVP, I will be using the following topology:
First we need to enable RSVP on all interfaces:
R1(config-if)#ip rsvp bandwidth 128 64
R2(config)#interface fa0/0 R2(config-if)#ip rsvp bandwidth 128 64 R2(config)#interface fa0/1 R2(config-if)#ip rsvp bandwidth 128 64
R3(config)#interface fa0/0 R3(config-if)#ip rsvp bandwidth 128 64 R3(config)#interface fa0/1 R3(config-if)#ip rsvp bandwidth 128 64
R4(config)#interface fa0/0 R4(config-if)#ip rsvp bandwidth 128 64
If you don’t specify the bandwidth then by default RSVP will use up to 75% of the interface bandwidth for reservations. I’m telling RSVP that it can only use up to 128 kbps for reservations and that the largest reservable flow can be 64 kbps.
Now we’ll configure R1 to act like a RSVP host so it will send a RSVP send path message:
R1(config)#ip rsvp sender-host 192.168.34.4 192.168.12.1 tcp 23 0 64 32
I will make a reservation between destination 192.168.34.4 and source 192.168.12.1 using TCP destination port 23 (telnet). The source port is 0 which means it can be anything. The average bitrate is 64 kbps with a maximum burst of 32 kbps.
R1#show ip rsvp sender To From Pro DPort Sport Prev Hop I/F BPS 192.168.34.4 192.168.12.1 TCP 23 0 192.168.12.1 64K
Above you see the reservation that we configured on R1. Now let’s configure R4 to respond to this reservation:
R4(config)#ip rsvp reservation-host 192.168.34.4 192.168.12.1 tcp 23 0 ff ? load Controlled Load Service rate Guaranteed Bit Rate Service
I can choose between controlled load or guaranteed bit rate. Guaranteed means the flow will have a bandwidth and delay guarantee. Controlled load will guarantee the bandwidth but not the delay.
R4(config)#ip rsvp reservation-host 192.168.34.4 192.168.12.1 tcp 23 0 ff rate 64 32
Let’s verify our configuration on R4:
R4#show ip rsvp reservation To From Pro DPort Sport Next Hop I/F Fi Serv BPS 192.168.34.4 192.168.12.1 TCP 23 0 192.168.34.4 FF RATE 64K
You can see that it has received the reservation from R1. What about R2 and R3?
R2#show ip rsvp reservation To From Pro DPort Sport Next Hop I/F Fi Serv BPS 192.168.34.4 192.168.12.1 TCP 23 0 192.168.23.3 Fa0/1 FF RATE 64K
R3#show ip rsvp reservation To From Pro DPort Sport Next Hop I/F Fi Serv BPS 192.168.34.4 192.168.12.1 TCP 23 0 192.168.34.4 Fa0/1 FF RATE 64K
Above you can see that R2 and R3 also made the reservation. We can also check RSVP information on the interface level:
R2#show ip rsvp interface detail | begin Fa0/1 Fa0/1: Interface State: Up Bandwidth: Curr allocated: 64K bits/sec Max. allowed (total): 128K bits/sec Max. allowed (per flow): 64K bits/sec Max. allowed for LSP tunnels using sub-pools: 0 bits/sec Set aside by policy (total): 0 bits/sec Admission Control: Header Compression methods supported: rtp (36 bytes-saved), udp (20 bytes-saved) Traffic Control: RSVP Data Packet Classification is ON via CEF callbacks Signalling: DSCP value used in RSVP msgs: 0x3F Number of refresh intervals to enforce blockade state: 4 Number of missed refresh messages: 4 Refresh interval: 30 Authentication: disabled
Above you can see how R2 reserved 64 kbps on its FastEthernet0/1 interface.
If you really want to see what is going on you should enable a debug, let’s do so on all routers:
R1,R2,R3,R4#debug ip rsvp RSVP signalling debugging is on
Now let’s create a new conversation on R1:
R1(config)#ip rsvp sender-host 192.168.34.4 192.168.12.1 tcp 80 0 32 16
This is what you will see:
R1# RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Received Path message from 192.168.12.1 (on sender host) RSVP: new path message passed parsing, continue... RSVP: Triggering outgoing Path refresh RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh Path psb = 66C8D7CC refresh interval = 0mSec RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Path message to 192.168.12.2
You can see that R1 has received a path message from itself and that it forwards it towards 192.168.12.2.