Search

Loading...

VoIP Call Admission Control Using RSVP

RSVP (Resource Reservation Protocol) is an IP service that is used to enable endpoints to request an end-to-end reserved-bandwidth path to ensure that they receive the necessary quality of service.  Once this guarantee has been made, all devices between the endpoints (in this case, voice endpoints) can reliably know that the quality of their connection has been guaranteed.

RSVP requests a certain amount of bandwidth and latency with each network hop that supports RSVP.  If a network node (router) does not support RSVP, RSVP moves onto the next hop.  A network node has the option to approve or deny the reservation based upon the load of the interface to which the service is requested.

This is a topic that I have rarely encountered in the production environments that I have seen, but since it is on the CCIE Voice blueprint it deserves your attention in case you are tested on it.  There is no substitute to researching and testing in the lab - but the information in this post can very well help you answer a question or two on the CCIE Voice written exam.

VoIP Call Admission Control

When a gateway is configured for RSVP, the requested QoS and acceptable QoS values will be configured on the dial-peer that matches the call destination.  These values can be either "controlled-load", "guaranteed-delay", or "best effort".  Depending on the configuration of the originating gateway and the terminating gateway, the call will proceed or fail. The following chart will help explain what happens in a variety of scenarios:


Originating Gateway Terminating Gateway

Requested QoS Acceptable QoS Requested QoS Acceptable QoS Results
1 controlled-load or guaranteed-delay controlled-load or guaranteed-delay controlled-load or guaranteed-delay controlled-load or guaranteed-delay Call proceeds only if both RSVP reservations succeed.
2 controlled-load or guaranteed-delay controlled-load or guaranteed-delay controlled-load or guaranteed-delay best-effort Call proceeds only if both RSVP reservations succeed.
3 controlled-load or guaranteed-delay controlled-load or guaranteed-delay best-effort best-effort Call is released.
4 controlled-load or guaranteed-delay best-effort controlled-load or guaranteed-delay controlled-load or guaranteed-delay Call proceeds only if both RSVP reservations succeed.
5 controlled-load or guaranteed-delay best-effort controlled-load or guaranteed-delay best-effort Call proceeds regardless of RSVP results. If RSVP reservation fails, call receives best-effort service.
6 controlled-load or guaranteed-delay best-effort best-effort best-effort Call proceeds with best-effort service.
7 best-effort best-effort controlled-load or guaranteed-delay controlled-load or guaranteed-delay Call is released.
8 best-effort best-effort controlled-load or guaranteed-delay best-effort Call proceeds with best-effort service.
9 best-effort best-effort best-effort best-effort Call proceeds with best-effort service.

RSVP Bandwidth Calculations

You could be tasked with some very specific call admission requirements that require expert-level knowledge of the bandwidth consumed by RSVP.  Please check out this amazing RSVP post from my friend, Matthew Berry (CCIE #26721).  He shows detailed "debug ip rsvp messages" output and explains how to interpret the results.

RSVP Precondition on Cisco IOS SIP Gateway

This document from Cisco has a very good conceptual explanation about why call admission control (CAC) is an important element in any VoIP design.  It draws comparison between the traditional circuit-switched networks and IP telephony networks.   Building upon this basic comparison, the document continues into greater detail regarding the Cisco RSVP IOS Agent and how it functions.

The concept of RSVP Precondition is the idea that certain conditions must be met before the RSVP session can begin to establish.  This allows the bandwidth resources to be reserved before full session information is actually exchanged, thus minimizing the chances that the bandwidth could actually be consumed by the time the call establishment is attempted (causing the call to fail).

RSVP Basic IOS VoIP Configuration

In this scenario, imagine two analog phones that would like to call one another across an IP network.  Extension 101 resides in New York and extension 901 resides in Chicago.   RSVP setup must complete before the destination phone rings and the call is released if the RSVP setup fails or does not complete within the allotted time (call rsvp-sync resv-timer on the terminating VoIP gateway)

New York Gateway Configuration:

call rsvp-sync
call rsvp-sync resv-timer 10
!
interface GigEthernet0/0
 ip address 10.1.10.1 10.255.255.255
 fair-queue 64 256 31
 ip rsvp bandwidth
!
voice-port 3/0/0
!
dial-peer voice 901 voip
 destination-pattern 901
 session target ipv4:10.1.90.1
 req-qos controlled-load
 acc-qos controlled-load
!
dial-peer voice 101 pots
destination-pattern 101
 port 3/0/0
 
Chicago Gateway Configuration:

call rsvp-sync
call rsvp-sync resv-timer 10
!
interface GigabitEthernet0/0
 ip address 10.10.90.1 10.255.255.255
 fair-queue 64 256 31
 ip rsvp bandwidth
!
voice-port 3/0/0
!
dial-peer voice 101 voip
 destination-pattern 101
 session target ipv4:10.1.10.1
 req-qos controlled-load
 acc-qos controlled-load
!
dial-peer voice 901 pots
 destination-pattern 901
 port 3/0/0


RSVP Command Summary
  • call rsvp-sync - Enables synchronization between RSVP and H.323
  • call rsvp-sync resv-timer n - On terminating gateway, timer for reservation requests
  • ip rsvp bandwidth - Enables RSVP for IP on an interface
  • req-qos controlled-load - Requested QoS level
  • acc-qos controlled-load - Accepted QoS level
  • show call rsvp-sync conf - Show the RSVP configuration
  • show call rsvp-sync stats - Show stats for calls that try to use RSVP
  • debug call rsvp-sync events -Shows events occurring during RSVP synchronization
Additional Information

No comments:

Post a Comment