|
|
You have been introduced to the many variables that determine how to configure and implement a Cisco Wholesale Voice Solution. This chapter shows you how to determine the appropriate solution for a given set of circumstances.
This chapter presents the following major topics:
Begin by asking the right questions and identifying key issues. Figure 4-1 illustrates the decision blocks necessary to determine a particular Cisco Wholesale Voice Solution.
These steps are discussed below.
Step 2 Determine the type of carriers/providers to interconnect with.
(See Call Topologies and SP Interconnection Methods.)
Step 3 Determine the interconnection types.
(See Call Topologies and SP Interconnection Methods, and Design Issues and Choices.)
Step 4 Determine the call topologies used.
(See Call Topologies and SP Interconnection Methods.)
Step 5 Find the appropriate deployment template.
(See Deployment Templates, and Design Issues and Choices.)
 |
Note OSP or DGK peering may be required. Refer to IP Interconnect Variations 4-3, for more information. |
Step 6 Identify the functional components required.
(See Functional Areas, and Design Issues and Choices.)
Step 7 Identify the required hardware/software components.
(See "Solution Components.")
Step 8 Identify design and scalability considerations.
(See to Design Issues and Choices.)
Step 9 Configure and provision components.
(Refer to the Cisco Wholesale Voice Solution Design and Implementation Guide.)
This section discusses in detail a variety of issues choices that will vary with each application.
Because of the many ways in which multifunctional groups can interact, a variety of issues deserve discussion in greater detail. Among these are the following:
In addition to the four fundamental topologies discussed in Call Topologies and SP Interconnection Methods, wholesalers can interconnect with other IP-based service providers (ITSPs and ASPs) in one of two ways:
Each method has its own provisioning requirements.
In this method, the wholesaler provisions call routing between its IP interconnect partners by peering DGKs to which it sends LRQ RAS messages. The wholesaler may direct certain destination patterns to specific interconnect partners. These destination patterns could have potentially been modified upon ingress into the wholesaler network to provide limited ingress CSR applications. Additionally, the wholesaler may also use sequential LRQ features to provide limited egress CSR applications.
With DGK-based interconnect, the wholesaler benefits from centralizing route provisioning in the DGK, rather than pushing it to the edge GWs as with OSP. However, billing/settlement functions and security options are processes external to call routing that require some configuration in the GWs, GKs, and related shared-services components.
For a large service provider with many POP GWs, provisioning complexities may decide that this is the more attractive option for interconnect. Figure 4-2 illustrates a DGK-based interconnect with other ITSP/ASP partners.
In this method, an OSP server performs call routing, billing/settlement, and security functions. However, OSP-based interconnect requires additional provisioning. 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.
OSP may be an attractive interconnect option for a wholesaler who wants to combine call routing, security, and billing/settlement into one architecture. However, in current Cisco implementations, limitations with OSP deployments require extensive provisioning in the GWs, so that they can interact with the required shared services, support the dial plan architecture, and cover termination caveats.
Figure 4-3 illustrates OSP-based interconnect with other ITSP/ASP service partners.
Originating and terminating providers may connect to the wholesaler through either TDM or IP. The call routing and billing/settlement functions determine whether the wholesaler will be DGK or OSP based.
Wholesale providers have the option to interconnect routes with other service providers using a DGK. In this model, the wholesaler and the interconnect partner configure the DGKs to exchange LRQ RAS messages between their administrative domains, in order to resolve call routing for desired prefixes.
The DGK maintains an overall routing table of destination patterns and the corresponding local GKs that support them. The DGK simply forwards LRQ requests to the local GK that handles that destination pattern.
This use of GKs and DGKs allows the addition of new GK zones, POPs, and certain types of IP interconnect partners with minimal impact on dial plan provisioning. Changes are isolated to the local GK and the DGK. The rest of the elements in the network are untouched. Often, the level of dial plan resolution at the DGK can be simplified. For example, a DGK may know to route all calls beginning with a country code of 1 to the local U.S. GK. The local US GK can then expand selection to more digits (such as NPA or NPA-NXX) to route the call to the proper terminating gateway.
There are two design choices for call routing between IP service providers:
DGK-based call routing uses LRQ (Location Requests) to request the terminating GW IP addresses. An LRQ is sent from the originating SP's DGK to the terminating service provider's DGK. SPs would use the DGK method of call routing where the originating and terminating service providers are trusted peers.
OSP-based call routing uses a separate entity called an OSP clearinghouse, which maintains OSP servers. These OSP servers contain the prefix call routing tables of all SPs that subscribe to the clearinghouse. The originating GW, in this case, sends an ARQ (Authorization Request, an OSP message) to the OSP server, and the OSP server responds with an ARP (Authorization Response) containing a list of possible IP addresses of the terminating GW plus a security token. This 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.
To account for service properly, the wholesaler must accurately identify the originating carrier and terminating carrier for calls. The degree of difficulty for this varies depending upon the call topology used. Furthermore, the usage indicators must be extracted from a reliable source. This implies that the devices supplying call usage indicators are somewhere within the H.225 call-signaling path. In the Cisco Wholesale Voice Solution, if billing is desired, this means the wholesaler must own at least one GW in any given conversation.
There are two design options for billing and settlement:
These options may be used either individually or in conjunction with each other and will directly depend upon the method of interconnect. Though differing in protocol, each method addresses the same basic needs for call accounting.
The wholesaler implements AAA billing for any intradomain traffic because OSP is designed to bill for interdomain calls only. AAA may be also be used for interdomain calls if interconnect is not handled by an OSP server, but rather by a peering DGK relationship. In this model, the billing application correlates the usage records to generate CDRs. The wholesaler then distributes these CDRs to customers in the form of a periodic bill. Customers can verify this bill against their own records before ultimately exchanging money and settling the bill. There are various mediation vendors that help automate the verification and settlement stages, but the Cisco Wholesale Voice Solution does not specify any. Details regarding from which GWs AAA accounting records are collected and how they are correlated are addressed in the specific deployment templates presented in the chapters that follow.
For interconnects using OSP, the wholesaler may either own an OSP server or depend upon a third-party OSP clearinghouse server to provide accounting services. The OSP server receives accounting information from the wholesaler GW much as in the AAA RADIUS case. Since the OSP server receives usage indicators from both GWs across administrative domains, the OSP server gets accurate terminating and originating carrier information. The OSP server may then correlate the usage records to generate CDRs. These CDRs may be distributed as periodic bills to customers. Customers can verify their bills against their own records before ultimately exchanging money or settling the call. To provide personal accounting records for verification, the wholesaler may use parallel AAA accounting records.
In the case of an OSP clearinghouse, the clearinghouse may also provide a single interface for settlement between multiple providers, but at an added cost. Details regarding OSP billing mechanisms are provided in the specific deployment templates discussed in the chapters that follow.
It is a possibility that a third party and not the wholesaler manages an interconnecting TDM POP. In this case, the wholesaler cannot depend upon GWs to send them CDR info. A wholesaler may therefore choose to do billing from either only the terminating GWs (if the wholesaler owns them) or only from the GK.
Billing from the GK has limitations. Cisco GKs can send call start/stop records to an AAA RADIUS server based upon receipt of ARQ and DRQ RAS messages from GWs. However, RAS messages are sent over UDP and not guaranteed to arrive at the GK. Furthermore, this method of billing lacks answer supervision. Therefore, billing is most reliable and accurate if performed at the gateway. The Cisco Wholesale Voice Solution recommends that GW-based billing be done whenever possible.
Within the wholesaler network, dial plan responsibilities are distributed among GWs, GKs, and DGKs. Because deployments of Cisco SS7 Interconnect for Voice Gateways leverage NI-2 type Q.931 backhaul signaling, the basic H.323 dial plan architecture is the same regardless of whether the POPs in the network are SS7 based, non-SS7 based, or a mixture of both. Figure 4-4 depicts a typical large-scale H.323 network design (the same figure as seen in Figure 2-2).
GWs deal with the local POP portion of the dial plan. This encompasses any digit manipulation needed to normalize numbers or implement local PSTN access rules. It also includes notifying a GK when resource availability indicator (RAI) thresholds are crossed in order to increase call completion rates. Furthermore, the GW may implement rotary dial peers to handle call-failover routing options, such as trying OSP if normal GK RAS call routing offers no possible termination.
For example, the provider may want the GW to notify the GK when its resource limits are nearly exhausted, thereby prompting the GK to select a different GW. Additionally, the provider may want to normalize numbers into a standard format before sending calls into the VoIP network (such as country code + area code + local number) to simplify route provisioning in the GKs and DGKs. Likewise, the provider may need to prefix/strip digits, as PSTN access rules require (such as prefixing any needed area or access codes), before sending calls out the TDM interfaces.
Local GKs monitor gateway health levels and maintain detailed routing tables, mapping destination patterns to specific terminating GWs within local zones. The local GKs can use features such as lightweight registration, RAI, and static gateway-priority assignments to influence gateway selection. For all other nonlocally supported destination patterns, the local GK configures a wild-card route to the DGK.
The DGK maintains an overall routing table of destination patterns and the corresponding local GKs that support them. The DGK simply forwards LRQ requests to the local GK that handles that destination pattern.
This use of GKs and DGKs allows the addition of new GK zones, POPs, and certain types of IP interconnect partners with minimal impact on dial plan provisioning. Changes are isolated to the local GK and the DGK. The rest of the elements in the network are untouched. Often, the level of dial plan resolution at the DGK level can be simplified. For example, a DGK may know to route all calls beginning with a country code of 1 to the local US GK. The local US GK can then expand selection to more digits (such as NPA or NPA-NXX) to route the call to the proper terminating GW.
For intradomain calls and DGK-based IP interconnects, a wholesaler has the option of overlaying fault tolerance on to the basic H.323 VoIP network dial plan design. This is done by using a combination of Cisco IOS software features such as alternate GKs on the GW, HSRP on the DGK, and sequential LRQs on the GKs and DGKs. Figure 4-5 illustrates a fault-tolerant architecture using alternate GKs.
GWs may be configured to register to a primary GK and an alternate GK in the event that 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).
A wholesaler may choose to implement various security methods over its H.323 VoIP network. The selected security mechanism has different provisioning needs within multiple functional areas. For intradomain calls, the wholesaler may use complex access lists.
GWs in the wholesaler network may be provisioned with complex access lists to accept calls from only known entities. This is obviously neither scalable nor friendly to network changes or elements that use DHCP (Dynamic Host Configuration Protocol). For interdomain calls, the wholesaler may choose to implement either complex access-lists or H.235 OSP access tokens, depending upon the interconnect method used (DGK vs. OSP).
|
Note The Cisco Wholesale Voice Solution supports Cisco H.235 security for registration only. For reasons of AAA latency, H.235 security is not supported on a per-call basis. When per-call security is required, Cisco recommends that you use access lists. |
The Cisco Wholesale Voice Solution supports different NMS components, each addressing a certain task, and that can be assembled to provide network management. The tasks, along with the components that address them, are considered below.
This deals with installing, provisioning, and tracking the provisioning of all components in the network.
This deals with real-time monitoring of network components, plus the ability to control them by bringing them up or down.
This is the ability to detect faults from individual components and correlate them into a coherent picture of an overall system problem.
The wholesaler or wholesaler's partners may want to generate reports related to system configuration, performance, and faults. In some cases, not all aspects of a component can be managed with available products. It may be necessary to manage devices through the CLI, or by using SNMP systems to manipulate the MIB directly.
This following two chapters provide a detailed discussion of issues that must be considered for the services of the Cisco Wholesale Voice Solution:
The following issues are presented as they apply to those services:
Posted: Wed Jan 22 15:18:10 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
