Over the years, there have been many competing models for network architecture. What seems like eons ago, many enterprise networks were source-route bridged, where vast networks of bridged token rings were meshed together, and the hosts were responsible for making routing decisions. These rings often had multiple bridges interconnecting them, providing many alternate paths through the network.
As time progressed and the much cheaper Ethernet appeared on the scene, the routed architecture prevailed. Because these networks still had a large amount of legacy protocols, such as NetBIOS, IPX and Appletalk, the subnets tended to be small. As these protocols were phased out, along with their broadcast-dominated traffic patterns, network designers gradually joined what has been called the Flat Earth Society movement. Cheap Ethernet and expensive and complex routers further compelled network designers to replace the small subnets, typically 254 hosts or less, with much larger ones supporting 1000, 2000 or more hosts in a mixed bridged and routed configuration.
This movement halted abruptly with the sudden availability of cheap Layer 3 switches. These switches allow engineers to manage a large number of small subnets efficiently. The small subnets are advantageous to voice over IP because the hosts process fewer broadcasts and each port buffer on the router sees less traffic.
The central debate today is about the enterprise backbone that ties all these Layer 3 switched LANs together. Greatly simplified, the first competing model is a hierarchical model, much like a tree, that facilitates scalability by allowing a very large number of ports to be aggregated together and managed in successive layers. This often results, however, in a less-than-optimal number of switch or router hops from source to destination in a network. Thus, we have a second model that is much flatter, requiring fewer hops and yielding lower latency, but it requires that that the backbone devices have more physical and logical interconnections and the routing and forwarding decisions can be more complicated.
To a large extent, what your company can do is limited by your geography and other factors. For instance, with the trend toward tighter security, departments inside some enterprises are deploying their own firewalls, which dramatically affects how the traffic enters and leaves the backbone. Of course, the size of your network and how important real-time traffic is to you will also affect the design. Whatever your circumstance, keep the following in mind when thinking about engineering your backbone for voice over IP services:
- Make redundant paths similar
If you're doing equal-cost load balancing, try to make the different paths onto the backbone as alike as possible. If one path takes more hops than another through the backbone, or the transmission distance is substantially longer, then some of your voice calls will have higher delay than others, and this will lead to users reporting poor quality that will be unpredictable and difficult to troubleshoot.
- Signaling vs. data paths
Remember that some of your call signaling may go to one location (e.g. a central SIP proxy server) while the actual RTP voice traffic may go a different direction (e.g. an IP phone in a branch office). This distributed traffic profile is becoming more common and, depending on your other data patterns (for example, if each branch has its own Internet connection or if a central one is shared), may lead you towards a classic "mesh" backbone and away from the "hub and spoke." Meshes are more complex and more expensive but offer lower latency.
- Reducing hops
Look for ways to take hops out of the network. In some models, such as the popular "core-distribution-access" model, engineers may have a propensity to add devices so that separate devices handle the unique functions associated with their respective layers. While this is simple and very scalable, it adds unnecessary delay. Most of the newer equipment deployed today is more than capable of supporting a "collapsed" architecture that combines multiple layers into a single physical device.
- Understand the failure modes
Assuming your backbone has redundant paths, you want to understand how the routing protocols make their decisions and how long it takes them to converge. What path will voice over IP take in a failure? What path will your other traffic take? If you're doing policy routing, how will that be affected? What effect will this have on quality of service mechanisms such as RSVP? When service is restored, will traffic be automatically redirected?
Consider a hypothetical situation where you have redundant trunks and limit the number of calls on each to 100. If you have 60 calls on one trunk and 70 calls on the second and a failover occurs, will your call admission control (CAC) allow 130 calls on the remaining trunk in a degraded state? Or will it drop 30?
About the author:
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
More info links:
Read all of Tom Lancaster's VoIP Tips.
Visit our extensive collection of Best Web Links on Voice/data Convergence.
