SAA probes are similar in concept to the popular ping IP connectivity mechanism, but are far more sophisticated. SAA packets can be built and customized to mimic the type of traffic for which they are measuring the network, in this case a voice packet. A ping packet is almost by definition a best-effort packet, and even if the IP precedence is set, it does not resemble a voice packet in size or protocol. Nor will the QoS mechanisms deployed in the network classify and treat a ping packet as a voice packet. The delay and loss experienced by a ping is therefore a very crude worst-case measure of the treatment a voice packet might be subject to while traversing the very same network. With the penetration of sophisticated QoS mechanisms in network backbones, a ping becomes unusable as a practical indication of the capability of the network to carry voice.

The SAA service is a client/server service defined on TCP or UDP. The client builds and sends the probe, and the server (previously the RTR responder) returns the probe to the sender. The SAA probes used for CAC go out randomly on ports selected from within the top end of the audio UDP-defined port range (16384 to 32767); they use a packet size based on the codec the call will use. IP precedence can be set if desired, and a full RTP/UDP/IP header is used like the header a real voice packet would carry. By default the SAA probe uses the RTCP port (the odd RTP port number), but it can also be configured to use the RTP media port (the even RTP port number) if desired.

SAA was introduced on selected platforms in Cisco IOS Release 12.0(7)T. With the release of 12.2 Mainline IOS, all router platforms support SAA; however, the IP Phones do not currently support SAA probes or respond to SAA probes.

The ITU standardizes network transmission impairments in ITU G.113. This standard defines the term calculated planning impairment factor (ICPIF), which is a calculation based on network delay and packet loss figures. ICPIF yields a single value that can be used as a gauge of network impairment.

ITU G.113 provides the following interpretations of specific ICPIF values:

SAA probe delay and loss information is used in calculating an ICPIF value that is then used as a threshold for CAC decisions, based either on the ITU interpretation described or on the requirements of an individual customer network.

When a call is attempted at the originating gateway, the network congestion values for the IP destination are used to allow or reject the call. The network congestion values for delay, loss, or ICPIF are obtained by sending an SAA probe to the IP destination the call is trying to reach. The threshold values for rejecting a call are configured at the originating gateway. Figure C-14 illustrates this concept.

Figure C-14 PSTN Fallback

Unlike AVBO, PSTN fallback does not require the static configuration of the IP destinations. The software keeps a cache of configurable size that tracks the most recently used IP destinations to which calls were attempted. If the IP destination of a new call attempt is found in the cache, the CAC decision for the call can be made immediately. If the entry does not appear in the cache, a new probe is started and the call setup is suspended until the probe response arrives. Therefore, an extra postdial delay is imposed only for the first call to a new IP destination. Figure C-15 illustrates these possible scenarios.

Figure C-15 PSTN Fallback Call Setup

Figure C-15 demonstrates three possible scenarios. In all scenarios, a call setup message is send to router 1 (R1). R1 consults its cache to determine whether a path exists and, if so, that the ICPIF or delay/loss thresholds have not been exceeded. In scenario one, both conditions are true and the call setup message is forwarded to router 2 (R2) to connect the call. In scenario two, a path to the IP destination is found in cache; however, the ICPIF or loss/delay exceed the threshold for that path and the call is either rejected or hairpinned back to the origination PBX, depending on the interface type connecting the PBX with R1. In scenario three, a path to the IP destination is not found in cache. An SAA probe is sent to the IP destination to determine the ICPIF or loss/delay values. If the response shows that the thresholds have not been exceeded, the call setup message is forwarded on to router 2 (R2) to connect the call.

After an IP destination has been entered into the cache, a periodic probe with a configurable timeout value is sent to that destination to refresh the information in the cache. If no further calls are made to this IP destination, the entry ages out of the cache and probe traffic to that destination is discontinued. In this way, PSTN fallback dynamically adjusts the probe traffic to the IP destinations that are actively seeing call activity.

Each probe consists of a configurable number of packets. The delay, loss, and ICPIF values entered into the cache for the IP destination are averaged from all the responses.

If an endpoint is attempting to establish a voice conversation using a G.729 or G.711 codec, the probe’s packet size emulates the codec of the requesting endpoint. Additional codecs use G.711-like probes.

The IP precedence of the probe packets can also be configured to emulate the priority of a voice packet. This parameter should be set equal to the IP precedence used for other voice media packets in the network. Typically the IP precedence value is set to 5 for voice traffic.

PSTN fallback is configured on the originating gateway and applies only to calls initiated by the originating gateway. Inbound call attempts are not considered. PSTN fallback is configured at the global level and therefore applies to all outbound calls attempted by the gateway. You cannot selectively apply PSTN fallback to calls initiated by certain PSTN/PBX interfaces. The SAA responder feature is configured on the destination node, also referred to as the terminating gateway.

To apply PSTN fallback, enter the following global configuration commands:

Table C-11 lists the options and default values of the call fallback command.

Table C-10 Call Fallback Command

Examples C-13 and C-14 demonstrate PSTN fallback between a host and remote site. SAA is configured on the remote site to answer the probes from the host site. When the number 1234 is dialed from the host site and congestion is observed on the link between the host site and the remote site, the call is redirected to port 3/0:23 and connected to the remote site over the PSTN.

Probes are sent every 20 seconds with 15 packets in each probe. The probes share the priority queue with the other voice packets. The delay and loss threshold command is configured with a delay threshold of 150 ms and a loss threshold of 5 percent and the cache aging timeout is configured for 10,000 seconds.

Example C-13 shows the configuration for the host site router.

Example C-14 shows the configuration for the remote site router.

With the configuration of Examples C-13 and C-14, 15 probes are placed in the priority queue of the host site router every 20 seconds. The responses received from the remote site router must not exceed 150 ms of delay or 5 lost packets for the host site routers to determine that this path will support the QoS necessary for a voice conversation. If this path is not used in 10,000 seconds, it is removed from the cache and a new set of probes have to be launched at the next request. The rtr responder command is enabled on the remote site router to enable responses to the probes.

