Call Admission Control

Call admission control (CAC) is used to protect the quality of your voice calls by preventing call completion if not enough resources are available to support it. CAC is needed over an IP WAN because IP does not possess the ability of the time-division multiplexing (TDM) world to meter calls. When a POTS line is in use, or a DS0 in a PRI is in use, the gateway cannot use that link for additional calls. But nothing is inherent in an IP interface that stops more packets from attempting to use it.

It is generally recognized that a voice network needs quality of service (QoS) mechanisms. However, QoS just protects voice from interference by data traffic. It does not protect voice from voice. Consider a router that is configured with a low-latency queue (LLQ) for voice, and that queue is allocated enough bandwidth for ten calls. Then suppose that an eleventh call is placed. QoS would not prevent the router from sending that call. Instead, the queue would fill up faster, and voice packets would start to be dropped. This would affect the quality of all 11 calls, not just the extra one.

CAC techniques attempt to remedy this. If CAC were implemented, the eleventh call could be rerouted to another VoIP dial peer or out to the PSTN. If the call came from a TDM switch, it could be returned to that switch for handling.

Many different types of CAC exist, and each uses different methods to decide whether to allow a call. CAC techniques can be divided into three categories:

• Local
• Measurement based
• Resource based

This section discusses each CAC type to help you decide which ones to use in your network. You can deploy multiple types of CAC mechanisms on the same gateway. If so, the gateway goes through a sequence of checks against the CAC types. If any of these tests rejects the call, the process ends at that point, and no further checking is done.

When multiple CAC mechanisms are configured, the selection process follows these steps:

Network components other than a gateway can also make CAC decisions. In a network that uses Cisco CallManager, it is the CallManager, not the gateway, that usually makes CAC decisions. You can configure CallManagers with locations. You assign phones and other devices to a location when you add them to CallManager. Configure CallManager with a maximum bandwidth for audio and for video calls for each location. It then allows calls to or from that location across the WAN only if sufficient bandwidth is available. In addition, you can configure CallManager to use RSVP for some locations and not for others.

You can also configure gatekeepers to do CAC. Gatekeepers base their decisions either on bandwidth between zones or gateway resource availability. The section "Resource-Based CAC Mechanisms" has more information. SIP proxy servers can make CAC decisions in SIP networks.

Local CAC Mechanisms

Local CAC mechanisms are configured on the outgoing gateway, and they are aware only of local conditions. They base their call routing decisions on either the number of current calls or the state of the interface to which calls are routed. If that works for your network, you do not need to introduce the extra complexity of other techniques. Local CAC mechanisms are relatively easy to configure, and they have low overhead.

Physical DS0 Limitation

A straightforward way to limit the number of calls over the IP WAN is to limit the number of internal calls coming to the gateway. A router that is connected to a PBX with six POTS lines will never have more than six calls active over the WAN. If the router is connected to the PBX with a PRI, the number of timeslots can be configured. When all the DS0 channels are in use, the PBX is responsible for rerouting outbound calls to the PSTN.

Maximum Connections

You can configure the number of calls allowed per dial peer by using the max-conn number command under dial-peer configuration mode. The default is to allow an unlimited number of calls. In Example 11-6, five connections are allowed to phone numbers beginning with 11.

Keep in mind that this is just for the specific dial peer, not for the interface or the network as a whole. Limiting connections could be useful in a network with a few sites having a small number of phones and low WAN bandwidth. You must configure a separate dial peer for each remote site. The number of calls allowed on the egress interface is equal to the sum of all the connections that are allowed. The max-conn command helps limit the bandwidth use of the gateway WAN interface, and it prevents remote sites from being overwhelmed by calls that they will deny. However, it does not adjust to topology changes or WAN usage, and it works only in gateways that use dial peers.

Local Voice Busyout

Local voice busyout (LVBO) is used on a gateway that is connected to a PBX and an IP WAN. It tells the router to watch an interface, and if that interface goes down, the router busies out the ports or trunks to the PBX. This appears to the PBX as if the ports are off-hook. Multiple interfaces can be tracked; all must be down before the router busies out a voice port.

