ip telephony success

7/28/2019 IP Telephony Success

1/6


2/6

Implemented properly, InternetProtocol (IP) telephony is theenabler of increased productivity andheightened customer relationships.Running on a converged, applica-tion-optimized network, IP telepho-ny now scales to 200,000 users. Itspans the entire range from corpo-rate headquarters through regionalbranches, remote offices andtelecommuters.

But there are also challenges inherentin IP telephony such as end-to-enddelays, echo and insufficientthroughput (to name a few). If IPtelephony is not properly engineeredand implemented, it can result inlost productivity, frustrated cus-tomers and curtailed revenue.

Here is a list of the five principlebarriers to IP Telephony Success, as

well as proven methods to overcomethem:

Barrier #1 Avoiding theChasm of the Last 100Meters

A few years ago, desktop networkswere built on shared media hubs

using a variety of cabling schemesthat incorporated best-effort net-

working. Today, Ethernet is thenorm while wireless LAN usage isexploding. The result: while thebackbone may be highly reliable withan abundance of bandwidth, the last100 meters to the end user at thedesktop, laptop or mobile device isoften weak.

The prevailing expectations for relia-

bility and security, as set by tradi-tional voice networks, are:

Always-on dial tone (as aguaranteed service indicator)

150 msec one-way delaymaximum

Calls are private Calls with high quality of

service, and real-timeresponsiveness - guaranteed

The real measure, then, of the per-formance of IP telephony systemsand the underlying networkmustbe how well the above user require-ments and expectations are met.

Have you considered?High reliability in IP telephony

backed up by enterprise-class securitycan be achieved via switchedEthernet and wireless LANs usingthe following guidelines:

A. Structured in-building wiring tothe desktop

Category 5 (or better) structuredwiring should be used to the desk-top. This ensures that high-quality

voice can be delivered over full

duplex 10/100-Mbpslinks.Structured wiring is also importantin meeting emergency 911 needs,

which require a correlation betweenthe physical location of the IP tele-phone, and the location code or ALI(Automatic Location Indicator) data-base location being sent to the 911PSAP center.

B. Dedicated switched Ethernet toeach telephony desktop

Only switched Ethernet QoS-enabled switching with dedicatedports to each desktop should be usedfor IP telephony. Shared-mediaEthernet hubs must never bedeployed due to packet collisionsthat will impact voice quality bydropping voice packets. TheEthernet connection, however, couldsupport a soft client in a desktop PC

or separate IP telephone and PC sharing the port via a three-portQoS-enabled switch. The wiringcloset Ethernet switch should be in asecure location to avoid eavesdrop-ping and other security breaches.

C. IP telephony powering

Power outages pose a serious concernand may have an enormous cost to abusiness in terms of loss of produc-

tive output, loss of work-in-process,

and lost revenue. For certain indus-tries such as health care, even theoccasional power outage is unaccept-able. In such industries, it is stan-dard practice to provide battery andeven generator backup for telephonysystems. Powering of IP telephonesand the use of uninterrupted powersupplies (UPS) can provide increasedreliability for IP telephony, matching

what can be done over PBX.Powering of IP phones can also easecabling at the desktop.

D. IP Telephony over WLANs

Wireless LANs operate over a sharedradio spectrum, providing mobilityfor data devices, IP phones, and PC-based soft clients. Running IP tele-

phony on WLANs must address twokey requirements QoS and securityover the radio portion. QoS is beingaddressed by IEEE 802.11 for

WLANs, which will result in an802.11e standard. However, SymbolTechnologies, Inc. has implementedEnhanced Packet Prioritization(EPP) QoS technology in its 11-Mbps AP-1431 Access Point prod-uct, which will support 802.11e.EPP prioritizes packet transmissions

from access points to mobile unitsand is very useful for media content(for example, IP telephony andstreaming video) that can be priori-tized over a heavily loaded accesspoint. As with public wireless hotspots, users of QoS-enabled WLANsshould expect less than toll-quality

voice some of the time, particularlyin busy mobile PC-intensive envi-ronments. On the other hand, highquality-voice can be expected in con-

trolled environments such as retail.

Another important considerationwith 802.11 WLANs is encryptionand authentication. Native security,

wireless application protocol (WAP)or use of IP security measures (IPsec)

via IP virtual private network (VPN)soft clients in PCs meet the encryp-tion needs for IP telephony and dataalike. For authentication, 802.1x andits extensible authentication protocol


3/6

(EAP) is the recommendedapproach.

Barrier #2 MinimizingPacket Delay, Loss and

JitterMany enterprises have not imple-