Examples C-13 and C-14 in the preceding section describe a simple network in which the remote site router acts as the terminating gateway for the voice conversation. The IP address of the remote site router and the network congestion values of the link between the remote and host router are held in the cache of the host site router. When the host site router receives the digits 12 followed by 2 additional digits, the host cache is consulted to determine whether the call can be successfully placed.

As the network becomes more complex, such as with the addition of IP telephony, it becomes necessary to designate a single terminating gateway to represent a number of IP destination devices. Consider the example illustrated in Figure C-16. There are a large number of IP Phones at Site 6, each one having a unique IP address.

Figure C-16 PSTN Fallback Scalability

If Site 1 calls an IP Phone at Site 6, the cache at Site 1 does not need to contain an entry for each separate IP destination at Site 6. All IP call destinations at Site 6 can be mapped to the IP address of the WAN edge router at Site 6 so that a single probe from Site 1 to Site 6 can be used to probe CAC information for all calls destined to Site 6. The same principle applies if there were multiple terminating gateways at Site 6.

The probe traffic can therefore be reduced substantially by sending probes to IP destinations that represent the portion of the network that is most likely to be congested, such as the WAN backbone and WAN edge. This same scalability technique also provides a mechanism to support IP destinations that do not support SAA responder functionality.

PSTN fallback is a widely deployable, topology-independent CAC mechanism that can be used over any backbone. Consider the following attributes of PSTN fallback when designing a network:

Table C-12 evaluates the PSTN fallback mechanism against the CAC evaluation criteria described earlier in this chapter.

Table C-11 PSTN Fallback CAC Evaluation Criteria

The calculation to reach the CAC decision is performed by the terminating gateway. Different gateway platforms may use different algorithms. The H.323 standard does not prescribe the calculation or the resources to include in the calculation. It merely specifies the RAI message format and the need for the gatekeeper to discontinue routing calls to the terminating gateway in the event that the gateway has insufficient available resources for the additional call, and the gateway will inform the gatekeeper to resume routing calls when resources become free.

Calculating utilization first takes into account the number of accessible channels on the target device. Accessible channels are either active or idle voice channels on the device that are used to carry voice conversations. Disabled channels are not counted as accessible channels.

The following formula is used to determine accessible channels:

When the number of accessible channels is known, the utilization can be calculated from the following formula:

Suppose, for instance, that you have four T1 CAS circuits. Two of the T1 CAS circuits are used for incoming calls, and the remaining two T1 CAS circuits are used for outgoing calls. You have busied out 46 time slots of the outgoing time slots, and you have one call on one of the outgoing time slots. You will have the following:

The outgoing accessible channels in this situation are as follows:

The DS0 utilization for this device is as follows:

or

The utilization for the outgoing channels is equal to 50 percent. If the configured high threshold is 90 percent, the gateway will still accept calls. Only DS0s reachable through a VoIP dial peer are included in the calculation.

The preceding calculation took the DS0 resources into consideration. Remember that the DSP resources are monitored and calculated in the same manner. The terminating gateway sends an RAI message in the event that either the DS0 or DSP resources reach the low or high threshold.

RAI is an indispensable feature in SP networks that provide VoIP calling services such as debit and credit card calling and VoIP long-distance phone service. Figure C-17 shows the general structure of these networks.

Figure C-17 Service Provider VoIP Network Topology

Around the world there are points of presence (POPs) where racks of gateways, such as Cisco AS5300 access servers, connect to the PSTN with T1/E1 trunks. The call routing is managed through several levels of gatekeepers as shown in Figure C-17. Call volume is high, and these gateways handle voice traffic only (no data traffic other than minimal IP routing and network management traffic).

When a customer on the West Coast dials a number residing on the East Coast PSTN, the East Coast gatekeeper must select an East Coast gateway that has an available PSTN trunk to terminate the call. If an East Cost gateway cannot be found, the customer’s call fails. In the event of a failed call, the originating gateway must retry the call or the customer must redial the call. In either case, there is no guarantee that the same out-of-capacity terminating gateway will not be selected again.

This scenario is inefficient and provides poor customer service. It is important that calls are not routed by the gatekeeper to a terminating gatekeeper that cannot terminate the call due to the lack of PSTN trunk capacity.

In general, calls are load balanced by the gatekeeper across the terminating gateways in its zone. But the gateways could have different levels of T1/E1 capacity and by load balancing across the gateways one gateway could become shorter on resources than another. It is in this situation that RAI is imperative. The overloaded terminating gateway has the capability to initiate an indication to the gatekeeper that it is too busy to take more calls.

RAI is generally less applicable in enterprise networks than in SP networks because there is often only one gateway at each site, as shown in Figure C-18. This is almost always true for the typical hub-and-spoke enterprise network. Even at the large sites, there may be multiple T1/E1 trunks to the attached PBX, but there are seldom multiple gateways.

Figure C-18 Enterprise VoIP Network Topology

If a single gateway is used to terminate a call, where the called user resides on a specific PBX and is reachable only through a specific gateway in the network, RAI does not provide additional network intelligence. With no alternate gateway to handle excess calls, a call will always fail whenever the single terminating gateway is too busy. In addition, in enterprise networks the probability of congestion is typically higher in the IP cloud than in the number of terminating POTS trunks. In the SP networks discussed earlier, congestion is more common in the terminating POTS trunks than in the IP cloud.

In spite of these limitations, RAI can still be used for enterprise networks provided the gateway to PBX connections at the remote sites consist of T1/E1 trunks. If a terminating gateway is too busy, it triggers a PSTN reroute instead of selecting an alternate gateway as in the SP network situation.