You should only use LVBO when the gateway is connected to a PBX, and the PBX connects to the PSTN. The PBX can then reroute internal callers to the PSTN instead of over the IP WAN. If you use it on a router that is a PSTN gateway, the PSTN interfaces are taken out of service, which stops external calls from coming into the network. That is usually not the desired result.

Note

LVBO tracks only the up or down status of an interface, not its usage.

LVBO can monitor LAN, WAN, and virtual interfaces and subinterfaces. You configure LVBO under the voice port configuration mode, as shown in Example 11-7.

You can add an additional command, busyout action graceful, to the voice port configuration. The router then busies out the port only after active calls hang up. In H.323 networks that use gatekeepers, you can monitor the gatekeeper, and busy out ports if the gateway is unreachable, by using the busyout monitor gatekeeper command.

Measurement-Based CAC Mechanisms

Measurement-based CAC mechanisms look beyond the local router, into the network between the originating and terminating gateways. They attempt to measure network congestion by sending probes through the network to measure latency, delay, and jitter. The outgoing gateway uses this information to permit or deny calls. The router can reroute calls when network delay or packet loss is too high, or it can busy out voice ports so that they will not be used. The functionality to send and respond to probes is part of the Cisco IOS. In Cisco IOS releases after 12.3(14)T, the feature is called IP Service Level Agreement (IP SLA). IP SLA is an extension to the Service Assurance Agent (SAA) and Response Time Reporter (RTR) features that are present in Cisco IOS versions prior to 12.3(14)T. New commands using the ip sla syntax have been released beginning with Cisco IOS version 12.4.

IP SLA

IP SLA is a network monitoring and management feature that is part of the Cisco IOS. It enables you to proactively monitor and measure network performance for specific applications, not just in general. IP SLA works by sending probes to the IP address of a target device, which responds to them. When a Cisco router is the target, you can configure it as an IP SLA responder and return more accurate information. For instance, an IP SLA responder adds timestamps to the response packets so that router processing delay is not counted as part of the round-trip time. You can configure an IP SLA responder to listen only on a certain port for probe packets. You can use MD5 authentication between IP SLA sources and responders for enhanced security.

You can schedule IP SLA probes to run at a certain time, or you can run them at periodic intervals. These probes can emulate many different types of network traffic, such as FTP, Dynamic Host Configuration Protocol (DHCP), and HTTP. For VoIP and CAC, typically User Datagram Protocol (UDP) and Real-Time Transport Protocol (RTP) headers are used to emulate voice traffic, measuring jitter, gatekeeper delay, post dial delay, and RTP operations. Codec can be specified for the probes, and IP SLA will send a configurable number of packets sized appropriately for the type of codec. You can set type of service (TOS) values so that the probes receive the same QoS treatment as voice.

Measurements include jitter, round-trip time, packet loss, and one-way delay. From this information, IP SLA estimates voice quality using the Calculated Planning Impairment Factor (ICPIF) and Mean Opinion Scores (MOS) described in the next section of this chapter.

You can retrieve this information from the command line with show commands, but its real usefulness lies in the ability of the router to store the results in MIBs. Then you can retrieve the information via Simple Network Management Protocol (SNMP) so that applications, such as CiscoWorks and some third-party applications, can use it. A change in network performance can trigger alerts or other types of probes to troubleshoot the problem, for instance. Companies that are considering moving to VoIP need to be sure that their network will support it, and IP SLA is one way to test that.

Calculated Planning Impairment Factor and Mean Opinion Scores

IP SLA uses the information it gathers from its probes to provide estimates of probable voice quality. If network conditions are such that voice quality will be too low, calls can be rejected or rerouted, or troubleshooting measures can be triggered. Voice quality is measured in two ways:

• ICPIF
• MOS

ICPIF is an International Telecommunications Union Telecommunication Standardization Sector (ITU-T) recommendation that attempts to objectively measure voice quality by measuring network elements that impair voice call quality. In calculating an ICPIF value, Cisco uses a formula that simplifies to icpif = idd + ie A, where

• idd (delay impairment factor) equals one-way delay.
• ie (equipment impairment factor) equals percent of packet loss.
• A (advantage factor, sometimes called expect factor) equals a value that is meant to reflect the fact that users accept some quality degradation under certain circumstances. Cisco assumes a value of 0 for this variable, but that is configurable.