mented any form of QoS. Because ofthis, the traffic may experience dif-fering amounts of packet delay, lossand jitter. This can cause speechbreakup, speech clipping, and popsand clicks or worse. Even if band-

width is over-engineered, growth oftraffic, rapid changes in traffic pat-terns and network connection fail-ures may result in impairments thatimpact IP telephony (such as packetloss and excessive delays).

Fidelity (the clarity of the signal) hasimproved over the decades as thetelephone network has moved to dig-ital operation. Therefore, the indus-try talks about toll-quality voice asan objective of IP telephony, refer-ring explicitly to the user experienceover circuit switched networks. Users

want this level of fidelity, and insome cases users will reluctantly tol-erate lower levels if they gain suffi-

cient value (such as mobility withcell phones).

In IP telephony, voice packets aretransmitted over digital transmissionfacilities with very good error perfor-mance; the percentage of voice pack-ets that contain errors (and are there-fore discarded) is extremely low. Thefidelity of the voice is dependent onthe performance of thecoder/decoder (codec) and rate of

lost packets. Codecs convert the ana-log signal to a digitized bit stream atone end of a call and return it to itsanalog state at the other. While bitrates of 64 kbps have been used for

years in digital system, state-of-the-art codecs can deliver acceptablequality voice at bit rates as low as 8kbps. The occasional lost packet(e.g., one percent) is problematic fortelephony, since this only impacts a

short sample of speech; beyond thislevel, packet loss will be very disrup-tive to voice communications. Lostpackets arise when noise corrupts thepacket or most likely in todaysenvironmentwhen a switch orrouter in the path drops packets dueto congestion or failure conditions,or when an IP telephone or MediaGateway discards a voice packet thathas been delayed beyond someacceptable limit.

Clearly, QoS plays an integral part inthe success of any IP telephonyimplementation.

Have you considered?The following guidelines will help

you implement QoS uniformly

across the network, thereby avoidingthese pitfalls:

A. QoS via 802.1p/Q

The IEEE 802.1Q standard addsfour additional bytes to the standard802.3 Ethernet frame that providesEthernet QoS via a three-bit fieldand a virtual LAN (VLAN) ID. MostEthernet switches support this stan-dard. Ethernet QoS can be accom-

plished via the three 802.1p user pri-ority bits, to create eight classes ofservice for packets traversingEthernet networks. Ethernet QoScan also be accomplished by priori-tizing traffic based on the VLAN IDonly. For IP telephony, a binary

value of 100 for 802.1p is recom-mended with both voice bearer and

voice signaling. VLANs can be usedto separate traffic for ease-of-man-

agement and security purposes.

B. IP QoS via Differentiated Services

Different types of applications(including IP telephony) have differ-ent characteristics and require differ-ent types of QoS behaviors to beapplied to them at every router andswitch along the path. DifferentiatedServices (DiffServ), for example,defines a number of different QoS

behaviors and their correspondingQoS mechanisms, called per-hopbehaviors (PHBs). These PHBs areidentified by an IETF-standardizedDiffServ control point (DSCP) car-ried in each IP packet. Even if thereis plenty of unused bandwidth avail-able, IP QoS is required, since IPtelephony performance may beimpacted during times of congestionand traffic peaks and after loss ofbandwidth after failures. The sim-plest approach is to construct twotraffic classes one for IP telephonyand the other for best-effort datatraffic.

C. Nortel Networks Service Classes

End-to-end QoS management can be

quite complex. Nortel Networks hassimplified QoS by creating standard-ized, default QoS configurations andbehaviors for its products in theform of end-to-end network serviceclasses. These are called NortelNetworks Service Classes (NNSCs).NNSCs have been defined basedupon the most common types ofapplications. They provide defaultmapping between DiffServ and dif-ferent link layer QoS technologies

that a particular interface uses.

D. IP address prioritization

IP telephony traffic can also be pri-oritized by its IP address. Thisapproach is ideal for devices withstatically assigned IP addresses thatrarely, if ever, change. IP PBXs, VoIPgateways, and communicationsservers are VoIP devices that wouldhave their IP addresses statically

assigned. Routers and switches canbe configured to filter/classify andprioritize all packets originated fromIP addresses.

E. Switch and router performance

Even under heavy load, routers andswitches should provide IP telephonytraffic with very low latency. In addi-tion, they should support wire-speed


4/6

operation (even with short packets)when packet classification (QoS) isactivated. Turning on various packetclassification schemes on some soft-

ware-based routers can have severeimpacts on performance, including

VoIP packet loss and delay. Routingswitch technology with deep packetfiltering prevents performance degra-dation even at Gbps speeds.