The discussion of where and how RAI is used in SP and enterprise networks clearly shows that RAI is most useful in situations where multiple terminating gateways can reach the same destination, or called, phone number. However, RAI has value in any situation where there is a desire to prevent a call from being routed to a gateway that does not have the available POTS capacity to terminate the call.

When a gatekeeper receives an RAI unavailable indication from a gateway, it removes that gateway from its gateway selection algorithm for the phone numbers that gateway would normally terminate. An RAI available indication received later returns the gateway to the selection algorithm of the gatekeeper.

RAI is an optional H.323 feature. When you implement a network, therefore, it is prudent to verify that both the gateways and gatekeepers support this feature. Cisco gatekeepers support RAI. Cisco gateway support for RAI is detailed in a later section of this chapter.

RAI on the gateway is configured with high-water- and low-water-mark thresholds, as shown in Figure C-19. When resource usage rises above the high-water mark, an RAI unavailable indication is sent to the gatekeeper. When resource availability falls below the low-water mark, an RAI available indication is sent to the gatekeeper. To prevent hysteresis based on the arrival or disconnection of a single call, the high- and low-water marks should be configured 10 percentage points apart. (Hysteresis refers to the process of switching a feature on, then off, then on, and so on, over and over again, as would happen if the high- and low-water marks were configured to very similar values.)

Figure C-19 RAI Configuration

To configure RAI, use the following gateway configuration command:

To configure an RAI unavailable resource message to be sent to the gatekeeper at a high-water mark of 90 percent and a RAI available resource message to be sent to the gatekeeper at a low-water mark of 80 percent, enter the following command:

The Cisco AS5300 access server has supported RAI since Cisco IOS Release 12.0(5)T. The Cisco 2600 and 3600 series routers have supported RAI for T1/E1 connections only, not for analog trunks, since Release 12.1.3T. The other Cisco IOS gateways do not yet support RAI as of Release 12.1(5)T or 12.2. The RAI calculation includes digital signal processors (DSPs) and DS0s, and may not be the same for all platforms. In current software, CPU and memory are not yet included in the RAI availability indication.

Table C-13 evaluates the RAI mechanism against the CAC evaluation criteria described earlier in this chapter.

Table C-12 RAI CAC Evaluation Criteria

The Cisco CallManager centralized call-processing model uses a hub-and-spoke topology. The host site, or hub, is the location of the primary Cisco CallManager controlling the network while the remote sites, containing IP endpoints registered to the primary CallManager, represent the spokes. The Cisco CallManager Administration web page can be used to create locations and assign IP endpoints, such as IP Phones, to these locations. After the locations have been created and devices have been assigned, you can allocate bandwidth for conversations between the hub and each spoke locations.

For calls between IP endpoints in the host site of Figure C-20, the available bandwidth is assumed to be unlimited, and CAC is not considered. However, calls between the host site and remote sites travel over WAN links that have limited available bandwidth. As additional calls are placed between IP endpoints over the WAN links, the audio quality of each voice conversation can begin to degrade. To avoid this degradation in audio quality in a CallManager centralized call-processing deployment, you can use the locations feature to define the amount of available bandwidth allocated to CallManager controlled devices at each location and thereby decrease the number of allowed calls on the link.

The amount of bandwidth allocated by CallManager locations is used to track the number of voice conversations in progress across an IP WAN link on a per-CallManager basis. CallManager servers in a cluster are not aware of calls that have been set up by other members in the cluster. To effectively use location-based CAC, all devices in the same location must register with the same centralized CallManager server.

In Cisco CallManager, locations work in conjunction with regions to define how voice conversations are carried over a WAN link. Regions define the type of compression, such as G.711 or G.729, used on the link, and locations define the amount of available bandwidth allocated for that link.

Figure C-21 illustrates a CallManager centralized call-processing model with three remote sites. Each remote site has a location name that all IP endpoints in that location are associated with and a region that determines which codec is be used for voice conversations to IP endpoints in this location.

Figure C-21 CallManager Centralized Call-Processing Model with Regions and Locations Defined

Each IP endpoint uses the G.711 codec for voice conversations with other endpoints in the same region. When an IP endpoint establishes a voice conversation with an IP endpoint in another region, the G.729 codec is used. The following examples illustrate this:

After the regions have been defined and all devices have been configured to reside in the desired location, you can begin to allocate the desired bandwidth between the locations to use for CAC. This allocated bandwidth does not reflect the actual bandwidth required to establish voice conversations; instead, the allocated bandwidth is a means for CallManager to provide CAC. CAC is achieved by defining a maximum amount of bandwidth per location to use and then subtract a given amount, dependent upon the codec used, from that maximum for each established voice conversation. In this way, CallManager has the capability to deny or reroute call attempts that exceed the configured bandwidth capacity.

Table C-14 shows the amount of bandwidth that is subtracted, per call, from the total allotted bandwidth for a configured region.

Table C-13 Location-Based CAC Resource Calculations

In Figure C-21, suppose that you need to protect six simultaneous calls between the HQ and Atlanta locations, but allow only four between the HQ and Dallas location and three between the HQ and San Jose location. Because each region has been configured to use the G.729 codec between regions, each of these voice conversations represent 24 kbps to the configured location. Remember that the location bandwidth does not represent the actual bandwidth in use.

For the Atlanta location to allow 6 simultaneous calls, the Atlanta Location Bandwidth needs to be configured for 144 kbps, as shown in the following calculation:

For the Dallas location to allow 4 simultaneous calls, the Dallas location bandwidth needs to be configured for 48 kbps, as shown in the following calculation:

Finally, for the San Jose location to allow 3 simultaneous calls, the San Jose location bandwidth needs to be configured for 72 kbps, as shown in the following calculation:

The link to the Atlanta location, configured for 144 kbps, could support 1 G.711 call at 80 kbps, 6 simultaneous G.729 calls at 24 kbps each, or 1 G.711 call and 2 G.729 calls simultaneously. Any additional calls that try to exceed the bandwidth limit are rejected and the call is either rerouted or a reorder tone returns to the caller.

CallManager continues to admit new calls onto a WAN link until the available bandwidth for that link (bandwidth allocated to the location minus all active voice conversations) drops below zero.

Prior to CallManager version 3.3, if a call was blocked due to insufficient location bandwidth, the caller would receive a reorder tone and manually have to redial the called party through the PSTN. Automated alternate routing (AAR), introduced in CallManager version 3.3, provides a mechanism to reroute calls through the PSTN or another network WAN link by using an alternate number when Cisco CallManager blocks a call because of insufficient location bandwidth. With automated alternate routing, the caller does not need to hang up and redial the called party.

The fully qualified E.164 address, also known as the PSTN number, is obtained from the external phone number mask configured on the called device. The calling device is associated with an AAR group, which is configured with the digits that will be prepended to the phone number mask to access the PSTN gateway and reroute the call over the PSTN.

Table C-15 evaluates location-based CAC against the CAC evaluation criteria described earlier in this chapter.

Table C-14 Location-Based CAC Evaluation Criteria

By dividing the network into zones, a gatekeeper can control the allocation of calls in its local zone and the allocation of calls between its own zone and any other remote zone in the network. For the purpose of understanding how this feature operates, assume a voice call is equal to 64 kbps of bandwidth. Actual bandwidth used by calls in a gatekeeper network are addressed in the “Zone Bandwidth Calculation” section.

Figure C-22 shows a single-zone gatekeeper network with two gateways that illustrates gatekeeper CAC in its simplest form. If the WAN bandwidth of the link between the two gateways can carry no more than two calls, the gatekeeper must be configured so that it denies the third call. Assuming every call is 64 kbps, the gatekeeper is configured with a zone bandwidth limitation of 128 kbps to achieve CAC in this simple topology.

Figure C-22 Simple Single-Zone Topology

Most networks, however, are not as simple as the one shown in Figure C-22. Figure C-23 shows a more complex topology; however, it is still configured as a single-zone network. In this topology, the legs in the WAN cloud each have separate bandwidth provisioning and therefore separate capabilities of how many voice calls can be carried across each leg. The numbers on the WAN legs in Figure C-23 show the maximum number of calls that can be carried across each leg.

Figure C-23 Complex Single-Zone Topology

Assume that the gatekeeper zone bandwidth is still configured to allow a maximum of 128 kbps, limiting the number of simultaneous calls to two.

With a single zone configured, the gatekeeper protects the bandwidth of the WAN link from Site 1 to the WAN aggregation point by not allowing more than two calls across that link. When two calls are in progress, however, additional calls between the PBXs at Headquarters are blocked even though there is ample bandwidth in the campus backbone to handle the traffic.

To solve the single-zone problem of reducing the call volume of the network to the capabilities of the lowest-capacity WAN link, you can design multiple gatekeeper zones into the network. A good practice in designing multiple zones is to create one zone per site, as shown in Figure 8-24.

The Site 1 gatekeeper limits the number of calls active in Site 1, regardless of where those calls originate or terminate, to two simultaneous calls by limiting the available bandwidth to 128 kbps. Because there is only one gateway at Site 1, there is no need to configure a limit for the intrazone call traffic. All interzone traffic is limited to two calls to protect the WAN link connecting Site 1.

At Site 2 there is also a single gateway, and therefore no need to limit the intrazone call traffic. There are separate interzone limits for the following scenarios:

The Headquarters site has a similar configuration to Site 2 except that calls are unlimited within Headquarters; not because there is a single gateway, but because there is ample bandwidth between the gateways at this site.

In the network topology in Figure C-24, gatekeeper CAC provides sufficient granularity needed to protect voice conversations across the low-speed WAN links. Consider another network topology in which there are multiple gateways per zone, however, with each gateway at the remote sites having a separate WAN connection to the aggregation point. Figure C-25 shows such a network topology.

Figure C-24 Simple Enterprise Multizone Topology

Figure C-25 Complex Enterprise Multizone Topology

Of the three gateways in remote Site 1, the slowest WAN access link can carry a maximum of two simultaneous calls. Because the gatekeeper bandwidth limitation is configured per zone and not per gateway, there is no facility within gatekeeper CAC to limit the calls to specific gateways within the zone. To ensure protection of voice conversations, the zone bandwidth must be configured for the slowest link in the zone. For both remote Sites 1 and 2, the slowest link is 128 kbps bandwidth or two calls.

This configuration ensures proper voice quality at all times, but it is also wasteful of the gateways that could terminate more calls without oversubscribing their WAN bandwidth. In this network configuration, CAC is activated too soon and reroutes calls over to the PSTN when in fact they could have been carried by the WAN. In this type of topology, gatekeeper CAC is not sufficient to protect voice quality over the WAN link, and, at the same time, optimize the bandwidth use of all WAN links.

The last configuration to consider is an SP network where the gateways in the POPs are connected via Fast Ethernet to the WAN edge router, as shown in Figure C-26.

Figure C-26 Service Provider Topology with Multiple Gateways per Zone

In this network, gatekeeper CAC is sufficient, even though there are multiple gateways per zone, because the connections to specific gateways within the zone are not the links that need protection. The bandwidth that needs protection is the WAN access link going into the backbone that aggregates the call traffic from all gateways. A gatekeeper bandwidth limitation for the zone indeed limits the number of calls over that link. It is assumed that the OC-12 backbone link is overengineered and requires no protection.

In summary, a multizone gatekeeper network offers the following CAC attributes:

Gatekeeper CAC cannot protect the bandwidth on WAN segments not directly associated with the zones. For example, gatekeeper CAC cannot protect the backbone link marked with 20 calls in the simple enterprise topology shown in Figure C-24, unless the slowest link approach is followed.

