University of WollongongResearch Online

Faculty of Informatics - Papers (Archive) Faculty of Engineering and Information Sciences

2007

Fast RSVP: a cross layer resource reservationscheme for mobile IPv6 networksYi SunChinese Academy of Sciences

Bin FengChinese Academy of Sciences

Yucheng ZhangChinese Academy of Sciences

Gengfa FangChinese Academy of Sciences

Jinglin ShiChinese Academy of Sciences

See next page for additional authors

Research Online is the open access institutional repository for the University of Wollongong. For further information contact the UOW Library:research-pubs@uow.edu.au

Publication DetailsYi, S., Feng, B., Zhang, Y., Fang, G., Shi, J. & Dutkiewicz, E. (2007). Fast rsvp: a cross layer resource reservation scheme for mobileIPv6 networks. IEEE Symposium on Computers and Communications (pp. 691-697). Portugal: IEEE.

Fast RSVP: a cross layer resource reservation scheme for mobile IPv6networks

AbstractThis paper proposes a new cross layer scheme (Fast (Fast RSVP) RSVP) to reserve resources in mobile IPv6networks. networks. Through the cooperation of mobile IP and RSVP modules, The organ Fast RSVPincludes a number of mechanisms such as ad- introduces re vanced resource reservation on neighbor tunnels,resource RSVP schem reservation on optimized routes, resource reservation for results; Secti handoversessions, path merge etc. Network simulation re- conclusions. sults show that our scheme, compared withother traditional ways to reserve resources in mobile environments, has the 2. Related following advantages:(1) it allows a mobile node to realize fast handover with QoS guarantees; (2) it avoids resource wastingcaused by triangular routes and duplicate In recent reservations; (3) it distinguishes different types of reserva-have carried tion requests, greatly reducing the handover session forced vation schem termination rate whilemaintaining high performance ofthe posals [2-6] network.

DisciplinesPhysical Sciences and Mathematics

Publication DetailsYi, S., Feng, B., Zhang, Y., Fang, G., Shi, J. & Dutkiewicz, E. (2007). Fast rsvp: a cross layer resourcereservation scheme for mobile IPv6 networks. IEEE Symposium on Computers and Communications (pp.691-697). Portugal: IEEE.

AuthorsYi Sun, Bin Feng, Yucheng Zhang, Gengfa Fang, Jinglin Shi, and E. Dutkiewicz

This conference paper is available at Research Online: http://ro.uow.edu.au/infopapers/3055

Fast RSVP: A Cross Layer ResourceReservation Scheme for Mobile IPv6 Networks

Yi Sun, Bin Feng, Yucheng Zhang,Gengfa Fang, Jinglin Shi

Institute of Computing TechnologyChinese Academy of Sciences

{ sunyi,fengbin,zhangyucheng,gengfa.fang,sjlI} @ict.ac.cn

Abstract sions. Thereltion in mobile

This paper proposes a new cross layer scheme (Fast (Fast RSVP)RSVP) to reserve resources in mobile IPv6 networks. networks.Through the cooperation of mobile IP and RSVP modules, The organFast RSVP includes a number of mechanisms such as ad- introduces revanced resource reservation on neighbor tunnels, resource RSVP schemreservation on optimized routes, resource reservation for results; Sectihandover sessions, path merge etc. Network simulation re- conclusions.sults show that our scheme, compared with other traditionalways to reserve resources in mobile environments, has the 2. Relatedfollowing advantages: (1) it allows a mobile node to re-alize fast handover with QoS guarantees; (2) it avoids re-source wasting caused by triangular routes and duplicate In recentreservations; (3) it distinguishes different types of reserva- have carriedtion requests, greatly reducing the handover session forced vation schemtermination rate while maintaining high performance ofthe posals [2-6]network. Reference