Barrier #3 Putting an Endto UnreliabilityThe telephony world refers to99.999 percent base system reliabili-ty based on a mean time betweenfailure measured in tens of years andredundant common control for largesystems. But this metric alone does-nt reflect the realities of most enter-prise IP networks.

An IP network may fail in terms ofperformance:

If it is 100 percent up, butthere are non-hardware failureconditions, such as a remote site,

which make being physicallyconnected logically unreachable(perhaps due to routing

information protocol hopcount limits) If it is 100 percent up, but

there is congestion in thenetwork resulting in increasedpacket loss and excessive delays

If it is 100 percent up, but IProuting convergence after failurestakes too long

Consequently, an end-to-end system-level view of IP telephony reliability

is a vital necessity.

Have you considered?A comprehensive approach to relia-bility is required in order to meet theexpectations of IP telephony users.The following guidelines should befollowed in deploying networks,

which meet IP telephony require-ments as they relate to reliability:

A. Backbone node reliability andavailability

Backbone node reliability and avail-ability should be comparable toavailability levels delivered with tra-ditional telephony systems, recogniz-ing that networking techniques canbe used to fill the gap. This isachieved by designing switches todeliver the following:

Very high component MTBF Highly reliable, robust base

software, and real-timeoperating system software

Redundant power, fans andtemperature sensors

Redundant switch fabricand common control with

sub-second switchover Hot swappable capability ofall core system elements

Automatic short system bootand restart times

Short software upgrade serviceoutage time

B. Rapid detection and recoverybelow Layer 3

A sound design principal is to pro-

vide resilience at the Layer 1 leveland provide rapid recovery from fail-ures at that level. In this way, linkfailures can be handled withoutimpacting the Layer 3 routing sys-tem. Three technologies play keyroles in achieving this:

Ethernet link aggregationallows multiple 100/1000 MbpsEthernet links to be configuredas a trunk group between wiring

closet switches and backbonenodes, and between backbonenodes. Automatic trafficrebalancing takes place ifone of the links fails.

Optical dual ring technologiescan provide very high resiliencefor extended campus and datacenter environments. These offer50-ms recovery from failures ona SONET and wavelength basis.

Resilient packet rings (RPR) isa Layer 2 solution that combinesoptical ring and Layer 2technology to provide 50-msrecovery from failures by usinga counter-rotating ring.

C. Dynamic routing over designednetworks

Some of the key IP networking stan-dards that enhance fault-tolerant net-

working include high-performancedynamic routing protocols, protocolsfor route balancing across paths, andfor LAN redundancy. These proto-cols should be carried over networksthat are designed to put an upperlimit on the number of routingpoints between end users. This puts

a ceiling on the delay across the net-work and speeds up routing conver-gence times.

Barrier #4 MinimizingRisk on Public PacketNetworksMeeting IP telephony QoS, securityand reliability requirements acrosspublic packet networks requires spe-cial attention. While leased lines are

always an option to interconnectsites, virtual private lines usingFrame Relay, ATM and, increasingly,IP-VPNs and Optical Ethernet areattractive alternatives. A high degreeof flexibility is required in interfac-ing to public networks for high avail-ability and QoS.

Have you considered?The following guidelines apply to

real-world IP networks that supportIP telephony across the cloud:

A. Engineering the bandwidth

Typically, LAN bandwidth is inex-pensive and is a fixed one-time cost.However, in the MAN or WAN,bandwidth is expensive and results ina monthly recurring cost. QoS allowsthe enterprise to use expensive WANbandwidth most cost-effectively. The


5/6

bandwidth used for voice calls isdependent on the codecs used andhow these are configured for differ-ent types of calls. How facsimile ishandled also needs to be factored in.Traditional voice engineering meth-ods can be used to determine thenumber of calls that need to be engi-neered over the WAN link, factoringin calling communities of interest,the number of busy hour callattempts, and the average call hold-ing time. On under-utilized T3-and-above leased lines, for instance,adding IP telephony traffic uses upavailable bandwidth. For highly uti-lized high-speed links and lowerbandwidth (T1 or less) connections,though, the amount of VoIP trafficshould be limited to a percentage of

the bandwidth of the connection.Rule of thumb: for low-bandwidth(less than 1 Mbps) connections, nomore than 50 percent of the availablebandwidth for voice traffic should beused; for connections more than 1Mbps, up to 85 percent of the avail-able bandwidth for voice traffic canbe used.

B. Flexible QoS mapping at theWAN edge

