Introduction to RSVP

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:

Four Routes Square R1 R2 R3 R4

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.

Debugging RSVP

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.

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 657 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

521 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. I’ve been searching for an RSVP implementation for linux and haven’t had good luck. Any chance you have come across anything? It seems like there hasn’t been any work since 2000.
    Thanks!

  2. Hello Rene,
    I hope u r doing well!
    I want to know what in this command line:

    R4(config)#ip rsvp reservation-host 192.168.34.4 192.168.12.1 tcp 23 0 ff rate 64 32

    The double ff means please?

    BR,
    Ulrich

  3. Hi,
    If i have 10 Mbps leased-line connect HQ and Branch and i set up InterSrv or DiffSrv between my 2 edge router . QoS for high priority for a service , example http

    1- Qos by DiffSrv : When no congestion on Leased-line ( traffic < 10 Mbps), Qos no affect ? or http traffic going to high priority only when have congestion ?

    2- QoS by InterSrv : If i config 2 Mbps for RSVP, allway have only 2 Mbps for http traffic , if over 2 Mbps, it drop . Others traffic can using 8 Mbps ?

    Thank .

  4. Hello Timothy

    RSVP is used in Cisco Unified Communications architecture in a feature called Call Admission Control (CAC) makes a bandwidth reservation using RSVP along the full length of the path between the two communicating endpoints. Look at the following diagram that comes from Cisco documentation (the link to this document is shown further below).

    //cdn-forum.networklessons.com/uploads/default/original/2X/3/3cf3897fc3e342ebbd654bd163a02820371f58d2.jpeg

    There is a SIP session that is initiated between two user agents (UAs). These can be phones, gateways,

    ... Continue reading in our forum

  5. Thanks Stefanita, just fixed this.

    Rene

22 more replies! Ask a question or join the discussion by visiting our Community Forum