nel) to set uEthe problemset up resour(

1. Introduction ing weaknessmechanism.

In recent years, deploying multimedia services in next in the tunnelgeneration mobile IPv6 networks has become an inevitable messages aftctrend. However, multimedia sessions containing real-time Therefore, thvoice and video are very sensitive to delay and delay jit- the time thatter, and hence have strict QoS requirements. To fulfill but has not fithe QoS needs of such multimedia sessions, adequate net- tunnel. (2) Twork resources must be reserved for their transmissions. nel between tThis can be done using the Resource Reservation Protocol session data,(RSVP) [1] that IETF proposed in 1997. However, RSVP Thus resourcis designed for hardwired and fixed networks and when ap- route. (3) Thplying it in wireless mobile environments, a lot of prob- vation requeslems arise: (1) RSVP control messages cannot be identified sessions.in the tunnel; (2) RSVP protocol has no advance resource MRSVP s

reservation schemes. (3) RSVP protocol cannot distinguish support advaresource reservation requests from different kinds of ses- subnet, thus r

Eryk DutkiewiczUniversity of WollongongWollongong, Australia

eryk@uow.edu.au

fore, RSVP is unsuitable for resource reserva-e networks. This paper proposes a new schemeto realize resource reservation in mobile IPv6

iization of the paper is as follows: Section 2lated research work; Section 3 describes Faste in details; Section 4 presents the simulationion 5 summarizes the paper and presents our

Work

years, experts and scholars all over the worldout a lot of research work on resource reser-es in mobile environments and a series of pro-have been made.s [2] and [3] proposed a scheme (RSVP Tun-p RSVP tunnels. The scheme properly solvesthat the traditional RSVP protocol could notce reservation in tunnels, but it has the follow-ses: (1) It has no advance resource reservationIn addition, the setup of resource reservationis triggered by the end-to-end RSVP refresh

er a mobile node hands over to the new subnet.e QoS of session cannot be guaranteed duringthe mobile node hands over to the new subnetinished the resource reservation process in the'he scheme utilizes a resource reservation tun-the Home Agent and Foreign Agent to transmitbut has no route optimization consideration.

,e waste is inevitable because of the triangular-e scheme does not distinguish between reser-sts from new sessions and those from handover

scheme [4] and Multicast RSVP scheme [5]ince resource reservation in handover targetrealizing mobile node handover with QoS guar-

1-4244-1521-7/07/$25.00 §2007 IEEE691

antees. However, these schemes have the following weak-nesses: (1) They require passive resource reservations in allneighbor subnets for a mobile node which may lead to sig-nificant resource wasting. (2) When a mobile node handsover to a new subnet, all the resources reserved for it on theold path become useless, and the schemes do not considertaking full advantage of the resources already reserved onthe old path. (3) The schemes do not distinguish betweenreservation requests from new sessions and those from han-dover sessions.

Reference [6] proposed a link layer assisted multicast-based reservation scheme (LM-MRSVP) utilizing 802.1 lblink layer information to make handover predictions. Thislink layer assisted reservation scheme would effectivelyavoid the over-reservation problem. However, it has the fol-lowing disadvantages: (1) When a mobile node hands overto a new subnet, all the resources reserved for it on the oldpath become useless, and the scheme does not consider tak-ing full advantage of the resources already reserved on theold path. (2) Because the scheme is based on multicast tech-nology, when handover prediction fails, the mobile node hasto rebuild a totally new multi-hop reservation path. Thus thereservation setup time is relatively long and during this pe-riod of time the QoS of the session cannot be guaranteed.(3) The scheme does not distinguish between reservationrequests from new sessions and those from handover ses-sions.

3 Fast RSVP

In the Fast RSVP scheme, a handover process with QoSguarantees could be divided into 2 stages: (1) setup of theresource reservation neighbor tunnel and (2) resource reser-vation on the optimized route. As illustrated in Fig. 1, afterthe mobile node (MN) moves to a new subnet, it first com-municates with the corresponding node (CN) utilizing theresource reservation tunnel which is set up ahead of the han-dover event (illustrated by the solid line in Fig. 1). WhenMN gets stable in the new subnet, it starts the resource reser-vation process on the optimized route. After resources aresuccessfully reserved on the optimized route, the sessionsbetween MN and CN are smoothly switched from the reser-vation tunnel to the new optimized route (illustrated by thedashed line in Fig. 1).

3.1 Resource Reservation on NeighborTunnel

In order to better mark the multimedia sessions in mobileenvironments, Fast RSVP imports a new object MSESSIONto replace the SESSION object in the traditional RSVP pro-tocol. Compared with the SESSION object, MSESSION

Figure 1: Example of Fast RSVP. The solid line depicts the re-source reservation tunnel and the dashed line represents resourcereservation on optimized route after handover.

adds a "home address" field in the object. In mobile envi-ronments, the RSVP router should label a multimedia ses-sion based on the content of MSESSION and set up thecorresponding Path State and Resv State accordingly. FastRSVP relies on the fact that a mobile node can predict itshandover event. This requirement is not hard to be met, anda lot of handover prediction algorithms [7, 8] can be usedhere.

When the mobile IP module of MN predicts that a han-dover event from PAR (Previous Access Router) to NAR(New Access Router) is imminent, it sends an indicationmessage HandoverForecast.ind to RSVP module and tellsthe RSVP module the new care-of address that will beused by MN in NAR's subnet. The RSVP module uti-lizes the new care-of address to form the MSESSION ob-ject and sends a HandoverForecast message (containingMSESSION) to the current access router PAR. When PARreceives the HandoverForecast message, it looks up thematching Path State of the session according to the "HomeAddress", "Dest Port" and "Protocol Id" in the MSES-SION object. Then the RSVP module of PAR extractsthe SENDER TSPEC (defines the traffic characteristics of asender's data flow) [1] contained in the matching Path State,constructs the TunnelPath message accordingly, and sendsthe message to NAR. The TunnelPath message includes theSENDER TSPEC and MN's new care-of address which canbe found in the HandoverForecast message.

When intermediate routers receive the TunnelPath mes-sage, they set up the Path State for the session accordingto the content of MSESSION and forward the TunnelPathmessage to the next hop. Finally, when the router of thehandover target subnet (NAR) receives the TunnelPath mes-sage, it makes advance resource reservation for the sessionlocally and sets up the corresponding Path State, Resv State.After that, NAR replies with a TunnelResv message.

692

When intermediate routers receive the TunnelResv mes-sage, they make advance resource reservation for the ses-sion locally, set up the corresponding Resv State and for-ward the TunnelResv message to the previous hop. Finally,when PAR receives the TunnelResv message, advance re-source reservation on the neighbor tunnel between PAR andNAR successfully completes.

The TunnelPath and TunnelResv messages share thesame format with the Path and Resv messages, except thatthey have a different "Msg Type" field value in CommonHeader to indicate that they correspond to tunnel resourcereservation.

AfterMN hands over to a new subnet, its mobile IP mod-ule sends a BU message to PAR, so that PAR can redirectthe session data to MN's new position. Besides, the mo-bile IP module of MN should check whether the currentsubnet is the same as the predicted handover target sub-net. If it is the same, MN and CN can communicate witheach other through the resource reservation neighbor tun-nel and the QoS of the communication can be guaranteed.Otherwise, the handover prediction is wrong and then themobile IP module of MN should send an indication mes-sage HandoverForecastError.ind to the RSVP module. Thisindication message contains the current in use care-of ad-dress and the formerly falsely predicted care-of address ofMN. When the RSVP module of MN receives this indica-tion message, it sends a HandoverForecastError message toPAR. After receiving the HandoverForecastError message,the RSVP module of PAR extracts MN's current care-of ad-dress and formerly falsely predicted care-of address fromthe payload of the message. Based on this address informa-tion, PAR sends a TunnelPathTear message to release thepreviously mistakenly built reservation tunnel and sends anew TunnelPath message to rebuild the resource reservationtunnel with MN's current subnet. If the handover event doesnot occur within a given time after MN made a handoverprediction, the mobile IP module ofMN should also send aHandoverForecastError.ind message to notify RSVP mod-ule that the handover prediction fails, so that RSVP modulecan send a HandoverForecastError message to PAR to re-lease the resources reserved in advance on the falsely builttunnel.

3.2 Resource Reservation on OptimizedRoute

The use of tunnels induces the triangular route problem,thus causing unnecessary network resource waste. Thus,Fast RSVP should consider how to reserve resources formultimedia sessions on the optimized route. By adding anew cache (Pending Cache) maintained by the mobile IPmodule and utilizing several indication messages betweenthe RSVP module and the mobile IP module, Fast RSVP

scheme can realize resource reservation on the optimizedroute and ensure that the session data are switched from theold path (neighbor tunnel) to the new optimized route seam-lessly.

When MN gets stable in the handover target subnet, itsends a BU message to CN. After the mobile IP module ofCN receives this BU message, it updates the correspond-ing entry of MN in its Pending Cache to record the <homeaddress, care-of-address> pair, and sends a SessionHan-dover.req message to the RSVP module inquiring whetheror not to redirect application data to the new optimizedroute. On receiving the SessionHandover.req message, theRSVP module of CN checks whether the mobile node (in-dicated in the SessionHandover.req message) has multime-dia sessions requiring resource reservation. If the mobilenode (MN) has no such sessions, the RSVP module imme-diately sends a SessionHandover.ind message to the mobileIP module so that all the packets from CN to MN with-out QoS requirements are switched to the optimized routeat once. If MN does have sessions with resource reserva-tion requirements, the RSVP module of CN must start theresource reservation process on the optimized route first be-fore it sends a SessionHandover.ind message to the mobileIP module.

The RSVP module of CN initiates the resource reserva-tion process on the optimized route by sending a Path mes-sage to MN. It extracts the new care-of address and homeaddress ofMN from the SessionHandover.req message andgenerates the MSESSION object accordingly. Then theRSVP module of CN encapsulates the Path message andsends it to MN.

After an intermediate RSVP router on the transmissionpath receives the Path message, it checks whether it alreadyhas the corresponding Path State of the session accordingto the "Home Address" "Dest Port" and "Protocol Id" inthe MSESSION object. If the corresponding Path State isfound, the RSVP module on the router only needs to up-date this state; otherwise, it sets up the corresponding PathState for the session. In addition, the RSVP module on therouter should notify the mobile IP module of MN's homeaddress so that the mobile IP module could fill this addressin "Type 2 Routing Header" [9] when re-encapsulating thePath message.

After the Path message corresponding to the optimizedroute finally reaches MN, the RSVP module ofMN replieswith the proper Resv message. After an intermediate RSVProuter on the transmission path receives the Resv message,it checks whether it already has the corresponding ResvState of the session also according to the "Home Address""Dest Port" and "Protocol Id" in the MSESSION object. Ifthe corresponding Resv State is found, the RSVP moduleon the router only needs to update this state; otherwise, ittries to reserve resources for the session locally and set up

693

the corresponding Resv State.

Finally, when the RSVP module of CN receives the Resvmessage, the resource reservation process on the optimizedroute successfully completes. Then the RSVP module sendsan indication message SessionHandover.ind to the mobileIP module. On receiving this indication, the mobile IP mod-ule of CN updates the proper entry in the Bindng Cache,thus the session data is redirected to the optimized routefrom then on.

Figure 2: Simulation scenario

3.3 Distinguishing Resource ReservationRequests from Different Kinds of Ses-sions

Experience shows that users are more sensitive to ter-minating an ongoing session compared with blocking anew session. So Fast RSVP introduces a new mechanismto distinguish resource reservation requests from differentkinds of sessions, giving handover sessions a higher prior-ity, therefore reducing the forced termination rate of ses-sions due to handover.

In Fast RSVP, we stipulate that each router reserves agiven amount of its resources only to support handover ses-sions. Suppose that the total amount of resources that arouter has is C, the amount of resources specially reservedfor handover sessions is K(K < C) and the amount of re-sources already in use is N(N < C).

When the router receives a reservation request (theamount of resources in request is q), it checks that the re-quest is included in a Resv message or a TunnelResv mes-sage. If the request is included in a Resv message, it meansthat this request is either from a new session or correspond-ing to resource reservation on the optimized route. For thiskind of request, the router would compare N+q and C -K.If the former is not bigger than the latter, the request is ad-mitted, otherwise it is rejected. If the request is included ina TunnelResv message, it means that this request is from ahandover session. For this kind of request, the router com-pares N + q and C. If the former is not bigger than thelatter, the request is admitted; otherwise it is rejected.

Network administrators should establish the exactamount of resource reserved for handover sessions accord-ing to the distribution of different types of sessions in thenetwork.

4 Simulation Results

4.1 Impact of Utilization of Advanced Re-source Reservation Neighbor Tunnelon the QoS of Sessions during Han-dover

The simulation scenario is shown in Fig. 2. Initially, MNstays in the subnet of Router 1 and starts a voice sessionwith CN when simulation time reaches 120s. Then MNmoves towards Router 2 and handover occurs at about 240 s.

Fig. 3 and Fig. 4 respectively depict the end-to-end voicepacket delay for the RSVP Tunnel [2, 3] and for our FastRSVP scheme. It can be seen that in Fig. 3 packets havevery long delays during 240 to 270 s (the longest delay ex-

ceeds 3 s). This is because in the RSVP Tunnel scheme,the setup of resource reservation tunnel is triggered by theevent that MN receives a refresh Path message from CN af-ter handing over to the new subnet. The default value ofthe Path message refresh period in RSVP Tunnel schemeis 30 s, so during this period the QoS of the session can-

not be guaranteed due to the lack of resource reservationin the tunnel. However, in Fast RSVP, because we alreadyreserve adequate resources in the tunnel for MN before ithands over to the target subnet, the QoS of the multimediasessions on MN can be guaranteed (the end-to-end packetdelay is restricted to 0.3 s).

4.2 Impact of Different Tunnel Policies on

Network Performance

In this subsection, we simulated and analyzed the im-pact of different tunnel policies (no tunnel [4-6], hometunnel [2, 3] neighbor tunnel in our scheme) on the net-work performance indicators such as new session block-ing rate, handover session forced termination rate, over-

all session completion rate etc. The simulation parameters

694

.25

9-no tunnel-h home tunnel

neighbor tunnel0.2

O1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

ptime(s)

Figure 3: End-to-end voice packet delay in RSVP Tunnel

m 1.5

0.3

100 150 200 250 300 350 400 450

time(s)

Figure 4: End-to-end voice packet delay in Fast RSVP

are as follows: the arrival of new sessions and handoverevents are both Poisson distributed and the correspondingparameters are As and Ah respectively. The holding timeof new sessions and handover events are both exponen-tially distributed, with the corresponding parameters I/i'sand 1 /Uh. The system capacity is C and the amount ofresources that every session needs is r (evenly distributedbetween rmin and rmax). The system payload intensity isdefined as p = (As r)'(,us C). We define tunnel pro-portion as the ratio of tunnel length to whole path lengthafter handover and its value depends on the specific tun-nel policy. We define new session blocking rate Pb as theprobability that new sessions are blocked due to lack ofsystem resources, and handover session forced terminationrate Pf as the probability that sessions are rejected duringhandover due to lack of system resources. Overall sessioncompletion rate P, is the probability that sessions success-fully initiate without forced terminating during handoversand finally smoothly complete. The exact values of theabove parameters are: As = 10 100 sessions/sec, Us =

0.01 sec- 1,C 10 Mbps, rmin 64 Kbps, rTax =

2Mbps,Ah 100 events/sec,i'h = 0.1secC-. Bychanging AS, we adjust the system payload intensity p, andobserve the variations of Pb, Pf, P, when applying no tun-nel, home tunnel and neighbor tunnel policies during han-dover.

The simulation time is 1 day and the results are shown in

Figure 5: The variation of new session blocking rate Pb as thesystem payload intensity p changes using different tunnel policies.

Fig. 5 to Fig. 7. It can be seen that Pb and Pf both increaseas the system payload intensity goes up. Utilization of thetunnel causes a slight rise in new session blocking rate Pb(home tunnel 2%, neighbor tunnel 5%), but greatly reducesthe forced termination rate of handover sessions (home tun-nel about 4%, neighbor tunnel about 10%). This is becausewhen using the tunnel, the mobile session can make full useof the resources already reserved on the old path and neednot set up resource reservations on a totally new path, so theforced termination rate due to handover can be remarkablyreduced. However, since more system resources are occu-pied by handover sessions, the new call blocking rate mightincrease when the system payload is heavy. The neighbortunnel policy used in Fast RSVP has a larger ratio of reuseof the already reserved resources compared with the hometunnel policy and fewer new resources are needed when re-serving on the neighbor tunnel. Thus the improvement ofhandover session forced termination rate Pf in our schemeis more significant. Also as can be seen from Fig. 7, theoverall session completion rate PC declines as the systempayload intensity increases. Use of the tunnel improves Pc,because the overall session completion rate P, is related tothe new session blocking rate Pb as well as handover ses-sion forced termination rate Pf. The tunnel policy greatlyreduces Pf and only brings a slight rise of Pb when the sys-tem payload is heavy, therefore achieving the improvementin P,

4.3 Impact of Path Merge Mechanism onNetwork Performance

In Fast RSVP we make use of a new mechanism namedPath Merge. The mechanism utilizes Home Address in theMSESSION object to label a mobile node so that when do-ing reservation on the optimized route, duplicate reserva-tions are avoided on the intermediate nodes and links sharedby the old and new routes. Thereby, Path Merge is expectedto improve the network performance.We define a new simulation parameter Path Merge Ra-

695

.. ......P=AOAOA A Z

3.5

2.5

7>1

2IV.2

,v

..d 1.5mCL

1

0.5

0.3

0 -100

z

:,W; .- --. 1. j...". 11 ..'; -- ;-.. -i-<.4: .--4..-

3.5

125

-9 no tunnel-A- home tunnel

neighbor tunnel0.2-

1.15

Figure 6: The variation of handover session forced terminationrate Pf as the system payload intensity p changes using differenttunnel policies.

0.9s \

0.75

0.65 e no tunnel|

-A home tunnel-* neighbor tunnel

0.6

Figure 7: The variation of overall session completion rate P, as thesystem payload intensity p changes using different tunnel policies.

tio rj as the proportion of the shared route length to thewhole route length. The exact values of the simula-tion parameters are: As = 10 100 sessions/sec, /us0.Osec- 1,C = 10Mbps,rmjn - 64 Kbps, rma2Mbps, Ah = 100 events/sec, h = 0.1 sec-1, X0.2 (neighbortunnel), r= 0.6. By changing As, we adjustthe system payload intensity p. The variations of new ses-sion blocking rate Pb, handover session forced terminationrate Pf, overall session completion rate PC and optimizedroute reservation successful rate PO are shown in Fig. 8 toFig. 11 respectively. (The simulation time is 1 day.)

As can be seen from Fig. 11, Path Merge remarkably en-

A- n path merge_,, pathmerge

0.11

0.05

Figure 8: Impact of Path Merge mechanism on the new sessionblocking rate Pb.

Figure 9: Impact of Path Merge mechanism on the handover ses-sion forced termination rate Pf.

Figure 10: Impact of Path Merge mechanism on the overall sessioncompletion rate P,.

0.9X

0.75

no path merge_,, path merge

0.70.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

p

Figure 11: Impact of Path Merge mechanism on the optimizedroute reservation successful rate P0.

Figure 12: Impact of special reservation for handover sessions on

the network performance indicators Pb, Pf and P,.

696

A A"I

- Pb0~~~~~~~~~* Pf

-A Pc

I A2 9

0.8

r T 1 T 1 T _ T

T T1 ----- v

lp &2 0.3 0.4 0.5 0.6.1 0r-- - 0.7 0.8 0.9

p

0.6

"' 0.5

11. 0.4

U: 0.2

hances the optimized route reservation successful rate Po(maintaining above 95%). The reason is obvious; PathMerge avoids duplicate reservations, thus requiring fewernew resources when reserving on the optimized route. Be-sides, simulation results illustrated in Fig. 8 to Fig. 10 in-dicate that Path Merge also brings improvement in Pb, Pfand P, This is because Path Merge enhances the optimizedroute reservation successful rate and this reduces resourcewasting due to the triangular route. Thereby, the networkperformance is improved.

4.4 Impact of Special Reservation forHandover Sessions on Network Per-formance

In order to reduce the handover session forced termina-tion rate, Fast RSVP introduces a new mechanism to re-serve a part of network resources especially for handoversessions. In this subsection, we simulated and analyzed theimpact of this mechanism on network performance. We de-fine a new simulation parameter Handover Reservation Ra-tio ( as the ratio of the amount of resources reserved espe-cially for handover sessions to the total amount of networkresources. The exact values of the simulation parametersare: p = 0.8, Ah = 100 events/sec, Ph = 0.1 sec-0 0.2. The simulation time is 1 day.

Fig. 12 depicts the variations of Pb, Pf and PC as theHandover Reservation Ration ( changes. It can be seenthat with the increase of (, handover session forced termi-nation rate Pf declines, accompanied by the rise of newsession blocking rate Pb. The reason is apparent. Reserv-ing part of network resources for handover sessions giveshandover sessions a high priority thus making handoverresource reservation requests more likely to be accepted.Meanwhile, the amount of resources left for new sessionsdecreases, making new sessions more likely to be rejected.It should be noted that in our simulation scenario the over-all session completion rate PC declines as ( gets larger. Byobserving the curve variation trends in Fig. 12, we can findthat when ( is small, Pf declines faster and PC declinesslower; but when ( is large, Pf declines slower and PC de-clines faster. Therefore, in real systems, network adminis-trators should establish the proper amount of resources re-served for handover sessions according to the distributionof different kinds of sessions, so that the handover sessionforced termination rate is reduced while the new sessionblocking rate and overall session completion rate is not se-riously deteriorated.

5 Conclusion

Aiming at supplying QoS guarantees to multimedia ses-sions, we proposed a new scheme, Fast RSVP, to reserve

network resources in mobile IPv6 networks. The scheme,with the cooperation of the mobile IP and RSVP modules,can help a mobile node realize fast handover with QoS guar-antees. Also, through the new mechanisms such as resourcereservation on the optimized route and Path Merge, FastRSVP avoids the resource wasting problem due to trian-gular routes and duplicate reservations. In addition, FastRSVP introduces a new way to distinguish reservation re-quests from different types of sessions, giving handoversessions a higher priority and thus greatly reducing thehandover session forced termination rate while maintaininghigh performance of the network.

References

[1] R. Braden and L. Zhang. Resource Reservation Pro-tocol (RSVP) - version 1 functional specification.RFC2205, Sep 1997

[2] A. Terzis, M. Srivastava and L. Zhang. A Simple QoSSignaling Protocol for Mobile Hosts in the IntegratedServices Internet. In Proc. of INFOCOM1999, NY, pp1011-1018

[3] A. Terzis, J. Krawczyk, J. Wroclawski and L. Zhang.RSVP Operation over IP Tunnels. RFC2746, January2000

[4] A. K. Talukdar, B. R. Badrinath and A. Acharya.MRSVP: A Resource Reservation Protocol for an Inte-grated Services Network with Mobile Hosts. In WirelessNetworks Vol. 7 2001, pp 5-19

[5] W. Chen and L. Huang. RSVP Mobility Support: A Sig-naling Protocol for Integrated Services Internet withMobile Hosts. In Proc. of INFOCOM2000, Tel Aviv,Israel, pp 1283-1292

[6] H. Jeon, M. Kim, K. Lee, J. Mo and D. Lee. Link LayerAssisted Multicast-Based Mobile RSVP(LM-MRSVP).In Proc. of 1COIN2005, Cheju Island, Korea, pp 452-462

[7] V. Bharghavan and M. Jayanth. Profile-based Next-cellPrediction in Indoor Wireless LAN. In Proc. of IEEESICON' 97.

[8] J. Capka and R. Boutaba. Mobility Prediction in Wire-less Networks Using Neural Networks. In Proc. ofthe 7th International Conference on Management ofMultimedia Networks and Services (MMNS2004), SanDiego, California, USA, October 3-6, 2004.

[9] D. Johnson, C. Perkins and J. Arkko. Mobility Supportin IPv6. RFC3775, June 2004

697