In this network, gatekeeper CAC is again sufficient, although there are multiple gateways per zone. That's 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 will limit the number of calls over that link. It is assumed that the OC-12 backbone link is over-engineered and requires no protection.
In summary, a multi-zone gatekeeper network offers the following CAC attributes:
• The WAN bandwidth at each connecting site can be protected, provided each site is also a zone. For small remote sites in an enterprise network, this often translates into a zone per gateway, which may or may not be a practical design.
• The bandwidth within a site can be protected if necessary, but this is frequently of little value because there is only one gateway in the site (small remote offices, or a CPE entrypoint to a service provider Managed Network Service) or because there is a high-speed LAN between the gateways (large sites and service provider POPs).
• Gatekeeper CAC is a method well suited to limit calls between sites.
• Gatekeeper CAC cannot protect the bandwidth on WAN segments not directly associated with the zones. For example, the backbone link marked with 20 calls in the simple enterprise topology in Figure 4-17 cannot be protected by gatekeeper CAC unless we follow the lowest common denominator approach.
That's why we over-provisioned the bandwidth on this link for the maximum number of calls possible.
Zone-per-Gateway Design
As 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:
• Geographical considerations.
• CAC to protect the WAN access link into a site containing a single gateway.
• Dialing plans often coincide with sites, so a zone prefix easily translates to the gateway serving that site if the gateway is equivalent to a zone.
A gatekeeper is a logical concept, not a physical concept. Each gatekeeper doesn't mean a separate box in the network; it merely means a separate "local zone"
statement in the configuration.
Where combined gateway/gatekeeper software images are available (as in Cisco IOS Release 12.1(5)T and 12.2 mainline), each gateway—at small remote sites in particular—can also be its own gatekeeper, provided the CPU of that platform is sufficient for all these functions. (It likely also serves as the WAN edge router.)
With all this said, a zone-per-gateway design nevertheless thwarts the scalability aspect that gatekeepers bring to H.323 networks, and largely negates the
"centralized dial plan" aspect of gatekeeper networks unless the dial plan is implemented entirely on a separate level using directory gatekeepers. You should carefully consider the pros and cons of such a design.
Gatekeeper In CallManager Networks
Of all the CAC mechanisms discussed in this chapter, gatekeeper zone bandwidth is the only method applicable to multi-site distributed CallManager networks. In this scenario, the CallManager behaves like a VoIP gateway to the H.323 gatekeeper, as shown in Figure 4-20.
Figure 4-20. Gatekeeper in a CallManager topology.
Zone Bandwidth Calculation
The gatekeeper doesn't have any knowledge of network topology and doesn't 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. What the gatekeeper does is take a fixed amount of bandwidth, statically configured on the gatekeeper as we've seen in the preceding network examples, then subtract 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 therefore does not do bandwidth reservation of any kind; it merely does a static calculation to decide whether or not a new call should be allowed.
It is up to the gateways to inform the gatekeeper of how much bandwidth is required for a call. Video gateways will therefore potentially request a different bandwidth for every call setup: One video session might require 256 kbps, another 384 kbps. Voice gateways should take codec, Layer 2 encapsulation and compression features such as Compressed Real-Time Protocol (cRTP) into account 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. At the time this book went to print, this functionality was not yet implemented on Cisco gateways.
In the previous examples, you've assumed a fixed bandwidth of 64 kbps per call.
This is how Cisco H.323 gateways are implemented in current software. The codec and other bandwidth-determining features such as cRTP are not currently being taken into account when the bandwidth of a call is considered by the gatekeeper zone bandwidth calculation. This will change in future software releases, but until then, implementing this feature requires a manual mathematical calculation of how many calls should be allowed based on n times 64 kbps per call and the total available WAN bandwidth.
Gatekeeper zone bandwidth nevertheless remains an inexact science because the gateway might not have full knowledge of the bandwidth required by the call. Layer 2 technologies used in the WAN or backbone legs of the network and hop-by-hop features, such as cRTP, might be used deeper into the network than the gateway is aware of. The following are some examples:
• The gateway might be attached to an Ethernet segment in a campus network where cRTP does not apply and where the Layer 2 headers are larger than they would be for Frame Relay or multi-link PPP on the WAN legs.
• A different codec can be used in the campus network from the WAN segments, leveraging codec transcoding functionality at the WAN edge.
• In the backbone of the network, ATM can be used as the transport technology and cell fill should be taken into account for bandwidth calculations.
• cRTP can be used at the WAN edge router.
Both the gateway and the gatekeeper are unaware of the preceding network topology information unless the gateway is also the WAN edge router, in which case it has slightly more visibility. But it probably still won't see an ATM backbone and therefore won't account for it.
Zone Bandwidth Configuration
As of Cisco IOS Releases 12.1(5)T and12.2 mainline, the following types of zone bandwidth limitations can be configured on the gatekeeper:
• The maximum bandwidth for all H.323 traffic between the local zone and a specified remote zone. (If desired, this configuration can be repeated individually for each remote zone.)
• The maximum bandwidth allowed for a single session in the local zone (typically used for video applications, not for voice).
• The maximum bandwidth for all H.323 traffic allowed collectively to all remote zones.
The following is the syntax for the gatekeeper:
[no] bandwidth {interzone | total | session} {default | zone zone-name}
max-bandwidth
[no] bandwidth remote max-bandwidth
Gatekeeper Zone Bandwidth Summary
Gatekeeper CAC works well in network designs where the desire is to limit the number of calls between sites. This might be required due to either bandwidth limitations or business policy. If there are bandwidth limitations on the WAN legs, manual calculations can be done to translate the maximum number of calls to be allowed between sites into a bandwidth figure that will cause the gatekeeper to deny calls exceeding that number.
Gatekeeper zone bandwidth control is a key part of H.323 video network designs.
Here bandwidth is more of an issue because video uses much more bandwidth per session than voice. In addition, different video sessions can request different amounts of bandwidth for video transmissions, making the manual calculation method used for voice almost unusable.
One additional thing to keep in mind when designing gatekeeper CAC is that redundant gatekeepers complicate the issues somewhat. For example, if HSRP is used on the gatekeepers for redundancy, there is no shared database between the gatekeepers. If the primary gatekeeper fails, the secondary gatekeeper can take over, but it has no knowledge of how much bandwidth is currently used in the zone or how many calls are currently active. Until its information converges back to reflect reality, the secondary gatekeeper will allow too many calls onto the network. 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 4-16 evaluates the gatekeeper zone bandwidth mechanism against the CAC evaluation criteria described earlier in this chapter.
Table 4-16. Summary of Gatekeeper Zone Bandwidth
Evaluation Criteria Value
1 VoX supported VoIP/H.323 only
2 Trunking/IP telephony Trunking and IP telephony
Table 4-16. Summary of Gatekeeper Zone Bandwidth
Evaluation Criteria Value
Some caveats if both CM and Cisco IOS gateways used in the same zone
3 Platform/Release Cisco IOS gateways since Cisco IOS Release 11.3
CM has recent changes in E.164 registration, and bandwidth requested per call
4 PBX trunk types
supported All
5 End-to-end/Local/IP
cloud End to end between outgoing gateway and terminating gateway, although not aware of the network topology (bandwidth availability) in between
6 Per call/
interface/endpoint Per call 7 Topology awareness None 8 Guarantees QoS for
duration of call None 9 Post-dial delay None 10 Messaging network
overhead
Part of the gatekeeper RAS messaging