March 2002

BY TONY RYBCZYNSKI

Much has been written about IP telephony, a term, which is often interchanged with voice over IP, Internet telephony, and LAN telephony, and for good reason. The enterprise benefits of IP telephony � a term that retains the essence of the application (telephony) while being network agnostic � include: Easier moves and changes and lower operation costs; new applications such as collaboration tools for an increasingly distributed work force; better disaster recovery through distribution of networking and application intelligence; and lower-cost WAN connectivity through convergence.

The challenges of delivering the voice quality, features, and reliability expected by end users involves a host of decisions. Whether the solution is based on a standalone IP-PBX, an evolution of the installed PBX base, or an integrated small office solution, the IP network has to provide telephony-grade performance and reliability. 

CHALLENGES WITH IP
IP was originally designed as a robust networking technology, and is quite resilient to network failures through connectionless operation and dynamic routing. Intelligence built into the data application supports end-to-end protocols such as the Transmission Control Protocol (TCP), which ensures reliable transport across a failure-prone network with variable bandwidth and delay. 

The networking design principles that work very well for TCP/IP data applications are inadequate for IP telephony. IP telephony, and real-time applications in general, have latency constraints that preclude using mechanisms such as retransmissions to overcome packet loss. For example, spending seconds to find alternate routes around failures is acceptable for data, but totally disruptive to telephony. A key requirement for IP telephony is that there needs to be a high probability of call setup and of successfully call completion once it is established. The human at the end of the line, who will hang up if high-quality communication isn�t maintained, is the true arbiter of success. To meet these requirements, one-way packet delays and loss must be consistently kept below 100 ms and one percent, respectively, even under heavy load and network failures. 

QoS � PART OF THE ANSWER
There are two generic approaches to meeting IP telephony performance requirements. The first approach is to over-engineer the bandwidth in order to ensure that there is more than enough bandwidth available for all traffic, while making sure that latency requirements are met. In practical terms, over-engineering has been feasible only in campus networks. However, given the growth of traffic, over-engineering is a short-term patch. The second approach introduces IP quality of service (QoS) mechanisms such as those based on the IETF�s Differentiated Services (DiffServ) architecture, which allow voice traffic (and signaling) to be handled on a priority basis. But it doesn�t stop there.

Most enterprises would have little concern about running IP telephony over a state-of-the-art, QoS-enabled campus network. Enterprises, whose campus networks are still based on legacy LAN protocols (i.e., shared media Ethernet, token ring, ATM, and FDDI), have major challenges in introducing and managing QoS. In fact, it is not recommended to run IP telephony over contention-based shared media Ethernet LANs, because of the non-predictable behavior of these systems. While token ring, FDDI, and ATM support various QoS mechanisms, these have not been widely deployed and don�t map well into DiffServ. Enterprises need to proceed with caution in these mixed LAN environments, and consider upgrading to switched Ethernet campus networks. A state-of-the-art campus network consists of 10/100 Mbps desktops connected to workgroup Layer 3-aware Ethernet switches, which in turn are interconnected via fiber to campus 100 Gbps-plus, routing switches. Ethernet has become the clear Layer 2 network architecture of choice within the campus, exhibiting superior price/performance compared to legacy LAN technologies. To handle DiffServ, DiffServ bits in the IP header are mapped by the Layer 3-aware Ethernet switch to the IEEE802.1p QoS, carried in the Layer 2 Ethernet header.

The WAN is problematic when it comes to supporting telephony-grade performance due to the broad range of technologies used. These include leased line, frame relay, ATM, and IP-VPNs. The WAN edge router has the daunting task of leveraging QoS capabilities provided as part of the WAN service, while handling service-specific encapsulation, traffic management, and signaling capabilities. 

Leased lines could be 56 Kbps copper-based circuits running across the country or OC-12 622 Mbps connections running on the optical network. Even with DiffServ, 56 Kbps operation is not recommended because of latency variation introduced at this speed. At T1 or higher speeds, DiffServ should suffice if the circuits are properly engineered. 

