An Analytical Tool to Assess Readiness of Existing Networks for Deploying IP Telephony

Transcription

1 An Analytcal Tool to Assess Readness of Exstng Networks for Deployng IP Telepony K. Sala M. Almasar Department of Informaton and Computer Scence Kng Fad Unversty of Petroleum and Mnerals Daran 31261, Saud Araba Emal: {sala, Abstract Deployng IP telepony or voce over IP (VoIP) s a major and callengng task. Ts paper descrbes an analytcal approac and tool to assess te readness of exstng IP networks for te deployment of VoIP. Te analytcal approac utlzes queueng network analyss and nvestgates two key performance bounds for VoIP: delay and bandwdt. Te analytcal tool s GUI-based and as an engne tat automates te analytcal approac. Te engne determnes te number of VoIP calls tat can be sustaned by a gven generc network wle satsfyng VoIP QoS requrements and leavng adequate capacty for future growt. As a case study, te paper llustrates ow te analytcal tool can assess te readness to deploy VoIP for a typcal network of a small enterprse. 1 Introducton Wen deployng a new network servce suc as VoIP over exstng network, many network arctects, managers, planners, desgners, and engneers are faced wt common strategc, and sometmes callengng, questons. Wat are te QoS requrements for VoIP? Wll my exstng network support VoIP and satsfy te standardzed QoS requrements? If so, ow many VoIP calls can te network support before upgradng prematurely any part of te exstng network ardware? Tese callengng questons ave led to te development of some commercal tools for testng te performance of multmeda applcatons n data networks. A lst of te avalable commercal tools tat support VoIP s lsted n [1,2]. For te most part, tese tools use two common approaces n assessng te deployment of VoIP nto te exstng network. One approac s based on frst performng network measurements and ten predctng te network readness for supportng VoIP. Te predcton of te network readness s based on assessng te ealt of network elements. Te second approac s based on njectng real VoIP traffc nto exstng network and measurng te resultng delay, jtter, and loss. Oter tan te cost assocated wt te commercal tools, none of te commercal tools gves any predcton for te total number of calls tat can be supported by an exstng network wen consderng mportant desgn and engneerng factors. Tese factors nclude VoIP flow and call dstrbuton, future growt capacty, performance tresolds, and mpact background traffc on VoIP. Ts paper attempts to address tose mportant factors utlzng an analytcal approac based on queueng networks. Te approac utlzes queueng network analyss and nvestgates two key performance bounds for VoIP: delay and bandwdt. Te paper also descrbes a GUI-based analytcal tool tat mplements te analytcal approac to compute te maxmum number of VoIP calls tat can be sustaned by a gven generc network wle satsfyng VoIP QoS requrements and leavng adequate capacty for future growt. As a case study, te paper llustrates ow te presented analytcal tool can assess te readness to deploy VoIP for a typcal network of a small enterprse. Te rest of te paper s organzed as follows. Secton 2 presents an analytcal approac to assess te readness of IP telepony. Secton 3 descrbes a GUI-based analytcal tool tat as an engne tat mplements our proposed analytcal approac. Secton 3 also gves an example of a typcal network topology of a small enterprse to be used as a case study for deployng VoIP. Fnally, Secton 4 concludes te study and dentfes future work. 2 Analytcal Approac VoIP s bounded by two mportant metrcs. Frst s te avalable bandwdt. Second s te end-to-end delay. Te actual number of VoIP calls tat te network can sustan and support s bounded by tose two metrcs. Dependng on te network under study, eter te avalable bandwdt or delay can be te key domnant factor n determnng te number of calls tat can be supported.

2 Our analytcal approac consders mportant factors as background traffc, traffc flow, call dstrbuton and growt factor. For background traffc, network measurements must be performed to determne te traffc rates n bps (bts per second) and pps (packets per second) for lnks drectly connected to te router and swtces. Traffc flow as to do wt te pat tat a sesson travels troug. Sesson dstrbuton as to do wt te percentage of sessons to be establsed wtn and outsde of a floor, buldng, or department. In order to allow for future growt, we wll consder a 25% growt factor for all network elements ncludng router, swtces, and lnks. 2.1 Bandwdt Bottleneck Analyss Te requred bandwdt for a voce call, one drecton, s 50 pps or 90.4 kbps. G.711 codec samples 20ms of voce per packet. Terefore, 50 suc packets need to be transmtted per second. Eac packet contans 160 voce samples n order to gve 8000 samples per second. Eac packet s sent n one Eternet frame. Wt every packet of sze 160 bytes, eaders of addtonal protocol layers are added. Tese eaders nclude RTP + UDP + IP + Eternet wt preamble of szes , respectvely. Terefore, a total of 226 bytes, or 1808 bts, needs to be transmtted 50 tmes per second, or 90.4 kbps, n one drecton. For bot drectons, te requred bandwdt for a sngle call s 100 pps or kbps assumng a symmetrc flow. Bandwdt bottleneck analyss s an mportant step to dentfy te network element, weter t s a node or a lnk, tat puts a lmt on ow many VoIP calls can be supported by te exstng network. For any pat tat as N network nodes and lnks, te bottleneck network element s te node or lnk tat as te mnmum avalable bandwdt. Ts mnmum avalable bandwdt can be defned as follows A = mn A, = 1,..., N and A = ( 1 u ) C, were C s te capacty of network element and u s ts current utlzaton. Te capacty C s te maxmum possble transfer or processng rate. Terefore te teoretcal maxmum number of calls tat can be supported by a network element E can be expressed n terms of A as A ( 1 growt ) MaxCalls =, (1) CallBW were growt s te growt factor of network element E, and takes a value from 0 to 1. CallBW s te VoIP bandwdt for a sngle call mposed on E. In order to fnd te bottleneck network element tat lmts te total number of VoIP calls, one as to compute te maxmum number of calls tat can be supported by eac network element, as n equaton (1), and te percentage of VoIP traffc flow passng by ts element. Te percentage of VoIP traffc flow for E, denoted as flow, can be found by examnng te dstrbuton of te calls. Te total number of VoIP calls tat can be supported by a network can be expressed as MaxCalls mn. 1,..., TotalCalls Supported = = N (2) flow 2.2 Delay Analyss In order to aceve a natural voce conversaton, te endto-end upper bound delay (sometmes termed latency) for a voce packet sould be kept to mnmal. Essentally, suc a delay can broken nto at least tree contrbutng components, wc are as follows () voce samplng or frame grabbng, encodng, compresson, and packetzaton delay at te sender () propagaton, transmsson and queung delay n te network and () bufferng, decompresson, depacketzaton, decodng, and playback delay at te recever. Accordng to recommendatons by ITU [3], wen delays are less tan 150 ms, most nteractve applcatons, bot speec and non-speec, wll experence essentally transparent nteractvty. For voce, te end-toend delay s sometmes referred to by M2E or Mout-to-Ear delay. Terefore, We must always ascertan tat te worst-case end-to-end delay for all te calls must be less tan 150 ms. It sould be kept n mnd tat our goal s to determne te network capacty for VoIP,.e. te maxmum number of calls tat exstng network can support wle mantanng VoIP QoS. Ts can be done by addng calls ncrementally to te network wle montorng te tresold or bound for VoIP delay. Wen te end-to-end delay, ncludng network delay, becomes larger tan 150 ms, te maxmum number of calls can ten be known. Tere are tree sources of delay for a VoIP stream: sender, network, and recever. An expresson s gven n [4] to compute te end-to-end delay D for a VoIP flow n one drecton from sender to recever. D = D + ( T + Q + P ) + D, pack Pat were D pack s te delay due to packetzaton at te source. At te source, tere s also Denc and D process. Denc s te encoder delay of convertng A/D sgnal nto samples. D process s te PC of IP pone processng tat ncludes encapsulaton. In G.711, D pack and D enc, are 20 ms and 1ms, respectvely. Hence, t s approprate for our analyss to ave a fxed delay of 25 ms beng ntroduced at te play

3 Dplay source, assumng worst case stuaton. s te playback delay at te recever, ncludng jtter buffer delay. Te jtter delay s at most 2 packets,.e. 40ms. If te recever s delay of D process s added, we obtan a total fxed delay of 45 ms at te recever. T + Q + P s te sum of delays ncurred n te packet network due to transmsson, queung, and propagaton gong troug eac op n te pat from te sender to te recever. Te propagaton delay P s typcally gnored for traffc wtn a LAN, but not for a WAN. For transmsson delay T and queueng delay Q we apply queueng teory. Hence te delay to be ntroduced by te network, expressed as ( T + ), sould not exceed ( ) or 80 ms. Q Pat We utlze queueng analyss to approxmate and determne te maxmum number of calls tat te exstng network can support wle mantanng a delay of less tan 80ms. In order to fnd te network delay, we utlze te prncples of Jackson teorem for analyzng queueng networks. In partcular, we use te approxmaton metod of analyzng queueng networks by decomposton dscussed n [5]. In ts metod, te arrval rate s assumed to be Posson and te servce tmes of network elements are exponentally dstrbuted. Analyss by decomposton s summarzed n frst solatng te queueng network nto subsystems, e.g., sngle queueng node. Next, analyzng eac subsystem separately, consderng ts own network surroundngs of arrvals and departures. Ten, fndng te average delay for eac ndvdual queueng subsystem. And fnally, aggregatng all te delays of queueng subsystems to fnd te average total end-to-end network delay. Te queueng models of network elements for lnk, swtc, and router are presented n [6]. In order to determne te maxmum number of calls tat can be supported by an exstng network wle mantanng VoIP delay constrant, we developed te followng algortm tat bascally determnes network capacty n terms of VoIP calls. Ts algortm s essentally part of te analytcal tool engne for calculatng number of calls based on delay bound. Calls are added teratvely untl te worst-case network delay of 80 ms as reaced. Te algortm can be descrbed n te followng steps: () Intally, no calls are ntroduced and te only traffc n te network s te background traffc. () A new call s added, accordng to te call dstrbuton. () For eac network element, λ = λ VoIP + λbg s computed. ( λ VoIP s te total added new traffc from a sngle VoIP n pps, and λ bg s te background traffc n pps). λ bg s known for eac element; owever, λ VoIP can get affected by (v) (v) (v) (v) ntroducng a new call dependng on te call traffc flow,.e. weter or not te new call flow passes troug te network element. For eac network element, te average delay of a VoIP packet s computed. Te end-to-end delay s computed by summng up all te delays of step (v) encountered for eac possble VoIP flow. Ts ncludes all external and nternal flows, wt nternal flows consstng of ntra-floor and nterfloor. Te maxmum network delay of all possble flows s determned. If te maxmum network delay s less tan 80 ms, ten te maxmum number of calls as not been reaced. Terefore a new call can be added, and ence go to step (). If not, te maxmum delay as been reaced. Terefore te number of VoIP calls bounded by te delay s one less tan te last call addton. 3 Analytcal Tool In order to make use of te analytcal approac presented n Secton 2 and to ease te mplementaton of te algortms of trougput and delay analyss for a gven generc network of nterest, an analytcal tool 1 as been developed n C#. Te tool s GUI-based and ts engne mplements te analytcal approac. Te tool takes as an nput several parameters and confguratons. As sown n Fgure 1, several tab optons are avalable. Te tab of Nodes & Floors allows te confguraton of nodes (swtces, routers, or servers) and ter respectve capacty and locaton. Lnks allows for nterconnectng network nodes to form te network topology. Eac lnk capacty and background traffc can be confgured. Call Dstrbuton allows confguraton of call dstrbuton per flow n percentage. Te call flows between floors can be confgured usng Pat. Oter settngs and confguratons suc as percentage of growt, bandwdt, packet sze, ost and network latences can be confgured under VoIP Settngs tab. Te results of maxmum calls to be supported based on trougput and delay bounds are reported separately under Analyss opton. Te tool as useful pull-down menus to save and restore confguratons from a fle. Also under te Tools opton one can vew and verfy te network topology. 1 Te tool s freeware and can be downloaded from ttp:// zp.

4 number of voce calls to be supported. Terefore 307 voce calls can be supported. 4 Concludng Remarks Fgure 1. Analytcal tool optons In order to llustrate te tool s optons furter we gve an example. Fgure 2 llustrates a typcal network topology of a small enterprse resdng n a g-rse buldng. Ts topology was also reported n [6] and used ere for comparson purposes. We wll also use te same parameter values for background traffc, traffc flow, and call dstrbuton as tose reported n [6]. Accordng to [7] and [8], te capacty C for te router or te swtc, s 25,000pps and 1.3M pps, respectvely. All lnks are swtced full-duplex Fast (100Mbps). Te network sows te added VoIP nodes of an H.323 gatekeeper and gateway. Te gatekeeper node andles sgnalng for establsng, termnatng, and autorzng connectons of voce calls. Te VoIP gateway s responsble for convertng VoIP calls to/from te Publc Swtced Telepone Network (PSTN). Oter ardware requrements nclude a VoIP clent termnal, wc can be a separate VoIP devce,.e., IP pones, or a typcal PC or workstaton tat s VoIP-enabled. Fgure 3 sows te correspondng network dagram produced by te analytcal tool. It can be noted tat tere was no need to ave separate nodes for floor s PCs and Servers. However, ter aggregate background traffc was taken nto account. We also gnore te sgnalng traffc generated by te gatekeeper. We base our analyss and desgn on te worstcase scenaro for VoIP call traffc. Te sgnalng traffc nvolvng te gatekeeper s only generated pror to te establsment of te voce call and wen te call s fnsed. Ts traffc s relatvely lmted and small compared to te actual voce call traffc. In general, te gatekeeper generates no sgnalng traffc trougout te duraton of te VoIP call for an already establsed on-gong call. Fgure 4 (Left) sows te number of calls tat can be supported for selected nodes and lnks. It s sown tat te router s te bottleneck wt 314 voce calls to support. Fgure 4 (Rgt) sows tat network can support 307 voce calls wt less tan 80 ms (actually sown 74 ms) of network delay. So one can conclude tat network delay (for ts partcular network topology) s te more domnant parameter n determnng te Te paper presented an analytcal approac and a GUIbased analytcal tool to assess network readness and support for VoIP. Te approac can elp network researcers and desgners to determne quckly and easly ow well VoIP wll perform on a network pror to deployment. Pror to te purcase and deployment of VoIP equpment, t s possble to predct te number of VoIP calls tat can be sustaned by te network wle satsfyng QoS requrements of all exstng and new network servces and leavng enoug capacty for future growt. Te results obtaned by te analytcal tool are very muc n lne wt reported results of prevous work reported n [6]. Te results of [6] were based on analytcal results obtaned usng Matlab and OPNET smulaton. In ts paper, only peer-topeer voce calls were consdered. As a future work, one can consder mplementng mportant VoIP optons suc as VoIP conferencng and messagng. Acknowledgements Te autor acknowledges te support of Kng Fad Unversty of Petroleum and Mnerals n te development of ts work. Specal tanks go to Mr. A. Alkoradly and Mr. K. El-Badaw for ter valuable dscussons, comments. References [1] M.Bearden,L.Denby,B.Karacal,J.Meloce,andD.T.Stott, Assessng Network Readness for IP Telepony, Proceedngs of IEEE Internatonal Conference on Communcatons, ICC02, vol.4, 2002, pp [2] B. Karacal, L. Denby, and J. Melce, Scalable Network Assessment for IP Telepony, Proceedngs of IEEE Internatonal Conference on Communcatons (ICC04), Pars, June 2004, pp [3] Recommendaton G.114, One-Way Transmsson Tme, ITU, [4] M. Karam and F. Tobag, Analyss of delay and delay jtter of voce traffc n te Internet, Computer Networks Magazne, vol. 40, no. 6, December 2002, pp (2002) [5] K. M. Candy and C. H. Sauer, Approxmate metods for analyzng queueng network models of computng systems, Journal of ACM Computng Surveys, vol. 10, no. 3, September 1978, pp ` [6] Sala, K., On te Deployment of VoIP n Eternet Networks: Metodology and Case Study, Internatonal Journal of Computer Communcatons, Elsever Scence, (In Press). [7] Csco Systems Inc., Csco 2621 Modular Access Router Securty Polcy, 2001, ttp:// 2600/secure/2621rect.pdf [8] 3Com, 3Com Networkng Product Gude, Aprl 2004, ttp://

5 Fgure 2. Network topology wt added VoIP Components Fgure 3. Correspondng network dagram generated by analytcal tool Fgure 4. Trougput and delay analyss report