文献翻译——以太网网络电话传送调度：方法论和案例分析

11外文文献资料OnthedeploymentofVoIPinEthernetnetworks:methodologyandcasestudyKhaledSalah,DepartmentofInformationandComputerScience,KingFahdUniversityofPetroleumandMinerals,P.O.Box5066,Dhahran31261,SaudiArabiaReceived25May2004;revised3June2005;accepted3June2005.Availableonline1July2005.AbstractDeployingIPtelephonyorvoiceoverIP(VoIP)isamajorandchallengingtaskfordatanetworkresearchersanddesigners.Thispaperoutlinesguidelinesandastep-by-stepmethodologyonhowVoIPcanbedeployedsuccessfully.Themethodologycanbeusedtoassessthesupportandreadinessofanexistingnetwork.PriortothepurchaseanddeploymentofVoIPequipment,themethodologypredictsthenumberofVoIPcallsthatcanbesustainedbyanexistingnetworkwhilesatisfyingQoSrequirementsofallnetworkservicesandleavingadequatecapacityforfuturegrowth.Asacasestudy,weapplythemethodologystepsonatypicalnetworkofasmallenterprise.Weutilizebothanalysisandsimulationtoinvestigatethroughputanddelaybounds.Ouranalysisisbasedonqueuingtheory,andOPNETisusedforsimulation.Resultsobtainedfromanalysisandsimulationareinlineandgiveaclosematch.Inaddition,thepaperdiscussesmanydesignandengineeringissues.TheseissuesincludecharacteristicsofVoIPtrafficandQoSrequirements,VoIPflowandcalldistribution,2definingfuturegrowthcapacity,andmeasurementandimpactofbackgroundtraffic.Keywords:NetworkDesign，NetworkManagement，VoIP，PerformanceEvaluation，Analysis，Simulation，OPNET1IntroductionThesedaysamassivedeploymentofVoIPistakingplaceoverdatanetworks.MostofthesenetworksareEthernetbasedandrunningIPprotocol.Manynetworkmanagersarefindingitveryattractiveandcosteffectivetomergeandunifyvoiceanddatanetworksintoone.Itiseasiertorun,manage,andmaintain.However,onehastokeepinmindthatIPnetworksarebest-effortnetworksthatweredesignedfornon-realtimeapplications.Ontheotherhand,VoIPrequirestimelypacketdeliverywithlowlatency,jitter,packetloss,andsufficientbandwidth.Toachievethisgoal,anefficientdeploymentofVoIPmustensurethesereal-timetrafficrequirementscanbeguaranteedoverneworexistingIPnetworks.WhendeployinganewnetworkservicesuchasVoIPoverexistingnetwork,manynetworkarchitects,managers,planners,designers,andengineersarefacedwithcommonstrategic,andsometimeschallenging,questions.WhataretheQoSrequirementsforVoIP?HowwillthenewVoIPloadimpacttheQoSforcurrentlyrunningnetworkservicesandapplications?WillmyexistingnetworksupportVoIPandsatisfythestandardizedQoSrequirements?Ifso,howmanyVoIPcallscanthenetworksupportbeforeupgradingprematurelyanypartoftheexistingnetworkhardware?Thesechallengingquestionshaveledtothedevelopmentofsomecommercialtoolsfortestingtheperformanceofmultimediaapplicationsindatanetworks.AlistoftheavailablecommercialtoolsthatsupportVoIPislistedin1,2.Forthemostpart,thesetoolsusetwocommonapproachesinassessingthedeploymentofVoIPintotheexistingnetwork.OneapproachisbasedonfirstperformingnetworkmeasurementsandthenpredictingthenetworkreadinessforsupportingVoIP.Thepredictionofthenetworkreadinessisbasedonassessingthehealthofnetworkelements.ThesecondapproachisbasedoninjectingrealVoIPtrafficintoexistingnetworkandmeasuringtheresultingdelay,jitter,andloss.Otherthanthecostassociatedwiththecommercialtools,noneofthecommercialtoolsofferacomprehensiveapproachforsuccessfulVoIPdeployment.Inparticular,nonegives3anypredictionforthetotalnumberofcallsthatcanbesupportedbythenetworktakingintoaccountimportantdesignandengineeringfactors.ThesefactorsincludeVoIPflowandcalldistribution,futuregrowthcapacity,performancethresholds,impactofVoIPonexistingnetworkservicesandapplications,andimpactbackgroundtrafficonVoIP.ThispaperattemptstoaddressthoseimportantfactorsandlayoutacomprehensivemethodologyforasuccessfuldeploymentofanymultimediaapplicationsuchasVoIPandvideoconferencing.However,thepaperfocusesonVoIPasthenewserviceofinteresttobedeployed.Thepaperalsocontainsmanyusefulengineeringanddesignguidelines,anddiscussesmanypracticalissuespertainingtothedeploymentofVoIP.TheseissuesincludecharacteristicsofVoIPtrafficandQoSrequirements,VoIPflowandcalldistribution,definingfuturegrowthcapacity,andmeasurementandimpactofbackgroundtraffic.Asacasestudy,weillustratehowourapproachandguidelinescanbeappliedtoatypicalnetworkofasmallenterprise.Therestofthepaperisorganizedasfollows.Section2presentsatypicalnetworktopologyofasmallenterprisetobeusedasacasestudyfordeployingVoIP.Section3outlinespracticaleight-stepmethodologytodeploysuccessfullyVoIPindatanetworks.Eachstepisdescribedinconsiderabledetail.Section4describesimportantdesignandengineeringdecisionstobemadebasedontheanalyticandsimulationstudies.Section5concludesthestudyandidentifiesfuturework.42ExistingnetworkFig.1illustratesatypicalnetworktopologyforasmallenterpriseresidinginahigh-risebuilding.Thenetworkshownisrealisticandusedasacasestudyonly;however,ourworkpresentedinthispapercanbeadoptedeasilyforlargerandgeneralnetworksbyfollowingthesameprinciples,guidelines,andconceptslaidoutinthispaper.ThenetworkisEthernet-basedandhastwoLayer-2Ethernetswitchesconnectedbyarouter.TherouterisCisco2621,andtheswitchesare3ComSuperstack3300.Switch1connectsFloors1and2andtwoservers;whileSwitch2connectsFloor3andfourservers.EachfloorLANisbasicallyasharedEthernetconnectingemployeePCswithworkgroupandprinterservers.ThenetworkmakesuseofVLANsinordertoisolatebroadcastandmulticasttraffic.AtotaloffiveLANsexist.AllVLANsareportbased.Switch1isconfiguredsuchthatithasthreeVLANs.VLAN1includesthedatabaseandfileservers.VLAN2includesFloor1.VLAN3includesFloor2.Ontheotherhand,Switch2isconfiguredtohavetwoVLANs.VLAN4includestheserversforE-mail,HTTP,Webandcacheproxy,andfirewall.VLAN5includesFloor3.AllthelinksareswitchedEthernet100MbpsfullduplexexceptforthelinksforFloors13whicharesharedEthernet100Mbpshalfduplex.53Step-by-stepmethodologyFig.2showsaflowchartofamethodologyofeightstepsforasuccessfulVoIPdeployment.Thefirstfourstepsareindependentandcanbeperformedinparallel.Beforeembarkingontheanalysisandsimulationstudy,inSteps6and7,Step5mustbecarriedoutwhichrequiresanyearlyandnecessaryredimensioningormodificationstotheexistingnetwork.Asshown,bothSteps6and7canbedoneinparallel.Thefinalstepispilotdeployment.3.1.VoIPtrafficcharacteristics,requirements,andassumptionsForintroducinganewnetworkservicesuchasVoIP,onehastocharacterizefirstthenatureofitstraffic,QoSrequirements,andanyadditionalcomponentsordevices.Forsimplicity,weassumeapoint-to-pointconversationforallVoIPcallswithnocallconferencing.FordeployingVoIP,agatekeeperorCallManagernodehastobeaddedtothenetwork3,4,5.Thegatekeepernodehandlessignalingforestablishing,terminating,andauthorizingconnectionsofallVoIPcalls.AlsoaVoIPgatewayisrequiredtohandleexternalcalls.AVoIPgatewayisresponsibleforconvertingVoIPcallsto/fromthePublicSwitchedTelephoneNetwork(PSTN).Asanengineeringanddesignissue,theplacementofthese6nodesinthenetworkbecomescrucial.Wewilltacklethisissueindesignstep5.OtherhardwarerequirementsincludeaVoIPclientterminal,whichcanbeaseparateVoIPdevice,i.e.IPphones,oratypicalPCorworkstationthatisVoIP-enabled.AVoIP-enabledworkstationrunsVoIPsoftwaresuchasIPSoftPhones.Fig.3identifiestheend-to-endVoIPcomponentsfromsendertoreceiver9.Thefirstcomponentistheencoderwhichperiodicallysamplestheoriginalvoicesignalandassignsafixednumberofbitstoeachsample,creatingaconstantbitratestream.Thetraditionalsample-basedencoderG.711usesPulseCodeModulation(PCM)togenerate8-bitsamplesevery0.125ms,leadingtoadatarateof64kbps.ThepacketizerfollowstheencoderandencapsulatesacertainnumberofspeechsamplesintopacketsandaddstheRTP,UDP,IP,andEthernetheaders.Thevoicepacketstravelthroughthedatanetwork.Animportantcomponentatthereceivingend,istheplaybackbufferwhosepurposeistoabsorbvariationsorjitterindelayandprovideasmoothplayout.Thenpacketsaredeliveredtothedepacketizerandeventuallytothedecoderwhichreconstructstheoriginalvoicesignal.WewillfollowthewidelyadoptedrecommendationsofH.323,G.711,andG.714standardsforVoIPQoSrequirements.7Table1comparessomecommonlyusedITU-Tstandardcodecsandtheamountofone-waydelaythattheyimpose.ToaccountforupperlimitsandtomeetdesirablequalityrequirementaccordingtoITUrecommendationP.800,wewilladoptG.711ucodecstandardsfortherequireddelayandbandwidth.G.711uyieldsaround4.4MOSrating.MOS,MeanOpinionScore,isacommonlyusedVoIPperformancemetricgiveninascaleof15,with5isthebest.However,withlittlecompromisetoquality,itispossibletoimplementdifferentITU-Tcodecsthatyieldmuchlessrequiredbandwidthpercallandrelativelyabithigher,butacceptable,end-to-enddelay.Thiscanbeaccomplishedbyapplyingcompression,silencesuppression,packetlossconcealment,queuemanagementtechniques,andencapsulatingmorethanonevoicepacketintoasingleEthernetframe.3.1.1.End-to-enddelayforasinglevoicepacketFig.3illustratesthesourcesofdelayforatypicalvoicepacket.Theend-to-enddelayissometimesreferredtobyM2EorMouth-to-Eardelay.G.714imposesamaximumtotalone-waypacketdelayof150msend-to-endforVoIPapplications.In22,adelayofupto200mswasconsideredtobeacceptable.Wecanbreakthisdelaydownintoatleastthreedifferentcontributingcomponents,whichareasfollows(i)encoding,compression,andpacketizationdelayatthesender(ii)propagation,transmissionandqueuingdelayinthenetworkand(iii)buffering,decompression,depacketization,decoding,andplaybackdelayatthereceiver.3.1.2.BandwidthforasinglecallTherequiredbandwidthforasinglecall,onedirection,is64kbps.G.711codecsamples20msofvoiceperpacket.Therefore,50suchpacketsneedtobetransmittedpersecond.Eachpacketcontains160voicesamplesinordertogive8000samplespersecond.EachpacketissentinoneEthernetframe.Witheverypacketofsize160bytes,headersofadditionalprotocollayersareadded.TheseheadersincludeRTP+UDP+IP+Ethernetwithpreambleofsizes12+8+20+26,respectively.Therefore,atotalof226bytes,or1808bits,needstobetransmitted50timespersecond,or90.4kbps,inonedirection.Forbothdirections,therequiredbandwidthforasinglecallis100ppsor180.8kbpsassumingasymmetricflow.83.1.3.OtherassumptionsThroughoutouranalysisandwork,weassumevoicecallsaresymmetricandnovoiceconferencingisimplemented.Wealsoignorethesignalingtrafficgeneratedbythegatekeeper.Webaseouranalysisanddesignontheworst-casescenarioforVoIPcalltraffic.Thesignalingtrafficinvolvingthegatekeeperismostlygeneratedpriortotheestablishmentofthevoicecallandwhenthecallisfinished.Thistrafficisrelativelysmallcomparedtotheactualvoicecalltraffic.Ingeneral,thegatekeepergeneratesnoorverylimitedsignalingtrafficthroughoutthedurationoftheVoIPcallforanalreadyestablishedon-goingcall.Inthispaper,wewillimplementnoQoSmechanismsthatcanenhancethequalityofpacketdeliveryinIPnetworks.AmyriadofQoSstandardsareavailableandcanbeenabledfornetworkelements.QoSstandardsmayincludeIEEE802.1p/Q,theIETFsRSVP,andDiffServ.Analysisofimplementationcost,complexity,management,andbenefitmustbeweighedcarefullybeforeadoptingsuchQoSstandards.Thesestandardscanberecommendedwhenthecostforupgradingsomenetworkelementsishighandthenetworkresourcesarescarceandheavilyloaded.3.2.VoIPtrafficflowandcalldistributionKnowingthecurrenttelephonecallusageorvolumeoftheenterpriseisanimportantstepforasuccessfulVoIPdeployment.BeforeembarkingonfurtheranalysisorplanningphasesforaVoIPdeployment,collectingstatisticsaboutofthepresentcallvolumeandprofilesisessential.SourcesofsuchinformationareorganizationsPBX,telephonerecordsandbills.Keycharacteristicsofexistingcallscanincludethenumberofcalls,numberofconcurrentcalls,time,duration,etc.Itisimportanttodeterminethelocationsofthecallendpoints,i.e.thesourcesanddestinations,aswellastheircorrespondingpathorflow.Thiswillaidinidentifyingthecalldistributionandthecallsmadeinternallyorexternally.Calldistributionmustincludepercentageofcallswithinandoutsideofafloor,building,department,ororganization.Asagoodcapacityplanningmeasure,itisrecommendedtobasetheVoIPcalldistributiononthebusyhourtrafficofphonecallsforthebusiestdayofaweekoramonth.ThiswillensuresupportofthecallsatalltimeswithhighQoSforallVoIPcalls.9Whensuchcurrentstatisticsarecombinedwiththeprojectedextracalls,wecanpredicttheworst-caseVoIPtrafficloadtobeintroducedtotheexistingnetwork.Fig.4describesthecalldistributionfortheenterpriseunderstudybasedontheworstbusyhourandtheprojectedfuturegrowthofVoIPcalls.Inthefigure,thecalldistributionisdescribedasaprobabilitytree.Itisalsopossibletodescribeitasaprobabilitymatrix.Someimportantobservationscanbemadeaboutthevoicetrafficflowforinter-floorandexternalcalls.Forallthesetypeofcalls,thevoicetraffichastobealwaysroutedthroughtherouter.ThisissobecauseSwitchs1and2arelayer2switcheswithVLANsconfiguration.Onecanobservethatthetrafficflowforinter-floorcallsbetweenFloors1and2imposestwicetheloadonSwitch1,asthetraffichastopassthroughtheswitchtotherouterandbacktotheswitchagain.Similarly,Switch2experiencestwicetheloadforexternalcallsfrom/toFloor3.3.3.DefineperformancethresholdsandgrowthcapacityInthisstep,wedefinethenetworkperformancethresholdsoroperationalpointsforanumberofimportantkeynetworkelements.Thesethresholdsaretobeconsideredwhendeployingthenewservice.Thebenefitistwofold.First,therequirementsofthenewservicetobedeployedaresatisfied.Second,addingthenewserviceleavesthenetworkhealthyandsusceptibletofuturegrowth.Twoimportantperformancecriteriaaretobetakenintoaccount.10Firstisthemaximumtolerableend-to-enddelay;andsecondistheutilizationboundsorthresholdsofnetworkresources.Themaximumtolerableend-to-enddelayisdeterminedbythemostsensitiveapplicationtorunonthenetwork.Inourcase,itis150msend-to-endforVoIP.Itisimperativetonotethatifthenetworkhascertaindelaysensitiveapplications,thedelayfortheseapplicationsshouldbemonitored,whenintroducingVoIPtraffic,suchthattheydonotexceedtheirrequiredmaximumvalues.Asfortheutilizationboundsfornetworkresources,suchboundsorthresholdsaredeterminedbyfactorssuchascurrentutilization,futureplans,andforeseengrowthofthenetwork.Properresourceandcapacityplanningiscrucial.Savvynetworkengineersmustdeploynewserviceswithscalabilityinmind,andascertainthatthenetworkwillyieldacceptableperformanceunderheavyandpeakloads,withnopacketloss.VoIPrequiresalmostnopacketloss.Inliterature,0.15%packetlosswasgenerallyasserted.However,in24therequiredVoIPpacketlosswasconservativelysuggestedtobelessthan10.Amorepracticalpacketloss,basedonexperimentation,of5below1%wasrequiredin22.Hence,itisextremelyimportantnottoutilizefullythenetworkresources.Asrule-of-thumbguidelineforswitchedfastfull-duplexEthernet,theaverageutilizationlimitoflinksshouldbe190%,andforswitchedsharedfastEthernet,theaveragelimitoflinksshouldbe85%25.Theprojectedgrowthinusers,networkservices,business,etc.mustbealltakenintoconsiderationtoextrapolatetherequiredgrowthcapacityorthefuturegrowthfactor.Inourstudy,wewillascertainthat25%oftheavailablenetworkcapacityisreservedforfuturegrowthandexpansion.Forsimplicity,wewillapplythisevenlytoallnetworkresourcesoftherouter,switches,andswitched-Ethernetlinks.However,keepinmindthispercentageinpracticecanbevariableforeachnetworkresourceandmaydependonthecurrentutilizationandtherequiredgrowthcapacity.Inourmethodology,thereservationofthisutilizationofnetworkresourcesisdoneupfront,beforedeployingthenewservice,andonlytheleft-overcapacityisusedforinvestigatingthenetworksupportofthenewservicetobedeployed.3.4.PerformnetworkmeasurementsInordertocharacterizetheexistingnetworktrafficload,utilization,andflow,network11measurementshavetobeperformed.Thisisacrucialstepasitcanpotentiallyaffectresultstobeusedinanalyticalstudyandsimulation.Thereareanumberoftoolsavailablecommerciallyandnoncommerciallytoperformnetworkmeasurements.Popularopen-sourcemeasurementtoolsincludeMRTG,STG,SNMPUtil,andGetIF26.AfewexamplesofpopularcommerciallymeasurementtoolsincludeHPOpenView,CiscoNetflow,LucentVitalSuite,PatrolDashBoard,OmegonNetAlly,AvayaExamiNet,NetIQVivinetAssessor,etc.Networkmeasurementsmustbeperformedfornetworkelementssuchasrouters,switches,andlinks.Numeroustypesofmeasurementsandstatisticscanbeobtainedusingmeasurementtools.Asaminimum,trafficratesinbitspersecond(bps)andpacketspersecond(pps)mustbemeasuredforlinksdirectlyconnectedtoroutersandswitches.Togetadequateassessment,networkmeasurementshavetobetakenoveralongperiodoftime,atleast24-hperiod.Sometimesitisdesirabletotakemeasurementsoverseveraldaysoraweek.Onehastoconsidertheworst-casescenariofornetworkloadorutilizationinordertoensuregoodQoSatalltimesincludingpeakhours.Thepeakhourisdifferentfromonenetworktoanotheranditdependstotallyonthenatureofbusinessandtheservicesprovidedbythenetwork.Table2showsasummaryofpeak-hourutilizationfortrafficoflinksinbothdirectionsconnectedtotherouterandthetwoswitchesofthenetworktopologyofFig.1.Thesemeasuredresultswillbeusedinouranalysisandsimulationstudy.12中文翻译稿以太网网络电话传送调度：方法论和案例分析KhaledSalah,信息与计算机科学,FahdUniversity皇家石油矿物大学,信箱5066,Dhahran31261,沙特阿拉伯半岛收到日期2004年5月25日;校正日期2005年6月3日;接受日期2005年6月3日。网上可用日期2005年7月1日。摘要对网络数据为研究人员和设计师来说，IP电话或通过IP电话语音调度是一项重要而艰巨的任务。本文中介绍的标准和循序渐进的方法，介绍了语音的成功如何通过IP调度传输。该方法可用于支持评估和对现有网络的使用做准备。购买和部署网络电话设备设备之前，这种方法出来的预算，以确保现有和未来网络的网络电话设备足够的扩展能力基础上的呼叫数量的服务质量要求。作为一个研究课题，我们在一个典型的小型企业把这个方法网上已经逐步应用。我们使用分析和模拟吞吐量和延迟方面。我们的分析是基于排队论和OPNET仿真。比较一致的理论分析和仿真结构。此外，我们谈到了很多的设计和工程问题。这些问题包括功能和网络电话设备通信服务质量要求，网络电话设备流和呼叫分配，定义未来增长能力，确定背景流量的影响。这些天来大规模部署的VoIP正在发生通过数据网络。大多数网络都是基于以太网和运行IP协议。许多网络管理人员发现它非常有吸引力和成本效益进行合并和统一的语音和数据网络为一体。这是比较容易运行，管理和维护。然而，人们必须记住，IP网络是被设计用于非实时应用尽力而为的网络。在另一方面，网络电话需要及时的数据包传送的低时延，抖动，丢包和足够的带宽。为了实现这一目标，一个高效部署的VoIP必须确保这些实时路况要求可保证在新的或现有的IP网络。在部署新的网络服务，例如VoIP在现有的网络，许多网络设计师，管理人员，策划人员，设计师和工程师都面临着共同的战略，有时具有挑战性的，问题。什么是VoIP的要求？新的VoIP负荷将如何影响服务质量为当前运行的网络服务和应用？我现有的网络支持VoIP和满足规范的QoS要求？如果是这样，有多少VoIP电话可以在之前的网络支持升级过早任何部分13现有的网络硬件？这些具有挑战性的问题导致了用于测试的数据网络多媒体应用的性能一些商业工具的开发。那支持VoIP的可商业化的工具列表中列出的1,2。在大多数情况下，这些工具的使用在评估部署的VoIP纳入现有的网络两种常见的方法。一种方法是基于第一次执行网络测量和预测，然后在网络准备就绪，支持VoIP。网络就绪的预测是基于评估网络元件的健康状况。第二种方法是基于真正注入VoIP流量到现有的网络并测量产生的时延，抖动和丢包。除与商业工具相关的成本，没有一个商业工具提供了成功的VoIP部署一个全面的方法。特别是，没有给出任何预测，可以由网络考虑到重要的设计和工程因素来支持呼叫的总数。这些因素包括：对VoIP的VoIP流和呼叫分配，未来增长的容量，性能阈值，网络电话对现有的网络服务和应用程序的影响，而影响背景流量。本文试图解决这些重要因素和布局成功部署的任何多媒体应用，如VoIP和视频会议的全面的方法。然而，本文的重点是网络电话的部署感兴趣的新服务。该文件还包含了许多有用的工程和设计准则，并讨论有关VoIP的部署许多实际问题。这些问题包括VoIP流量和QoS的要求，VoIP流的特点和呼叫分配，定义未来增长的能力，以及测量和背景流量的影响。作为一个案例研究中，我们说明了如何我们的方法和指导原则可以应用到一个小企业的典型网络。本文的其余部分安排如下。第2节介绍一个小企业要作为部署VoIP的一个案例研究的一个典型的网络拓扑结构。第3节概述了实用的八个步骤的方法来部署成功的VoIP在数据网络。每个步骤中相当详细地描述。第4节介绍的基础上，分析和仿真研究作出重要的设计和工程决