Frame relay and ATM support virtual circuits, generally configured as a best-effort packet pipe with some maximum bit rate (called Committed Information Rate in frame relay and Peak Cell Rate in ATM). Both these technologies support QoS (frame relay�s being primitive, compared to ATM�s comprehensive capabilities) on a virtual circuit basis, requiring that parallel virtual circuits be configured between every pair of end points. Running IP telephony over these Layer 2 networks is feasible with careful engineering and design, though operational complexity is an issue on an on-going basis.

IP VPNs support IPSec tunneling over the general Internet or over a specific carrier�s business grade IP service. In both cases, QoS is likely not supported, though in the latter case, maximum packet loss (e.g., three percent) and delay (e.g., 100 ms) may be specified on a statistical basis. This limits the appeal of relying on IP VPNs for site-to-site IP telephony. However, given that the largest market for IP VPNs is for remote user access, and given the widespread penetration of broadband cable modem and xDSL access, there are some interesting applications for IP telephony in spite of the lack of QoS, particularly through the use of fully-featured business sets and softclients as an extension of the office environment. 

NETWORK RELIABILITY
IP network reliability occurs during network failure conditions or during the interval during which routers are learning about the availability of new routes. These convergence times may be substantial. For example, if routing protocols such as Open Shortest Path First (OSPF) are used, the convergence times may be proportional to the square of the number of routers in the network, and can last minutes in large networks. 

Ethernet switching in campus networks is based on the Spanning Tree Protocol, which itself has very long convergence times, which is neither acceptable for data nor voice applications. State-of-the-art campus networks solve this problem by combining switching with a Layer 2 technology called MultiLink Trunking (MLT), which is compliant with IEEE802.3ae. MLT combines multiple (typically GigE) links into an MLT group with traffic load balanced across the group. Sub-second recovery from failures of a particular link is provided by switching traffic to the remaining working links of the MLT group. An MLT group operates between two Ethernet switches or between an Ethernet switch and a campus backbone routing switch. It is possible to take this one step further through a so-called split-MLT, which allows a single Ethernet switch to home in on two routing switches for an added level of reliability. Sub-second recovery from failures introduces a short burst of noise or dead time on a voice call, this being acceptable for IP telephony, given that these failures are relatively rare.

Achieving adequate levels of reliability in the more hostile WAN is somewhat problematic. IP dynamic routing capabilities are invoked for all connectivity failures in leased line, frame relay, ATM, and IP VPN offerings, making these disruptive to IP telephony communications. The implications are dropped calls and an inability to re-establish the connection for as long as it takes for the routing system to converge. This is universally unacceptable for customer or external communications. 

OPTICAL ETHERNET � A BETTER WAY
The notion of extending the campus environment across the MAN and the WAN is very appealing to support both data and IP telephony applications. This is what Optical Ethernet is all about. Optical Ethernet combines the reliability and scalability of optics with the utility and price/performance of Ethernet. It builds on the massive deployment of optical networks in the campus, MAN, and WAN. Today, over 100,000 business sites are connected optically, and half of the remaining are within a few hundred meters of fiber. Service providers are rolling out Virtual Private Ethernet networks with one national carrier offering services in and between 63 metropolitan areas. 

Three major technology and standards developments are enabling Optical Ethernet networking on a private or managed service basis, namely: 10 Gbps Ethernet, which not only increases the speed of Ethernet to the next plateau but also is specified to run over WANs (a first for Ethernet!); resilient packet rings under IEEE802.17, which creates a new media access control (MAC) Layer, which leverages optical ring technology to deliver 50 ms recovery from failures; and coarse and dense wave division multiplexing technologies, which support massive scalability, particularly for Ethernet and storage applications, and likewise delivering 50 ms recovery from failures. 

What all this means to the enterprise is that Optical Ethernet is a simple, fast, and reliable networking infrastructure that can meet the requirements of IP telephony, and mission-critical and future e-business applications. 

Tony Rybczynski is director of strategic marketing and technologies for Nortel Networks� Enterprise Solutions with 30 years experience in networking. For more information, visit the company�s Web site at www.nortelnetworks.com. E-mail questions or comments to [email protected].

[ Return To The March 2002 Table Of Contents ]