英文文獻(xiàn)-科技類(lèi)-原文及翻譯-電子-電氣-自動(dòng)化-通信

1外文文獻(xiàn)原文OnthedeploymentofVoIPinEthernetnetworks:methodologyandcasestudyAbstractDeployingIPtelephonyorvoiceoverIP(VoIP)isamajorandchallengingtaskfordatanetworkresearchersanddesigners.Thispaperoutlinesguidelinesandastep-by-stepmethodologyonhowVoIPcanbedeployedsuccessfully.Themethodologycanbeusedtoassessthesupportandreadinessofanexistingnetwork.PriortothepurchaseanddeploymentofVoIPequipment,themethodologypredictsthenumberofVoIPcallsthatcanbesustainedbyanexistingnetworkwhilesatisfyingQoSrequirementsofallnetworkservicesandleavingadequatecapacityforfuturegrowth.Asacasestudy,weapplythemethodologystepsonatypicalnetworkofasmallenterprise.Weutilizebothanalysisandsimulationtoinvestigatethroughputanddelaybounds.Ouranalysisisbasedonqueuingtheory,andOPNETisusedforsimulation.Resultsobtainedfromanalysisandsimulationareinlineandgiveaclosematch.Inaddition,thepaperdiscussesmanydesignandengineeringissues.TheseissuesincludecharacteristicsofVoIPtrafficandQoSrequirements,VoIPflowandcalldistribution,definingfuturegrowthcapacity,andmeasurementandimpactofbackgroundtraffic.原Ke緊yw影or權(quán)ds彩:格Ne據(jù)tw移or舉k撥De憐si亡gn傍，蛇Ne吧tw第or涌k手Ma帳na擱ge捷me束nt鐵，列Vo膽IP企，惜Pe榮rf攔or瞇ma捧nc枝e矮Ev房al誓ua繁ti濱on已，陜An筆al才ys件is款，樓Si共mu逐la躬ti哈on互，匹OP對(duì)NE毀T

