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
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
ï¿½ 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
ï¿½ 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
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.
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.
To The September 2003 Table Of Contents ]