Because the zone-per-gateway design offers the finest granularity of gatekeeper CAC, it is worth exploring a little further. In enterprise networks, this often makes sense from the following points of view:

A gatekeeper is a logical concept, not a physical concept. Each gatekeeper therefore does not imply that there is a separate box in the network; it merely means that there is a separate local zone statement in the configuration.

With Cisco IOS Release 12.1(5)T and Release 12.2, a small remote site router has the capability to provide gateway, gatekeeper, and WAN edge functionality; however, a zone-per-gateway design complicates the scalability aspect that gatekeepers bring to H.323 networks. You should therefore carefully consider the advantages and limitations of such a design.

Of all the CAC mechanisms discussed in this chapter, gatekeeper zone bandwidth is the only method applicable to multi-site distributed CallManager clusters. In this scenario, the CallManager behaves like a VoIP gateway to the H.323 gatekeeper, as is shown in Figure C-27.

Figure C-27 Gatekeeper in a CallManager Topology

In this example, the CallManager in Zone 2 requests the WAN bandwidth to carry a voce conversation from the gatekeeper on behalf of the IP Phone x2111. The gatekeeper determines whether each zone has sufficient bandwidth to establish the call. If the gatekeeper allows the call to proceed, the CallManager in Zone 2 contacts the CallManager in Zone 1 to begin call setup. If the gatekeeper rejects the call, the CallManager in Zone 2 can reroute the call over the PSTN to reach the called party.

The gatekeeper does not have any knowledge of network topology and does not know how much bandwidth is available for calls. Nor does the gatekeeper know how much of the configured bandwidth on the links is currently used by other traffic. The gatekeeper takes a fixed amount of bandwidth, statically configured on the gatekeeper, and subtracts a certain amount of bandwidth for each call that is set up. Bandwidth is returned to the pool when a call is disconnected. If a request for a new call causes the remaining bandwidth to become less than zero, the call is denied. The gatekeeper does not use bandwidth reservation. Instead, the gatekeeper performs a static calculation to decide whether a new call should be allowed.

It is the responsibility of the gateways to inform the gatekeeper of how much bandwidth is required for a call. Video gateways therefore could request a different bandwidth for every call setup. One video session may require 256 kbps, whereas another requires 384 kbps. Voice gateways should consider codec, Layer 2 encapsulation, and compression features, such as compressed Real Time Protocol (cRTP), when requesting bandwidth from the gatekeeper. Sometimes these features are not known at the time of call setup, in which case a bandwidth change request can be issued to the gatekeeper after call setup to adjust the amount of bandwidth used by the call. As of Cisco IOS Software Release 12.2(2)XA, Cisco has implemented only the functionality of reporting any bandwidth changes when the reported codec changes.

Prior to Cisco IOS Software Release 12.2(2)XA on a Cisco H.323 Gateway, calls were always reported to require a bandwidth of 64 kbps. This is the unidirectional payload bandwidth for a Cisco G.711 codec. If the endpoints in the call chose to use a more efficient codec, this was not reported to the Cisco gatekeeper. In the Cisco IOS Software Release 12.2(2)XA version of the Cisco H.323 Gateway or a later version that conforms with H.323 version 3, the reported bandwidth is bidirectional. Initially, 128 kbps is specified. If the endpoints in the call select a more efficient codec, the Cisco gatekeeper is notified of the bandwidth change.

Figure C-28 illustrates a network that uses a gatekeeper to limit bandwidth to 144 kbps between two zones. A connection is requested with an initial bandwidth of 128 kbps. After the call has been set up, the endpoints report the change in the bandwidth. Assuming the endpoints are using G.729, 16 kbps is subtracted from the configured maximum of 144 kbps. The 16 kbps represents a bidirectional G.729 payload stream to the gatekeeper.

Figure C-28 Gatekeeper Bandwidth Calculation

In the event that the second call arrives before the endpoint requests the change in bandwidth for the first call, the Cisco gatekeeper rejects the second call, because the total requested bandwidth exceeds the 144 kpbs configured. As call 1 is being set up, for example, the gatekeeper records this call as a 12C-kbps call and waits for a codec change before adjusting the recorded bandwidth. At this point, the gatekeeper has subtracted 128 kbps from the configured 144 kbps, leaving 16 kbps available. If call 2 requests admission before the codec change is reported in call 1, the gatekeeper does not have enough available bandwidth to allow this 12C-kbps call to proceed.

Gatekeeper zone bandwidth remains an inexact science because the gateway may not have full knowledge of the bandwidth required by the call. The following examples describe common situations where the gateway will not have full knowledge of the bandwidth required per call:

As of Cisco IOS Software Release 12.1(5)T and Release 12.2, the following types of zone bandwidth limitations can be configured on the gatekeeper:

Tables C-16 and C-17 list the gatekeeper command and options used to configure gatekeeper zone bandwidth.

Table C-15 Gatekeeper Bandwidth Command

Table C-16 Gatekeeper Bandwidth Command Options

Gatekeeper CAC works well in network designs where the desire is to limit the number of calls between sites. This may be required due to either bandwidth limitations or business policy. If bandwidth limitations are on the WAN links, manual calculations can be performed to translate the maximum number of calls allowed between sites into a bandwidth figure that will cause the gatekeeper to deny calls when the calculated number is exceeded.

Gatekeepers do not share database information. If the primary gatekeeper fails, a secondary gatekeeper can begin to perform CAC for the network; however, the secondary gatekeeper has no knowledge of the amount of bandwidth currently used in the zone or the true number of active voice conversations. Until the secondary gatekeeper has an accurate count of current calls and consumed bandwidth, the network may become oversubscribed with voice conversations. If alternate gatekeepers are used as the redundancy method, this problem is circumvented.

