Designing & Managing IP Networks for Voice
BY SAM SHIFFMAN
When designing and managing IP networks for voice, the key design guide to keep in mind is that voice applications are not “patient.” Users of voice applications require instant availability. While many data networks may boast of 99 percent uptime, that generally excludes maintenance windows. Unavailability between 2 am and 5 am might be satisfactory for Web surfers, but it’s not ok if you’re supporting voice-based communications.
PointOne has been building its voice network since 1998, so we’ve had time and experience to learn what to do and more importantly what not to do. PointOne’s IP network natively covers more than 75 percent of the U.S. communications infrastructure (and 100 percent through partners) and represents one of the largest pure advanced IP communications networks in North America. It is currently processing more than a half billion communications sessions per month for the largest commercial carriers and service providers, who require the utmost in guaranteed service availability.
PointOne designed its network around an “any-to-any” concept, recognizing that as we opened our network up to the world in an IP peering manner, we would need to support a variety of protocols, including SIP, H.323, MGCP, and others. In recent years, SIP has gained a tremendous amount of momentum for application creation in IP networks, but we also recognized there was a large installed base of H.323-based applications that was not going to disappear overnight. It was obvious that we would need to interoperate between the two, and not be boxed into one world or the other.
Our network supports a range of voice, data, video and multimedia applications, such as IP peering, hosted IP telephony (HIP-t), direct Internet access, data and voice virtual private networks, termination, toll-free and local origination, conferencing, and voice mail. It also has to support a diverse mix of users, including other service providers, cable systems, wireless providers, Internet service providers, enterprises, multimedia companies, and residences.
When we first began building out our network, it was based on ATM. Although we always envisioned a pure IP network, at the time we started, most of the IP routers and switches were software-based and were not up to the task of pushing the amount of bits required to constantly transmit voice. The practical option was to run IP over ATM, which was the best switching technology available to bridge packetized voice traffic to the PSTN. But ATM built in many complexities. For example, when we were an ATM-based network, we had more than three times the people managing the network than we do today in an IP-based architecture.
Those days really do underscore the validity of a simple mantra — KISS (keep it simple stupid). We’ve learned to keep the network as simple as possible. Rather than trying to build in greater intelligence into the core, our philosophy is to put the higher order functions out on the edge of the network. This meant that we needed to do the policing for traffic on the feeder roads (edge of the network) and build the largest superhighway (core/backbone network) possible.
In the past three years, our focus has been on implementation of MPLS, the IETF’s effort to build a standardized technology for using label switching and for the implementation of label-switched paths over various packet based link-level technologies, such as Packet-over-SONET, Frame Relay, ATM, and LAN technologies. MPLS provides the means for a router to pass on its routing priorities to another such device, without the second router having to examine packets and headers; speeding up network traffic flow, and making it easier to manage.
MPLS works nicely for real time applications like voice because it speeds up fail-over routing, ensures that voice receives the bandwidth it requires, and facilitates implementation of QoS. MPLS has lot of similarities to SONET networks, in that it can reroute packets in quickly and efficiently. While standard IP has always embodied the concept of routing around problems, the time required could end up being measured in minutes and seconds, rather than fractions of seconds. That may be tolerable when you’re downloading a song or sending e-mail, but if it happens during the course of a voice conversations, it becomes intolerable.
PointOne completed its initial implementation of MPLS about two years ago, secure in the knowledge that the IETF was on the right course and that we could deploy hardware that could be upgraded via firmware to the evolving MPLS specifications.
Page 1 of 2 [Go to Page 2]