An Improved Resource Reservation Protocol

Transcription

1 Jounal of Compute Science 3 (8: , 2007 SSN Science Publications An mpoved Resouce Resevation Potocol Desie Oulai, Steven Chambeland and Samuel Piee Depatment of Compute Engineeing Ecole Polytechnique de Monteal P.O. Box 6079, Station Cente-Ville, Monteal (Quebec, Canada H3C 3A7 Abstact: The classical esouce esevation potocol (RSVP is a flow-based signaling potocol used fo eseving esouces in the netwok fo a given session. RSVP maintains state infomation fo each esevation at evey oute along the path. Even though this potocol is vey popula, he has some weaknesses. ndeed, RSVP does not include a bidiectional esevation pocess and it equies efesh messages to maintain the soft states in the outes fo each session. n this pape, we popose a sendeoiented vesion of RSVP that can eseve the esouces in both diections with only one message, thus educing the delay fo establishing the esevations. We also suggest a efeshment mechanism without any efesh message which could be applied to any soft states potocol. Simulation esults show that the poposed potocol is appoximately twice faste than RSVPv2 fo establishing bidiectional esevations with almost no contol ovehead duing the session. Key wods: ntenet potocol (P, quality of sevice (QoS, esouce esevation potocol (RSVP, setup time, signaling load, soft state efeshment, failue scenaios. NTRODUCTON Nowadays, many applications such as voice and video applications have stingent quality of sevice (QoS equiements. Howeve, the ntenet potocol (P, which is the most used potocol at the netwok laye, lacks of QoS mechanisms. That is why many QoS achitectues and potocols have been poposed, fo instance, integated sevices (ntsev, diffeentiated sevices (DiffSev and multipotocol label switching (MPLS (see Ni and Xiao [9] fo details concening QoS in P netwoks. The classical esouce esevation potocol (RSVP, such as defined in RFC 2205 [5], is a flow-based esouce esevation potocol. t has been oiginally ceated to wok with the ntsev [4] achitectue. Basically, ntsev implements thee classes of sevices: guaanteed sevice (GS, contolled load (CL and best effot (BE. GS guaantees maximal delay and bandwidth. Contolled load offes a QoS simila to what can be offeed in a netwok without congestion and BE does not offe any guaantee. RSVP allows signaling fo multicast and unicast sessions. Fo instance, when Route A wants to establish a session with Route B, it sends a PATH message to Route B. The PATH message collects infomation about the esouces on the outes on the path used fom Route A to Route B and it also establishes a PATH state in each oute. The PATH states also acts as a passive esevation with no physical esevation. When Route B eceives the PATH message, it esponds with a RESV message that is outed along the evese path taken by the PATH message. The RESV message eseves the esouces by ceating a RESV state in each oute. Such a potocol is called a eceive-oiented potocol. The RESV message physically eseves the esouces that ae available fistly by the flow fo which the esevation has been equested. The PATH and RESV states ae soft states, i.e., they will be deleted afte a cetain timeout if thee is no efeshment. Refesh messages ae scheduled each [0.5R,.5R] in ode to avoid synchonization between outes (whee R is a common pedefined value fo all the outes within the RSVP domain. Refesh messages ae also useful fo path estoation in failue scenaios. When a failue occus, the PATH efesh message will be sent though the netwok to pass aound the failed netwok elements and each the destination. Fo a faste estoation, RSVP implements the local epai pocess [6]. With this pocess, if a failue occus on a link adjacent to a oute, its RSVP module sends a PATH efesh message to estoe the segment of the path passing though the failed link. As a esult, the oveall path may not be optimal. RSVP has two main dawbacks. Fist, RSVP does not suppot bidiectional esevations. Coesponding Autho: Steven Chambeland, Depatment of Compute Engineeing Ecole Polytechnique de Monteal P.O. Box 6079, Station Cente-Ville, Monteal (Quebec, Canada H3C 3A7 658

2 n fact, two unidiectional esevations can be used fo bidiectional esevations. Howeve, this implies moe delays and if we have to ecove fom a failue o to signal new esouces afte a handove in a mobile netwok, these delays could be a poblem. The second dawback is that efesh messages should be sent peiodically. n this pape, we popose RSVP+, an impoved RSVP with bidiectional signaling and states efesh mechanisms without efesh messages. The pape is oganized as follows. Section 2 pesents elated woks followed by the pesentation of the potocol RSVP+ in Section 3. n Section 4, we pesent and analyze the simulation esults and, finally, conclusions and futhe woks ae pesented in Section 5. RELATED WORKS Ove ecent yeas, many impovements have been poposed fo RSVP. RSVP-TE (Taffic Engineeing, typically used with MPLS [3], distibutes the labels to the outes and allows the sende to explicitly choose the path fo a given session. With RSVP-TE, when Route A wants to initiate a bidiectional esevation to Route B, it sends a PATH message which distibutes labels in downsteam diection and othe labels ae distibuted by the RESV in the evese diection. RSVPv2 [0] used almost the same pinciple but does not wok with MPLS. Abondo and Piee [] intoduced a sende-oiented RSVP fo fast signaling. The esevation is done by the PATH messages. RFC 296 [2] poposes to bundle the efesh messages between two adjacent outes. The bundles many efesh messages and sends them in one packet, thus educing the amount of ovehead needed fo the efesh messages. Thee is a gain on the P ovehead but the RSVP messages ae J. Compute Sci., 3 (8: , 2007 unchanged. Moeove, RFC 296 [2] intoduces a Summay Refesh message (SRefesh. n the SRefesh message, thee is an object MESSAGE containing an identifie, called MESSAGE ENTFER, used to identify the PATH messages. As a esult, the outes do not need all the content of the efesh messages because they ae able to identify the session and update the times. These identifies can be aggegated in one packet. These poposals educe the size of the efesh messages, but one poblem emains if one o moe efesh messages ae lost on thei ways. The RFC 296 [2] suggests a MESSAGE ACK to acknowledge the messages, but with an incease in signaling load. Pesently, the next steps in signaling (NSS woking goup of the ETF woks on potocols fo signaling infomation about a data flow along its path in the netwok. A famewok fo NSS signaling has been poposed in the RFC 4080 [7]. The NSS famewok is 659 composed of two layes. The uppe laye, called NSLP (NSS Signaling Laye Potocol, includes the signaling applications and the lowe laye, called NTLP (NSS Tanspot Laye Potocol, povides a geneic tanspot sevice fo those applications. Due to its geneic famewok, NSS uns ove many tanspot potocols. NSS intoduces a session identifie which is diffeent fom the flow identifie. One session can cay infomation elated to seveal signaling applications. The session identifie allows NSS to suppot mobility easily. f a flow identifie changes along the path, the flow can still be associated with the signaling session. t is assumed that applications contolled by a single session could pefom bandwidth shaing [8]. ntsev and DiffSev could be used with NSS. n the case of signaling fo QoS, NSS has many featues. Fist, NSS QoS allows sende-initiated and eceive-initiated esevations. Fo bidiectional esevations, a common message can eseve esouces on both diections if the physical path is the same. Othewise, two unidiectional pocesses have to be initiated. Fo scalability, NSS QoS uses a soft state mechanism and the efesh is done with a educed message containing a session as in RFC 296 [2]. Howeve, the lost of efesh messages is still a poblem. THE NEW VERSON OF RSVP: RSVP+ RSVP+ is an impoved RSVP with new featues. Fist of all, because most of the ntenet communications ae unicast, RSVP+ is defined fo unicast sessions although some ideas might wok with multicast sessions. By this way, RSVP+ is less complex than RSVP. Futhemoe, RSVP+ is a sende-oiented esevation potocol, i.e., the esevation is done by the PATH message. t is supposed that the sende is awae of the equested QoS. Resouces Resevation: When Route A wants to initiate a QoS session with Route B, it sends a PATH message as in RSVP. The PATH message ceates the PATH and the RESV states on the oute along the path with the infomation contained in the session object. The PATH message can eseve the esouces on the diection fom Route A to Route B, Route B to Route A, o both. The diection can be maked in the fist two bits of the Flags field in the RSVP Common Heade which is cuently unused. Fo instance, 00: fo the nomal diection only (fom Route A to Route B; 0: fo the evese diection only (fom Route B to Route A; 0: fo both diections. When Route B eceives the PATH message, the

3 J. Compute Sci., 3 (8: , 2007 QoS is aleady configued on the path and can be used. Next, Route B sends a RESV message to Route A as a confimation. Bidiectional Resevation:The bidiectional esevation can be done in two ways: both diections take the same physical path o not. Same Path: The sende sends one PATH message that eseves the esouces on both diections. f we want to have a eceive-oiented potocol, the PATH message woks as in RSVP but collects infomation fo both diections and the RESV message is used to eseve the esouces. With this appoach, the numbe of signaling messages fo establishing the bidiectional esevation is divided by two when using the same physical path. Diffeent Paths: The sende sends simultaneously two PATH messages, one fo each diection. When the eceive eceives both PATH messages, it sends a RESV message to confim that the esevations have been successful. f one o the two esevations have failed, the RESV message can initiate new esevations. The main diffeence between ou pocess and NSS QoS is that we allow the sende to eseve esouces fo the eceive without eceiving a quey equest. As a esult, the pocess is faste. We can also have a eceive-oiented potocol by utilizing the RESV to eseve the esouces. n the sende-oiented case, the QoS is configued along the paths as soon as the PATH messages ae eceived. Even if thee ae similaities with RSVP-TE and NSS QoS, the main diffeence is that RSVP+ allows a PATH message to eseve esouces in evey diection. Thee is no need to wait fo a quey message befoe launching the esevation. States Refesh: We popose a new and simple way to efesh the states in a oute. Ou poposal is based on the fact that the efesh messages ae most of the time copies of the oiginal messages. They ae useful when a new path has to be signaled due to a netwok failue o when the specifications of the esevation have changed. n the fome case, the local epai pocess in RSVP is enough to signal the new path [5]. Fo the latte case, we can notice that the modification of a esevation does not happen fequently. Based on these obsevations, we can say that the best way to know if a session is still woking is to eceive packets associated to this session. Data taffic is most of the time enough to efesh the sessions. Ou poposal is as follows. When a oute eceives a data packet of a given flow, the oute can update the expiation time associated to the states of the flow. The oute can update the expiation time fo each packet o afte a cetain amount of time since the last update. n this case, the states will not expie while packets ae flowing. f thee is no taffic but the sende wants to keep the esevation, it sends a classical PATH efesh message along the path. This message is fowaded with high pioity along the path to maintain the states. f a state expies in a oute, it sends a PathTea message to delete the esevations along the path. With this solution, the need fo explicitly efesh messages may be educed to nothing, impoving the bandwidth usage. Futhemoe, a efesh message could be lost while the session is still active. With efeshment done by the data packets, each packet acts as a efesh message so the pobability to lose efesh infomation is consequently educed. Ou efesh pocess is moe obust and the idea can be used to any soft state potocol. Session Blocking Reduction:n sende-oiented esevation potocols, a potential poblem is that an uncompleted session blocks anothe one. Fo instance, suppose that Sende # sends a PATH message to Receive # and, afte a few seconds, Sende #2 wants to eseve esouces to Receive #2 but the equest is efused due to the fist esevation (see Fig.. We popose a solution to educe this kind of blocking. Fist, the following notation is used. Let C be the capacity of the inteface (pot, C c, the eseved capacity that has been confimed and cannot be used by a new equest, C u, the unconfimed but eseved capacity and cannot be used by a new equest, C, the esidual capacity that is not eseved and, finally, A, the capacity equested on the inteface. Fist note that C = C c + C u + C. Fig. : Session blocking example When a equest eaches an inteface, thee ae thee cases. Case : A < C n that case, the equest is accepted. The oute eseves the capacity and fowads the equest to the next oute. Case 2: A > C C c The equest is ejected due to insufficient capacity. 660

4 J. Compute Sci., 3 (8: , 2007 Case 3: C < A < C + C u n that case, ou poposition follows. Fist, the oute puts the equest on hold fo a timeout. The oute can keep a waiting list odeed by pioity class o aival time. f duing this timeout, enough unconfimed esouces ae feed, the ongoing esevation will be accepted and fowaded to the next hop. Othewise, the equest is ejected. With this pocess, the setup time may incease but the blocking due to uncompleted esevation is educed. PERFORMANCE ANALYSS n this section, we assess the pefomance of RSVP+. The metics chosen ae the time to establish a esevation, the estoation time when a failue occus and the amount of signaling messages. We compae RSVP+ to the classical RSVP fo unidiectional esevations because RSVP and RSVP-TE have the same pocedue fo such esevations. Fo bidiectional esevations, we compae RSVP to RSVPv2 because RSVPv2 has bette pefomance than classical RSVP fo such esevations [0]. t is impotant to mention that we choose RSVPv2 instead of RSVP-TE because the latte woks with MPLS and involves label distibution. Howeve, RSVPv2 and RSVP-TE have the same pocedue fo bidiectional esevations except can be witten down fo unidiectional and bidiectional esevations. Unidiectional Resevation RSVP : T e = T c +2 T t RSVP+: T e = T c + T t. Bidiectional Resevation RSVPv2: T e =2 T c +2 T t RSVP+ : T e =2 T c + T t (fo one PATH message, T e = T c + T t (fo two PATH messages. The simulato OPNET.0 is used to un ou simulations. The fist test is to compae the setup time between RSVP and RSVP+. Fig. 2 shows the test netwok that is composed of two sendes and two eceives who ae communicating though a bidiectional sevice of 96 kbps. Sende # is communicating with Receive # and Sende #2 with Receive #2. We used thee types of links: 256, 52 and 024 kbps. Fig. 3 shows that RSVP+ has a bette setup time than RSVP fo unidiectional esevations. Fo bidiectional esevations, we consideed the case whee both sessions use the same physical path. f both sessions ae not equied to use the same path, the esults fo RSVP+ fo bidiectional and unidiectional esevations should be the same since both esevations ae launched simultaneously. Fig. 4 shows that RSVP+ has a bette setup time than RSVP fo bidiectional esevations. t can also be obseved that RSVP+ is appoximately twice faste than RSVPv2 fo establishing bidiectional esevations. This can be explained by the fact that the oute configuation time, T c, is vey small. As a esult, T e 2 T t fo RSVPv2, T e T t fo RSVP+ and T e (RSVP+ 0.5 T e (RSVPv2. Fig. 2: Test netwok used to analyze the setup time that in RSVPv2, the downsteam oute could not tansmit afte eceiving the PATH messages even if esouces ae eseved. As we ae concened with the time fo establishing the esevation, this detail is not impotant fo us. We did not choose NSS because some pocesses ae simila to RSVPv2 and is still in development. Setup Time Reduction: Let T e be the establishment time of a given esevation, T t, the tansfe time fom the sende to the eceive and T c, the configuation time Fig. 3: Setup time as a function of the link capacity fo of evey oute along the path. The following equations unidiectional esevation 66

5 J. Compute Sci., 3 (8: , 2007 Fig. 4: Setup time as a function of the link capacity fo bidiectional esevation Restoation Time in Failue Scenaios: Failue ecovey is an impotant issue in netwoks. The ecovey time has to be shot in ode to quickly estoe the QoS fo the affected flows. n ou expeiment, we use two sendes and two eceives with the same 96 kbps application. The test netwok is pesented in Fig. 5. Sende # is communicating with Receive # using RSVP and Sende #2 is communicating with Receive #2 without RSVP. n the no failue scenaio, the flows use the path A-C-B. Afte 00 seconds, we simulate the failue of Route C. Thus, the flows ae eouted though the path A-D-B. We use 28 kbps links to put emphasis on congestion. Ou objective is to detemine if ou algoithm is able to quickly estoe the QoS on the altenate path. We use RSVP, RSVPv2 and RSVP+ fo the simulation. The esults ae illustated in Fig. 6. Fig. 6 shows that the QoS estoation time is smalle fo RSVP+. This can be explained by the fact that when a failue occus, the taffics ae fowaded though the altenate path in best effot until the QoS is estoed. Since RSVP+ configues the QoS with the PATH message, the QoS is estoed faste. So when the path message joins the eceive, the entie altenate path can povide the QoS end-to-end. Fig. 6: QoS (end-to-end delay estoation time in a failue scenaio fo RSVP, RSVPv2 and RSVP+ Refesh Reduction: n this section, we want to assess the poposed efesh pocedue. The test netwok, pesented in Fig. 7, has seven sendes and seven eceives who ae communicating though a bidiectional sevice of 96 kbps. The link capacity used is 500 kbps and the simulation time is 600 seconds. Fig. 8 shows that the states ae being efeshed when using RSVP+. Fo each RSVP packet sent o eceived, we checked the numbe of active RESV states in the oute. (Note that the esults fo PATH states ae simila. As mentioned befoe, the potocol RSVP+ is implemented such that the states ae efeshed fo evey packet associated to a flow. This appoach does not have a measuable impact on the CPU utilization of the outes (see Fig. 9. Fig. 7: Test netwok used to analyze the efesh load eduction Fig. 5: Test netwok used to analyze the estoation time in failue scenaios 662 Fig. 8: Numbe of active RESV in Route B fo RSVP+

6 J. Compute Sci., 3 (8: , 2007 Fig. 0 illustates the numbe of efesh messages (PATH and RESV sent by Route B fo RSVP, RSVPv2 and RSVP+. The efesh inteval used is seconds and the simulation time is 600 seconds (i.e., 8 efesh cycles. Fig. 9: CPU utilization of Route B fo RSVP and RSVP+ Fig. 0: Numbe of efesh messages sent by Route B fo RSVP, RSVPv2 and RSVP+ The following notation is used to evaluate the aveage signaling load geneate by a single oute: N, the numbe of outes in the netwok; B, the bundle heade length in RFC 296 (in bits; C, the aveage numbe of bidiectional connections flowing though a oute; D, the aveage session duation (in sec; F, the aveage numbe of connected intefaces on a oute; H P, the length of an P packet heade (in bits;, the efesh inteval fo a given oute (in sec; M, the length of message object in RFC 296 (in bits; P, the length of the PATH message (in bits; R, the length of the RESV message (in bits; S, the heade length of the message that contains the messages (in bits; L, the aveage efesh signaling load geneated by a single oute when using classical efesh pocedue (in bps; L B, the aveage efesh signaling load geneated by a single oute when using bundle descibed in RFC 296 (in bps; L S, the aveage efesh signaling load geneated by a single oute when using SRefesh descibed in RFC 296 (in bps. Fist note that fo RSVP+, the signaling load is zeo since thee ae no efesh messages. Moeove, fo RFC 296 solutions, thee is only one P heade pe bundle of RSVP messages and we conside the acknowledgement messages. The equation of the signaling load fo each potocol follows. t can be obseved that fo RSVP, the numbe of efesh messages at each cycle is 28 (i.e., 4 PATH messages and 4 RESV messages. The total numbe of messages fo the simulation is then 546 (i.e., 8 cycles of efesh messages, 28 setup messages and 4 ResvConf messages. Fo RSVPv2, the numbe of efesh messages at each cycle is 4 (i.e., 7 PATH messages and 7 RESV messages. The total numbe of messages fo the simulation is then 266 (i.e., 8 cycles of efesh and 4 setup messages. Finally, RSVP+ pefoms a total of 4 messages fo the setup of the 7 bidiectional sessions. The teadown messages ae not consideed in the simulations. Note that RSVP and RSVPv2 signaling messages gow linealy with the simulation time whee RSVP+ signaling messages stay constant at 4 messages duing the simulation time. This is an advantage fo scalability assuming a lage numbe of simultaneous sessions flow though the netwok. 663 RSVP L = 2C ( P + H P + ( R + H P = 2C ( P + R + H P L B = (2CP + 2CR + FB + FH P L S = + FS = [ 2C( P + R + M + F( B + S + H ] (2CM = [ 8CM + F( S + H ] + FS + FH P P P ( (2 (3

7 RSVPv2 L = C ( P + H P + ( R + H P = C ( P + R + 2H P L B = ( CP + CR + FB + FH P L S = + FS = [ C( P + R + 2M + F( B + S + H ] ( CM = [ 4CM + F( S + H ] + FS + FH P P J. Compute Sci., 3 (8: , 2007 P (4 (5 (6 Based on RFC 2205, is supposed to be between 5 and 45 seconds. Let us calculate the bandwidth (in bps fo the exteme values when B is set to 64 bits, F to 3, H P to 60 bits, M to 64 bits, P to 896 bits, R to 736 bits, and S to 64 bits. The esults ae pesented in tables and 2. The esults ae descibed fo classical efesh, bundle extensions and SRefesh extensions. Fo all scenaios, RSVPv2 gives bette pefomances than RSVP. Table : Refesh signaling load (in bps fo = 5 seconds RSVP RSVPv2 Classical C 30.4 C Bundle C C SRefesh 34.3 C C Table 2: Refesh signaling load (in bps fo = 45 seconds RSVP RSVPv2 Classical C C Bundle C C SRefesh.37 C C The esults in those tables also pesent the gap between RSVP+ and RSVP and the gap between RSVP+ and RSVPv2 since the signaling load of RSVP+ due to efesh message is zeo. These esults ae only the aveage signaling load fo one oute. Now conside a netwok with N = 30 nodes and C = 000. Let us calculate the oveall netwok signaling load NL S, fo some cases. RSVP and classical Refesh, = 5 seconds: NL S = 30[260.27(000] = Mbps 664 RSVP and classical Refesh, = 45 seconds: NL S = 30[86.75(000] = Mbps RSVPv2 and SRefesh, = 5 seconds: NL S = 30[7.07( ] = kbps RSVPv2 and SRefesh, = 45 seconds: NL S = 30[5.67( ] = kbps. As a esult, RSVP with classical efesh is the wost case and RSVPv2 with SRefesh is the best case. Best Field of Applications: RSVP+ is a potocol that can be used instead of RSVP. Howeve, RSVP+ woks bette in uneliable netwoks because its estoation time is bette. Anothe impotant aea is mobile netwoks whee the netwok needs to quickly estoe QoS in a new path when it switches fom an access oute to anothe. RSVP+ educes the delay to estoe the QoS in the new segment. CONCLUSONS AND FURTHER WORKS n this pape, we poposed RSVP+, an impoved esouce esevation potocol. Ou potocol is sendeoiented. With one PATH message, we can signal bidiectional esevations o unidiectional esevations in evey diection without the need of a quey message like in NSS QoS. RSVP+ sets up the esevations moe quickly than the othe potocols and the estoation time is faste. Moeove, we have poposed a new efesh pocedue with a minimum numbe of efesh messages. RSVP+ is also moe obust because evey data packet acts like a efesh packet. Many featues of RSVP+ could be included in othe esouce esevation potocols like NSS QoS. Thee ae seveal avenues of eseach that ae open at this point. ndeed, it would be inteesting to implement the efesh mechanism in a way that each oute will update the state only afte a cetain inteval of time and to see the pefomance of RSVP+ in a mobility context and to implement the solution fo educing the blocking due to uncompleted esevation. REFERENCES. Abondo, C., and S. Piee, Hieachical Poxy Mobile Resouce Resevation Potocol, ETF ntenet Daft, daft-abondo-hmpsvp-00.txt. 2. Bege, L., D. Gan, G. Swallow, P. Pan, F. Tommasi and S. Molendini, 200. RSVP Refesh Ovehead Reduction Extensions, ETF RFC 296.

8 J. Compute Sci., 3 (8: , Bege, L., Genealized Multi-Potocol Label Switching (GMPLS Signaling Resouce ReseVation Potocol-Taffic Engineeing (RSVP- TE Extensions, ETF RFC Baden, R. and D. Clak, 994. ntegated Sevices in the ntenet Achitectue: an Oveview, ETF RFC Baden, L., S. Zhang, S. Beson, S. Hezog and S. Jamin, 997. Resouce ReSeVation Potocol (RSVP Vesion Functional Specification, ETF RFC Baden, R. and L. Zhang, 997. Resouce ReSeVation Potocol (RSVP Vesion Message Pocessing Rules, ETF RFC Hancock, R., G. Kaagiannis, J. Loughney and S. Van den Bosch, Next Steps in Signaling (NSS: Famewok, ETF RFC Manne, J., G. Kaagiannis, A. McDonald and S. Van den Bosch, NSLP fo Quality-of-Sevice signaling, ETF ntenet Daft, daft-ietf-nsis-qosnslp-08.txt. 9. Ni, N. and X. Xiao, 999. ntenet QoS: A Big Pictue, EEE Netwoks, 3:2, Westbeg, L., A. Bade, D. Patain and V. Rexhepi, A Poposal fo RSVPv2-NSLP, ETF ntenet Daft, daft-westbeg-poposal-fo-svpv2-nslp- 00.txt. 665