A major advantage of gatekeeper CAC is that it is the only CAC method that can incorporate mixed networks of Cisco IOS gateways and CallManagers with IP Phones.

Table C-18 evaluates the gatekeeper zone bandwidth mechanism against the CAC evaluation criteria described earlier in this chapter.

Table C-17 Gatekeeper Zone Bandwidth CAC Evaluation Criteria

RSVP uses path and resv messages to establish a reservation for a requested data flow. A path message carries the traffic description for the desired flow from the sending application to the receiving application, and the resv message carries the reservation request for the flow from the receiving application to the sending application. Figure C-29 shows a network that consists of several routers carrying the path and resv messages for a sending and receiving application.

Figure C-29 RSVP Path and Resv Messages

In this example, the sending application responds to an application request by sending a path message to the RSVP router R1 describing the level of service required to support the requested application. R1 forwards the path message to router R2, R2 forwards the message to router R3, R3 forwards the message to R4, and finally R4 forwards the message to the receiving application. If the level of service described in the path message can be met, the receiving application sends a resv message to RSVP router R4. The resv message causes each router in the data path to the sending application to place a reservation with the requested level of service for the flow. When the resv message reaches the sending application, the data flow begins.

Path messages describe the level of service required for a particular flow through the use of the Sender_Tspec object within the message. The Sender_TSpec object is defined by the sending application and remains in tact as the path message moves through the network to the receiving application. Also included in the path message is the ADSpec object. The ADSpec object is modified by each intermediary router as the RSVP path message travels from the sending application to the receiving application. The ADSpec object carries traffic information generated by the intermediary routers. The traffic information describes the properties of the data path, such as the availability of the specified level of service. If a level of service described in the ADSpec object is not implemented in the router, a flag is set to alert the receiving application.

Effectively, the Sender_Tspec states what the application needs, and the ADSpec allows each successive router to comment on the level of service it can and cannot support. The receiving application can look at both settings and decide whether to accept or reject the reservation request. Figure C-30 shows the Sending_TSpec and ADSpec objects sent in a path message from a sending application.

Figure C-30 Path Messages Sending_TSpec and ADSpec Objects

In Figure C-30 the Sending_TSpec is advertising the required level of service for this application as guaranteed. Because intermediary routers do not modify the Sending_TSpec, this value is passed through the network to the receiving application. The ADSpec lists the level of service available at each intermediate router along the data path. As the path message reaches router R3, the ADSpec object is modified to indicate that router R3 can only provide a controlled-load level of service. Essentially, the sending application has asked for guaranteed RSVP service, and the ADSpec implies that at least one router can only support a controlled-load service for this request.

The receiver of the path message replies with an resv message. Resv messages request a reservation for a specific flow through the use of a FlowSpec object. The FlowSpec object provides a description of the desired flow and indicates the desired level of service for the flow to the intermediary routers, based on the information received from the path message in the ADSpec object. A single level of service must be used for all nodes in the network—in other words, it can be controlled-load or guaranteed service, but not both. Because the sending application requires either guaranteed or controlled-load level of service to begin the flow, and router R3 can only provide controlled-load level of service, the receiving application can only request a reservation specifying controlled-load level of service. Example C-31 shows the FlowSpec object sent in a resv message from a receiving application.

Figure C-31 Resv Messages FlowSpec Objects

After the reservation for controlled-load service has been installed on the intermediary routers, the flow is established between the sending application and the receiving application.

Voice gateways use H.323 signaling when setting up voice calls. To reserve network resources for voice calls with RSVP, RSVP in an H.323 environment operates by synchronizing its signaling with H.323 version 2 signaling. This synchronization ensures a bandwidth reservation is established in both directions before a call moves to the alerting, or ringing, H.323 state. RSVP and H.323 version 2 synchronization provides the voice gateways with the capability to modify H.323 responses based on current network conditions. These modifications allow a gateway to deny or reroute a call in the event that QoS cannot be guaranteed.

Figure C-32 shows a call flow of the H.323 call setup messages and the RSVP reservation messages.

Figure C-32 RSVP Call Setup for an H.323 Voice Call

In this example, the originating gateway initiates a call to the terminating gateway with an H.225 setup message. The terminating gateway responds with a call proceeding message. Because voice conversations require a bidirectional traffic stream, each gateway initiates a reservation request by sending an RSVP path message. An RSVP resv message is sent in response indicating that the requested reservation has been made. The originating gateway sends an RSVP resvconf message to the terminating gateway confirming the reservation. At this point, the terminating gateway proceeds with the H.323 call setup by sending an alerting message to the originating gateway.

To configure RSVP for use with H.323, you need to enable RSVP as normal and add a few commands to the H.323 dial peers. By default, RSVP is disabled on each interface to remain backward compatible with systems that do not implement RSVP. To enable RSVP for IP on an interface, use the ip rsvp bandwidth command. This command starts RSVP and sets the maximum bandwidth for all RSVP flows combined, and a single-flow bandwidth limit. The default maximum bandwidth is up to 75 percent of the bandwidth available on the interface. By default, a single flow has the capability to reserve the entire maximum bandwidth.

To configure a network to use RSVP, regardless of whether it is used for voice calls, you just configure the ip rsvp bandwidth command on every link in the network. You also need to configure a queuing tool that supports RSVP on each interface, namely WFQ, IP RTP Priority, or LLQ. Configuration details are listed later in this section.

To use RSVP to allow voice gateways to reserve bandwidth for voice calls, RSVP synchronization must be configured on the voice gateways. When doing so, each dial peer is configured with an accept QoS (acc-qos) value, and a request QoS (req-qos) value. Each of these two settings indicates the level of service that the dial peer will request, and the level that it will accept to make a reservation. Table C-19 describes the available options for the acc-qos and req-qos commands.

