September 2003

IP Telephony Lessons From The LAN Edge

BY TONY RYBCZYNSKI & MATTHEW MICHELS

IP Telephony is certainly a hot topic these days, and many enterprises are either deploying it, or are planning to in the near future. What end users want is relatively well understood: high-quality voice, always-on dial tone, and easy to use features. Technically, this translates into delays of less than 150 msec, short variable delays or jitter, and zero packet loss. Achieving this in a LAN environment should be simple, since there�s lots of bandwidth available, delays are small, and campus networks have been over-engineered for reliability. Would that reality was this simple!

Even in a LAN environment, we should implement end-to-end QoS in the form of 802.1p and DiffServ to ensure VoIP traffic gets preferred treatment even under failure conditions or when unplanned traffic patterns result in network congestion. Reliability designs that work for data may not work for voice, since there is no time either for long spanning tree or routing convergence times or to retransmit lost packets. The answer lies in high availability switching, and leveraging network techniques that bypass spanning tree operation and do not require routing changes in the event of failures. Fortunately, technologies such as highly resilient modular and stackable switching architectures and dual-homed multi-link operation are readily available to enterprises.

In our experience, designing the campus backbone for IP telephony is relatively straightforward given the small number of network elements involved (except in the largest of campus backbones). The area that requires the greatest attention is in the last 100 meters on three fronts: The need for full-duplex Ethernet switching right to the desktop, the need for standards-based power of Ethernet for IP telephony and WLANs.

Desktop Ethernet Switching -- Necessary But Not Sufficient
Ethernet historically has been a shared media architecture whereby multiple PCs on a LAN segment contend for the bandwidth. Collisions were resolved by having stations back off their transmissions in such a way as to avoid future collisions -- this worked for data but is a VoIP-killing impairment. The technology answer was and is Ethernet switching, which most IT organizations are deploying. Unfortunately, Ethernet switching too often is deployed behind the installed base of shared media hubs. It is absolutely essential that QoS-enabled Ethernet switching be implemented right to the desktop level, not only to ensure that voice performance requirements are met but also as a foundation for power over Ethernet to IP phones. Switched Ethernet is also the first step in securing IP telephony traffic by not allowing voice packets to be casually monitored by other PCs. The desktop can consist of a soft client in a PC, a single IP telephone or a combination interconnected by a three-port QoS-enabled Ethernet switch (often built into the phone).

There is a real world issue that needs to be understood in achieving VoIP quality over switched Ethernet. QoS mechanisms can only be effective over full duplex links, whereby there is a separate transmission medium in each direction. Obviously, even if VoIP is put at the head of the queue, waiting to get control over the link operating in half duplex is not acceptable. Ethernet switches support full duplex operation, but the rub is that negotiation between the two end points (the IP phone and the Ethernet switch) can result in half duplex operation.

In fact, the top VoIP-killing impairment in the LAN that we have found in the field has been the �duplex mismatch� -- one device running in full duplex mode while the other device is running in half duplex mode. The symptoms of duplex mismatches in the speech path are random packet loss, with accompanying jitter buffer packet loss, which increase in severity with traffic volume (either data or VoIP traffic). Many IT departments had painful experiences in the early days of autonegotiation, so now have a policy of forcing LAN switch configurations to full duplex operation. There is a popular misconception that attached devices/phones, which autonegotiate will detect and match the speed AND full duplex setting of the switch port. The reality in the 802.3 specifications is that the device, if autonegotiation fails, is defined to select half duplex mode -- hence, and unknowingly, creating the duplex mismatch. To accommodate VoIP, the recommended approach is to either put both devices in autonegotiate mode, or if possible to configure both devices to full duplex mode.

General recommendations for the LAN are:

� Deploy only L2 switches and/or L2/L3 switches to the edge, and within the core;
� Use a QoS-aware QoS-enforcing switch, and enable QoS;
� Specify autonegotiation mode everywhere, and correct autonegotiation failures on a case-by-case basis (the goal is to run Full Duplex everywhere possible, and many VoIP devices only support autonegotiation mode or default to autonegotiation);
� Educate IT staff about autonegotiation and the duplex mismatch problem, and how to avoid it;
� Employ only Cat-5 or better wiring (Cat-5 required for 100 Mbps, Cat-5e required for 1000 Mbps);
� Ensure cable lengths do not exceed specifications (100 meter standard, or product specific requirement); and
� Use only standard IEEE8023af power over Ethernet.

VoIP and WLANs
WLANs offer a new dimension in productivity for business users. A Gartner study suggested that enterprises could expect a 22 percent productivity improvement by introducing WLANs. Adding VoIP to WLAN is a natural productivity enhancement opportunity. Unfortunately, first-generation WLAN systems were all about basic connectivity for data, much the way Ethernet in its early days evolved around ad hoc networking, shared media operation, and unstructured wiring. Second-generation WLAN systems are all about enhanced standards addressing security (via IPSec, SSL, and ultimately IEEE802.1i), QoS (ultimately via IEEE802.1e) and interoperability, and architected solutions with placement of functionality for optimal price, performance, and control. IP mobility will open the door for roaming across the enterprise, not just across a few wireless cells. This is quite analogous to the widespread adoption of in-building Layer 2-7 architectures based on switched Ethernet and hierarchical campus networks built around routing switches.

Mobility and always-on access are one of the drivers behind IP telephony. As a shared-media LAN topology, first-generation WLANs are a poor infrastructure over which to extend converged networking due to lack of QoS and bandwidth controls, which result in poor fidelity and lost calls. VoIP over WLANs should be built on second-generation WLAN solutions, which are built around what we call QoS-enabled WLAN Security switches. WLAN Security switches dynamically manage bandwidth by authenticated user, protocol, and application. Controls are enforced, stipulating which protocols, network resources, and applications are available to each user. Comprehensive bandwidth management support at Layer 3-7 ensures that certain users and applications (such as IP telephony) are optimally served, while other less critical applications and users are capped from hogging the WLAN bandwidth.

CONCLUSION
Enterprises, deploying IP telephony for business advantage, need IP telephony-grade IP network infrastructures to deliver the expected voice quality and reliability. In LAN environments, this means QoS-enabled Ethernet switching right to the desktop with standard-based power over Ethernet with attention paid to ensure full duplex operation. Second generation WLAN solutions, based on WLAN Security switches, enable the extension of IP telephony to mobile users. IP telephony is not just another application running on an IP network. Performing a network assessment is a necessary step in any successful IP telephony deployment across the LAN.

Tony Rybczynski is Director of Strategic Enterprise Technologies at Nortel Networks. He has over 30 years experience in the application of packet network technology. Matthew F. Michels is a Senior Consulting Engineer in Nortel Networks Succession Network Design and Systems Engineering group.

[ Return To The September 2003 Table Of Contents ]