Section 13.4. WAN Design

13.4. WAN Design

The layout of your WAN has huge implications for VoIP, particularly when it comes to failover ability, disaster preparedness, and latency. The high-level topology modeldistributed or client/serverwill affect where you place gateways, registrars, and PSTN connect points. Meanwhile, your network's topographic layouthub and spoke, meshed, or peeredwill affect how well your network survives local outages and how latency impacts your telephony apps.

13.4.1. Distributed Versus Client/Server

As in network computing, there are two essential models for voice applications: distributed and client/server. In the distributed model, processing resources are on smart endpoints and servers are spread out over the network, which acts as an unintelligent transport between them. In distributed computing, each client agent has a substantial processing role in the application, and the server may or may not. IP phones working with a softPBX to connect users over an Ethernet network is a decidedly distributed idea.

Client-server (also called server-based ) computing is a more consolidated, centralized approach to information processing. In client-server models, the endpoints have very little processing capability and serve a narrow role in the neighborhood of the OSI presentation layer. Meanwhile, processing- intensive tasks and network transport are managed by a central server that works on behalf of all the dumb endpoints. Mainframes that use serial terminals to display and collect datasay, in a POS (point-of-sale) environmentare a good example of client-server computing. So are TDM phones connected to a legacy PBX.

Just as in client-server computing, TDM endpoints are often referred to as terminals .

Consider the difference between a SIP phone and TDM phone. A SIP phone is somewhat functional apart from the softPBX, since it has both a user agent (UA) and server agent (SA), but the TDM phone can't be used at all on its own. In client-server models, the endpoints or clients are slaved to the server. On the other hand, SIP phones, which have memory and onboard programming, are smart enough to be configured to work with other SIP-compatible PBX systems. This difference will affect the placement of telephony resources within your network: SIP phones can work in a distributed fashion, while TDM and analog phones cannot. SIP phones all around the Internet could use your PBX server back at HQ, but TDM phones have no such luxury.

Both models are important in IP telephony. Even though "native" VoIP (i.e., no TDM or analog connections) uses a distributed model, client-server objects may still need to be integrated into your VoIP network. TDM phones may be necessary in offices where adequate cabling isn't possible to support IP phones or where IP phones are not cost-justified. With the right interface hardware, VoIP can be used to trunk between these legacy resources on the WAN.

It's also possible to force certain IP phones to become completely dependent upon server resources in order to boot and be usable. This makes them more like TDM phones, taking on a client-server guise. Most IP phones can be configured to obtain their VoIP configuration from a TFTP server. This allows a group of IP phones to be maintained centrally . All of their configuration files can be stored on a single server, just as a TDM phone receives its configuration from a central PBX.

The Cisco 7960's SIP firmware can be configured to retrieve the phone VoIP configuration from a TFTP server. After unlocking the configuration options, enter the IP address of the TFTP server in option 7 on the Networking Options menu. Or, better yet, have your DHCP server assign the TFTP server address.

13.4.2. WAN Layout

13.4.2.1 Hub and spoke

If your WAN is a hub and spoke layout, you most likely have a single (or a few), centralized data center where all of your business locations' connections with the rest of the network are made. Hub and spoke networks, like the one at the lower left in Figure 13-2, allow for easy central network administration and often have lower facilities costs than other layouts. In hub and spoke networks, all remote locations connect directly to the data center without any intermediate hops.

Figure 13-2. WAN layouts, clockwise from top left: partially meshed, circular peered, linear peered, hub and spoke

The benefit of hub and spoke layouts to VoIP is that they minimize latency because there's only one hop between the remote office and the data center (where the softPBX and primary switching equipment are). Other layouts may contribute more to latency than hub and spoke does. If there's a drawback to the hub and spoke approach, it's that there's a single point of failure on the WANthe data center.

13.4.2.2 Peered

Sites in a peered network form a chain along which data travels . The data hops from one site to the next until it reaches its intended destination. The sites furthest from the destination use the ones that are closer to the destination as their " next hops" along the path , getting the data closer to its destination as it travels through each consecutive site.

The benefit of this technique is cost reduction. Peering keeps point-to-point connectivity costs down by decreasing the mileage of each link. In a hub and spoke layout, you might use six remote site links with an average length of 300 miles apiece. But, if the distances between each site and its closest peer are all lower than the distance to the data center, a peered layout can drastically lower that average distance and the associated cost. This is because each site is connecting to nearby peers, which are much closer than the HQ, which is further away. In a peered layout, only one peer needs to be connected to the HQ.

But there is a big drawback to this layout. Peered networks (like the lower-right example in Figure 13-2) are prone to cascading failure patterns. When an office that supplies a route to the HQ for other offices experiences an outage , so do the offices that rely upon that route. An ingenious way to eliminate this problem, if the geography is suitable, is to make a circular peer layout, like the upper-right example in Figure 13-2. When dynamic routing is employed, circular peer layouts are very resilient to isolated failures.

Exclusively peered layouts impose a higher number of router hops on call paths that traverse the WAN than a hub and spoke or meshed layout would. This might be OK for data applications, which aren't as sensitive to delays, but for VoIP, excessively peered networks can be showstoppers. If you had a 10-hop chain of peers with T1s between them, you could easily have 50 ms of latency from end to end, not accounting for higher-layer sources of latency. Making a high-quality VoIP phone call in this scenario just wouldn't be possible.

13.4.2.3 Meshed