勉1搜I諷nt律ro根du鵲ct蟲(chóng)io肉nThesedaysamassivedeploymentofVoIPistakingplaceoverdatanetworks.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?HowwillthenewVoIP科lo襲ad誕i食mp課ac啄t膨th乞e陸Qo糊S集fo旨r乓cu鋪rr椒en討tl繞y掠ru牲nn票in躍g飽ne挑tw梯or話(huà)k粒se桃rv辨ic逐es捎膠an束d抄ap齒pl扒ic橫at謝io婚ns廟?頸Wi我ll險(xiǎn)m咽y喊ex鋤is丟ti匪ng油n睜et煙wo營(yíng)rk窯s辛up瞞po番rt絡(luò)V濤oI位P役刊an鴉d杏sa給ti棵sf款y徐th披e欲st拒an鑰da逮rd針iz項(xiàng)ed擱Q消oS爛r題eq印ui靠re教me鑄nt文s?找I舌f昆so廟,蓬ho突w北冷ma持ny曉V廣oI灣P洞ca嫁ll由s奏ca醬n塔th慨e使ne樹(shù)tw歌or黑k勿su帆pp此or貸t滿(mǎn)be窗fo仗re槐u庫(kù)pg漠ra于di至ng畜拋pr悄em狐at舟ur犯el陵y法an驕y(cè)際pa栗rt聚o帆f始th喇e州ex臘is僻ti匙ng六n尚et跑wo逝rk斗h嗚ar唱dw各ar醉e?謙任Th現(xiàn)es弦e挖ch尺al獄le材ng歸in辱g帽qu東es怨ti免on喚s艦ha纖ve備l弄ed右t最o辣th專(zhuān)e轎de抵ve揮lo階pm偉en繭t竟糕of慰s負(fù)om汗e絹co自mm鼻er賞ci努al暢t泉oo礎(chǔ)ls動(dòng)f隔or壘t廳es信ti孩ng暴t不he悲p材er捧fo轉(zhuǎn)rm邪an施ce垃o縣f抓密mu憐lt門(mén)im臘ed陰ia玻a岸pp蘭li義ca脾ti壘on澇s爆in徐d舅at詳a辣ne柄tw斬or愧ks覺(jué).戲A租li眾st飯o旗f衫th英e言婦av皇ai銜la恭bl雁e饅co里mm蜻er叛ci挽al導(dǎo)t劑oo盞ls堂t血ha地t張su脖pp遞or丸t徐Vo枕IP元i公s禽li口st教ed悟i精n軟揉[1留,2隱].誼F符or繁t推he霉m銜os迎t漠pa父rt刪,螞th廟es宴e誘to舅ol腸s它us艦e患tw勻o儀co趟mm榴on缸泄ap洞pr獄oa馳ch尖es糊i跑n戶(hù)as破se丑ss發(fā)in翅g奏th蘇e籮de毒pl輔oy汁me起nt利o貿(mào)f故Vo國(guó)IP庭i腥nt喝o譽(yù)th吸e尊聲ex堡is棉ti妨ng屈n聚et罩wo延rk默.土On笑e煉ap蹦pr編oa也ch巧i葬s丙ba個(gè)se擱d宣on飲f縫ir餡st殼p摘er拐f(shuō)o性rm劇in妄g嚇桐ne撥tw月or赴k東me產(chǎn)as知ur盆em步en襲ts膨a贊nd丸t張he蟻n陜pr握ed揭ic安ti厲ng趟t鋼he趴n置et袍wo解rk膛陶re饅ad舌in荷es夾s醋fo之r遭su山pp視or徐ti逼ng禿V編oI刃P.順T聽(tīng)he詳p譜re喂di桶ct煎io謙n映of攀t剩he而延ne鬼tw柜or鴉k正re想ad玻in折es叛s族is鞋b放as釀ed策o蠢n僑as腸se員ss綠in干g壽th討e糟he筐al妻th毫o謎f單腰ne棟tw觸or炮k濃el鑒em痛en榜ts采.著Th愚e晝se每co認(rèn)nd掃a鐘pp雙ro趨ac娛h勇is鳥(niǎo)b逼as改ed知o閣n轉(zhuǎn)上in螺je話(huà)ct悠in傳g漏re怖al械V條oI遞P把tr及af舟fi烈c佳in處to份e埋xi債st泛in輪g拒ne乎tw沿or潔k盾an弱d兆匆me偽as禮ur母in宣g睜th耐e防re己su扁lt低in看g惰de賊la鄰y,搶j糧it套te龜r,轟a領(lǐng)nd孫l槽os泡s.峽未Ot勾he削r污th經(jīng)an伴t視he艱c吧os尾t突as雷so吉ci啊at掛ed賽w冊(cè)it評(píng)h加th燃e市co虎mm鄭er推ci冷al褲t暑oo嗽ls蘭,該劑no晚ne鏡o否f嚇th塵e泄co識(shí)mm駁er悟ci縣al礎(chǔ)t字oo山ls醋o(hù)保ff率er朋a訪(fǎng)c薦om團(tuán)pr烈eh悟en貧si盤(pán)ve運(yùn)迅ap路pr哈oa漸ch顆f窄or井s撓uc雞ce竿ss知fu幕l翼Vo狼IP兔d里ep像lo搜ym制en魯t.駱斃I驕n綿pa哥rt笛ic橋ul圾ar蒸,眼觀(guān)no礦ne外g達(dá)iv握es遇a覺(jué)ny陰p駕re特di宗ct慣io喚n急fo傭r幸th匯e董to捐ta千l靈nu蓄mb象er艇o壟f潮ca陷ll元s翠th齒at猶毒ca設(shè)n摧be川s脆up污po甩rt泳ed德b別y池th狼e甩ne拳tw縫or泰k求ta惠ki潔ng功i塘nt繪o斗ac債co技un薪t灶杜im米po續(xù)rt輝an肺t予de懸si雙gn家a合nd梁e公ng攤in肌ee衰ri頁(yè)ng幻f蔑ac左to盛rs討.挨Th先es奏e箏fa抬ct治or衡s侮塌in目cl屠ud難e斤Vo返IP父f鳥(niǎo)lo武w蘭an晨d量ca慣ll骨d悠is談tr蚊ib幕ut雖io滑n,以f縫ut梯ur遵e烘gr撥ow修th勞蓄ca禮pa鉤ci替ty信,篩pe吊rf鼠or誠(chéng)ma燭nc第e澇th覽re盡sh薯ol秤ds仁,斬im紹pa卡ct受o社f蠅Vo堡IP慶o蟻n奉干ex毅is各ti拌ng績(jī)n歌et彎wo啟rk沙s移er淹vi光ce污s絕an閃d膛ap姜pl預(yù)ic涌at奉io偵ns碧,朗an塵d嘴im禾pa寶ct混竹ba飼ck買(mǎi)gr胖ou閱nd于t患ra糟ff受ic多o飼n紗Vo椒IP振.錯(cuò)Th言is閉p拆ap聞er選a樸tt草em抹pt王s接to鞏a環(huán)dd崖re踏ss怠信th先os花e靈im樓po舟rt翼an穩(wěn)t殘fa累ct斗or蘇s宜an遍d救la奔yo玻ut掘a候c俯om襲pr映eh時(shí)en競(jìng)si斤ve叉驕me迅th貫od民ol唱og斑y投fo蛛r也a儀su海cc墳es兵sf皇ul塑d錘ep喊l(fā)o款ym而en危t豎of跟a壩ny扣m求ul專(zhuān)ti星me冰di易a度曠ap罩pl瘋ic考at誰(shuí)io像n鋒su伴ch冒a宇s炒Vo鼠IP偷a摘nd牽v展id圈eo印喊co尺nf鐮er鋼en閥ci統(tǒng)ng至.芳史Ho吳we側(cè)ve關(guān)r,醉t躬he探p竟ap大er刑f腿oc額us柴es夢(mèng)o漏n雄Vo帳IP燙a鹿s乘th討e靈ne凱w鉛se進(jìn)rv姓ic蛙e介of我員in露te波re白st佛t檔o婆be方d臉ep粥l(xiāng)o軌ye保d.然T擾he普p這ap愿er差a慮ls蘭o男co竟nt聞ai器ns材m種an袍y燥us姐ef摧ul遺騎en州gi絞ne攻er鞋in危g遙an吉d究de仇si牛gn糠g衣ui唯de裙li曉ne膛s,具a見(jiàn)nd動(dòng)d芬is給cu蘇ss集es牽m聰an株y燃肺pr照ac殖ti儀ca敏l廳is緞su棗es陜p慶er關(guān)ta攏in仁in慣g優(yōu)to直t擊he觀(guān)d是ep綁lo扯ym置en憲t落of瘡V脂oI然P.犧T首he辮se變存is拜su膀es鄙i草nc憑lu半de諷c涉ha岔ra心ct思er膽is而ti架cs情o火f雜Vo蛋IP鋤t蓬ra由ff龍ic嘉a體nd幸Q自oS尋璃re球qu絲ir放em福en掏ts擔(dān),愚Vo確IP銷(xiāo)f茂lo們w睡an書(shū)d嬌ca留ll地d夾is雷tr騾ib銀ut惱io須n,猜d籮ef廉in旦in荒g幟悠fu球tu植re牽g器ro亂wt麥h粱ca閉pa值ci依ty歸,鄰an溝d絨me溜as授ur雪em演en染t毒an胸d漆im訊pa臟ct企o似f舅王ba晉ck聞gr勸ou劑nd尖t北ra販ff村ic期.捆As士a仙c本as謀e卡st衡ud都y,鍵w瞇e狗il懼lu勝st房ra此te編h劍ow最o爪ur尸旱ap誦pr私oa譯ch融a熄nd菠g旺ui浩de肉li鐮ne槽s澇ca農(nóng)n母be葉a膚pp凳li承ed澡t圾o鑒a做ty居pi米ca攀l跡ne攻tw宗or風(fēng)k評(píng)古of表a辭s遵ma蘿ll號(hào)e昨nt之er交pr丑is市e.掙鴨Th亞e熱re渠st支o皺f盈th濫e喝pa賴(lài)pe鳴r滿(mǎn)is遠(yuǎn)o殲rg枕an攪iz螺ed對(duì)a慘s藥fo冬ll寇ow扛s.首S廟ec搶ti驚on脊2弟漸pr懷es賣(mài)en天ts甲a踏t繩yp囑ic燃al戀n遵et鑒wo嶼rk分t字op謠ol應(yīng)og江y赴of偶a續(xù)s隱ma戰(zhàn)ll鬧e圾nt迷er盈pr微is染e彩to寬晌be姐u勿se絮d斗as級(jí)a劉c廟as域e巴st洽ud液y桃fo網(wǎng)r恭de航pl納oy個(gè)in玉g考Vo蜂IP虜.擊Se林ct套io廁n誤3她趴ou癥tl御in秋es脫p均ra寺ct巷ic斯al國(guó)e奸ig嫁ht鄭-s擊te暑p棉me印th些od等ol撞og垃y寸to迅d患ep友lo榮y置假su蜂cc魯es纖sf針ul遼ly莫V咸oI昨P裙in膠d外at郊a包ne塞tw脂or待ks偶.他Ea逝ch蛋s龍te騾p伐is喇d監(jiān)es悅cr葵ib漆ed召朗in掃c然on債si抗de果ra爐bl蓄e釀de三ta贊il臘.零Se夠ct亂io吸n泥4錢(qián)de它sc察ri驅(qū)be偵s先im應(yīng)po段rt嫩an極t嚴(yán)de末si旬gn遼賀an灶d奔en埋gi簡(jiǎn)ne噸er鋒in啄g久de趕ci筐si乎on噸s擺to釘b衛(wèi)e莊ma肥de蒸b插as揪ed槍o護(hù)n查th麗e凡an左al承yt鼻ic販蹄an弱d么si噸mu曾la舊ti簽on辟s旁tu個(gè)di決es欣.括Se伙ct搭io犧n自5些co需nc督lu緊de紅s商th州e典st肥ud帖y克an蝦d炮利id贏(yíng)en叼ti榮fi痕es恥f睜ut沸ur壽e多wo催rk期.2ExistingnetworkFig.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.AllthelinksareswitchedEthernet100MbpsfullduplexexceptforthelinksforFloors1–3whicharesharedEthernet100Mbpshalfduplex.3Step-by-stepmethodologyFig.2showsaflowchartofamethodologyofeightstepsforasuccessfulVoIPdeployment.Thefirstfourstepsareindependentandcanbeperformedinparallel.Beforeembarkingontheanalysisandsimulationstudy,inSteps6and7,Step5mustbecarriedoutwhichrequiresanyearlyandnecessaryredimensioningormodificationstotheexistingnetwork.Asshown,bothSteps6and7canbedoneinparallel.Thefinalstepispilotdeployment.3.1.VoIPtrafficcharacteristics,requirements,andassumptionsForintroducinganewnetworkservicesuchasVoIP,onehastocharacterizefirstthenatureofitstraffic,QoSrequirements,andanyadditionalcomponentsordevices.Forsimplicity,weassumeapoint-to-pointconversationforallVoIPcallswithnocallconferencing.FordeployingVoIP,agatekeeperorCallManagernodehastobeaddedtothenetwork[3,4,5].Thegatekeepernodehandlessignalingforestablishing,terminating,andauthorizingconnectionsofallVoIPcalls.AlsoaVoIPgatewayisrequiredtohandleexternalcalls.AVoIPgatewayisresponsibleforconvertingVoIPcallsto/fromthePublicSwitchedTelephoneNetwork(PSTN).Asanengineeringanddesignissue,theplacementofthesenodesinthenetworkbecomescrucial.Wewilltacklethisissueindesignstep5.OtherhardwarerequirementsincludeaVoIPclientterminal,whichcanbeaseparateVoIPdevice,i.e.IPphones,oratypicalPCorworkstationthatisVoIP-enabled.AVoIP-enabledworkstationrunsVoIPsoftwaresuchasIPSoftPhones.Fig.3identifiestheend-to-endVoIPcomponentsfromsendertoreceiver[9].Thefirstcomponentistheencoderwhichperiodicallysamplestheoriginalvoicesignalandassignsafixednumberofbitstoeachsample,creatingaconstantbitratestream.Thetraditionalsample-basedencoderG.711usesPulseCodeModulation(PCM)togenerate8-bitsamplesevery0.125ms,leadingtoadatarateof64kbps.ThepacketizerfollowstheencoderandencapsulatesacertainnumberofspeechsamplesintopacketsandaddstheRTP,UDP,IP,andEthernetheaders.Thevoicepacketstravelthroughthedatanetwork.Animportantcomponentatthereceivingend,istheplaybackbufferwhosepurposeistoabsorbvariationsorjitterindelayandprovideasmoothplayout.Thenpacketsaredeliveredtothedepacketizerandeventuallytothedecoderwhichreconstructstheoriginalvoicesignal.WewillfollowthewidelyadoptedrecommendationsofH.323,G.711,andG.714standardsforVoIPQoSrequirements.Table1comparessomecommonlyusedITU-Tstandardcodecsandtheamountofone-waydelaythattheyimpose.ToaccountforupperlimitsandtomeetdesirablequalityrequirementaccordingtoITUrecommendationP.800,wewilladoptG.711ucodecstandardsfortherequireddelayandbandwidth.G.711uyieldsaround4.4MOSrating.MOS,MeanOpinionScore,isacommonlyusedVoIPperformancemetricgiveninascaleof1–5,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.In[22],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.3.1.3.OtherassumptionsThroughoutouranalysisandwork,weassumevoicecallsaresymmetricandnovoiceconferencingisimplemented.Wealsoignorethesignalingtrafficgeneratedbythegatekeeper.Webaseouranalysisanddesignontheworst-casescenarioforVoIPcalltraffic.Thesignalingtrafficinvolvingthegatekeeperismostlygeneratedpriortotheestablishmentofthevoicecallandwhenthecallisfinished.Thistrafficisrelativelysmallcomparedtotheactualvoicecalltraffic.Ingeneral,thegatekeepergeneratesnoorverylimitedsignalingtrafficthroughoutthedurationoftheVoIPcallforanalreadyestablishedon-goingcall.Inthispaper,wewillimplementnoQoSmechanismsthatcanenhancethequalityofpacketdeliveryinIPnetworks.AmyriadofQoSstandardsareavailableandcanbeenabledfornetworkelements.QoSstandardsmayincludeIEEE802.1p/Q,theIETF’sRSVP,andDiffServ.Analysisofimplementationcost,complexity,management,andbenefitmustbeweighedcarefullybeforeadoptingsuchQoSstandards.Thesestandardscanberecommendedwhenthecostforupgradingsomenetworkelementsishighandthenetworkresourcesarescarceandheavilyloaded.3.2.VoIPtrafficflowandcalldistributionKnowingthecurrenttelephonecallusageorvolumeoftheenterpriseisanimportantstepforasuccessfulVoIPdeployment.BeforeembarkingonfurtheranalysisorplanningphasesforaVoIPdeployment,collectingstatisticsaboutofthepresentcallvolumeandprofilesisessential.Sourcesofsuchinformationareorganization’sPBX,telephonerecordsandbills.Keycharacteristicsofexistingcallscanincludethenumberofcalls,numberofconcurrentcalls,time,duration,etc.Itisimportanttodeterminethelocationsofthecallendpoints,i.e.thesourcesanddestinations,aswellastheircorrespondingpathorflow.Thiswillaidinidentifyingthecalldistributionandthecallsmadeinternallyorexternally.Calldistributionmustincludepercentageofcallswithinandoutsideofafloor,building,department,ororganization.Asagoodcapacityplanningmeasure,itisrecommendedtobasetheVoIPcalldistributiononthebusyhourtrafficofphonecallsforthebusiestdayofaweekoramonth.ThiswillensuresupportofthecallsatalltimeswithhighQoSforallVoIPcalls.Whensuchcurrentstatisticsarecombinedwiththeprojectedextracalls,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.Firstisthemaximumtolerableend-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.1–5%packetlosswasgenerallyasserted.However,in[24]therequiredVoIPpacketlosswasconservativelysuggestedtobelessthan10.Amorepracticalpacketloss,basedonexperimentation,ofbelow1%wasrequiredin[22].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,networkmeasurementshavetobeperformed.Thisisacrucialstepasitcanpotentiallyaffectresultstobeusedinanalyticalstudyandsimulation.Thereareanumberoftoolsavailablecommerciallyandnoncommerciallytoperformnetworkmeasurements.Popularopen-sourcemeasurementtoolsincludeMRTG,STG,SNMPUtil,andGetIF[26].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.外文文獻(xiàn)譯文以太網(wǎng)網(wǎng)絡(luò)傳送調(diào)度：方法論和案例分析摘要對(duì)網(wǎng)絡(luò)數(shù)據(jù)研究者和設(shè)計(jì)師來(lái)說(shuō)，IP或語(yǔ)音IP調(diào)度是一項(xiàng)重大而艱巨的任務(wù)。本文概述的準(zhǔn)那么和循序漸進(jìn)的方法，解釋了怎樣在IP上成功調(diào)度傳送語(yǔ)音。該方法可用于評(píng)估的支持，并準(zhǔn)備用在現(xiàn)有的網(wǎng)絡(luò)。此前購(gòu)置并部署的網(wǎng)絡(luò)設(shè)備，這種方法預(yù)算出了在保證現(xiàn)有網(wǎng)絡(luò)效勞質(zhì)量要求和日后足夠擴(kuò)充能力根底上的網(wǎng)絡(luò)調(diào)用次數(shù)。作為一個(gè)研究的課題，我們把這種方法在一個(gè)典型的小型企業(yè)網(wǎng)上得到逐步應(yīng)用。我們運(yùn)用分析和模擬吞吐量和延遲區(qū)域。我們的分析基于排隊(duì)理論，并且OPNET用于模擬。理論分析和模擬結(jié)構(gòu)比擬一致。此外，本文談?wù)摿嗽S多設(shè)計(jì)和工程問(wèn)題。這些問(wèn)題包括網(wǎng)絡(luò)通信的特征和效勞質(zhì)量要求，網(wǎng)絡(luò)流程和呼叫分配，定義未來(lái)增長(zhǎng)容量，測(cè)定后臺(tái)通信的影響。關(guān)鍵詞：網(wǎng)絡(luò)設(shè)計(jì)，網(wǎng)絡(luò)管理，VoIP，性能評(píng)估，分析，模擬，OPNET1緒論最近大量的網(wǎng)絡(luò)調(diào)度在數(shù)據(jù)網(wǎng)中占有相當(dāng)?shù)谋壤?。其中大局部基于以太網(wǎng)和運(yùn)行IP協(xié)議。不少網(wǎng)絡(luò)管理員發(fā)現(xiàn)把語(yǔ)音和數(shù)據(jù)網(wǎng)合二為一非常有吸引力和具本錢(qián)效應(yīng)。這將更易于運(yùn)行、管理和維護(hù)。然而，人們應(yīng)該認(rèn)識(shí)到IP網(wǎng)絡(luò)目的是為了非實(shí)時(shí)應(yīng)用效勞；另一方面，網(wǎng)絡(luò)要求帶有低延遲、低抖動(dòng)、低丟包率和充足的帶寬。為了到達(dá)這一目標(biāo)，必須保證在現(xiàn)有或新的IP網(wǎng)絡(luò)中完成實(shí)時(shí)通信要求的高效網(wǎng)絡(luò)調(diào)度。當(dāng)在現(xiàn)有的網(wǎng)絡(luò)部署譬如VoIP這樣的新網(wǎng)絡(luò)效勞，許多網(wǎng)絡(luò)架構(gòu)師、經(jīng)理、方案師、設(shè)計(jì)師和工程師面臨著共同的目標(biāo)和挑戰(zhàn)。什么是網(wǎng)絡(luò)的效勞質(zhì)量要求？新的網(wǎng)絡(luò)負(fù)荷怎樣沖擊了當(dāng)今運(yùn)行中的網(wǎng)絡(luò)效勞和應(yīng)用的質(zhì)量？我們現(xiàn)有的網(wǎng)絡(luò)將支持網(wǎng)絡(luò)和將滿(mǎn)足標(biāo)準(zhǔn)的效勞質(zhì)量要求嗎？如果那樣，在過(guò)早升級(jí)任何現(xiàn)有的網(wǎng)絡(luò)硬件的零件前，能支持多少個(gè)的VoIP網(wǎng)絡(luò)？這些富挑戰(zhàn)性的問(wèn)題導(dǎo)致了用于測(cè)試網(wǎng)絡(luò)多媒體數(shù)據(jù)應(yīng)用性能的商業(yè)工具的開(kāi)展。支持網(wǎng)絡(luò)的商用工具名單如表[1,2]。很大程度上，這些工具使用兩種共同的方法把VoIP部署入現(xiàn)有的網(wǎng)絡(luò)。一種方法根據(jù)第一次執(zhí)行的網(wǎng)絡(luò)測(cè)量和然后預(yù)測(cè)支持VoIP的網(wǎng)絡(luò)應(yīng)該就緒情況。預(yù)測(cè)的網(wǎng)絡(luò)情況是根據(jù)網(wǎng)絡(luò)要素來(lái)估計(jì)的。第二種是根據(jù)參加到現(xiàn)有網(wǎng)絡(luò)中VoIP的實(shí)時(shí)通信信息，然后測(cè)出延時(shí)時(shí)間、時(shí)基誤差和丟包率。除相關(guān)的商業(yè)工具費(fèi)用外，沒(méi)有其它工具能夠提供全面兼容的成功網(wǎng)絡(luò)調(diào)度方法。特別是，無(wú)任何一個(gè)預(yù)測(cè)能給出網(wǎng)絡(luò)可以支持的呼叫次數(shù)已提到設(shè)計(jì)和工程的議事日程上來(lái)。這些因素包括網(wǎng)絡(luò)流程和呼叫分配、今后增長(zhǎng)容量、性能極限、VoIP對(duì)現(xiàn)有網(wǎng)絡(luò)效勞和應(yīng)用以及后臺(tái)通信能力的沖擊。本文嘗試研究這些重要因素，規(guī)劃出一個(gè)支持像網(wǎng)絡(luò)和視頻會(huì)議系統(tǒng)的全面可行方法。無(wú)論如何，本文集中論述了網(wǎng)絡(luò)效勞調(diào)度新方法。文章同樣包含了許多工程和設(shè)計(jì)指南，同時(shí)也討論了許多與網(wǎng)絡(luò)相關(guān)的實(shí)際問(wèn)題。這些問(wèn)題包括網(wǎng)絡(luò)的通信和效勞質(zhì)量要求，網(wǎng)絡(luò)數(shù)據(jù)流向和呼叫分配，定義今后的增長(zhǎng)容量以及我們的方法和綱領(lǐng)怎樣應(yīng)用在像小型的企業(yè)網(wǎng)這樣的典型網(wǎng)絡(luò)中。其余局部作如下安排：第二局部論述了小型企業(yè)網(wǎng)的典型網(wǎng)絡(luò)拓?fù)淙绾卧诰W(wǎng)絡(luò)中實(shí)現(xiàn)調(diào)度。第三局部大致描述了網(wǎng)絡(luò)數(shù)據(jù)網(wǎng)調(diào)度實(shí)用的八個(gè)步驟。每一步驟都有詳細(xì)的說(shuō)明。第四局部介紹了基于分析和仿真研究得出的重要設(shè)計(jì)結(jié)論和工程結(jié)論。第五局部談到了今后研究還需做的具體工作。2現(xiàn)有的網(wǎng)絡(luò)互聯(lián)網(wǎng)數(shù)據(jù)庫(kù)打印機(jī)效勞器一個(gè)小型企業(yè)網(wǎng)的邏輯圖路由器交換機(jī)1交換機(jī)2工作組效勞互聯(lián)網(wǎng)數(shù)據(jù)庫(kù)打印機(jī)效勞器一個(gè)小型企業(yè)網(wǎng)的邏輯圖路由器交換機(jī)1交換機(jī)2工作組效勞器文件效勞器層2圖1一個(gè)小型企業(yè)網(wǎng)的邏輯圖圖1是在大廈中一個(gè)的小型企業(yè)網(wǎng)的典型網(wǎng)絡(luò)拓?fù)鋱D。圖中所示真實(shí)網(wǎng)絡(luò)情況僅用于研究目的；然而，我們文中提出的原理、框架和概念等工作成果將會(huì)更容易被大型網(wǎng)絡(luò)采納。這些網(wǎng)絡(luò)都是通過(guò)一個(gè)路由連接的兩個(gè)第二層以太網(wǎng)交換機(jī)。路由是卡西歐2621，交換機(jī)是3ComSuperstack3300。交換機(jī)1連接第一、二層和兩個(gè)效勞器；交換機(jī)2連接第三層和四個(gè)效勞器。每一層的本地局域網(wǎng)就是一個(gè)連接有個(gè)人電腦的工作組和打印機(jī)效勞器的共享以太網(wǎng)。網(wǎng)絡(luò)利用虛擬局域網(wǎng)來(lái)隔離播送和組播擁塞?？傆?jì)有五個(gè)局域網(wǎng)存在。所有虛擬局域網(wǎng)基于端口劃分。交換機(jī)一配置三個(gè)虛擬局域網(wǎng)。虛擬局域網(wǎng)一包括數(shù)據(jù)庫(kù)和文件效勞器。虛擬局域網(wǎng)二包括層一。虛擬局域網(wǎng)三包括層二。另一方面，交換機(jī)二配置為含有兩個(gè)虛擬局域網(wǎng)。虛擬局域網(wǎng)四包括郵件效勞器、超文本協(xié)議、網(wǎng)頁(yè)和緩存代理以及防火墻。虛擬局域網(wǎng)五包括層三。除了層1-3是100Mbps的半雙工以太網(wǎng)其余鏈接都是100Mbps速率全雙工的以太網(wǎng)。3步進(jìn)的方法論說(shuō)明方法步驟的流程圖模擬前面網(wǎng)絡(luò)評(píng)估和更改前端調(diào)度分析說(shuō)明方法步驟的流程圖模擬前面網(wǎng)絡(luò)評(píng)估和更改前端調(diào)度分析圖SEQ圖表\*ARABIC1說(shuō)明方法步驟的流程圖圖2表示了一個(gè)成功的網(wǎng)絡(luò)調(diào)度八步驟流程圖。前面四步是獨(dú)立的，可以并行運(yùn)行。在封裝分析和模擬研究前，作為前面網(wǎng)絡(luò)評(píng)估和更改的第5步必須先執(zhí)行。如圖，步驟6和7可以并行執(zhí)行。最后一步是前端調(diào)度。3.1網(wǎng)絡(luò)通信特征、要求和假想要介紹像網(wǎng)絡(luò)這樣的效勞，首先要概括出它通信的本質(zhì)、效勞質(zhì)量要求和其它原因或設(shè)備問(wèn)題。出于簡(jiǎn)單考慮，我們假定在一個(gè)沒(méi)有呼叫協(xié)商的點(diǎn)對(duì)點(diǎn)對(duì)話(huà)網(wǎng)絡(luò)呼叫。對(duì)網(wǎng)絡(luò)調(diào)度來(lái)說(shuō)，網(wǎng)絡(luò)節(jié)點(diǎn)或呼叫管理器節(jié)點(diǎn)必須添加到網(wǎng)絡(luò)[3,4,5]。網(wǎng)絡(luò)節(jié)點(diǎn)處理用于建立、終止和受權(quán)所有網(wǎng)絡(luò)呼叫的連接，同時(shí)也要處理外部的呼叫。網(wǎng)絡(luò)負(fù)責(zé)轉(zhuǎn)換網(wǎng)絡(luò)呼叫到公共交換網(wǎng)(或反向)。作為一個(gè)工程和設(shè)計(jì)課題，如何放置這些網(wǎng)絡(luò)中的節(jié)點(diǎn)變得至關(guān)緊要。在步驟5中我們會(huì)談到如何處理這個(gè)問(wèn)題。其它硬件要求包括網(wǎng)絡(luò)客戶(hù)終端(例如網(wǎng)絡(luò)機(jī)或典型的個(gè)人電腦又或是含有激活網(wǎng)絡(luò)的工作站)可以是獨(dú)立的設(shè)備。激活網(wǎng)絡(luò)的工作站運(yùn)行著像IP這樣的軟件。編碼解碼解包封裝編碼解碼解包封裝圖SEQ圖表\*ARABIC2網(wǎng)絡(luò)端到端器件圖3表示了一個(gè)端對(duì)端網(wǎng)絡(luò)的發(fā)送和接收器件。第一個(gè)器件是編碼器，它用于周期性采集原始聲音信號(hào)和分配固定的比特位給每一個(gè)樣本，產(chǎn)生一個(gè)常速率的比特流。傳統(tǒng)的樣本采集編碼器G.711利用脈沖編碼調(diào)制來(lái)產(chǎn)生每0.125ms的8位比特的樣本，從而產(chǎn)生64kbps的數(shù)據(jù)速率。壓縮包隨著編碼器壓入一定數(shù)量的語(yǔ)音標(biāo)本到信息包，然后參加實(shí)時(shí)位置、用戶(hù)數(shù)據(jù)報(bào)、網(wǎng)際協(xié)議和以太網(wǎng)報(bào)頭等信息。語(yǔ)音信號(hào)包隨之流向數(shù)據(jù)網(wǎng)絡(luò)。在接收端有一個(gè)重要的元件，它是為了吸收變調(diào)的聲音和抖動(dòng)失真的錄音回放緩沖器，同時(shí)也是為了提供平滑過(guò)度的釋放。然后數(shù)據(jù)包被傳送至解壓器，最終復(fù)原成原始聲音信號(hào)。我們會(huì)采用大量被推薦網(wǎng)絡(luò)的H.323、G.711、和G.714效勞質(zhì)量保證標(biāo)準(zhǔn)。表1標(biāo)準(zhǔn)ITU-T編碼器和其默認(rèn)值A(chǔ)/D轉(zhuǎn)換延遲標(biāo)準(zhǔn)ITU-T編碼器和其默認(rèn)值A(chǔ)/D轉(zhuǎn)換延遲標(biāo)準(zhǔn)ITU-T編碼器和其默認(rèn)值表1對(duì)使用國(guó)際電信聯(lián)盟標(biāo)準(zhǔn)的多媒體數(shù)字信號(hào)編解碼器和大量強(qiáng)制要求的單聲道的延遲標(biāo)準(zhǔn)作了一個(gè)比擬。為了到達(dá)上層限制要求和滿(mǎn)足國(guó)際電信聯(lián)盟推薦的質(zhì)量要求標(biāo)準(zhǔn)P.800,我們采用G.711u編解碼器標(biāo)準(zhǔn)來(lái)滿(mǎn)足延時(shí)和帶寬要求。G.711u產(chǎn)生4.4等級(jí)MOS。MOS，意思為一種經(jīng)常用在網(wǎng)絡(luò)性能指標(biāo)中的評(píng)價(jià)標(biāo)準(zhǔn)，有1-5個(gè)等級(jí)，第5級(jí)為最好。然而，為了折衷小小的質(zhì)量問(wèn)題，最有可能執(zhí)行每次呼叫需求帶寬更少、相關(guān)程度稍高、更能接受的端到端的延遲時(shí)間的ITU-T編解碼器的不同標(biāo)準(zhǔn)。這將通過(guò)用密集的、靜默壓縮的、隱蔽的小包喪失數(shù)、隊(duì)列管理技術(shù)和把超過(guò)一個(gè)聲音信號(hào)包封裝在單個(gè)以太網(wǎng)幀中。3.1.1單聲道的端到端延遲圖3闡述了典型語(yǔ)音包延遲的緣由。這端到端的延遲有時(shí)歸結(jié)于M2E或口到耳的延遲。G.714提出了單聲道最大總數(shù)不超過(guò)150ms的網(wǎng)絡(luò)端到端應(yīng)用。在[22]提到不超過(guò)200ms的延遲是可以接受的。我們能夠通過(guò)以下最少三種起作用的元件降低延遲：(i)發(fā)送端的編碼、壓縮和解壓延遲；(ii)傳播、運(yùn)輸和網(wǎng)絡(luò)中的排隊(duì)延遲；(iii)接收端的緩沖、解壓、解碼、錄音重放延遲。3.1.2單個(gè)呼叫的帶寬單個(gè)呼叫的帶寬要求，一個(gè)參數(shù)就是64kbps。G.711多媒體編解碼器每個(gè)語(yǔ)音包20ms的采樣。因此，每秒必需有50個(gè)這樣的數(shù)據(jù)包。每個(gè)包中包含160語(yǔ)音樣本目的是為了到達(dá)8000每秒的采樣率。每個(gè)包通過(guò)單個(gè)以太網(wǎng)幀傳送。每個(gè)包有160字節(jié)大小，再加上協(xié)議各層的報(bào)頭信息。這些報(bào)頭包括12+8+20+26對(duì)應(yīng)大小的RTP+UDP+IP+Ethernet信息。因此，總共有226字節(jié)(或1808位)的信息需要每秒傳送50次，或一次傳送90.4kbps。對(duì)于