The result of this calculation is a value representing the probable voice quality of a call sent across the circuits traversed by the probe, at the moment the probe is sent. ICPIF values range between 5 and 55, and they are assigned the meanings shown in Table 11-1.

Voice quality is a fairly subjective thing. What might be adequate for one person might be intolerable for another. MOS is a rating of voice quality obtained by averaging the opinions of a wide range of listeners. Table 11-2 shows the MOS values, their meanings, and the equivalent ICPIF values.

IP SLA calculates the ICPIF and MOS values, and measurement-based CAC mechanisms can use these values to allow or disallow a call. You can also configure a maximum ICPIF value for calls that a VoIP dial peer sends.

Configuring IP SLA

Begin configuring IP SLA by choosing the routers on which it will be used. If you are using it to test a network, configure it on the routers at each end of the network. If you are using it to troubleshoot a problem, you might want to test network performance between each hop. If you plan to use IP SLA as a network monitoring tool, sending probes regularly, you should be aware that the tool has a performance cost. If you need to send a lot of probes, such as at a hub site that monitors remote sites, consider using a dedicated router as the IP SLA source router. This also gives you one central location from which to gather measurements.

Enter IP SLA configuration mode with the ip sla operation-number global command. The operation-number identifies a unique IP SLA instance. From there, you can configure the type of traffic to be measured. The measurements typically of concern to voice are contained under UDP jitter commands. For UDP jitter, the minimum required command is udp-jitter {destination_IP-address | destination_hostname} {port-number}. Additional options to this command include the following:

• codec Configures the codec type for IP SLA packets to use. When codec is specified, you can optionally configure codec-interval, codec-numpackets, and codec-size. The default interval between packets is 20 ms, the default number of packets sent is 1000, and the default size is 160 bytes for G711 and 20 bytes for G729.
• control {enable | disable} Enables or disables the sending of IP SLA control packets from the source to the responder. It is enabled by default; disabling it results in less accurate measurements.
• interval interval Configures the interpacket interval in milliseconds. The default is 20 ms.
• num-packets packets Sets the number of packets to send. The default is ten.
• source-ip {ip-address | hostname} Specifies a source IP address or hostname. Without this option, the router uses the IP address of the exit interface.
• source-port {port-number} Configures the source port for IP SLA packets. When this option is not set, the router chooses a port.

You can also set a TOS value for the IP SLA packets. IP SLA looks at the first 4 bits of the TOS byte in the IP header, but the value of these bits is calculated as if all 8 bits were used. For instance, an IP precedence of 5 and a differentiated services code point (DSCP) value of 40 both equate to an IP SLA TOS of 160. In IP SLA jitter configuration mode, give the tos value command.

