|
|
This chapter presents the following major topics:
—Discusses the basic components of the gatekeeper core, namely gateways, gatekeepers, and directory gatekeepers
—Illustrates how to configure core components in a wholesale VoIP service provider network
—Provides links to online references for how to install Cisco hardware
The infrastructure of a traditional gatekeeper core functional area consists of gateways (GWs) and gatekeepers (GKs). In a typical service provider network, a number of GWs are deployed at POPs throughout the service provider's coverage area. A GK is used to group these GWs into logical zones of control and perform all call routing between the zones.
However, larger H.323 VoIP networks may consist of multiple GKs, which segment the network into numerous local zones. In this case, GKs must communicate with each other in order to route calls between GWs located in different zones. To simplify the administration of dial plans for these multi-GK networks, Cisco introduces the concept of a directory gatekeeper (DGK), which is responsible for routing calls between local GKs.
With respect to the dial plan, each component within the H.323 network is responsible for a portion of the entire VoIP dial plan. GWs are responsible for making edge routing decisions between the PSTN and the H.323 network, while GKs and DGKs handle the core call routing logic between devices within the H.323 network. The configuration requirements for each of these network components are detailed in this chapter.
For example, when presented with a call, GWs determine whether a call should be sent out to the PSTN or into the H.323 VoIP network. If a call is sent into the H.323 VoIP network, then the GW asks the GK to select the best endpoint to receive the call. From its routing table, the GK may find that this endpoint is a device within its own local zone of control, in which case the GK simply supplies the IP address of the terminating endpoint. Alternatively, it may determine that the endpoint resides under the control of another remote GK. In this case, the GK forwards the location request (LRQ) either to the remote GK directly, or through a DGK. The remote GK ultimately responds with the address of the terminating endpoint. Figure 2-1 shows the relationship of the components that constitute the gatekeeper core, with VoIP-enabled GWs providing access to the PSTN.
Table 2-1 summarizes the functions of the components of the gatekeeper core.
For an example of these components in a large-scale H.323 VoIP network, see A Large-Scale H.323 VoIP Network.
Figure 2-2 illustrates the relationship of GWs, GKs, and DGKs in a large-scale H.323 VoIP network.
The communication between GWs and GKs is based on standard H.323v2 registration, admission, and status (RAS) messages. GWs query GKs for routes by means of RAS admission request/confirm (ARQ/ACF) messages. Cisco GKs and DGKs also communicate with each other by means of RAS location request/confirm (LRQ/LCF) messages. Figure 2-3 illustrates an example RAS message sequence when phone A calls phone B. For additional information about H.323v2 RAS messaging, refer to Cisco H.323 Version 2 Phase 2, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/h323v2p2.htm
This section discusses the basic principles underlying dial plans, which require configuring POTS and VoIP dial peers, and the related number-translation process known as "number normalization."
The dial plan is the method by which individual blocks of telephone numbers (technically, E.164 addresses) are assigned to physical facilities, or circuits. For large-scale service provider networks, dial plans consist of the following:
POTS dial peers define the phone numbers or prefixes of attached telephony devices, and the VoIP dial peers define the IP address of the remote device (H.323 GW, GK, or endpoint) that is connected to remote phone numbers. POTS dial peers will always point to a voice port on the router, while the destination of a VoIP dial peer will always be the IP address of a device that can terminate the VoIP call.
Good dial-plan architecture relies on effectively distributing the dial plan logic among the GW and GK components. Isolating H.323 devices to a specific portion of the dial plan reduces the complexity of the configuration, so each component can focus on accomplishing specific tasks. Generally, local POP-specific details are handled at the local GW, whereas higher-level routing decisions are passed along to the GKs and DGKs. A well-designed network consists of keeping the majority of the dial plan logic at the GK and DGK devices.
It is important to apply some basic design principles when designing a large-scale service provider dial plan.
1. Keep the design hierarchical.
Strive to keep the majority of dial plan logic (for routing decisions and failover) at the highest component level. The DGK would generally be considered the "highest" device. With a hierarchical design, the addition and deletion of zones becomes more manageable. For example, the scaling of the overall network is much easier when configuration changes must be made to only a single DGK and a single zone GK—rather than to all the zone GKs.
Keep the dial plan on the GWs and GKs as simple and symmetrical as possible. On the GWs, try to keep consistent dial plans, using translation rules to manipulate the local digit dialing patterns. These number patterns can be "normalized" into a standard format or pattern before the digits enter the VoIP core. By putting digits into a standard format, you simplify GK zone prefix provisioning and make GW dial peer management easier.
This methodology helps to reduce dial peer configurations on the outgoing POTS interface. If the GK can be provisioned to direct only calls of a certain area code to a particular GW, then you would not need to provision all the individual GWs with their respective area codes. Instead you may be able to generalize the GW configurations. By normalizing the number, you also reduce the length of zone prefix searches—and reduce the time to search for a zone prefix match. For example, if you have the digit pattern 0118943xxxx, you can send the number as only 8943xxxx, and have the gatekeeper search on 89 instead of on 01189.
Consider the effects of postdial delay in the network. GW/GK zone design, translation rules, and sequential LRQs all can increase postdial delay. Strive to use these tools efficiently in order to reduce postdial delay.
4. Design for availability and fault tolerance.
Consider overall network availability and call success rate. Using a Cisco alternate gatekeeper, sequential LRQs, and Hot Standby Routing Protocol (HSRP) helps to provide redundancy and fault tolerance in the H.323 network.
Designing a quality dial plan is essential to increasing network efficiency and maintainability. This section introduces a series of topics related to establishing a dial plan:
Consider two VoIP-enabled access GWs, one originating and one terminating, that transport a PSTN-to-VoIP call through the IP cloud. Figure 2-4, using the example of the EMEA PSTN, illustrates this basic direct inward dial (DID) scenario.
 |
Caution Cisco recommends that you make routing or dialing transparent to the user. For example, where possible avoid secondary dial tones from secondary switches. Enabling direct-inward-dial suppresses secondary dial tone, and therefore DID must be enabled when a GW interfaces to a PSTN switch. The switch normally provides dial tone, but does not send dial tone to the GW when DID is enabled. This issue is discussed in Configuring Voice over IP, at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/multi_c/mcprt1/mcdvoip.htm |
When DID is used on a POTS dial peer, the number that is dialed (DNIS, the number that accesses the PRI trunk of the GW) automatically becomes the destination-pattern number for the IP direction. On the originating GW, there is a POTS dial peer with a destination pattern that matches the DNIS. The dial peer for this example looks like the following:
The POTS dial-peer (100), which matches the port that the call came in on, has DID configured. The direct-inward-dial statement in the dial peer tells the GW to look for a number in a VoIP dial peer that matches the DNIS. It finds it in the following:
So a call is made across the IP network to 10.11.253.8 and a match is found in that terminating GW:
This dial peer matches on the dialed number and changes that number to 5274094 with the prefix command. The end result is that the user dials one number, gets connected, and never knows that the number reached is totally different from the number dialed.
GW dial plan configurations are focused on local PSTN access information at the edge of the H.323 network. This includes defining which E.164 prefixes are supported by the PSTN connections of the GW. In large-scale SP-type designs, the GW may also be relied on to perform "digit manipulation," where the GW takes a calling or called number and strips or adds (prefixes) digits before sending the number to its destination. The process of formatting the calling or called number to a predefined pattern is called "number normalization."
Figure 2-5 illustrates the process of translating a PSTN number for use in a VoIP network. The GW is connected to the PSTN and VoIP cloud, and uses Cisco IOS translation rules to accomplish digit manipulation. Translation rules can be applied on the GW's physical port, or in a VoIP dial peer. For example, number manipulation can be configured on the incoming POTS port, the outgoing voip dial peer, or both, to format a 7, 10, 11 or x-digit pattern into a fixed 10-digit pattern. The result is a number that has been normalized when it enters the VoIP cloud.
 |