In meshed networks, remote sites may be connected to one another, like a peered network, and connected to the data center, like a hub and spoke network. Or a single remote site might connect with two or more other remotes. This provides diversity for the transport to the data center and reduces the risk of widespread outage.

Depending on how meshed the network is (how much redundancy it offers), the threat of network downtime can be nearly eliminated. The Internet is a highly meshed network in the sense that many of its backbone carriers connect to multiple other backbone carriers .

In VoIP, a meshed network provides the greatest protection against unwanted system downtime. Meshed layouts, however, are the most expensive and aren't always practical. They might be needed in very demanding scenarios, such as a call center with offices in multiple states or highly redundant military or intelligence applications.

Quality-of-service measures must be more sophisticated when used in a highly-meshed network. Indeed, one thing RSVP is designed to do is negotiate the best-quality path through the network for a phone call when there are multiple potential paths. This is quite different from dynamic routing alone, which chooses paths across the network based on policies that have no direct relationship with the voice application.

13.4.3. Layout and PBX Placement

Most networks employ a combination of distributed and client-server models for different applications and a combination of different layout techniques for different balances of cost and resilience to failure. As long as the total number of remote locations is under 10 or so, a circular peer network is a great solution to the downtime issue, because if an upstream route fails, the other arc of the circle is still up and also leads back to the data center. This functionality is handled byyou guessed itIP routing. So it takes two points of failure on the circle in order to bring the voice transport down for any one site, as illustrated in Figure 13-3. If a particular arc on the circle can't handle the traffic being thrown at it by the voice application, then it's a matter of adding a mesh link between that arc and the DC.

Figure 13-3. Even though a failure has occurred on one of the WAN links, all the remotes on this circular peer network can still reach the data center

The old saying from the real estate business, "location, location, location" is also true in IP telephony. Indeed, your choice of WAN layouts and computing models is always tied to the locations of your application servers and user groups. Since you can't move your users around to meet the needs of your network design, you must strategically locate VoIP resources (like PBXs and PSTN gateways) to meet their needs.

13.4.3.1 Locate to conserve network availability

It would seem that it's ideal to take the existing WAN and just pick the best locations within it for all of these elementsbut that's not always the right approach. The WAN footprint may need to change shape to optimally support the VoIP network you're about to overlay upon it.

For example, the places where large amounts of traditional network traffic (say, database traffic) are transported may not always be the places where huge amounts of phone calls travel. Look at Figure 13-3. If a majority of voice traffic travels between the remote sites at the top of the diagram, it might make sense to put a PBX thererather than in the existing data center at the bottom of the diagram. The last thing you want to do is decrease network availability to existing apps in order to add voice. This is exactly what you'd be doing if you unnecessarily overlaid a voice pathway onto an already-busy data pathway .

13.4.3.2 Locate to save money

There may also be geoeconomic reasons to place a telephony resource at an otherwise unlikely location. Consider international call centers. Lately, it's become very fashionable for insurance, mortgage, and collection companies to house big groups of low-cost outbound telephone operators in countries such as India and Mexico. These English-speaking employees call American households on behalf of American companies.

It would be very expensive for all of these calls to traverse the international LD network from India to the U.S. Instead, these companies may use VoIP to trunk calls over a comparatively low-cost international WAN to a PSTN connect point in the United States. Calls that originate inside the U.S. PSTN are much cheaper when destined for U.S. destinations. So, depending on your line of business and the needs of your particular application, locating a PSTN connect point a great distance from your call center, or perhaps a great distance from your PBX, might be a good idea.

13.4.3.3 Locate for capabilities

The location of telephony equipment is often dictated by the equipment's purpose and interfacing capabilities. For example, PBX servers with built-in PSTN interfaces may need to be in the same building as the PSTN connect point. But a PBX server with an outboard PRI chassis could be located several hops away, and perhaps miles away, from the connect point. The PRI chassis would need to be near the connect point, but, WAN bandwidth notwithstanding, the PBX server itself could be anywhere on the private network.

Voice-mail servers, like Cisco's Windows-based Unity, may need to communicate with an email server if you're going to use integrated messaging. In this event, very high amounts of bandwidth between the Unity server and the email server will likely be required. It's quite common for voice mail and email servers to be installed in the same rack or to be running on the same PC.

Since we're talking about layout, all of these issues must be taken into account when looking at how your VoIP network will overlay your IP network layout. Is there enough bandwidth to support the necessary loads between all endpoints? Would adding a new connection solve a capacity problem imposed by VoIP, or would it be better to place a PBX somewhere to solve the problem? Which solution would be more cost-effective ? Is your vision of Voice over IP even feasible given today's load on the network? If it's a peered network, would the outlook for VoIP be better with a hub and spoke layout or a few new mesh links? How would such a change affect other network systems?

13.4.3.4 Don't locate for convenience

The VoIP network ought to drive the IP network design. A PBX shouldn't be placed in a particular location because "that office already has a server rack and a UPS" or because "that's the office where the old phone system is." Ultimately, while these issues are an influence, they can't be deciding factors in locating VoIP resources. The VoIP network's design must not be retrofitted around the current network's preexisting topography . If this were a good way to approach IP telephony, then VoIP-over-Internet would long ago have replaced the PSTN. Clearly, the existing layout of the Internet isn't suitable to replace the PSTN (yet).

If it makes sense to have a PSTN connect point in another country with VoIP trunking back to your PBX, build your WAN to accommodate that. The bottom line is this: the IP network you have in place today probably won't be the IP network you'll have in place when migration to VoIP is complete.