OPNET Simulation of SIP Based IP Telephony over MPLS Network

Transcription

1 OPNET Smulaton of Based IP Telephony over MPLS Network Bo Rong, Jacques Lebeau, Mara Bennan, Ahmed K. Elhakeem, and Mchel Kadoch LAGRIT, Department of Electrcal Engneerng, Ecole de technologe supereure, Unverste du Quebec Montreal, Quebec, Canada, HC 1K E-mal: {bo.rong, {mbennan, Department of Electrcal and Computer Engneerng, Concorda Unversty Montreal, Quebec, Canada, HG 1M8 E-mal: Abstract The next generaton communcaton system wll provde hgh qualty multmeda servce n a more flexble and ntellgent manner. In ths paper, we propose a new over MPLS archtecture to acheve ths goal. To ntegrate protocol wth the traffc engneerng functon of MPLS seamlessly and facltate call setup, the -MPLS traffc aggregaton server (TA server) s hghlghted n ths new archtecture. Furthermore, the call admsson and bandwdth renegotaton algorthms runnng on the TA server are nvestgated carefully. We rely on OPNET smulaton to assess the performance of our archtecture and the capablty of dfferent call admsson and bandwdth re-negotaton algorthms. The smulaton results show that the algorthm of TBCA-BP s a sutable canddate for accomplshng the call admsson and bandwdth re-negotaton task due to ts satsfyng performance, and our archtecture s able to shorten the call setup delay greatly by usng the TA server. Introducton IP telephony s becomng one of the most promsng research areas today, because both Internet Sevce Provders (ISP) and tradtonal telephony companes can beneft from ths technology. There are two hghly concerned ssues on usng IP to carry audo/vdeo traffc. The frst one s the sgnalng protocol to control a call; the second one s how IP provdes real-tme audo/vdeo applcatons wth QoS guaranteed servce. As for the frst ssue, Sesson Intaton Protocol () s proposed by Internet Engneerng Task Force (IETF) as a standard for IP telephony [1,2,]. In the panorama of protocols for IP telephony, s not the only possble choce. For nstance, ITU-T H.2 s an alternatve canddate. However, has recently ganed the ncreasng nterest from unverstes, standardzaton organzatons and companes. One of the man drvers for ths fact s the decson of GPP (Thrd-Generaton Partnershp Project) that, n the year 2, was selected as the call control protocol for G IP-based moble s. As for the second ssue, Mult-protocol Label Swtchng (MPLS) s suggested as an apt swtchng technology for future core s [4,5]. In MPLS, the packets are labeled at the edge of the and then routed through the based on smple labels. Ths enables explct routng and dfferentated treatment of packets whle keepng the core routers smple. Despte the fact that MPLS development started wth goal to expedte packet forwardng, the man beneft from MPLS n current envronment s from ts traffc engneerng capabltes ncludng QoS guarantee, effcent usage of resources, reslence, and economy [,7]. In fact, the traffc engneerng capabltes make MPLS a good choce for carryng sgnaled audo/vdeo traffcs. Although the archtecture of over MPLS has been dscussed n [8,], accordng to our study, drectly usng protocol over traffc engneerng (TE) enabled MPLS as prevous lterature suggested can cause a long delay when the call connecton s set up. We reach ths concluson by theoretcal analyss and OPNET smulaton. In the TE enabled MPLS, when a new call request comes, usually CR-LDP or RSVP-TE wll be employed to set up a correspondng LSP dynamcally. Our study shows that the dynamc LSP setup by CR-LDP or RSVP-TE can contrbute a lot to the whole call setup delay n TE enabled MPLS. For the above reason, we propose a new archtecture of over MPLS to solve ths problem. As a crucal part of our archtecture, the -MPLS traffc aggregaton server (TA server) s hghlghted n ths paper. The TA servers exchange traffc engneerng sgnalng wth MPLS on behalf of a cluster of clents. As a result, the call setup delay n MPLS s decreased greatly. The rest of the paper s organzed as follows. Frstly, we dscuss the call setup delay problem exsted n over MPLS technology n Secton 2. Then, to solve ths problem, we propose a new over MPLS archtecture n Secton. Furthermore, the call admsson and bandwdth re-negotaton algorthms runnng on TA servers are suggested n Secton 4, and the OPNET smulaton results of these algorthms are presented n Secton 5. In the end, Secton summarzes our results. The Call Setup Delay Problem n over MPLS Technology The protocol has been defned by the IETF as a sgnalng protocol to ntate voce, vdeo, and multmeda sessons, and t s an mportant canddate for call setup sgnalng n IP telephony. s a very flexble protocol, because t can easly work together wth QoS reservaton and/or admsson control mechansms. 1

2 Mult-protocol Label Swtchng (MPLS) s a new technology for IP core. It does not replace IP routng, but work together wth exstng and future routng protocols to provde very hgh-speed data forwardng and guarantee QoS requrements of dfferent users. Many of today s dscussons regardng MPLS revolve around traffc engneerng. Traffc engneerng s amed to make the best use of resources across entre by dstrbutng traffc over dfferent paths. Traffc engneerng offers VoIP provders the chance of utlzng resources fully and provdng the QoS guaranteed servce n a busy effectvely. Routng Protocols Profle attrbutes Applcaton attrbutes It s a good dea to deploy based IP telephony n MPLS [8,]. However, accordng to our study, drectly usng protocol over TE enabled MPLS as prevous lterature suggested can cause an unbearable long call setup delay. In TE enabled MPLS, when a new call request comes, usually CR-LDP or RSVP-TE wll be employed to set up a correspondng LSP dynamcally. Our study shows that the dynamc LSP setup can contrbute a lot to the whole call setup delay n TE enabled MPLS. If we use LDP nstead of CR-LDP or RSVP-TE n MPLS, the call setup delay s short and acceptable. Nevertheless, LDP cannot support traffc engneerng functon n MPLS, because t s only sutable for hop-by-hop label dstrbuton and always selects the same physcal path as conventonal IP routng would select. Our concluson s supported by the OPNET smulaton results, whch are acheved on OPNET Modeler 1. wth and MPLS models. Fg.1 and Fg.2 demonstrate the deployment and parameter setup n our OPNET smulaton scenaro. Fgure 2: The Parameter Setup n Our OPNET Smulaton Scenaro Fg.1 shows that the contans 8 label swtchng routers (LSRs) and label edge routers (LERs). In each sub- attached to the LER, there are 2 clents, 1 server, 1 swtch and 1 gateway. To enable MPLS swtchng, we set up dynamc label swtched paths (dynamc LSPs) between all the LERs. In our smulaton, the clents n all sub-s are confgured to call each other randomly accordng to the profle attrbutes n Fg.2. In Fg., the call setup delay of Clent_142_2 durng hour smulaton s demonstrated. We can see that the call setup delay vares between and 4 seconds when TE enabled MPLS s used. On the other hand, the delay s much lower when Clent_142_2 calls ts neghbour (Clent_142_1) n the same Ethernet based sub-. 5 call setup delay (seconds) Calls Passng Through MPLS Network Neghbour Calls Fgure : The Call Setup Delay of Clent_142_2 durng Hours Fgure 1: The Network Deployment of Our OPNET Smulaton Scenaro 2 To understand where the call setup delay comes, we use OPNET Debugger to trace the messages. As shown n Fg.4, t takes the frst message (Invte) about. seconds to travel from Clent_142_2 to Clent_144_2 because of LSP setup delay. After that, the transmsson delay of other messages s very

3 1 2 A BC GHI JK L P QRS TUV OP ER DE F MN O WX YZ CISC OIPPHONE 7 mes sages drect o re s s erv ces set t ngs 1 2 ABC GHI JKL PQR S TUV OPER DEF MNO WXYZ C ISC O IP P HONE 7 me ssages d rect or es serv ce s set ng s low. Therefore, we can conclude that the call setup delay s manly caused by the LSP setup between two LERs. Clent_142_2, tme n seconds Invte,4 ms OK _Server_ Meda Sesson Invte Tme : sec, [d h 2m 47s. 71ms 728us 528ns 45ps] Event : executon ID (14), schedule ID (2545), type (remote ntrpt) > Module : top.network_142.clent_142_2.applcaton (processor) UAC (PID 1) processng INVITE Request Sendng the request to UAS n packet (PK_ID.) Tme : sec, [d h 2m 47s. 71ms 851us 72ns 41ps] Event : executon ID (1447), schedule ID (25117), type (stream ntrpt) > Module : top.network_142.server_142.applcaton (processor) OK Clent_144_2 tme n seconds,82 UAS (PID 18) has receved a request n packet (PK_ID.) UAS (PID 18) openng an actve (tcp) connecton to dest (Network_144.Clent_144_2) on port (57) Tme : sec, [d h 2m 5s. 57ms 78us 41ns 5ps] Event : executon ID (1521), schedule ID (24), type (stream ntrpt) > Module : top.network_144.clent_144_2.applcaton (processor) UAC (PID 141) has receved a response. UAC (PID 141) processng C_CALL_INVITE Response Sendng a C_CALL_CONNECT_SUCCESS ACK to UAS Tme : sec, [d h 2m 5s. 515ms 5us 7ns 8ps] Event : executon ID (15428), schedule ID (2155), type (stream ntrpt) > Module : top.network_142.server_142.applcaton (processor) UAS (PID 18) has receved an ACK. UAS (PID 18) has updated the message on response packet (PK_ID.) to (C_CALL_CONNECT_SUCCESS). Tme : sec, [d h 2m 5s. 515ms 7us 85ns 1ps] Event : executon ID (154), schedule ID (215), type (stream ntrpt) > Module : top.network_142.clent_142_2.applcaton (processor) UAC (PID 1) has receved a response. UAC (PID 1) processng C_CALL_CONNECT_SUCCESS Response Forwardng the response to Applcaton Process (PID 144) Fgure 4: Message Tracng by OPNET Debugger Our New over MPLS Network Archtecture In order to shorten the call setup delay caused by CR-LDP or RSVP-TE, a new over MPLS archtecture s proposed n ths secton. Fg.5 shows that our over MPLS archtecture contans 2 parts, the local clent and MPLS core. Furthermore, there are two components n the clent, the termnal and the TA server. The TA server can be regarded as an enhanced proxy server, and t negotates/re-negotates wth the LER of MPLS core about the overall QoS requrements of local clent on behalf of a cluster of termnals (not only one termnal). Then, the LER exchanges TE sgnalng wth other routers nsde the MPLS core to set up the correspondng LSPs. We use a set of tme marks {t, t 1, t 2,, t n-1, t n, t n+1, } to descrbe the tme n our system. If the TA server knows exactly that the overall bandwdth requrement of ts local clent durng [t n-1,t n ] s B n-1, n, then at tme t n-1, the TA server negotates wth MPLS to get B n-1, n outgong bandwdth by usng Common Open Polcy Servce (COPS) messages. As tme goes by, f the TA server knows that the overall bandwdth requrement of ts local clent durng [t n,t n+1 ] changes to B n, n+1, then at tme t n, the TA server would re-negotate wth MPLS to ncrease/decrease the bandwdth requrement to B n, n+1. By ths way, the LSPs needed by telephony are setup n MPLS core before calls are made. As a result, the call setup delay n MPLS s decreased greatly. However, t s mpossble for the TA server to know the exact value of B n-1, n before the tme of t n-1. Usually, the TA server can only employ a certan bandwdth predcton algorthm to gve an approxmate value of B n-1, n, whch can be defned as B pred n-1, n. If B pred n-1, n-b n-1, n <, durng [t n-1,t n ], the local clent doesn t have enough outgong bandwdth to accommodate all the calls, and the TA server has to utlze admsson control algorthm to declne some of the call requests. On the contrary, f B pred n-1, n-b n-1, n > durng [t n-1,t n ], some outgong bandwdth resource of the local clent would be wasted. From the above dscusson, we can conclude that the call admsson and bandwdth predcton/re-negotaton algorthm runnng on TA servers s very mportant to the overall performance of our over MPLS archtecture. TA Server Termnal COPS Local clent MPLS Network (ISP) COPS Local clent Fgure 5: Our over MPLS Archtecture TA Server Fg. shows the sgnalng flow n our over MPLS archtecture. The call set-up starts wth a standard INVITE message sent by the caller to the local TA server. The message carres the callee URL n the header and the sesson specfcaton (sesson specfcaton descrbes the QoS requrements of the call) n the body SDP. The caller treats the TA server as a standard proxy server. Regardng the caller ID, the sesson nformaton and the remanng outgong bandwdth n local clent, the TA server decdes whether ths call request s admtted. Termnal If the call request s admtted, the TA server would forward the orgnal INVITE message to the callee; Otherwse, t smply sends the caller a DECLINE message to drop the call. Furthermore, no matter the call s admtted or not, t would be regstered n the TA server for the purposes of call admsson and bandwdth predcton n the future. In addton, f the bandwdth re-negotaton s needed, the TA server re-negotates wth MPLS core to adjust the bandwdth requrement by usng COPS messages.

4 1 2 A BC G HI JK L P QR S TU V O PE R D EF MN O WXYZ CISC O IP PH ON E 7 mes sages se rv ces d rect or es set t ng s 1 2 AB C GH I JK L PQ RS TU V O PE R D EF MNO WX YZ CISC O IP PHO N E 7 messa ges d rect ore s serv ces set t ngs Termnal If accepted INVITE INVITE INVITE Declne 18 Rngng TA Server Local clent If declned Declne Declne MPLS Network 18 Rngng 2 OK ACK ACK ACK Traffc stream... If accepted INVITE If declned Declne TA Server Local clent 18 Rngng 2 OK 2 OK If the bandwdth renegotaton s needed Termnal predcton/re-negotaton. We ntegrate these two parts seamlessly n ths algorthm, and the detals are shown as follows. Varables: b req : The bandwdth requrement of an ncomng call. b contract : The overall outgong bandwdth that the TA server contracts wth the MPLS. b occuped : The outgong bandwdth occuped by alve calls. b acc-thr : The bandwdth threshold to accept all the ncomng calls. b dec-thr : The bandwdth threshold to make a lower bandwdth requrement predcton. nc: The counter used to make a hgher bandwdth requrement predcton. dec: The counter used to make a lower bandwdth requrement predcton. p declne : The probablty to declne the call, when b acc-thr < b occuped + b req < b contract. Fgure : The Sgnalng Flow n Our over MPLS Archtecture The call admsson and bandwdth re-negotaton algorthm on TA servers In ths secton, the call admsson and bandwdth re-negotaton algorthms on TA server are dscussed. Three algorthms, ncludng smple and complcated ones, are depcted as follows. (1) FCFS wth fxed bandwdth contract (FCFS-FB) In ths case, the local clent has a fxed bandwdth contract wth the MPLS core, and the TA server accepts/declnes calls usng Frst Come Frst Serve (FCFS) polcy. Ths algorthm has some obvous drawbacks except ts advantage of smplcty. When the outgong traffc of local clent s less than the contracted bandwdth, some bandwdth resource s wasted. On the contrary, when the outgong traffc of local clent overweghs the contracted bandwdth, the call blockng probablty s qute hgh. (2) FCFS wth statc adaptve bandwdth contract (FCFS-SAB) We dvde one day nto a couple of perods, and n each perod the local clent has a specfc fxed bandwdth contract wth the MPLS core. Same to FCFS-FB, FCFS s employed for call admsson n ths algorthm. If the fxed bandwdth contract of each perod can be set up reasonably accordng to the statstcs of everyday traffc load n the local clent, ths algorthm has better performance than FCFS-FB. Nevertheless, the outgong traffc of local clent often behavors unexpectedly due to all knds of reasons. In ths respect, ths algorthm s not flexble enough. () Threshold based call admsson and bandwdth predcton (TBCA-BP) Generally speakng, there are two parts n ths algorthm,.e., makng call admsson decson and conductng bandwdth 4 Constants: N dec-thr : The counter threshold to make a lower bandwdth requrement predcton. N nc-thr : The counter threshold to make a hgher bandwdth requrement predcton. B contract-step : The bandwdth ncrement/decrement step for B contract, f the bandwdth re-negotaton s conducted. B acc-thr-step : The bandwdth ncrement/decrement step for B acc-thr, f the bandwdth re-negotaton s conducted. B dec-thr-step : The bandwdth ncrement/decrement step for B dec-thr, f the bandwdth re-negotaton s conducted. Relatonshps: b contract > b acc-thr > b dec-thr B dec-thr-step, B acc-thr-step < B contract-step The Algorthm: For each call arrval of bandwdth requrement b req f b occuped + b req > b contract declne the call nc= nc +1 dec= f nc >N nc-thr /make bandwdth requrement predcton/ b contract = b contract +B contract-step re-negotate wth MPLS for the new b contract b acc-thr = b acc-thr + B acc-thr-step b dec-thr = b dec-thr + B dec-thr-step nc= else f b occuped + b req <b acc-thr b occuped = b occuped + b req accept the call nc = f b occuped <b dec-thr dec= dec +1 f dec >N dec-thr /make bandwdth requrement predcton/ b contract = b contract -B contract-step re-negotate wth MPLS for the new b contract b acc-thr = b acc-thr - B acc-thr-step b dec-thr = b dec-thr - B dec-thr-step

5 dec= else f b acc-thr < b occuped + b req < b contract dec= p declne =( b occuped + b req - b acc-thr )/(b contract - b acc-thr ) Wth probablty p declne, declne the call f the call are really declned nc= nc +1 f nc >N nc-thr /make bandwdth requrement predcton/ b contract = b contract +B contract-step re-negotate wth MPLS for the new b contract b acc-thr = b acc-thr + B acc-thr-step b dec-thr = b dec-thr + B dec-thr-step nc= else b occuped = b occuped + b req accept the call nc= As revealed by the above descrpton, the TA server makes call admsson decson abdng by the followng rules. (1)The rule of acceptng a call: If b occuped + b req <b acc-thr, the local clent s dle and has enough outgong free bandwdth to accept new calls. As a result, the ncomng calls would be always accepted. On the other hand, f b acc-thr < b occuped + b req <b contract, the local clent only has lmted free outgong bandwdth to accept new calls. So, the ncomng call s accepted wth the probablty of 1- p declne. (2)The rule of declnng a call: f b occuped + b req >b contract, the local clent has no free bandwdth to accept a new call, and all the ncomng calls have to be declned. Moreover, f b acc-thr < b occuped + b req <b contract, the ncomng call wll be declned wth the probablty of p declne. Secton 4. Although analytcal approach can be appled to study these algorthms, t quckly becomes too complcated and ntractable when the source model and the algorthm become complex. For ths reason, we use OPNET smulaton to study ther performances. We suppose there are 4 groups of call requests n the local clent, and n each group there are dfferent bandwdth requrement classes. (a)group G 1 : 5Kbps (class1); (b)group G 2 : 2Kbps(class1), 5Kbps(class2); (c)group G : 1.5Mbps(class1); (d)group G 4 : 4Mbps(class1), Mbps(class2). Obvously, G 1 and G 2 are groups of low-bandwdth call requests, whle G s the medum-bandwdth call group and G 4 s hghbandwdth call group. Moreover, call requests of each class n every group are assumed to arrve accordng to Posson process ndependently, and the servce tmes are exponentally dstrbuted. The parameters used n ths model are defned below: λ k,m (calls/hour):average arrval rate of class m requests n G k. 1/µ k,m (hours/call):average servce tme for class m requests n G k. Pb k (%): the blockng probablty of group G k. Eff(%): the bandwdth utlty effcency of a certan algorthm. B contract (Mbps): the overall outgong bandwdth that the TA server contracts wth the MPLS. The node model used n our smulaton s shown n Fg.7. Ths node model conssts of several sources (G1, G2A, G2B, G, G4A, and G4B), a call admsson and bandwdth re-negotaton module and a snk. To make bandwdth predcton/re-negotaton, the TA server comples wth the followng rules: (1)Askng for more bandwdth: If more than N nc-thr calls are declned consecutvely, the TA server wll make a predcton of more bandwdth requrement, and conduct bandwdth renegotaton wth MPLS. (2)Askng for less bandwdth: Upon acceptng a call, f the TA server fnds the occuped bandwdth b occuped has been below b dec-thr for N dec-thr tmes consecutvely, t wll make a predcton of less bandwdth requrement, and conduct bandwdth renegotaton wth MPLS. The above dscusson shows that the algorthm of TBCA-BP s desgned to have more flexblty, hgher bandwdth utlty effcency, and lower call blockng probablty than other two algorthms. Frstly, when b acc-thr < b occuped + b req <b contract, ths algorthm drops calls randomly to avod the global synchronzaton of many termnals gvng up ther call requests at the same tme. Secondly, ths algorthm can trace the real bandwdth requrement n the local clent, and make an approprate predcton. In concluson, TBCA-BP s supposed to be a sutable call admsson and bandwdth renegotaton algorthm for TA servers. OPNET Smulaton In ths secton, the smulaton results are presented to demonstrate the performance of the algorthms suggested n 5 Fgure 7: Node Model Used n Our Smulaton The basc functon of ths node model s to mmc the real process of handlng a call request, ncludng call admsson control, resource allocaton, resource reclam and bandwdth renegotaton. The sources n Fg.7 are desgnated to generate the call requests accordng to our schedule and n our own packet format. As shown n Fg.8, our packet format contans 4 felds (groupid, classid, bandwdth requrement and call duraton). Generated packets from all sources are sent to the call admsson and bandwdth re-negotaton module. Group ID (2 bts) Class ID (2 bts) Bandwth Requrement (2 bts) Call Duraton (2 bts) Fgure 8: Packet Format n Our Smulaton

6 After recevng a packet, the call admsson and bandwdth renegotaton module extracts the correspondng nformaton of ths call request from the receved packet and executes the call admsson and bandwdth re-negotaton algorthm. If the call request s declned, the packet of ths call request should be sent to the snk and deleted. On the contrary, f the call request s accepted, the call admsson and bandwdth re-negotaton module has to reserve correspondng bandwdth resource for t and keep the nformaton of ths alve call untl t s out of servce tme and deleted. In addton, when bandwdth renegotaton s needed, the call admsson and bandwdth renegotaton module would ncrease/decrease the contracted bandwdth accordngly. Wth OPNET smulaton, numercal results are attaned from Fg. to Fg.1 to llustrate the performance of these algorthms. The Parameter Setup of our smulaton s shown as follows: (1)Traffc load n the local clent : probablty, and bandwdth utlty effcency of these algorthms durng one day. Frstly, we dscuss the performance of FCFS-FB. As shown n Fg., FCFS-FB has no capablty of bandwdth predcton. As a result, Fg.1 shows that the blockng probablty of FCFS-FB s not stable. When the traffc load n local clent overweghs the outgong bandwdth contract, the blockng probablty s hgh. On the other hand, when the traffc load s lower than the outgong bandwdth contract, the blockng probablty s low, but a lot of bandwdth resource s wasted. Furthermore, from Fg.1 we know the bandwdth utlty effcency of FCFS-FB s varyng wth the traffc load n local clent uncontrolledly. In a word, the performance of FCFS-FB s terrble. Secondly, the performance of FCFS-SAB s nvestgated. Fg., Fg.11, and Fg.1 demonstrate that FCFS-SAB has a good bandwdth utlty effcency but poor blockng probablty when ts bandwdth contract s lower than the real traffc load n most tme of 1 day. Actually, t s very dffcult for FCFS-SAB to have both good bandwdth utlty effcency and good blockng probablty due to ts un-flexblty. Thrdly, we focus on the performance of TBCA-BP. Fg. shows TBCA-BP has hgh bandwdth predcton accuracy, whle Fg.12 and Fg.1 llustrate t also possesses satsfyng blockng probablty and bandwdth utlty effcency. Obvously, TBCA-BP has the best performance among these three algorthms, and t s an apt canddate to fulfll call admsson and bandwdth re-negotaton task on TA servers. 5 Real Traffc FC FS-FB 4 FC FS-SAB (2) The parameter setup of these algorthms (a) FCFS-FB: Fxed Bandwdth=25Mbps; (b) FCFS-SAB: Bandwdth Contract Bcontract (Mbps) 2 TBC A -BP Tm e (h o u rs ) Fgure : The Bandwdth Contract Changng of All Algorthms durng 1 Day (c) TBCA-BP: 1 FC FS-FB Blockng Probablty (%) Pb1 Pb Pb2 Pb4 1 The smulaton results are shown from Fg. and Fg.1 to demonstrate the bandwdth contract changng, blockng Fgure 1: The Blockng Probablty of FCFS-FB durng 1 Day

7 Blockng Probablty (%) F C F S -S A B P b1 P b P b2 P b Tm e (ho urs) Fgure 11: The Blockng Probablty of FCFS-SAB durng 1 Day Blockng Probablty (%) T B C A -B P Pb1 Pb P b2 P b4 2,4 4,8 7,2, 12 14,4 1,8 1,2 21, 24 Fgure 12: The Blockng Probablty of TBCA-BP durng 1 Day Bandwdth Utlty Effcency Eff (%) ,4 4,8 7,2, 12 14,4 1,8 1,2 21, 24 Eff(FCFS-FB) Eff(FCFS-SAB) Eff(TBCA-BP) Fgure 1: The Bandwdth Utlty Effcency of All Algorthms durng 1 Day As mentoned n Secton 2, one man am of our new over MPLS archtecture s to shorten the call setup delay. To prove our new archtecture can reach ths am, we buld the algorthm of TBCA-BP nto the TA server, and do the smulaton shown n Fg.1 and Fg.2 agan. The smulaton result shows that call setup delay n our new archtecture s smlar to that of the neghbour calls n Fg.. Concluson We have presented a new archtecture of telephony over MPLS to overcome the long call setup delay problem n TE enabled MPLS. In order to ntegrate protocol wth the traffc engneerng functon of MPLS seamlessly and facltate call setup, the TA server s hghlghted as a key part of our archtecture. Furthermore, the call admsson and bandwdth re-negotaton algorthms runnng on the TA server are nvestgated carefully. In ths paper, we rely on OPNET smulaton to show the performance of dfferent call admsson and bandwdth re-negotaton algorthms. From the smulaton results we can conclude that the algorthm named TBCA-BP s a sutable call admsson and bandwdth re-negotaton algorthm for TA servers, due to ts satsfyng performance of hgh bandwdth predcton accuracy, low call blockng probablty, and hgh bandwdth utlty effcency. References [1] Deerng S.E., ": Smple Internet Protocol," IEEE Network, Volume: 7, Issue:, May 1, pp [2] Faccn S.M., Lalwaney P., Patl B., " IP multmeda servces: analyss of moble IP and nteractons n G s," IEEE Communcatons Magazne, Volume: 42, Issue: 1, Jan. 24, pp [] Ssalem D., Fedler J., Ruppelt R., " and IPv: why and how?," Proceedngs of Symposum on Applcatons and the Internet Workshops 2, Jan. 2, pp [4] Le Faucheur F., "IETF Multprotocol Label Swtchng (MPLS) Archtecture," 1st IEEE Internatonal Conference on ATM (ICATM- 8), June 18, pp [5] L T., "MPLS and the evolvng Internet archtecture," IEEE Communcatons Magazne, Volume: 7, Issue: 12, Dec. 1, pp [] Xpeng Xao, Hannan A., Baley B., N L.M., "Traffc engneerng wth MPLS n the Internet," IEEE Network, Volume: 14, Issue: 2, March-Aprl 2, pp [7] Awduche D.O., "MPLS and traffc engneerng n IP s," IEEE Communcatons Magazne, Volume: 7, Issue: 12, Dec. 1, pp [8] Zhang C., Guy C.G., "TE- server desgn for a -over-mpls based," Proceedngs of Internatonal Conference on Communcaton Technology 2 (ICCT 2), Volume: 2, Aprl 2, pp [] Salsano S., Veltr L., " QoS control by means of COPS to support -based applcatons," IEEE Network, Volume: 1, Issue: 2, March- Aprl 22, pp