Note Fore more information about translation rules, see Dial Plan Basics at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/dt0390s7.htm |
The translation rule above matches digit patterns that begin with [0011-0019] and translates this 4-digit pattern to [1-9], while preserving the remaining digits included in the digit pattern. This effectively strips the 011, a common international access code, and sends the remaining digits to the VoIP GK for call routing.
Translation rules can be used to manipulate both ANI and DNIS numbers. The parameters destination-pattern, answer-address, incoming-called-number, and numbering-type can all be configured to match a call's ANI (Automatic Number Identification) number, that of the originating party, or its DNIS (Dialed Number Identification Service) number, that of the destination party.
 |
Tip To test a translation rule, use the command test translation rule <rule number> <number to translate>, as in the following example: |
|
Note For background and syntax on translation rules, refer to Dial Peer Enhancements at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/dt0390s7.htm |
Also known as a "tech prefix" or a GW's supported prefix, the technology prefix is an arbitrary, administrator-defined prefix that is used to define a GW type. Analog GWs, which frequently use FXS signaling, do not require the use of a tech prefix, as the E.164 address is registered to the GK. However, digital GWs, which use T1/E1 signaling, require the use of a tech prefix.
For example, you might assign, on an H.320 GW, the prefix 1# to indicate 1-channel calls, and the prefix 2# to indicate 2-channel calls. Alternatively, you might use 1# to indicate voice GWs, 2# to indicate H.320 GWs, 3# to indicate GWs fronting voicemail servers, and so on. So, a call to "1#4085551212" would mean "Use a voice GW to reach 4085551212."
Each GW must be configured to register its tech prefix with its GK. The user interface varies depending on the vendor, but on Cisco voice GWs it is configured by means of the command h323-gateway voip tech-prefix. To facilitate administrative manageability, it is recommended that you use the same tech prefix to represent the same type of GW through all zones in your network.
The caller must prepend the tech prefix to the called number to indicate the type of GW to be used for hopoff. If the call originates through a Cisco voice GW, configuring the matching dial peer with the tech prefix to be prepended does this. If the call originates with an H.323 endpoint, the administrator will have told the user what tech prefix to use for the hopoff GW to the called number.
|
Caution If a call is not supplied with a tech prefix, you must configure a default tech prefix. Otherwise, the call will fail. |
The remote VoIP GWs will still have some dial peers to match digits, but instead of the dial peers pointing to all other VoIP GW, they will use H.323 RAS to register with the GK, and then query the GK for dial plan details. The GK will have all of the zones, zone prefixes, and tech prefixes defined, and will return the information necessary to complete the VoIP call to the originating VoIP GW.
GKs are configured to administer their local country zones and city/area codes (for example, 8610*) to their specific GWs. A DGK is used to handle call routing on the country code alone. Where necessary, GWs can use translation rules to normalize DNIS or ANI numbers before they are propagated to the GK and DGK. For details, see Configuring Translation Rules on the Gateways.
This section discusses the following fundamental activities:
In the following example, a service provider wants to offer voice services with a presence in North America, Asia, and EMEA (Europe, Middle East, and Africa). We will design and configure a GW, GK, and DGK H.323 network that will consist of the following:
The following are key design goals:
Figure 2-6 is a simplified view of our example wholesale network, whereas Figure 2-7 shows the detailed topology.
|
Note See also Figure 1-1, to review the basic aggregation model and all of its potential components. |
Building the core fundamentals consists of the following, as discussed below:
a. Configuring TDM connections to the PSTN (physical connections and POTS dial peers)
b. Configuring the GW to register to the GK
In addition, the following activities are also essential to the proper functioning of the core network.
Figure 2-7 illustrates a detailed topology of our example network. Although it is not illustrated here, calls can originate and terminate on GWs through analog interfaces (FXS, FXO, and E&M), as well as on digital interfaces, such as T1/E1 and PRI.
First we will focus on building a single GK zone. US-GW1 and US-GW2 are GWs in the North American (NA) zone, specifically in the San Francisco POP, and act (collectively) as the GW between the PSTN and the VoIP network. Both GWs register to the zone GK, forming a zone called NA-GK.
Figure 2-8 illustrates the components of zone NA-GK. Figure 2-7 illustrates the overall network topology.
A look at the configuration file for the two GWs, US-GW1 and US-GW2, illustrates the establishment of T1 facilities. The establishment of E1 facilities is similar. We begin with US-GW1, then proceed to US-GW2. In this example we use Cisco AS5300 GWs.
|
Note For detailed information about T1 and E1 provisioning, refer to the following URLs: |
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/dialts_c/dtsprt3/dcdchant.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/dial_r/drprt1/drchant.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/dial_c/dcchant.htm
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/sw_conf/ios_121/5300r2.htm
a. Establish T1 PRI signaling parameters for US-GW1. In this example, framing is ESF, linecode is B8ZS, and timing is being provided by the GW itself. The parameter pri-group allocates 24 DS0 channels.
b. Establish the physical interface that the PRI facility from US-GW1 will use. The 0 in Serial0:23 creates a relationship with the PRI facility that controller t1 0 established above. 23 indicates that channels 0 through 23 are used. Here the switch type is defined.
c. Establish the voice ports for US-GW1. In this case, the signaling is PRI, and the D-channels must be defined. In this case, we have configured only the first T1 interface for D-channel signaling. The remaining three voice ports are the default settings.
Step 2 Do the following on US-GW2.
a. Establish T1 CAS signaling parameters for US-GW2. Parameters are as for US-GW1. ds0-group 0 establishes a relationship between a T1 port and 24 DS0 channels (comprising a full T1). In this example, signaling has been defined as E&M, Feature Group B, multifunction tone, with the DNIS option (for DID). The ds0 busyout statement places all 24 time slots in the busyout state when they change state.
b. Establish the physical interface that the T1 CAS facility from US-GW2 will use. See Step 1a above.
c. Establish the voice ports for US-GW2. See Step 5. Because this GW uses CAS signaling, no D-channel is defined. Again, the remaining three voice ports are the default settings.
This concludes the basic establishment of facilities and dial peers. To have the GWs register with the GK, as well as to establish dial plans and translation rules, continue with the steps below, with US-GW1 as an example. See also Establishing a Dial Plan.
We begin with US-GW1, then proceed to US-GW2.
|
Caution The above must be the first H.323 command you configure. If you do not do this, the other H.323 commands will not appear following a show run. |
d. Establish the identity of the GK to which the GW will register. NA-GK is the name of the GK zone, and 1719 is the well-known port for H.323 RAS registration.
Step 2 On US-GW2, change the IP address and name of the GW and repeat Steps a through f, above.
Now we configure the appropriate translation rules on both GWs. The rules will be the same on both GWs. Refer to Number Translation or Normalization. Table 2-2 summarizes the current dialing patterns for each of the GWs in our configuration example. The objective is to use number normalization to reduce the number of dial peers on each GW.
|
Note For detailed information about translation rules, see Dial Peer Enhancements at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121limit/121x/121xm/121xm_5/ftdpeer.htm |
Do the following on both US-GW1 and US-GW2.
Step 2 Write a translation rule that adds the North America country code and local area code to the DNIS number. This is translation rule 2, which applies to the POTS dial peer.
As the VoIP dial peers are the same on both GWs, do the following on both US-GW1 and US-GW2. However, different POTS dial peers are needed, to serve different area codes.
a. Configure a VoIP dial peer for an international call that requires a country access code (here 011). See the note below for a discussion of the variable parameter T.
b. Configure a VoIP dial peer for a local 7-digit number. The last two lines, respectively, invoke translation rule 1 on a match, and cause a RAS ARQ message to be sent to the GK.
c. Configure a VoIP dial peer for an intra-country (in our example, U.S. domestic) call (1-xxx-xxx-xxxx).
Step 2 Configure POTS dial peers on the GWs. These will vary by area code.
Now look at key elements of the configuration for US-GW2.
Follow the steps below to configure the GK. See Building a Single GK Zone.
Step 2 Configure the router to be a GK and create a zone prefix table.
c. Create a zone prefix table for the zone served by US-GW1. This defines NA-GK as the zone for administering the 1408* prefixes. (1408* numbers reside in the GWs belonging to the NA-GK zone.)
e. Assign a default technology prefix. (Optional. See Technology Prefixes.)
Step 3 Verify that the GWs register to the GK.
When the registration is successful, something like the following appears. The GWs appear as endpoints. The other parameters are self-explanatory.
|
Note Endpoint registration is checked only on the initial RRQ. It is not checked on keep-alive RRQs. |
Step 4 Now build a new zone. Refer to Figure 2-9.
We will configure a second zone, AS-GK, located in China. For simplicity, this will consist of one GW at the China POP, and an associated zone GK.
The following are example abbreviated configuration files for the gateway CHINA-GW1 and the gatekeeper AS-GK.
Step 2 Now look at the GK.
The following steps add a DGK to the zones that have been established. The directory gatekeeper named DGK will be added to the network to provide call routing between the zone GKs. This DGK will contain the master zone prefix table, relieving the individual GKs of having to maintain the most current information. Figure 2-10 illustrates the relationship of DGK to zones NA-GK and AS-GK.
|
Note Consider the following performance relationship between the DGK and the GKs it supports. On the average, the DGK requires one-quarter of the CPU processing capacity needed by the local zone GKs. So if the CPU load on the GK is 40%, then you only need 10% CPU allocation on the DGK. Cisco IOS software has a limit of 5 recursive LRQs; an LRQ is limited to 5 hops. Local zones and LRQ forwarding zones can be mixed. |
Follow the steps below to add a DGK.
Step 2 Configure the zone prefix table on the DGK. A local zone called DGK is established, and the remote zones NA-GK and AS-GK are configured. DNIS numbers that begin with 1 (the NA-GK country code) are handled by NA-GK. DNIS numbers that begin with 86 (the AS-GK country code) are handled by AS-GK. The appropriate zone prefixes are configured to forward LRQs to the respective GKs, as shown below. Again, 1719 is the well-known port for H.323 RAS registration (the GK UDP registration and status port).
If one or more GWs become unduly burdened by incoming calls, there are various ways to manage traffic. This section discusses two techniques:
Problems can arise when traffic load causes GWs to reach their capacity. The Resource Availability Indicator (RAI) is an H.323 feature that informs the GK when no circuits (DS0s) or DSPs are available. RAI messages indicate both the availability and unavailability of a GW, depending on the threshold for each that the user can set. RAIs let the GK select the best available GW at the outset, increasing call-completion rates and lowering postdial delay. After the GK receives an RAI from an overburdened GW, it will not assign calls to that GW.
There are two load thresholds: A high value determines when the GW sends the GK an "unavailable" RAI, and the low value determines when the GW sends the GK an "available" RAI. The syntax is as follows:
So, to set a high threshold of 90 and a low threshold of 80, we enter the following:
To see the results, issue the command show gateway, as follows.
If only a single GW is within a zone, the GK will give that GW the call, in the hope that there are enough resources to terminate the call. Otherwise, the preferences will reroute the call at the ingress GW.
Call admission control (CAC) is another way to assign priority to GWs. The priority of the GW is configured on the GK to prioritize selection from among multiple GWs. The GK can select the most available GW at the outset, to increase call completion rates and lower postdial delay. The usage is as follows:
The result is a master list, which you can see with show gatekeeper:
This section discusses how to interconnect to an new administrative domain, such as a new wholesale VoIP provider. The interconnection is between two DGKs, and the DGK of the new SP forwards LRQs to the previously established domain, and vice versa.
Figure 2-11 illustrates the addition of a DGK, AUS-DGK, and the South Pacific zone it maintains. The GK is AUS-GK. The POP is Australia POP, and the country code is 61. The new DGK sends LRQs to the virtual address of the paired DGKs to the right. For information about virtual addresses and enabling redundancy, see Providing Redundancy for Fault Tolerance.
The following is an abbreviated configuration that highlights the essentials of configuring a GW in the new DGK zone. Our new GW is AUS-GW1. For details, see Adding a Directory Gatekeeper to the Zones.
|
Note The zone prefix "DGK *," above, represents zone prefix DGK 1 *, DGK 33 *, and DGK 86 *. See Table 2-4 on page 2-59. |
There are three principle methods of providing fault tolerance in large H.323 networks:
Figure 2-12 (the same as Figure 2-6) illustrates a network that provides fault tolerance through HSRP at the DGK level, alternate GKs, and alternate DGKs.
In addition, redundant components contribute considerably in minimizing downtime during software upgrades. For a discussion of things to consider when upgrading Cisco IOS software and other software, see Providing Redundancy for Software Upgrades.
Fault tolerance and redundancy within H.323 networks is most important at the DGK level. Current and future versions of Cisco IOS allow DGK redundancy to be configured for alternate DGKs, and Cisco's HSRP (Hot Standby Routing Protocol) to be configured for DGKs.
|
Caution Although both approaches can be used, Cisco recommends that only HSRP be used on DGKs, and that alternate GKs be used for zone GKs. |
In an alternative to the HSRP approach, using an alternate GK at the zone level provides redundancy. This enhancement allows a GW to use up to two alternate GKs as a backup in case a primary GK fails. More specifically, the GWs are configured to register to a primary and an alternate GK. If the primary GK fails, the alternate GK can then be used for call routing, and maintain call routing without call failure. Because Cisco GKs do not communicate registration states between each other, sequential LRQs must be configured on the GKs and DGKs to accommodate zone fragmentation. The configuration of the GKs is similar to that of the DGKs discussed in Method 3: Configuring an Alternate DGK.
Figure 2-13 illustrates a fault-tolerant architecture in an example network that uses alternate GKs.
GWs may be configured to register to a primary GK and an alternate GK if the primary GK fails. This implies that at any given time, a GW may be registered to either its primary or alternate GK. Since Cisco GKs do not communicate registration states between each other, sequential LRQs must be configured on the GKs and DGKs to accommodate zone fragmentation.
For example, a GK in the Western zone supports GWs in San Jose (408) and San Francisco (415). Under normal circumstances, when San Jose calls San Francisco, the route is resolved in the local primary GK. However, assume that San Jose fails over to the alternate GK while San Francisco remains on the primary GK. To continue to support regional call completion within the Western zone, the primary and alternate GKs must be provisioned to send local prefixes to each other if no local resources exist (for example, the terminating GW has failed over to the other GK). In this case, in order for San Francisco to complete calls to San Jose, the primary GK must know to send an LRQ for the San Jose prefix to the alternate GK. Similar provisioning is required on both primary and alternate GKs to support calls in both directions.
Provisioning is also required on the DGK to prevent zone fragmentation issues when calls are originated from other zones. For example, if San Francisco sends a call to New York, the DGK does not know with which GK (primary or alternate) the NY GW is registered. The DGK must be provisioned to send sequential LRQ requests to both primary and alternate terminating local GKs for all Eastern zone supported prefixes (messages 1a and 1b, which are addressed to both DGKs in the HSRP area). Similar provisioning is required for the Western zone prefixes to support calls in the other direction.
HSRP is used to provide fault tolerance for the DGK. However, HSRP failover detection may take some time during which no calls will be processed. To cover this case, local GKs may be configured to point to more than one DGK (an ALTDGK) for its wild-card route using sequential LRQs.
For example, the GK may point to an HSRP DGK pair as its primary option (message 1). If no response is received because HSRP failover has not been detected yet, the GK may initiate another LRQ (message 2) to an ALTDGK after a configurable timeout (100 to 1000 ms) to try to complete the call. During this time, calls will still be completed, although with additional postdial delay. The ALTDGK is configured in exactly the same way as the primary DGK HSRP pair (messages 2a and 2b).
Because the DGK maintains the majority of the call routing intelligence (such as zone prefix tables, tech prefix tables, E.164 registrations), the DGK should be fault tolerant. DGKs can be configured as HSRP pairs with a shared virtual IP address, so that when one DGK fails, the standby DGK assumes its role. Zone GKs need only to point to this virtual address.
A primary and secondary DGK functioning as a fault-tolerant pair must be addressed by a single virtual address. Figure 2-14 illustrates this assignment, with the virtual address 172.19.49.190 functioning as a single address (from the point of view of incoming traffic) for DGK1 and DGK2.
An active and a standby DGK must be configured on the same subnet, and therefore must be colocated. HSRP uses a priority scheme to determine which HSRP-configured router is to be the default active router. To configure a router as the active router, you assign it a priority that is higher than the priority of the other HSRP-configured routers. The default priority is 100, so if you configure just one router to have a higher priority, that router will be the default active router.
|
Caution Cisco recommends that you use the HSRP redundancy method at the DGK level, not at the zone GK level. This is because HSRP does not support reregistration from one HSRP DGK to the adjacent HSRP DGK. |
HSRP works by exchanging multicast messages that advertise priority among HSRP-configured routers. When the active router fails to send a "hello" (heartbeat) message within a configurable period of time, the standby router with the highest priority becomes the active router. An HSRP GK sends these "hello" messages every 3 seconds by default.
For more information about HSRP, refer to the following URL:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm
The standby timers interface configuration command sets the interval in seconds between hello messages (1 through 255 sec) and sets the duration in seconds that a router waits before it declares the active router to be down (1 through 255 sec). The defaults are 3 and 10 seconds, respectively. If you decide to modify the default values, you must configure each router to use the same hello time and hold time. For example, on an interface xxx, we could change the default values as follows:
where 5 = hello interval and 15 = the time the active router can be down before this state is declared.
The command does not appear until the value is changed. For more information, see the topic "Configuring HSRP" at the following URL:
http://www/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt1/1cdip.htm
HSRP failover detection may take some time, during which no calls will be processed. To cover this case, local GKs can be configured to point to an additional, or alternate, DGK. This alternate DGK can be used to back up an HSRP DGK pair, by using the sequential LRQ feature available on the zone GKs. For instance, if a zone GK sends an LRQ to a primary DGK, and fails to receive an LCF in return, another sequential LRQ can be sent from the zone GK to this alternate DGK. During this time, calls will still be completed, although with additional postdial delay. The alternate DGK will then provide the normal DGK prefix lookup and call routing in the network, until the primary DGK is able to function again. The alternate DGK is configured just like the primary DGK in the HSRP DGK pair. We apply this design in the example configuration shown in Method 3: Configuring an Alternate DGK.
|
Caution Cisco recommends that you use a combination of alternate GK, HSRP DGK, and alternate DGK to provide fault tolerance and redundancy in large H.323 networks. |
Although it is up to the service provider to determine the service availability required by its customers, it remains good practice to ensure that voice traffic is not interrupted. In many cases, "five nines" (99.999%) availability may be required. In addition to providing redundancy to cover outages of equipment or communications channels, it is necessary to provide redundancy to support traffic during upgrades of the Cisco IOS software.
|
Caution It is the responsibility of the service provider to engineer the network in such a way as to provide the required service availability for their customers. |
To ensure that software upgrades do not affect service availability, Cisco recommends that you provide redundancy for all components of the GK core. Note the following considerations:
|
Note The most recent information about upgrading the Cisco IOS software can be found in the Release Notes for your software. |
To upgrade software at the GW level, follow the steps below.
1. Ensure that the new Cisco IOS image is available on the TFTP server.
2. Download the new Cisco IOS files from a TFTP server to available flash memory on the selected routers. beforehand. To minimize service unavailability, it is recommended that you upgrade only one router at a time.
3. Select a maintenance window that ensures the least disruption of traffic. Do the following during the maintenance window.
a. Redirect traffic from the routers whose software is to be upgraded.
b. If you have GWs that support SS7 links, you must take those links out of service (OOS) on the Cisco SC2200 that supports those links. (This involves editing the file config.mml of the SC. See Step 4 of Define APCs, Linksets, SS7 Routes, and NAS Paths.)
c. Reboot the routers to move the new image from flash memory to RAM. This activates the IOS upgrade.
It is essential that billing information not be lost. In addition to providing redundancy to cover outages of equipment or communications channels, it is necessary to provide redundancy to maintain billing data during upgrades of software to support billing applications. Components to consider include AAA/RADIUS servers, OSP servers, and other servers providing third-party billing and settlement applications.
It is generally not necessary to provide redundancy at the network management level, because these applications can go out of service during a maintenance window with minimal impact on traffic. However, it is the responsibility of the service provider to consider any possible effects such outages may have, and provide redundancy if necessary.
The following configuration scenarios provide examples that illustrate the methods discussed above:
See Figure 2-7 for the relationships and address of the components discussed in these configurations.
Use this method, which uses the priority statement, to configure GWs to register to a primary and secondary (alternate) GK in the absence of HSRP.
The configuration registers each GW in a zone with two GKs, one primary and one secondary. Default priority = 127 (127 is lowest priority, 1 is the highest priority). 1719 is the well-known port for H.323 RAS messaging.
In this case, we have configured 172.18.193.65 as the primary (priority = 120) and 172.18.193.66 as the secondary GK.
Step 2 Verify the configuration.
Use this method to configure a primary and secondary (standby) DGK in an HSRP DGK pair.
This is the actual IP address of DGK1. The next two lines declare, respectively, the standby priority for this DGK and the virtual IP address of the HSRP DGK pair.
Step 2 Declare the first DGK and create zone local and zone remote statements.
The key to establishing an HSRP pair is having identical zone statements on each DGK. Note the following configurations for DGK1 and DGK2, respectively. Use the gatekeeper command to establish the DGK identity of the router. The zone local statement assigns the virtual address shared by the HSRP pair.
|
Note Note the lower standby priority. All zone statements must be identical to those in the other member of the HSRP DGK pair. |
Use this method to configure an alternate DGK in the absence of HSRP. The configuration, residing on each of the zone GKs, is identical to that of the primary DGK. The following illustrates a configuration on a duplicate DGK that shares the same routing table as the primary:
The following illustrates how to configure on each of the zone GKs a zone remote statement that points to an alternate DGK if the primary DGK fails. See Figure 2-13, and Using an Alternate Directory Gatekeeper for Fault Tolerance.
This section introduces the topic of H.235 security, and provides an example of configuring GWs, a GK, and an AAA/RADIUS server to provide security.
The RAS channel used for GW-to-GK signaling is not a secure channel. To ensure secure communication, Cisco H.235 access tokens allow GWs to include an authentication key in their RAS messages. This key is used by the GK, which passes it to a AAA/RADIUS server for verification of a user password and H.323 ID.
Cisco H.323 GWs support the use of CryptoTokens for authentication where the token can be included in the RRQ and ARQ messages. Figure 2-15 illustrates the generation and validation of a Cisco H.235 security token. This example illustrates "registration only" security. CHAP (Challenge Handshake Authentication Protocol) is the method used.
|
Note CHAP is supported on lines using PPP encapsulation, to prevent unauthorized access. CHAP does not itself prevent unauthorized access, but merely identifies the remote end. The router or access server then determines whether that user is allowed access. |
Figure 2-16 illustrates a CHAP challenge for a GW named WestGW and a GK named WestGK.
The general sequence is as follows:
1. A user password is manually established on the GW.
2. A token is generated at the access GW. The token results from the hashing of the user password, an H.323 ID, and a timestamp.
3. The GW passes the token to the GW as part of an RRQ (Registration Request) message.
4. The GK passes the token to the AAA/RADIUS server for validation.
a. If the password and H.323 ID match records on the AAA/RADIUS server, the token is validated.
b. If the password and H.323 ID do not match the records, an RRJ (Request Reject) is returned and the GW is not allowed to register with the GK.
5. The validated token is passed back to the GK as an RCF (Registration Confirm) message.
The following examples illustrate security configurations for the following components:
Refer to Figure 2-15.
The configuration of the necessary files on the RADIUS host will vary according to the application. In some cases these correlate the H.323 IDs of GWs or GKs with a key, or password.
For further details, see RADIUS Vendor-Specific Attributes Voice Implementation Guide Version 3.0 at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/vsaig3.htm
Establishing proper timing is essential not only for the proper operation of standard network functions, but also for the establishment of accurate stop and start intervals on call legs for billing and other accounting purposes.
The information below has been adapted from Task 1. Enabling the Network Time Protocol, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/as5xipmo/sysmgt.htm
For further information, including NTP time formats and links to useful sites, refer to Network Time Protocol (NTP) Usage Guidelines in Configuration Guide for AAA Billing Features in Cisco Voice-Enabled Routers and Access Servers, at the following URL:
http://www.cisco.com/warp/public/cc/so/cuso/sp/sms/acct/caaaf_cg.htm
The Network Time Protocol (NTP) provides a common time base for networked routers, servers, and other devices. A synchronized time enables you to correlate syslog and Cisco IOS debug output to specific events. For example, you can find call records for specific users within one millisecond.
Comparing logs from various networks is essential for the following tasks:
Without precise time synchronization between all the various logging, management, and AAA functions, time comparisons are not possible.
An NTP-enabled network usually gets its time from an authoritative time source, such as a Cisco router, radio clock, or an atomic clock attached to a timeserver. NTP then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to within a millisecond of one another. NTP runs over UDP, which in turn runs over IP.
|
Note NTP services are enabled on all interfaces by default. |
There are a variety of optional NTP features you can configure. For details regarding the following options, refer to Performing Basic System Management at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_c/fcprt3/fcgenral.htm#xtocid1345017
Use this feature to authenticate the associations with other systems for security purposes.
An NTP association can be a peer association (meaning that this system is willing to either synchronize to the other system or to allow the other system to synchronize to it), or it can be a server association (meaning that only this system will synchronize to the other system, and not the other way around). Use this feature to form an NTP association with another system.
The system can either send broadcast packets or listen to them on an interface-by-interface basis. You can also use this feature to configure the estimated round-trip delay for broadcast packets.
You can control NTP access by creating access groups and assigning a basic IP access list to it, and you can disable NTP services on a specific interface.
When the system sends an NTP packet, the source IP address is normally set to the address of the interface through which the NTP packet is sent. Use this feature to configure a specific interface from which the source IP address will be taken.
Even if a particular system is not synchronized to an outside time source, you can use this feature to be an authoritative NTP server.
On systems that have calendars, you can configure NTP to update the calender periodically.
The steps below are an example of how to enable NTP on a single Cisco AS5300
 |
