Gatekeeper Topology

The topology, or layout, of gatekeepers in an H.323 system determines how calls are routed throughout the network and affects how dial plans may be implemented. This makes the gatekeeper a fundamental device in an H.323 network. No special services such as multipoint conferencing or gateways to the public network can be accessed without registering with a gatekeeper.

PRIMARY QUESTIONS

• What is a gatekeeper?
• Why do I need a gatekeeper?
• What is the gatekeeper topology required to accomplish a cross-zone dial plan?

ANSWERS

What is a gatekeeper? The gatekeeper is the brain of an H.323 network, performing essential control, administrative, and managerial functions. However, the gatekeeper does not route any data packets in a network. These continue to rely on standard network routing equipment. The primary purposes of a gatekeeper are address translation and zone administration using layer three of the OSI model.

Why do I need a gatekeeper? Without a gatekeeper, there would be no technical control over use of resources on a network. End-users could strain links and traffic load by placing video calls at 768 kbps throughout the network. Even with Quality of Service enabled, if there is not enough bandwidth to handle the calls, the calls would be of poor quality or fail altogether. Further, an end-user would not be able to dial other end-users by their identities. End-users could only be accessed using their IP addresses.

What is the gatekeeper topology required to accomplish a cross-zone dial plan? A hierarchical gatekeeper structure will reduce administrative complexity for both ITN and the endpoints. This hierarchy allows assignment of different zone dialing prefixes if required. (Alternatives are described more fully below.)

Recommendation: The IPVTF recommends that ITN adopt a hierarchal gatekeeper plan, which will consist of a “Main Directory” gatekeeper, “Zone” gatekeepers, and “Institutional” gatekeepers.

This will allow the implementation of a multi-zone dial plan and also reduce administrative complications that the alternative mesh network would require.

Gatekeeper Topology

Gatekeeper Topology Types

There are two major topologies for a gatekeeper network: mesh and hierarchical.

A mesh network requires every gatekeeper in the network to know about every other gatekeeper on the entire network, as can be seen in Figure 3. This is accomplished within the gatekeeper using a table of neighbor gatekeepers. As the network changes and grows, this table needs to be updated in every single gatekeeper on the network. In a large network, this can be an administrative nightmare.

A hierarchical topology, similar to the layout in Figure 4, requires a gatekeeper to know only about the gatekeepers immediately above and below it. A change across the network would not require a change in every gatekeeper. Thus, this is a more manageable system.

Figure 3 Gatekeeper Mesh Arrangement

Figure 4 Gatekeeper Hierarchical Arrangement

Figure 5 Recommended Hierarchical Gatekeeper Topology

Hierarchical Gatekeeper Structure

The IPVTF determined that a hierarchical gatekeeper structure was the best method to implement for ITN. The gatekeepers used in this hierarchy would have the following requirements:

• Support for gatekeeper clustering for redundancy
• Compatibility with existing network infrastructure and H.323 endpoints
• Support for location request (LRQ) forwarding
• LRQ forwarding needs to forward across multiple gatekeepers
• LRQ forwarding must support at least four levels of hierarchy

Given this set of criteria for gatekeepers, the Dial Plan Committee put together a recommended gatekeepertopology. The topology starts with a primary directory gatekeeper or gatekeeper cluster. Clustering is a method of using multiple gatekeepers to increase capacity and redundancy. It would also offer scalability, since call volume will be low to begin with and increase as time goes by. Fanning out from this directory gatekeeper cluster are sub-gatekeepers. These sub-gatekeepers would be placed at each of the ITN major nodes and allow registration from ITN customers who may not have their own gatekeeper. These sub-gatekeepers would have a dialing prefix matching the area code of their location.

Larger institutions that wish to install their own gatekeeper should choose to install a directory gatekeeper. This gatekeeper would be “neighbored” to the ITN main directory gatekeeper. Sub-gatekeepers operated by the entity would be set up below their directory gatekeeper in the hierarchy.

This plan allows for three total levels of hierarchy including two levels for a large entity and two levels for ITN (due to the fact that the level immediately below the main directory gatekeeper will have some ITN gatekeepers and some institutional gatekeepers). A fourth level, which would be above ITN, could be used in the future for participation in a national network.

Recommended Topology

A drawing of the recommended gatekeeper topology is displayed in Figure 5. The drawing is simplified for clarity, as there would obviously be many more client terminals as well as institutions with their own gatekeepers. The main points to be conveyed with the drawing are as follows:

• There is a central redundant directory gatekeeper cluster, which is the central point of control for the entire state.
• No terminals are registered with the Main Directory Gatekeeper.
• Attached to this Main Directory Gatekeeper are the ITN Node Gatekeepers.
• Node Gatekeepers are placed at the various nodes of the network and will have dialing prefixes to match their respective area codes.
• Node Gatekeepers can accept registration from terminals.
• Institutions can have their own Directory Gatekeeper to service their own sub-gatekeepers attached to nodes of their own internal networks.
• Institutions’ Directory Gatekeepers will be connected directly to the ITN Main Directory Gatekeeper.
• Terminals will register with the gatekeepers using Registration Admission Status (RAS) protocol. Using gatekeepers for address resolution allows terminal endpoints to be configured for dynamic IP address allocation (DHCP). Terminals can literally be taken around the world and installed on any network. As long as terminals are registered with the same gatekeeper, they can be dialed using the same method as if they were at home. This is not unlike “roaming” in a mobile telephone arrangement.

This gatekeeper topology requires no more than three levels of hierarchy for the entire state. Given the current state of LRQ forwarding support within gatekeepers, only four total levels of hierarchy could be supported. This may change in the future, allowing a larger hierarchical structure. At this time, using three levels for the state leaves an additional level to allow participation in a larger network with other states.