Table C-18 acc-qos and req-qos Command Options

This table was derived from the following: www.cisco.com/en/US/partner/products/sw/iosswrel/ps1834/products_feature_guide09186a008008045c.html.

For instance, two voice gateways could be configured to request, and to only accept, guaranteed-delay service. That combinations make sense with voice CAC—voice calls need a particular amount of bandwidth, and they need low delay. Examples C-15 and C-16 demonstrate the requested QoS and acceptable QoS dial-peer configuration of the req-qos and acc-qos commands, respectively.

RSVP and H.323 synchronization has an added oddity that is not obvious at first glance. H.323 call setup actually includes two sets of call setup messages: one for the voice that travels in one direction, and another set for the voice in another direction. Each of the two requires a separate RSVP reservation. In addition to that, depending on what has been configured on the originating and terminating gateways, the gateways may request a high level of service (for example, guaranteed load), and be willing to accept a lower level of service. So, Table C-20 summarizes the results of nine call setup scenarios based on the QoS levels that can be configured in the VoIP dial peers at the originating and terminating gateways. This table does not include cases where the requested QoS is configured for best effort and the acceptable QoS is configured for a value other than best effort, because those configurations are considered invalid.

Table C-19 acc-qos and req-qos Call States

In Examples C-15 and C-16, the dial-peer configuration for both the originating and terminating gateway were configured for guaranteed-delay. Based on Table C-20, the call will proceed only if both RSVP reservations succeed.

As you learned in previous chapters, LLQ is one of the most important Cisco QoS mechanisms to ensure quality for voice conversations, because it prioritizes voice packets over data packets at the router egress interface. For this to work, voice packets must be classified such that they are placed in the priority queue (PQ) portion of LLQ.

Cisco IOS provides the service levels that RSVP accepts by working in conjunction with IOS queuing tools. As a general Cisco IOS feature, RSVP has its own set of reserved queues within Class-Based Weighted Fair Queuing (CBWFQ) for traffic with RSVP reservations. So, RSVP can create hidden queues that compete with the explicitly defined CBWFQ queues, with the RSVP queues getting very low weights—and remember, with all WFQ-like features, lower weight means better service.

You would just configure CBWFQ, and then RSVP, and not consider the two features together. However, the performance of the voice flows with RSVP reservations would actually suffer. The reason is that the reserved hidden RSVP queues, although they have a low weight, are separate from the PQ feature of CBWFQ/LLQ. Packets in reserved RSVP queues do not get strict priority over packets from other queues. It has long been known that this treatment, a low-weight queue inside WFQ, is insufficient for voice quality over a congested interface. Therefore, when RSVP is configured for a voice call, the voice packets need to be classified into the PQ.

IOS solves the problem by having RSVP put voice-like traffic into the existing LLQ priority queue on the interface. RSVP uses a profile to classify a flow of packets as a voice flow. The profile considers packet sizes, arrival rates, and other parameters to determine whether a packet flow is considered a voice flow. The internal profile, named voice-like, is tuned to classify all voice traffic originating from a Cisco IOS gateway as a voice flow without the need for additional configuration. Therefore, while RSVP makes the reservations, it then in turn classifies voice-like traffic into the LLQ PQ, and other non-voice-like traffic with reservations into RSVP queues, as shown in Figure C-33.

Figure C-33 RSVP Packet-Classification Criteria

To perform the extra classification logic shown in the figure, RSVP is the first egress interface classifier to examine an arriving packet. If RSVP considers the packet a voice flow, the packet is put into the PQ portion of LLQ. If the flow does not conform to the voice profile voice-like, but is nevertheless an RSVP reserved flow, it is placed into the normal RSVP reserved queues. If the flow is neither a voice flow, nor a data RSVP flow, LLQ classifies the packet as it normally would.

Although RSVP voice traffic can be mixed with traffic specified in the priority class within a policy map, voice quality can suffer if both methods are implemented simultaneously. The two methods do not share bandwidth allocation and therefore will lead to an inefficient use of bandwidth on the interface. As bandwidth is defined in the configuration for the egress interfaces, all the bandwidth and priority classes will be allocated bandwidth at configuration time. No bandwidth is allocated to RSVP at configuration time because RSVP requests its bandwidth when the traffic flow begins. RSVP therefore gets allocated bandwidth from the pool that is left after the other features have already allocated their bandwidth.

It is important to note that RSVP classifies only voice bearer traffic, not signaling traffic. Another classification mechanism such as an ACL or DiffServ code point (DSCP) / IP precedence must still be used to classify the voice-signaling traffic if any treatment better than best effort is desired for signaling traffic.

Both LLQ and RSVP see the Layer 3 IP packet. Layer 2 encapsulations (FR, MLPPP, and so on) are added after queuing, so the bandwidth allocated by both LLQ and RSVP for a call is based on the Layer 3 bandwidth of the packets. This number is slightly different from the actual bandwidth used on the interface after Layer 2 headers and trailers have been incorporated. RSVP bandwidth reserved for a call also excludes both cRTP and VAD. Table C-21 summarizes the bandwidth RSVP allocates for calls using different Cisco IOS gateway codecs.

Table C-20 RSVP Bandwidth Reservations for Voice Codecs

Subnet bandwidth management (SBM) specifies a signaling method and protocol for LAN-based CAC for RSVP flows. SBM allows RSVP-enabled Layer 2 and Layer 3 devices to support reservation of LAN resources for RSVP-enabled data flows.

SBM uses the concept of a designated entity elected to control the reservations for devices on the managed LAN. The elected candidate is called the designated subnetwork bandwidth manager (DSBM). It is the DSBM’s responsibility to exercise admission control over requests for resource reservations on a managed segment. A managed segment includes a Layer 2 physical segment shared by one or more senders, such as a shared Ethernet network. The presence of a DSBM makes the segment a managed one. One or more SBMs may exist on a managed segment, but there can be only one DSBM on each managed segment. A router interface can be configured to participate in the DSBM election process. The contender configured with the highest priority becomes the DSBM for the managed segment.

