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:
- Configurations
- R1
- R2
- R3
- R4
Want to take a look for yourself? Here you will find the startup configuration of each device.
First we need to enable RSVP on all interfaces:
R1(config)#interface fa0/0
R1(config-if)#ip rsvp bandwidth 128 64R2(config)#interface fa0/0
R2(config-if)#ip rsvp bandwidth 128 64
R2(config)#interface fa0/1
R2(config-if)#ip rsvp bandwidth 128 64R3(config)#interface fa0/0
R3(config-if)#ip rsvp bandwidth 128 64
R3(config)#interface fa0/1
R3(config-if)#ip rsvp bandwidth 128 64R4(config)#interface fa0/0
R4(config-if)#ip rsvp bandwidth 128 64If 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 32I 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 64KAbove, 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 ServiceI 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 32Let’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 64KYou 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 64KR3#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 64KAbove, 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 onNow 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 16This 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.2You can see that R1 has received a path message from itself and that it forwards it toward 192.168.12.2.
R2#
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Received Path message from 192.168.12.1 (on FastEthernet0/0)
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 = 650988D4 refresh interval = 0mSec
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Path message to 192.168.23.3R3#
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Received Path message from 192.168.23.2 (on FastEthernet0/0)
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 = 6508EB64 refresh interval = 0mSec
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Path message to 192.168.34.4R4#
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Received Path message from 192.168.34.3 (on FastEthernet0/0)
R4#
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh Path psb = 6618082C refresh interval = 30000mSec
RSVP: can't forward Path out received interfaceR2 receives the path message from R1 and forwards it to R3, who will forward it to R4. Now let’s configure R4 to respond:
R4(config)#ip rsvp reservation-host 192.168.34.4 192.168.12.1 tcp 80 0 ff rate 64 32This is what you will see:
R4#
RSVP session 192.168.34.4_80[0.0.0.0]: Received RESV for 192.168.34.4 (receiver host) from 192.168.34.4
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: this RESV has a confirm object
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 674BE740
RSVP-RESV: Locally created reservation. No admission/traffic control needed
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: start requesting 64 kbps FF reservation for 192.168.12.1(0) TCP-> 192.168.34.4(80) on FastEthernet0/0 neighbor 192.168.34.3
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh RESV, req=674C39E8, refresh interval=0mSec [cleanup timer is not awake]
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Resv message to 192.168.34.3
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: RESV CONFIRM Message for 192.168.34.4 (FastEthernet0/0) from 192.168.34.3
R3#
RSVP session 192.168.34.4_80[0.0.0.0]: Received RESV for 192.168.34.4 (FastEthernet0/1) from 192.168.34.4
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: this RESV has a confirm object
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 66171920
RSVP-RESV: reservation was installed: 66171920
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: start requesting 64 kbps FF reservation for 192.168.12.1(0) TCP-> 192.168.34.4(80) on FastEthernet0/0 neighbor 192.168.23.2
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh RESV, req=661769B4, refresh interval=0mSec [cleanup timer is not awake]
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Resv message to 192.168.23.2
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: RESV CONFIRM Message for 192.168.34.4 (FastEthernet0/0) from 192.168.23.2
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending RESV CONFIRM message to 192.168.34.4R2#
RSVP session 192.168.34.4_80[0.0.0.0]: Received RESV for 192.168.34.4 (FastEthernet0/1) from 192.168.23.3
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: this RESV has a confirm object
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 674B8E00
RSVP-RESV: reservation was installed: 674B8E00
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: start requesting 64 kbps FF reservation for 192.168.12.1(0) TCP-> 192.168.34.4(80) on FastEthernet0/0 neighbor 192.168.12.1
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh RESV, req=674BDE94, refresh interval=0mSec [cleanup timer is not awake]
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Resv message to 192.168.12.1
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: RESV CONFIRM Message for 192.168.34.4 (FastEthernet0/0) from 192.168.12.1
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending RESV CONFIRM message to 192.168.23.3R1#
RSVP session 192.168.34.4_80[0.0.0.0]: Received RESV for 192.168.34.4 (FastEthernet0/0) from 192.168.12.2
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: this RESV has a confirm object
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 66C95AF4
RSVP-RESV: reservation was installed: 66C95AF4
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending RESV CONFIRM message to 192.168.12.2Above, you can see that each router forwards the RESV message and makes the reservation for this particular flow. That’s all I wanted to show you for now. I hope this helps you to understand RSVP.