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
No comments:
Post a Comment