Running IP telephony over leasedlines leaves QoS and traffic manage-ment totally under the control of theenterprise. Support for flexible QoSmapping when working into carrierpacket services should be addressedas follows:

DiffServ, in conjunction withFrame Relay traffic management,is used to provide QoS over

Frame Relay networks. Inaddition, a separate mesh of

virtual circuits (VCs) shouldbe established for IP telephony

with appropriate committedinformation rate to minimizeinteraction between voice anddata traffic. The IP telephony

VCs should run at a higherpriority.

If ATM is to be used, thenIP telephony traffic should becarried over constant bit rate orreal-time variable bit rate VCs.These VCs should be sizedappropriately. Note that ATMcan support both voice and dataover a single VC, provided the

ATM VC is selected to supportthe most stringent multi-serviceapplication.

Optical Ethernet providesEthernet connectivity withsupport for IEEE 802.1p/Q.The high-speed, low-latencyattributes of this service makeit ideal for MAN/WANconnectivity among metro sites.

Using IP-VPNs over the Internetis very attractive for remoteaccess and for connectivityto remote office.

C. Reducing delays through packetfragmentation

In mixed voice/data IP networks,packets must be fragmented prior totraversing bandwidth limited (lessthan 1 Mbps) connections to mini-

mize voice delay and jitter. There areseveral protocols that can be used tofragment packets.

D. Reliability across the WAN

Extending the reliability of the cam-pus across the WAN can be a majorchallenge. While IP routing is thelast line of defense, lower-layermechanisms are required to mini-mize the impacts and failures and

meet IP telephony requirements.With serial links, various multi-linkredundancy options are available.These provide scalable bandwidthand enhanced reliability.

E. Secure IP telephony across theInternet

Security concerns of running voiceover the Internet can be taken off the

table because all traffic leaving thesite across an IP-VPN is authenticat-ed and encrypted. For remote offices,redundant access links and dynamicrouting over encrypted tunnels canprovide a high level of reliability.

Barrier #5 Looking

Inward OrganizationalBarriers to IP Telephonyand Their ImplicationsThe greatest technologies will not

yield the desired result unless theyare engineered and operated appro-priately. Traditional IP networksevolved from PCs to PC LANs tobridged, and ultimately switched androuted networks. At the same time,applications evolved from e-mail and

file transfers to ERP, CRM and nowIP telephony and collaboration.

Due to the real-time requirementsfor IP Telephony and other applica-tions like Video, existing practicesand procedures are likely outdatedand may have to be redesigned whenimplementing IP telephony.

Have you considered?

As each new networking andtelecommunications technology hascome along, enterprises have had torethink, and evolve their internalprocedures and engineering practices.The same holds true for IP telepho-ny. The following guidelines mayprove useful in smoothing the transi-tion from best-effort networking toalways-on, application-optimizedconverged networks.

A. Network convergence drives orga-nizational convergence

Deploying IP telephony solutions ontop of a converged network requiresa mixture of skill sets, including agood understanding of what the IPtelephony end user wants from a fea-ture and performance perspectives.

Also, IP telephony application engi-neering, as well as network engineer-


6/6

ing, operations and planning, isrequired.

B. Designing the network in linewith the business

IT planners must consider network-ing for IP telephony in the broadercontext of application optimized net-

working across the enterprise. Theymust establish business-driven relia-bility objectives, as well as securityand QoS policy management direc-tions. For example, they must estab-lish levels of network redundancythat are affordable and justifiable tomeet business needs.

C. Operational evolution

Enterprises need to establish opera-tional procedures that recognize thetransition from best-effort network-ing to always-on, application-opti-mized converged networks.Scheduling maintenance windowsand avoiding equipment resets as thefirst step for fault recovery are buttwo examples of areas that need tobe addressed.

D. SLA management for converged

networks

The increased reliability and perfor-mance requirements of convergednetworks put added pressures for theestablishment of strong SLAs withservice providers. Once established,there is a need to validate that thesecommitments are being met. Thisrequires a combination of manage-ment tools and reporting, and a real-time window on how the network is

performing.

For More Information:To obtain a copy of the white paper,"Designing Converged Networks ForIP Telephony," or to find out moreabout Nortel Networks IPTelephony and convergencesolutions, contact:

26610 Agoura Road, Suite 210, Calabasas, CA 91302

http://www.nortelnetworks.com

Copyright 2003 Nortel Networks. All Rights Reserved. Nortel Networks, the Nortel Networks logo and the Globemark are trademarks of

Nortel Networks. Information subject to change without notice. Nortel Networks assumes no responsibility for any errors or omissions that

may appear in this document. Printed in the USA.

ip telephony success

Documents