After you have configured an IP SLA operation, you can schedule it. You can have it run immediately, on a regular basis, or at some point in the future. Use the ip sla schedule operation-number [ageout seconds] [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [recurring] global command. After you have scheduled an operation, you cannot change its configuration. If you need to make changes, you must delete and re-create that operation.

To configure a router as an IP SLA responder, code the ip sla responder command in global configuration mode.

To enable MD5 authentication of IP SLA packets, complete the following steps on both the source and the responder routers:

You can create several keys for a specific key chain, but be sure to create them in the same order on both routers. If multiple keys exist, the routers will rotate key use during their communication. After the key chain is complete, configure IP SLA to use authentication with the ip sla key-chain name global command.

Example 11-8 shows the configuration of IP SLA source (Boise) and responder (Miami) routers. The routers use MD5 authentication for the IP SLA packets. UDP jitter is being measured using a destination port of 65424 and the G729 codec. A TOS value of 176 is used, which corresponds to an IP precedence of 5, and DSCP of 46 (expedited forwarding). The probe is scheduled to run every day at 9:00 am. In the output of the show ip sla statistics command, you can see the measured round-trip time, latency, jitter, and packet loss. The calculated ICPIF and MOS values are shown in the shaded area. PSTN fallback can use these values, which is discussed in the next section.

IP Service Assurance Agent and Response Time Reporter

For routers with IOS version prior to 12.3(14)T, you will need to configure probes using the SAA and RTR. Begin configuring SAA with the rtr number global command. The number simply identifies an RTR instance and takes you to RTR configuration mode. From there, enable RTR measurement type jitter, and then add the additional configuration needed. The entire command syntax is type jitter dest-ipaddr {hostname | ip-address} dest-port port-number codec codec-type[codec-numpackets number-of-packets] [codec-size number-of-bytes][codec-interval time-interval] [advantage-factor value][source-ipaddr {hostname| ip-address}] [source-port port-number] [control {enable | disable}]. Table 11-3 lists the meaning of each of these command options.

On the router that will be the RTR responder, the only command needed is rtr responder at global configuration mode. Once SAA is configured, you can either schedule it to run at another time or tell it to run immediately. The command is given at global configuration mode: rtr schedule rtr-number start-time {after | pending | hh:mm | hh:mm:ss | now}. Verify your SAA configuration with the show rtr configuration rtr-number command. After SAA has run, the ICPIF and MOS values can be observed with the show rtr operational-state rtr-number command or the show rtr collection-statistics rtr-number command.

PSTN Fallback

PSTN fallback, also referred to as call fallback, is a feature that uses statistics collected by probes to decide when to reroute a call to the PSTN or another IP path, or when to deny a call altogether. This call fallback feature lets you specify the thresholds to use based either on ICPIF or solely on delay and packet loss. You can use it on both H.323 and SIP gateways. PSTN fallback is typically used for toll bypass situations, where VoIP gateways connect PBX voice networks.

PSTN fallback makes call admission decisions on a call-by-call basis. The router keeps a cache of recently used destinations and the call quality values associated with them. After a destination is in the cache, the router sends probes periodically to keep the information accurate. If a destination gateway has no more calls, its entry ages out of the cache.

When an outgoing call arrives at the gateway, one of three things happens:

• The gateway checks its cache and does not find an entry for the destination gateway. It then sends a probe to that IP address and waits for a response. Call setup does not continue until the probe results are received. This causes some post call delay, but only for the first call to that remote gateway. If the ICPIF or packet loss and delay values are below the configured threshold, the call is allowed, and the probe results are added to the cache. Call setup proceeds.
• The gateway checks its cache, finds an entry for the destination gateway, and determines that the results are okay. No probe is sent, and the call is allowed. Call setup proceeds.
• The gateway checks its cache, finds an entry for the destination gateway, and determines that the results were above the configured threshold. The call is rejected. If a secondary dial peer is available, the call is sent to that dial peer. If that peer is not available, and the call came from a PBX, the call can be hairpinned back to the PBX.

You can use a series of call fallback commands to configure PSTN fallback on the outgoing gateway. Some of the most frequently used commands are described in Table 11-4. For a complete list of the call fallback commands, go to Cisco.com. Call fallback configuration is done at global configuration mode, so it applies to all calls. However, you can disable fallback for a specific dial peer so that calls denied by the primary dial peer do not fall back to it. The only configuration needed on the terminating gateway is the ip sla responder global command. For Cisco IOS versions prior to 12.4, use the rtr responder global command.

Verify PSTN fallback configuration with the show call fallback config command. If you have enabled fallback without other adjustments, this command shows you the default values. If you have changed any of the parameters, this command allows you to verify the changes. The show call fallback cache command reveals the current cache entries. The show call fallback stats command exhibits fallback statistics, such as accepted and rejected calls. You can send a test probe and view the ICPIF values with the test call fallback probe ip-address command. Two debug commands that can be helpful are debug call fallback probe and debug call fallback details.

Advanced Voice Busyout

Like LVBO, advanced voice busyout (AVBO) is used on routers that are connected to PBXs. It can busy out voice ports or trunks, causing the connected PBX to reroute its calls. AVBO, however, can make its decisions based on measurements of network conditions as well as interface status. Call fallback must first be enabled in order for probes to be sent. AVBO configuration is done either under the voice port or voice class busyout configuration modes. The command syntax to configure AVBO using probes is busyout monitor probe ip-address [codec codec-type] [icpif number | loss percent delay milliseconds].

Specifying the codec is optional, and the CAC decision can be made on either ICPIF results or packet loss and delay. The default codec is G711alaw. The default threshold is the one that the call fallback command uses. You must configure the terminating gateway as an IP SLA or RTR responder.

If you have multiple dial peers, you can use the same command in a voice class. If you are using the voice class busyout configuration, you can also trigger ABVO based on interface status with the busyout monitor interface command. You must then assign the voice class to a voice port with the voice class busyout tag command.

Resource-Based CAC Mechanisms

Resource-based CAC mechanisms examine the resources that are available for a call. These can be resources that are local to the router, such as CPU and memory, or they can be network resources, such as bandwidth. Two types of resource-based CACresource availability indication (RAI) and gatekeeper zone bandwidthare used in H.323 networks with gatekeepers.

Local Gateway Resources

You can configure CAC based on local system resources when using H.323 and SIP gateways. The global call threshold command has options for global resources, such as CPU, memory, and total calls, and interface resources based on number of calls. You configure a high and low threshold. Call threshold is used in conjunction with the call treatment command, as shown in the following steps:

Additionally, you can limit the number of PSTN calls that the router receives within a configurable time with the call spike global command.

To verify your configuration, use the following commands:

• show call threshold {config | stats | status}
• show call treatment {config | stats}
• show call spike status

Gatekeeper Zone Bandwidth

In this chapter you have learned some ways that gateways can control the number of calls they allow outside their local network. In a CallManager network, CallManager can also control call admission. However, in a network that has multiple CallManager clusters or multiple gateways, it can help to have a central authority. One device (or group of devices) that tracks the available bandwidth for every cluster and location could make intelligent, dynamic call admission decisions. In an H.323 network, you can configure gatekeepers to perform that function. When using a gatekeeper, you divide your network into zones and then tell the gatekeeper the bandwidth allowed for calls within and between zones. Gateways are configured to contact the gatekeeper before allowing a call to be set up. The gatekeeper tracks the number of calls for each zone and does not allow calls that exceed the maximum bandwidth.

On the gateways, under the VoIP dial peer, configure the command session target ras. That command tells the gateway to send a Registration, Admission, and Status (RAS) message to the gatekeeper before continuing the call setup for that dial peer. You can configure a backup to the gatekeeper by using preference values with your dial peers. Set the primary dial peer with a session target of RAS so that in normal circumstances, the gatekeeper can make CAC decisions. Use preference to set a secondary dial peer pointing to the PSTN or some other local link.

For more detailed information on this topic, see Chapter 16, "Deploying Gatekeepers."

Resource Availability Indication

Resource Availability Indication (RAI) also involves RAS messages between an H.323 gateway and gatekeeper, but in this case, it is the gateway that makes the CAC decision. The gateway sends a RAS message to its gatekeeper indicating whether it is able to accept incoming calls. RAI is useful in networks in which the gateway connects to a PBX or the PSTN via PRI circuits and processes incoming called numbers that would need to be routed out that PBX or PSTN link. RAI uses a high and a low threshold value based on the digital signal processor (DSP) and DS0 use within the gateway. When resource usage reaches the high threshold, the gateway sends an "AlmostOutOfResources" message to the gatekeeper. The gatekeeper stops sending calls for those phone numbers to that gateway. When usage falls below the low threshold value, the gateway notifies its gatekeeper, and calls are routed to that gateway once again.

For more detailed information on this topic, see Chapter 16.

Resource Reservation Protocol

RSVP is also a resource-based CAC mechanism. It is an Internet Engineering Task Force (IETF) protocol that is unique among CAC mechanisms in that it can reserve end-to-end resources for the length of the call. Other mechanisms might measure network resources at the time the call is initiated, but they cannot guarantee that conditions will remain acceptable during the call. When using RSVP, each RSVP-enabled router along the call path reserves bandwidth and the requested QoS for the duration of that call. Reservations are made on a flow-by-flow basis, so each call has its own reservation. If any router along the path cannot reserve the requested resources, the originating gateway or CallManager can reroute the call or send it as unreserved traffic.

RSVP is typically used in networks that have limited bandwidth and frequent congestion. It is most appropriate for traffic that cannot tolerate much delay or packet loss, such as voice and video, although it can be used for data, too. One drawback to RSVP is that the reservation process causes some delay in call setup. To minimize this, include RSVP control messages in your QoS configuration to ensure bandwidth and prioritized handling for them.

Some applications and devices are RSVP aware, and initiate their own reservations. More typically, either the gateways or CallManager controls the reservation process, acting in proxy for the devices to create a reserved path.

Although RSVP acts independently of the call signaling protocol, the traditional way to use it for CAC requires configuration of VoIP dial peers. Thus, traditional gateway-controlled RSVP can be used only with H.323 and SIP gateways, which require dial peers. H.323 and SIP gateways must know to delay call setup until reservations have been made; extensions to those protocols have been created to allow this. Network routers should be running at least Cisco IOS 12.1(5)T to implement gateway-controlled RSVP for H.323 traffic and 12.2(8)T for SIP. RSVP operates with both IPv4 and IPv6.

In CallManager 5.0, Cisco introduced an RSVP agent that allows RSVP to be used with all gateway protocols, including Media Gateway Control Protocol (MGCP). With RSVP agent, CallManager initiates the reservations. When a call needs a reservation to be created, CallManager instructs the RSVP agent on the gateway to begin the reservation process. The gateway reports back to the CallManager on the success or failure of the reservation, and CallManager then allows or disallows the call. This process is described in the section "CallManager-Controlled RSVP with RSVP Agent." RSVP agent requires CallManager version 5.0 or above. It is supported in router Cisco IOS version 12.4(6)T or above on Cisco 2600XM, 2691, 2800, 3700, and 3800 routers.

Gateway-Controlled RSVP

Figure 11-2 shows how a reservation is created between two gateways when using traditional gateway-controlled RSVP. Keep in mind that this process happens in both directions. Reservations are made per flow; a flow is identified in RSVP by a destination IP address, protocol ID, and destination port. One reservation is made from terminating to originating gateway, and another reservation is made from originating to terminating gateway.

Figure 11-2. RSVP Reservation Process

In Figure 11-2, both endpoints are IP phones that are not RSVP aware.

The RSVP portion of call setup proceeds as follows:

1. A phone behind GW4 initiates an H.323 call to a phone behind GW1. When the terminating gateway, GW1, receives the call setup information, it sends an RSVP PATH message toward the IP address of the originating gateway. It does this before it tells the phone to ring. PATH messages contain the IP address of the previous hop (PHOP) so that return messages can follow the same path back. They also describe the bandwidth and QoS needs of the call traffic.
2. The next hop router, GW2, is configured with RSVP. It records the previous hop information and forwards the PATH message. Notice that it inserts its IP address as the PHOP address. The destination address is still the remote gateway.
3. The third router, GW3, does not have RSVP configured. The PATH message looks just like a normal IP packet to this router, and it routes the message untouched toward the destination, just as it does any IP packet.
4. The fourth router, GW4, is the originating gateway. When it receives the PATH, it sends an RESV message to the previous hop address listed in the PATH message. This RESV message requests the needed QoS. If any router along the way does not have sufficient resources, it returns an error message and discards the RESV message. GW4 also initiates a PATH message toward GW1 to reserve resources in the other direction.
5. The RESV and PATH messages again look like normal IP packets to GW3, the non-RSVP router, so it simply routes the packets toward GW2. No resources are reserved on this gateway.
6. GW2 receives the RESV message and checks to see if it can supply the requested resources. If the check succeeds, it creates a reservation for that flow and then forwards the RESV message to the previous hop IP address listed in the PATH message it received earlier. When the other PATH message arrives, GW2 processes it and sends it to GW1.
7. When GW1 receives the RESV message, it knows that its reservation has succeeded. However, the reservation must succeed in each direction before it can continue call setup.

   GW1 responds to the second PATH message with an RESV message, which proceeds through the network as before. When GW4 receives the RESV message, resources have been reserved in both directions. GW4 responds with a ResvConf message, confirming the reservation.

8. Call setup has been delayed during the exchange of messages. When GW1 receives the ResvConf message, it knows that reservations have been made in both directions. Call setup can now proceed. RSVP then sends periodic refresh messages along the call path, enabling it to dynamically adjust to routing changes.

Configuring Gateway-Controlled RSVP

Before you configure RSVP, you need to decide how much bandwidth to allocate per flow and how much total bandwidth to allow RSVP to use, per interface. By default, you can reserve up to 75 percent of the interface bandwidth. Consider how much bandwidth is used per flow. This amount depends on the codec. By default, any flow can use up to the total reserved bandwidth, but this is configurable. Consider the expected call volume through that interface to determine the total amount of bandwidth to reserve. Remember to allow bandwidth for any other applications that use that interface.

You must configure RSVP on each router that will create reservations. It is enabled at the interface configuration mode with the ip rsvp bandwidth [total-kbps] [single-flow-kbps] command. If you do not specify the total bandwidth to reserve, the router reserves 75 percent of the interface bandwidth. If no flow value is specified, any flow can reserve the entire bandwidth.

To set the DSCP value for RSVP control messages, use the ip rsvp signalling dscp {dscp-value} interface command.

Synchronization between RSVP and call setup is enabled by default. If it has been disabled, the command to enable it is call rsvp-sync.

For RSVP to act as a CAC mechanism, also configure the requested and acceptable QoS parameters under any dial peers that RSVP will use. The req-qos command instructs the gateway to initiate an RSVP reservation for a call to that dial peer and specifies the type of QoS to request. The acc-qos command determines how strict the CAC must be. This must be done on both the originating and terminating gateways. It is recommended that both the requested and acceptable QoS be set to guaranteed-delay. The guaranteed-delay option tells RSVP to reserve bandwidth and to guarantee a minimum bit rate and priority treatment. The commands, under dial-peer configuration mode, are req-qos guaranteed-delay and acc-qos guaranteed-delay.

Example 11-9 shows a basic RSVP configuration. RSVP is enabled, and its signaling is marked with DSCP 31 under the interface configuration mode. The guaranteed delay commands are given under the outgoing dial peer.

A useful command to verify your RSVP configuration is show ip rsvp interface [detail]. Example 11-10 shows the output from this command, based on the configuration in Example 11-9. After RSVP is working within your network, you can observe the reservations made with the show ip rsvp installed detail command.

CallManager-Controlled RSVP with RSVP Agent

Cisco CallManager can use the RSVP agent feature on its gateways to provide CAC and reserve resources for calls. Resource reservation policies are configured on CallManager, and the RSVP agent on the gateway carries out these policies. The agent is a transcoding or media termination point (MTP) resource that is configured on the gateway and registered with CallManager as RSVP capable. It communicates with CallManager using Skinny Client Control Protocol (SCCP), which you must enable on the gateway.

RSVP agent provides some additional functionality over traditional gateway-controlled RSVP, including the following:

• Multilevel precedence and preemption (MLPP) With MLPP, high-priority calls can preempt low-priority calls if bandwidth is unavailable.
• Application ID You can create separate bandwidth pools within the total bandwidth that is allocated to RSVP. Then you can allocate traffic to those pools by application, based on an application ID. You can give video and voice traffic different application IDs and assign them to different bandwidth pools. This prevents video from using all the reservable bandwidth.
• Multiprotocol support Because CallManager is controlling the reservation policies, no additional configuration of dial peers is needed. Thus, MGCP gateways are supported in addition to SIP and H.323.
• Interoperability with location-based CAC You can enable RSVP use on CallManager by location, thus allowing its use for some locations but not others.
• Site awareness If multiple calls are made to the same site, only one RSVP connection is made to that site.

Cisco RSVP agent is useful only for intracluster calls, because the same CallManager cluster must be able to control the RSVP agent on the gateway at each end of the call. You can use a Cisco IP-to-IP gateway to reserve bandwidth for intercluster calls. You cannot use the RSVP agent with device mobility, and it is not supported in Cisco CallManager Express (CME). See Cisco.com for a current list of RSVP agent capabilities.

The same router can be both an RSVP agent and a media gateway. Some overhead is involved with RSVP, however, and in a busy network you might want to use dedicated RSVP agent routers.

Note

Because RSVP reservations are made before media negotiation is done, Cisco CallManager assumes a worst-case per-flow bandwidth and asks for more bandwidth than might actually be needed. This is to prevent a post-ring failure caused by adjusting the bandwidth upward. The amount is adjusted down after media negotiation is complete. In a CallManager network, allow 96 Kbps for G.711 calls and 40 Kbps for G.729 calls when planning bandwidth.

Call flow with RSVP agents adds the SCCP communication between CallManager and the gateway. Router-to-router communication is still the same as in the traditional RSVP call flow, and reservations can be made on each router in the path. Figure 11-3 illustrates protocols that you might use in a CallManager network with RSVP agent. Both the SCCP phone and the RSVP agents on the gateways exchange SCCP messages with CallManager. The SIP phone exchanges SIP messages with CallManager. Each gateway also communicates with CallManager using its call control protocolMGCP and SIP in Figure 11-3. The two gateways establish RSVP reservations across the IP WAN using the process shown in Figure 11-2. After the call is established, the two phones use RTP for the call media.

Figure 11-3. Using RSVP Agent with Cisco CallManager

Configuring RSVP Agent

Configuration is needed both on the gateway and CallManager. This section describes the gateway configuration. Example 11-11 shows a gateway configuration for RSVP agent. Perform the following steps to configure a gateway to use RSVP agent:

The previous commands are demonstrated in Example 11-11, which shows a gateway that is configured for RSVP agent. The gateway has a primary and a backup CallManager in addition to MTP and transcode DSP farm profiles, and it is using interface Gi0/0 to communicate with CallManager.

You must also configure the CallManager Publisher to use RSVP. Configure RSVP policies for locations or for the cluster as a whole. To use RSVP, the two call endpoints must belong to different locations. Create media resource groups, and add any transcoders or MTPs that will be registered as an RSVP agent. Then configure a media resource group list (MRGL) and assign a media resource group to the list. Assign the MRGL to a device pool. See Cisco.com for complete information on configuring Cisco CallManager for RSVP agent.

RSVP and the IntServ/DiffServ Model

RSVP reserves resources, but it is up to each router to implement the appropriate QoS techniques to deliver those resources. Low-latency queuing (LLQ) is the QoS mechanism typically used for voice, putting voice in a priority queue with guaranteed but policed bandwidth. This is part of the DiffServ model of QoS. However, RSVP has its own set of queues that it puts reserved traffic into by default. These queues have a low weight, but they are not prioritized. This is part of the IntServ model of QoS. What is needed is a way to put reserved voice traffic into the LLQthe IntServ/DiffServ model.

By default, RSVP uses weighted fair queuing (WFQ) to provide its QoS. When using LLQ with class-based weighted fair queuing (CBWFQ), disable the RSVP use of WFQ with the ip rsvp resource-provider none interface command. Also, by default, RSVP attempts to process every packetnot just provide CAC. Turn this off with the ip rsvp data-packet classification none interface command. Then you can configure the LLQ and CBWFQ as usual. RSVP reserves bandwidth for voice calls, and the QoS processes of the gateway place that voice traffic into the priority queue. In Example 11-10, note under the Traffic Control section that these two commands have been given.

When you are using LLQ, the priority queue size includes Layer 2 overhead. The RSVP bandwidth statement does not take Layer 2 overhead into consideration. Therefore, when you are using both LLQ and RSVP, set the RSVP bandwidth equal to the priority queue minus the Layer 2 overhead. You can find instructions for configuring LLQ, CBWFQ, and RSVP on Cisco.com in the "Quality of Service Solutions Configuration Guide" and in Cisco IOS Command Reference Guides. See the case study at the end of this chapter for an example of using RSVP with LLQ.

Incorporating RSVP into the Voice Network

It is not necessary to configure RSVP on every router within your enterprise. Because RSVP messages are passed through non-RSVP-enabled routers, you can use RSVP selectively. You might enable it in sections of the network that are prone to congestion, such as areas with low bandwidth. In the core of the network, where bandwidth is higher, you might rely on LLQ/CBWFQ to handle voice and video traffic. This helps in scaling RSVP, cutting down on the number of routers that must track each session and be involved in RSVP messaging.

Figure 11-4 shows a network with remote sites connecting to a core IP WAN. The core might be enterprise owned, or it might, for example, be a Multiprotocol Label Switching (MPLS) network of the service provider. All the remote site links are T1 and carry both voice and data. All WAN interfaces of the remote site routers are configured for RSVP. Bandwidth is reserved when sites place calls between each other. When these calls go across the core IP WAN, reservations are made on the WAN interfaces of the edge routers, and CAC is done based on resources that are available on the remote site routers. The core does not participate in RSVP, so you must use other means of QoS in that part of the network.

Figure 11-4. Using RSVP in a Large Network