TimeSaver For testing purposes, you can use a Cisco router as the master timing source. Set the time, then assign master status to this router, as follows: clock set 14:00:00 22 jun 2001 ntp master However, this is not recommended in a production network. |
Step 2 On the Cisco router, specify the primary NTP server's IP address and automatic calendar updates on other routers that will be slaves to the master clock:
Step 3 Verify that the clock is synchronized to the NTP server. Inspect the status and time association. Clock sources are identified by their stratum levels. The following example shows a stratum level five clock.
The following command identifies how often the NAS is polling and updating to the stratum clock. An asterisk (*) next to the NTP server's IP address indicates successful synchronization with the stratum clock.
For additional information, refer to Performing Basic System Management at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_c/fcprt3/fcgenral.htm
To increase traffic volume, subscriber bases, or revenue generation, partnerships can be made between both TDM-based and IP-based telephony carriers. By interconnecting with other VoIP carriers, not only can more attractive service offerings be provided, but coverage can also be increased with a minimum investment in capital and operations.
For TDM interconnections, Cisco supports a variety of interfaces and signaling variants to provide global connectivity. For solutions not requiring SS7 signaling, see "Provisioning Non-SS7-Based POPs." For solutions that require SS7 signaling, see "Provisioning SS7-Based POPs."
For IP interconnections, Cisco provides high-performance call routing through standards-based methods (such as OSP and H.323v2 LRQ), while flexibly accommodating networks that are not standards-based.
The wholesale service provider has the freedom to support any combination of interconnection methods simultaneously, so as not to limit business opportunities to a particular protocol. This is not the case with closed, proprietary systems.
This section discusses the following enhancements to interconnection:
Where multiple partners are involved and AAA/RADIUS is not used, prepaid and postpaid card services may require the assistance of clearinghouse services for billing, settlement, and invoicing. These services can be based on Open Settlements Protocol (OSP). The use of OSP for secure settlement transactions involves a clearinghouse entity, or at least a dominant carrier in the interconnect relationship that administers the OSP server. The clearinghouse maintains the OSP servers.
|
Note Where services are OSP based, the Cisco Wholesale Voice Solution supports call termination agreements through support for OSP in Cisco devices. For a high-level discussion of OSP, refer to Appendix A in the Cisco Wholesale Voice Solution Overview. For a detailed discussion of dial plans, billing/settlement, and security as these relate to OSP, see Template A3: TDM-to-IP-Based Interconnect with OSP in the Cisco Wholesale Voice Solution Overview. |
In an OSP-based interconnect, all edge GWs must be registered with the OSP server, and rotary dial-peer failover must be provisioned to route calls through the OSP interconnect. To provide OSP-based call routing, the OSP servers hold the prefix call routing tables of all SPs that subscribe to the clearinghouse. The originating GW sends an ARQ (Authorization Request) to an OSP server, which responds with an ARP (Authorization Permit) that contains a list of possible IP addresses of the terminating GW, plus a security token. The token is included in the SETUP message, to provide security validation at the terminating GW. The SP would use the OSP method of call routing when carriers want a third party to provide the billing and settlement. Figure 2-17 illustrates an example call flow for RAS failover to an OSP server.
|
Note For information on configuring an OSP server in the network, see Provisioning OSP Servers to the Gateway, page 3-12. |
As an added enhancement to simple carrier interconnect applications, the Cisco Wholesale Voice Solution has a limited ability to route a call to different destination carriers. This allows one service provider's DGK to send sequential LRQs (Location Requests) to other SPs' DGKs to route a call properly. The wholesaler has the same considerations as with simple carrier interconnect models, but with slightly increased call routing responsibilities.
The DGK can make limited egress carrier sensitive routing (CSR) decisions using the sequential LRQ feature. All simple, interconnect applications using DGK routing can apply this. For the most part, this consists of any TDM partners and DGK peering partners, but also includes any OSP partners where an OSP interconnection zone is used (as opposed to direct implementation on the wholesaler's GWs).
For example, the wholesaler may provision their DGKs to route certain destination-patterns to carrier A first. If carrier A is unavailable [as determined by an LRJ (Location Reject) or LRQ timeout], the wholesaler may try carrier B, then C, and so on. Figure 2-18 illustrates this application, sequential LRQ forwarding in support of limited egress CSR.
Sequential LRQ places the following restrictions on egress CSR:
The gatekeeper routes calls by means of DNIS. The wholesaler statically configures a list of possible egress carriers for destinations and they are tried in order. Routing decisions are not based on which carrier sourced the call. For example, if carrier A sourced the call, it does not determine that carrier A is the first carrier selected for termination.
Each destination carrier must be contained within its own zone. For ITSP carriers interconnecting through a DGK, this is fairly simple. Interconnecting ITSPs are seen as single remote zones to which the wholesaler DGK sends LRQ messages. For interconnecting TDM carriers, this implies that the GWs capable of sending calls to the carrier are grouped into their own hopoff zone managed by a GK, and that multiple carriers are never supported on a single GW.
Sequential LRQ selection order is statically configured. There is no provision for percentage-based routing, maximum minute cutoffs, and so on. Egress carriers are always chosen from a statically configured list of routes. If the DGK determines that an OSP interconnection zone handles a route, it is possible that the OSP server returns a terminating GW on the basis of advanced routing logic if so provisioned. For example, the OSP server may dynamically select a least-cost, terminating carrier according to criteria such as time of day or best voice quality. These options depend on the OSP server.
If OSP interconnections are supported directly from the POP GWs, sequential LRQs on the DGK may still be used to select an egress carrier through TDM or DGK peering interconnects if calls originate from any of the wholesaler POPs. If RAS fails to offer any routes, the GW may reoriginate the call through an OSP server to find termination through an IP interconnect.
For calls entering the wholesaler network from an OSP server, all POP GWs register with the OSP server. The OSP server may be provisioned with terminating carrier information and advanced routing logic rules to return the desired egress carrier GW.
Figure 2-19 illustrates an example network for which we will demonstrate the configuration of limited CSR. The DGK in the zone NETMAN sends LRQs sequentially to the new SP's DGKs, until the DGK zone that can route the call is found. The GK in that zone then sends an LCF confirming the route to the NETMAN GK.
We have added three new service providers in New Zealand (country code, or international calling code = 64) to our original network (see Figure 2-7): ITSP-A, ITSP-B, and ITSP-C. Now look at the required configuration, which resides on the NETMAN DGK, 172.19.49.190.
We have already established the following in the provisioning we have done so far:
The following new three lines establish remote zones for our three new SPs:
We have already established the following country code prefixes (see Table 2-2):
Now we establish the new country code prefixes for the following DGKs, and add a zone remote statement that directs them to the NETMAN DGK:
The following introductory information is borrowed in part from the Cisco Wholesale Voice Solution Overview, which contains additional information related to various features of back-to-back GWs. Platforms considered for back-to-back configurations are the Cisco 3600 series, the Cisco AS5300, the AS5350, and the Cisco AS5400. The Cisco 3600 series is not used where SS7 signaling is required.
The back-to-back GW is a special component used for a variety of applications. GWs are deployed as a pair in a back-to-back TDM T1 CAS or E1 R2 trunk, single-stage dialing configuration. Depending on the application, back-to-back GWs may function as unidirectional or bidirectional call devices.
For example, in an IVR application, the back-to-back GW has a dedicated half that receives all calls while the other half is dedicated to originating calls. In contrast, for an OSP interconnect zone application, the back-to-back GW may process calls in both directions, although each GW is responsible for separate protocols. For unidirectional applications, to provide added clarity in discussing back-to-back GW pairs, we refer to the individual GWs in a pair as an ingress (inbound) VoIP GW and an egress (outbound) VoIP GW with respect to the call direction. For bidirectional applications, we generally refer to the GW by the protocol it supports.
Figure 2-20 illustrates the use of multiple back-to-back GWs within a wholesaler's network, to partition call billing among various ITSPs, an OSP clearinghouse, and a Clarent domain.
The GW pair allows wholesalers to insert themselves into the call-signaling path in IP-to-IP interconnect call topologies. This allows them to generate usage records by means of AAA, interconnect with Clarent-based and OSP-based environments, and front-end PC-to-phone applications for IP-based interconnect partners. In many ways, the back-to-back GW area functions just like a normal non-SS7 POP, with the implications discussed in the subsections that follow.
Back-to-back GWs simply need to be configured with similar TDM signaling types. However, Cisco recommends that you use ISDN PRI signaling. Although one DS0 is lost to signaling, the call setup time is faster with ISDN (generally less than 2 seconds) than it is for T1 CAS signaling (up to 4 or 5 seconds). Use T1 or PRI crossover cables to provide the physical connection between each router.
|
Note The GWs in each back-to-back pair are cabled directly to each other (through T1 connections) by means of an RJ-45-to-RJ-45 T1 crossover cable. |
A transit GW is a back-to-back GW that acts as a proxy between an OSP clearinghouse or Clarent GK and the H.323 GK VoIP network. Transit GWs are used to enable routing by the OSP or Clarent entities without disrupting the existing H.323 network. For example, in an OSP scenario, only OSP-based calls go through the back-to-back transit GW, eliminating the need for additional OSP overhead on other GWs. The same applies in principle in a Clarent scenario.
Voice quality suffers especially in the case of tandem compression. The use of back-to-back gateways adds both postdial delay and latency for all calls. There is even greater impact if more than one back-to-back GW zone is traversed. Fax relay may also suffer.
|
Caution Modem passthrough is highly unreliable, and as a result is not supported in scenarios that employ back-to-back GWs. |
The following example scenarios are discussed in this section:
|
Note The term back-to-back GW is used to refer to both GWs in the pair. This allows one to speak of multiple back-to-back GWs. |
We begin with a back-to-back GW in a fundamental IP-to-IP interconnect scenario, as illustrated in Figure 2-21.
On the ingress side of wholesaler B's network, wholesaler A terminates calls beginning with country code 61. On the egress side of wholesaler B's network, wholesaler C terminates calls beginning with 1408. (I and E in wholesaler B's network represent ingress and egress, respectively.)
1. Customer at 611011112222 calls 14085551111.
2. GWA is configured to forward all 1408* numbers to GWI (ingress side of back-to-back GW).
3. GWI terminates the call on the POTS side.
4. GWI reoriginates the call to GWE (egress side of the back-to-back GW).
5. GWE sends an ARQ to GKE, the GK supporting GWE, to identify the terminating GW, GWC.
The following configuration examples look at the configurations on GWI and GWE, as well as that on GWA, the originating GW.
|
Note Only those steps of interest to the back-to-back configuration are shown. |
Step 2 Configure the T1 controller for PRI. This is the controller that will be connected to the second GW of the pair, GWE.
Step 3 Configure the POTS dial peer to terminate 1408 calls. Because we want to preserve the entire ANI string, we use the command no digit-strip.
Step 4 Establish the router as a GW, an essential step.
Step 2 Configure the POTS dial peer for incoming calls from 61*. Again, because we do not want to send dial tone, we use the command direct-inward-dial.
|
Note The first GW in the pair is configured as the session target for all calls to 1408*. Using the explicit IP address simplifies the dial plan. |
Now we look at a back-to-back GW in an OSP transit zone, as illustrated in Figure 2-22. (See Transit Gateways.)
This scenario illustrates how two GWs in a back-to-back configuration can be used to create a transit zone to interconnect OSP-based networks. The ingress GW (GWI) is configured to register with the Cisco GK and acts as the demarcation point into the Cisco H.323 RAS network. The egress GW (GWE) is configured to register with the OSP server. The configuration of GWE is provided below. The configuration for GWI is not included, because it is configured as in Back-to-Back Gateway in an IP-to-IP Topology.
Billing CDRs for GWI are generated and reported to a RADIUS/AAA server (not shown). Billing for GWE is handled through usage indication messages sent directly to the OPS server.
1. Customer at 611011112222 calls 14085551111.
2. GWA is configured to forward all 1408* numbers to GWI (ingress side of back-to-back GW).
3. GWI terminates the call on the POTS side.
4. GWI reoriginates the call to GWE (egress side of the back-to-back GW).
5. GWE sends an OSP Authorization Request to the OSP server, to identify the terminating GW, GWC.
The following annotated configuration excerpt provides for GWE to register with the OSP server.
This is similar to our previous example, except that now a Clarent GK and associated Clarent Command Center replace the OSP server. See Figure 2-23.
This scenario describes how a back-to-back GW can be used to create a transit zone when interconnecting with Clarent-based networks. The ingress GW (GWI) is configured to register with the Cisco GK and acts as the demarcation point into the Cisco H.323 RAS network. The second B2B GW (GWE) is configured to register with the Clarent GK, which supports H.323 on one side and Clarent proprietary protocol on the other. The configuration of the egress GW, GWE, is provided below. The configuration for GWI is not included, because it is configured as in Back-to-Back Gateway in an IP-to-IP Topology.
GWE will look essentially like another GW to the Clarent Command Center, and CDRs will be generated through the same GK Routed Call Signaling (GKRCS) methods that Clarent supports.
1. Customer at 611011112222 calls 14085551111.
2. GWA is configured to forward all 1408* numbers to GWI (ingress side of back-to-back GW).
3. GWI terminates the call on the POTS side.
4. GWI reoriginates the call to GWE (egress side of the back-to-back GW).
5. GWE sends an ARQ to the Clarent GK, to identify the terminating GW, GWC.
The following annotated configuration excerpt provides for GWE to register with the Clarent GK.
Step 2 Use a translation rule such as the one below to translate the 1408 * to a national number type, which is the Clarent default.
Step 3 Configure the POTS dial peer for incoming calls from 61. Because we do not want send dial tone, we use the command direct-inward-dial.
Finally, we consider the case of multiple back-to-back GWs. Where traffic requirements are high, these provide more than one TDM interface worth of simultaneous calls. Figure 2-24 illustrates this topology. The basic issues to consider are the following:
1. Configure the ingress and egress GWs in the back-to-back pair as in Back-to-Back Gateway in an IP-to-IP Topology.
2. Use dial peers to groom the traffic you want assigned to each back-to-back GW.
This section discusses the following installation and provisioning topics:
|
TimeSaver Because it depends on many components, the Cisco Wholesale Voice Solution depends upon many documents. As noted in Related Documents, you can access these documents directly from the electronic version of this guide by clicking on the URL. The following sequence will help you navigate to where these documents reside on Cisco's public website, http://www.cisco.com/univercd/home/home.htm. |
Before proceeding, however, you may find it useful to size your network, as discussed in the section below.
Sizing your network, or determining the number of components of a certain type to serve a given architecture, is not an exact science. However, there are general guidelines that provide good first-order estimates. The following discussion will help you estimate approximate numbers for the following relationships:
POPs are locally defined entities that serve both common prefixes as well as distinct geographical serving areas. It is the responsibility of the service provider to determine the number and location of POPs that will partition the wholesale network to accommodate anticipated traffic.
Consider the following in designing the service provider POP:
The BHCA supported per platform depends on the following factors:
However, the majority of these factors are beyond the scope of the following discussion.
First consider the maximum number of BHCA a given POP must support during the busiest time of day. The general formula is as follows:
POP BHCA = Max POP CPS * 60 * 60
where POP BHCA is the peak traffic the entire POP must support, Max POP CPS is the maximum anticipated calls per second for the entire POP, and 60 * 60 is the number of seconds per minute times the number of minutes per hour. A good working number for Max POP CPS at peak calling periods is 5, which we use in our examples.
Next consider the BHCA per DS0. The general formula is as follows:
where DS0 BHCA is the maximum number of DS0s per hour supported, 60 is the number of minutes per hour, and HT is hold time.
Thus, for an HT of 3, we obtain a DS0 BHCA of 20.
Now we need to know the BHCA for a given GW, the GW BHCA. However, the maximum number of DS0s per GW depends not only on the GW but also on the signaling type. Table 2-3 presents sizing parameters for the four common signaling types, for a Cisco AS5300. That router supports a typical maximum call rate of 2 CPS, a maximum of 92 T1 DS0s, and a maximum of 120 E1 DS0s. Numbers in parentheses indicate both origination and termination.
| Parameter | T1 PRI | T1 CAS | E1 PRI | E1/R2 |
|---|---|---|---|---|
| 192 * 20 BHCA per DS0
2120 * 20 BHCA per DS0 (0.67 CPS) |
If we assume a Max POP CPS of 5 in our example POP, we obtain a POP BHCA of 18,000. Now we need to know the number of GWs we need to support this call rate. The general formula is as follows:
Number of GWs = (POP BHCA)/(GW BHCA)
So, if we take an E1 example, we have a GW BHCA of 2400, resulting in
Number of GWs = (POP BHCA)/2400)
= 7.5 GWs needed to support a BHCA of 18,000
(Fractional GWs are not practical.)
|
Note However, at this point you may wish to reassess your traffic requirements in favor of saving a GW if possible. |
Now we proceed to estimating the number of GKs needed to support our GWs. With a Cisco 7200 GK, call success rates of 99% have been seen with 1000 registered endpoints (GWs) at 60 CPS (that is, 60 transactions with the GK per second during peak calling periods). We must ensure that this rate is not exceeded given the number of GWs being served by the GK and the CPS those GWs can handle. In other words, we are looking for a maximum GK CPS (Max GK CPS) that is below 60.
|
Note For the Cisco 3660 as a GK, call success rates of 99% have been seen with 1000 endpoints at 40 CPS. |
The following calculations are for a single POP. Here we must consider the maximum CPS for a GW, which we will call Max GW CPS. This figure varies according to platform, but here we will again assume a Max GW CPS of 2 for the Cisco AS5300. Max GK CPS is a function of the number of GWs. The general formula is as follows:
Max GK CPS = Number of GWs * Max GW CPS
For a single POP with the 8 GWs we derived previously, this is
= 16 CPS maximum to support a BHCA of 18,000
If we have three symmetrical POPs with 8 GWs each to service an SP network, can we service them with a single GK? Three POPs places a load on the GK of 3 * 16 = 48 Max GK CPS—clearly within our recommended limit of 60 Max GK CPS. With asymmetrical POPs, simply count the total number of GWs you need to serve by a single GK, and ensure that you do not exceed 60.
|
Note Theoretically, you could therefore support up to 30 (2 * 30 = 60) Cisco AS5300 GWs with a single Cisco 7200 GK. |
Finally, we need to determine how many DGKs we will need to support our GKs. The key factor here is CPU load. The following rough guidelines have been established through testing:
|
Caution Cisco recommends that you adhere to a GK/DGK ratio of 6:1. Also take into account that typical DGK deployments handle less than 100% of new calls, and that GK/DGK ratios will increase. |
In a service provider network with three symmetrical POPs with 8 GWs each, we have a total of 3 GKs, clearly within the GK/DGK ratio of 6:1. However, the recommended 6:1 GK/DGK ratio is for 100% new calls. For a call load of 20% of that, we can have a 30:1 ratio of GKs to DGKs:
If your application does not require SS7 signaling, the GW provisioning discussed below is sufficient. If SS7 signaling is required, refer to "Provisioning SS7-Based POPs."
Refer to Table 2-4 for the following discussion.
| 1FG = feature group |
Follow the steps below to establish GWs and interfaces appropriate to your network.
|
Note For the latest information, always visit the website that supports your Cisco equipment. |
a. For Cisco 3620, 3640, and 3660 GWs, see Procedures for Cisco 3600 Series Gateways.
b. For Cisco AS5300 series GWs, see Procedures for Cisco AS5300 Gateways.
c. For Cisco AS5350 and Cisco AS5400 GWs, see Procedures for Cisco AS5350 and Cisco AS5400 Gateways.
Step 2 Determine the signaling types required for each interface you need to support. This will depend on your telephony service provider. Refer to the Signaling Types column in Table 2-4.
Step 3 Determine the types of interface cards required to support the required signaling. Refer to the Interface Modules column in Table 2-4.
Step 4 Install and provision the interface cards as needed, considering the following parameters:
a. For Cisco 3620, Cisco 3640, and Cisco 3660 GWs, see Procedures for Cisco 3600 Series Gateways.
b. For Cisco AS5300 series GWs, see Procedures for Cisco AS5300 Gateways.
c. For Cisco AS5400 GWs, see Procedures for Cisco AS5350 and Cisco AS5400 Gateways.
Step 5 When you are done you will have established the necessary access GWs. Now refer to the following:
a. To establish GKs, see Establishing Gatekeepers.
b. To establish DGKs, see Establishing Directory Gatekeepers.
Follow the steps below to access the necessary documentation:
1. Refer to the following: Cisco 3600 Series Routers at
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3600/index.htm
2. If you have not yet installed this equipment, begin with the following series of documents at the above URL:
Follow the steps below to access the necessary documentation:
1. Refer to the following: Cisco AS5300 at
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/index.htm
2. If you have not yet installed this equipment, begin with the following series of documents at the above URL:
Follow the steps below to access the necessary documentation:
1. Refer to the following: Cisco AS5400 at
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5400/index.htm
2. If you have not yet installed this equipment, begin with the following series of documents at the above URL:
The Cisco Wholesale Voice Solution uses Cisco 3640, Cisco 3660, and Cisco 7200 routers as GKs.
Your selection of Cisco hardware to function as GKs will depend on the traffic needs of your network.
See Procedures for Cisco 3600 Series Gateways.
Depending on which router you have selected (Cisco 7202, Cisco 7204, or Cisco 7206), follow the steps below to access the necessary documentation:
1. For the Cisco 7202, refer to the following:
http://www.cisco.com/univercd/cc/td/doc/product/core/7202/index.htm
2. If you have not yet installed this equipment, begin with the following document at the above URL:
Cisco 7202 Installation and Configuration Guide
1. For the Cisco 7204, refer to the following:
http://www.cisco.com/univercd/cc/td/doc/product/core/7204/index.htm
2. If you have not yet installed this equipment, begin with the following document at the above URL:
Cisco 7204 Installation and Configuration Guide
1. For the Cisco 7206, refer to the following:
http://www.cisco.com/univercd/cc/td/doc/product/core/7206/index.htm
2. If you have not yet installed this equipment, begin with the following document at the above URL:
Cisco 7206 Installation and Configuration Guide
DGKs are an optional, not mandatory, component of the Cisco Wholesale Voice Solution. However, they are required in large-scale H.323 VoIP networks. The Cisco Wholesale Voice Solution uses Cisco 3640, Cisco 3660, and Cisco 7200 routers as DGKs. The Cisco 3620 is not appropriate for this purpose.
Your selection of Cisco hardware to function as DGKs will depend on the traffic needs of your network.
See Procedures for Cisco 3600 Series Gateways.
See Procedures for Cisco 7200 Gatekeepers.
Posted: Tue Jan 21 02:45:48 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
