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:

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:

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:

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

Категории