Introduction to RSVP

IntServ and RSVP

When it comes to Quality of Service (QoS), we have three models that we can use:

• Best Effort (don’t use QoS for traffic that doesn’t need any special treatment.)
• 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 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 an RSVP reservation request using an RSVP path message. This message is passed along the route toward 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 an RSVP resv message. The same process will occur in the opposite direction. Each router will check if they have enough bandwidth/delay for the flow, and if so, it will forward the message to 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 its reservation information? Currently, RSVP is mostly used for MPLS traffic engineering, we use DiffServ for QoS implementations.

Configuration

Anyway, let’s take a look at the configuration of RSVP. I will be using the following topology:

hostname R1
!
interface GigabitEthernet0/1
 ip address 192.168.12.1 255.255.255.0
!
router ospf 1
 network 192.168.12.0 0.0.0.255 area 0
!
end

hostname R2
!
interface GigabitEthernet0/1
 ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.23.2 255.255.255.0
!
router ospf 1
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.23.0 0.0.0.255 area 0
!
end

hostname R3
!
interface GigabitEthernet0/1
 ip address 192.168.34.3 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.23.3 255.255.255.0
!
router ospf 1
 network 192.168.23.0 0.0.0.255 area 0
 network 192.168.34.0 0.0.0.255 area 0
!
end

hostname R4
!
interface GigabitEthernet0/1
 ip address 192.168.34.4 255.255.255.0
!
router ospf 1
 network 192.168.34.0 0.0.0.255 area 0
!
end

R1(config)#interface fa0/0
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 an RSVP host so it will send an 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.

Verification

Let’s verify our work.

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.

Debugging

If you 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 toward 192.168.12.2.