Figure C-34 shows a managed segment in a Layer 2 domain that interconnects a group of routers.

Figure C-34 DSBM Managed Subnet

When a DSBM client sends or forwards an RSVP path message over an interface attached to a managed segment, it sends the path message to the DSBM of the segment rather than to the RSVP session destination address, as is done in conventional RSVP processing. As part of its message-processing procedure, the DSBM builds and maintains a path state for the session and notes the previous Layer 2 or Layer 3 hop from which it received the path message. After processing the path message, the DSBM forwards it toward its destination address.

The DSBM receives the RSVP resv message and processes it in a manner similar to how RSVP handles reservation request processing, basing the outcome on available bandwidth. The procedure is as follows:

The following three tasks are performed on a gateway to originate or terminate voice traffic using RSVP:

1.   Turn on the synchronization feature between RSVP and H.323. This is a global command and is turned on by default when Cisco IOS Release 12.1(5)T or later is loaded.

2.   Configure RSVP on both the originating and terminating sides of the VoIP dial peers. Configure both the requested QoS (req-qos) and the acceptable QoS (acc-qos) commands. The guaranteed-delay option must be chosen for RSVP to act as a CAC mechanism. Other combinations of parameters may lead to a reservation, but not offer CAC.

3.   Enable RSVP and specify the maximum bandwidth on the interfaces that the call will traverse.

Table C-22 lists the commands used to define and enable RSVP.

Table C-21 RSVP Profile, req-qos and acc-qos Commands

Example C-17 demonstrates the configuration required to enable RSVP with LLQ.

In the example, the call rsvp-sync command enables synchronization of H.323 and RSVP, which allows new call requests to reserve bandwidth using RSPV. The ip rsvp pq-profile command tells IOS to classify voice packets into a low-latency queue priority queue, assuming LLQ is configured on the same interface as RSVP. On interface serial 0/0, a service-policy command enables a policy map that defines LLQ, and the ip rsvp bandwidth command reserves a total of 200 kbps, with a per-reservation limit of 25 kbps. The req-qos and acc-qos commands tell IOS to make RSVP reservation requests when new call requests have been made.

Although RSVP does support reservations for voice traffic with H.323 sync, IOS does of course support RSVP independent of voice traffic. To support data traffic, LLQ may not even be needed.

Example C-18 demonstrates the configuration required to enable RSVP on a PPP interface, but with WFQ used rather than LLQ.

You can also configure RSVP along with traffic shaping. RSVP can reserve bandwidth inside shaping queues. In Example C-19, the configuration shows RSVP enabled with Frame Relay traffic shaping (FRTS). The ip rsvp bandwidth command in this case is a subinterface subcommand, essentially reserving bandwidth inside the FRTS queues for each virtual circuit on that subinterface.

Finally, Example C-20 shows RSVP and SBM enabled on Ethernet interface 2. After RSVP is enabled, the interface is configured as a DSBM and SBM candidate with a priority of 100. The configured SBM priority is higher than the default of 64, making the interface a good contender for DSBM status. The maximum configurable priority value is 128, however, so another interface configured with a higher priority could win the election and become the DSBM.

Table C-23 lists the commands used to enable and define the DSBM in Example C-20, which also shows the example SBM configuration.

Table C-22 SBM Commands

This section covers a few details about the commands used to troubleshoot RSVP installations. Table C-24 lists other RSVP commands that can be useful in monitoring and troubleshooting RSVP.

Table C-23 RSVP Monitoring and Troubleshooting Commands

Verifying synchronization is the first step in troubleshooting RSVP. Without synchronization, RSVP has no means to prevent an H.323 gateway from moving into the alerting state and consuming resources that may not be available. To verify synchronization, use the show call rsvp-sync conf command.

Example C-21 shows the output from the show call rsvp-sync conf command.

This output tells you that synchronization is enabled and the reservation timer will wait a maximum of 10 seconds for a reservation response.

To display statistics for calls that have attempted RSVP reservation, use the show call rsvp-sync stats command.

Example C-22 shows a sample output from the show call rsvp-sync stats command.

The show call rsvp-sync stats command offers a quick glance at reservation successes and failures on the router. A high number of errors or timeouts may indicate a network or configuration issue.

You can use the show ip rsvp installed command to display information about local interfaces configured for RSVP and the current reservations on the interfaces. In Example C-23, the show ip rsvp installed command shows that Ethernet interface 2/1 has four reservations but serial interface 3/0 has none.

The current amount of reserved bandwidth for this interface is 187 kbps, as shown in the following:

With this information, you have the ability to compare the actual bandwidth reserved versus the maximum bandwidth configured on Ethernet 2/1 using the ip rsvp bandwidth command. Reserved bandwidth approaching the maximum can result in RSVP rejections.

You can obtain more detail about current reservations with the show ip rsvp installed detail command. Example C-24 shows an output of this command.

In this example, the reservation on Ethernet 2/1 has met the criteria of the voice-like profile and has been admitted into the priority queue. (A weight of 0 identifies the flows that have matched the voice-like profile.) The reservation on Serial 3/0 has not met the criteria of the voice-like profile and so has been admitted to a reserved WFQ.

Remember the following factors regarding the use of RSVP as a CAC mechanism:

RSVP is a true end-to-end CAC mechanism only if configured on every interface that a call traverses.

For the unique capability to serve as both an end-to-end CAC mechanisms, and to guarantee the QoS for the entire duration of the call, RSVP does incur some “costs” on the network, as follows:

Table C-25 evaluates the RSVP mechanism against the CAC evaluation criteria described earlier in this chapter.

Table C-24 RSVP CAC Evaluation Criteria