Gatekeeper Deployment Models

Without the use of a gatekeeper, as the number of gateways in an H.323 network increases, the effort to manage the dial plan grows exponentially. For each gateway, you must specifically code VoIP dial-peers pointing to the IP addresses (or DNS names) of every destination gateway that can be reached from that originating gateway.

When a gatekeeper is used, the dial plan is vastly simplified. Only the local trunk connections need to be defined in the gateways using POTS dial peers. The E.164 addresses to reach these local trunks are then registered with the gatekeeper. You can do this manually by coding zone prefix statements in the gatekeeper, or the gatekeeper can dynamically learn them from the gateway when it registers.

In this configuration, the gateway is only aware of local trunk connections and the gatekeeper. It has no direct knowledge of any of the other gateways in the network. When a call comes into the gateway, one of two things happens:

• A POTS dial peer is matched, and the call goes out a local trunk connection.
• The gateway issues an ARQ to the gatekeeper to find the destination for the call.

Figure 16-9 illustrates the effect of this simplification on even a small network.

Figure 16-9. Dial Plan Simplification Using a Gatekeeper

 

Redundancy

A gatekeeper is a critical network component. It is responsible for most or all of the call routing, bandwidth management, and CAC. Because the gatekeeper centrally controls the dial plan, a failure can cause disruptions across the entire network under its control. Because of this criticality, it is advisable to implement gatekeeper redundancy to reduce the possibility of service interruptions.

Several options are available to provide redundancy in a gatekeeper-controlled network:

• Gateway dial peers Gateways use dial peers that are coded with RAS as the session target to communicate with the gatekeeper. You can code additional VoIP dial peers in the gateway with a lower priority than the RAS dial peer. These lower-priority dial peers have as session targets the IP addresses of the gateways to which they can send calls.

  If the gatekeeper becomes unreachable, the RAS dial peer becomes inactive. At that point, the gateway begins using the lower-priority dial peers to resolve destination addresses.

  Although this might work for smaller networks, the added administrative overhead for coding and maintaining the redundant dial peers removes much of the advantage of using a gatekeeper for centralized dial plan management.

• Hot Standby Routing Protocol (HSRP) Another method of gatekeeper redundancy is the use of HSRP. HSRP has been available for some time in Cisco IOS. Guidelines and caveats for implementing HSRP on a Cisco IOS gatekeeper are as follows:

  - Only one gatekeeper is active at any given time.

  - The standby gatekeeper does not process calls unless the primary gatekeeper fails.

  - No load balancing is supported.

  - All gatekeepers must reside on the same subnet.

  - No state information is maintained between the gatekeepers, and current state information is lost in the event of a failover.

  - Outage duration during a failover might be substantial. All endpoints must reregister with the standby gatekeeper before you can place calls. Active calls are not affected.

  - Gatekeeper configurations must match exactly between the primary and standby gatekeepers. You must replicate any changes or updates manually to the standby.

• Alternate gatekeeper H.323 Version 2 introduced the alternate gatekeeper concept for providing gatekeeper redundancy. The alternate gatekeeper feature allows multiple gatekeepers to control one zone. When an endpoint, such as a voice gateway, registers with a gatekeeper, it is provided with a list of alternate gatekeepers for the zone in which it registers. These alternates were specified in the gatekeeper configuration. If the gatekeeper fails, the endpoint can use the alternate gatekeepers to continue operation. As with HSRP, state information is not maintained between redundant gatekeepers. The alternate gatekeeper feature is the best alternative for networks with non-Cisco gatekeepers.
• Gatekeeper clustering Gatekeeper clustering is a Cisco proprietary feature that uses GUP to maintain state information.

  A gatekeeper cluster is a group of up to five gatekeepers within a zone. The cluster shares information about the zone, including the following:

  - Current calls

  - Gateways within the zone

  - Bandwidth

  - Alternate gatekeepers available for the zone

  - Remote gatekeepers

You can redirect gateways to other gatekeepers in the cluster either because of a gatekeeper failure or to load-balance gatekeeper traffic.

Clustering permits rapid failover in the event of a failure, without losing call state, so CAC information is maintained. Gatekeeper clustering also enhances scalability by allowing load balancing between cluster members based on number of calls, number of endpoints, memory usage, or CPU usage.

These advanced features make gatekeeper clustering the recommended method of implementing redundancy. Cisco recommends using HSRP only if your software feature set does not support clustering.

Resource Availability Indicator

The Resource Availability Indicator (RAI) is a mechanism by which gateways can report the status of resources to the gatekeeper. If RAI is enabled, the gateway tracks the status of DS0 channels and DSP resources.

If a low resource condition occurs, the gateway sends a RAS RAI message to the gatekeeper. The low resource condition is determined by a configurable available resource threshold within the gateway. When the resource level goes above the high resource threshold, the gateway again notifies the gatekeeper that a low resource condition no longer exists. These thresholds are configured as a percentage of total resources.

The RAI feature was introduced in H.323 Version 2 and is available in Cisco IOS Release 12.1.1T and later.

The gateway determines the utilization with the following formulas:

• Accessible channels = In-use channels + free channels
• Utilization = In-use channels ÷ accessible channels

Both DS0 channels of active trunks and DSP resources are monitored in the same manner. If the utilization for either exceeds the configured threshold, an RAI message is generated.

Note that this feature is useful only if multiple gateways are servicing the same call destinations. When more than one gateway can satisfy a request, the gatekeeper selects the gateway to use based on priority and resource threshold. If all gateways have the same priority and resources, the gatekeeper does load balancing among the gateways.

After a gateway is marked as "low on resources," the gatekeeper puts the gateway in the bottom of the priority list. (It changes the gateway priority to 1.) If no other gateway has a higher priority or if all gateways in that zone have priority 1, the gatekeeper still sends calls to the gateway that sent an RAI message declaring that it is almost out of resources.

To cause the gatekeeper to reject interzone calls if all the gateways in that zone are marked as "low on resources," use the lrq reject-resource-low command. If you do not use this command, the gatekeeper does not reject calls from other zones even when all gateways in that zone are marked as low on resources.

Directory Gatekeeper

As H.323 networks continue to grow, you might need additional gatekeepers to be included in the design. This might be necessary if numerous gateways exist, if the call volume is high, or perhaps for geographic or some other type of segmentation.

Each time a new gatekeeper is added, you must update all the gatekeepers in the network so that they are aware of the zones that are local to the newly installed gatekeeper. Configure zones as a full mesh to all the gatekeepers in the network. As more gatekeepers are added, the complexity involved in updating all the zone information grows exponentially.

You can solve this issue in large networks by implementing a directory gatekeeper. A directory gatekeeper contains a registry of all the different zones throughout the network and coordinates the LRQ forwarding process. This is also known as a hierarchical gatekeeper implementation.

Directory gatekeeper is not an industry standard but rather a feature provided on Cisco IOS gatekeepers to facilitate implementation of large H.323 networks.

You can see the impact on network simplification for a large network provided by a hierarchical gatekeeper implementation in Figure 16-10.

Figure 16-10. Simplifying Large Network Implementations with a Directory Gatekeeper