HMRSVP: A Hierarchical Mobile RSVP Protocol Abstract. In this paper, we propose a hierarchical Mobile RSVP (HMRSVP) that can achieve mobility independent QoS guaranteed services in mobile computing environments. The HMRSVP integrates RSVP with Mobile IP regional registration and makes advance resource reservations only when an inter-region movement may possibly occur. We first show that, by NS simulator, our HMRSVP can achieve the same QoS guarantees as MRSVP does with fewer resource reservations. Then, we show that HMRSVP outperforms MRSVP in terms of reservation blocking, forced termination and session completion probabilities. for 1. Introduction Resource reservation Protocol (RSVP) [2,11] is a protocol that can provide QoS guarantees for integrated services on the Internet. However, RSVP cannot be used directly in a mobile computing environment the following two reasons. First,RSVP messages are in visible to the intermediate routers of the IP tunnel used in Mobile IP [7] because the IP tunnel is implemented using an IP-in-IP encapsulation scheme. Second,after a mobile host moves to a new location, the previously allocated resources are no longer available.Some schemes have been proposed to resolve the mobility impact on RSVP in mobile computing environments.The RSVP Tunnel [11] was proposed to resolve the RSVP signaling invisibility problem. The RSVP Tunnel does not support seamless handoffs for QoS guarantees due to the lack of advance reservations in a neighborhood.Mobile RSVP (MRSVP) [9,10] overcomes the handoff impact of mobility on RSVP by making advance resource reservations in all neighboring subnets.However, these excessive resource reservations may demand too much bandwidth and degrade the network performance. In this paper, we propose a new Mobile RSVP Protocol a hierarchical Mobile RSVP(HMRSVP) that can achieve the same QoS -guaranteed seamless handoff as MRSVP does but makes fewer 1 

advance resource reservations. HMRSVP adopts the hierarchical concept of Mobile IP regional registration[5] and makes advance resource reservations for a mobile host only when the mobile host resides in the overlapped area of the boundary cells between two regions. To measure the performance of our proposal, we compare the HMRSVP performance with that of MRSVP in terms of data transmission rate, reservation blocking, forced termination and session completion probabilities using simulations. Numerical results show that HMRSVP, compared with MRSVP, reduces the reservation blocking and forced termination probabilities by 50% and 27%, respectively, when the offered load is 0.6. They also show that HMRSVP improves the session completion probability by more than 8% if the load is larger than 0.6.The rest of this paper is organized as follows. In section 2,we discuss the mobility impact on RSVP in mobile environments. In section 3, we introduce the related research: RSVP Tunnel and MRSVP. The HMRSVP scheme is proposed insection 4. Section 5 presents our simulation models and results. Finally, we make some conclusions in section 6. 2. Mobility impacts on RSVP RSVP is a signaling protocol for Internet resource reservations. Two types of messages, PATH and RESV, are used in RSVP to setup resource reservation states on the nodes along the path between a sender and a recipient. Initially,the sender learns the IP address of the recipient using some out-of-band mechanism and sends a PATH message to the recipient to find a path all the way from the sender to the recipient for a specific flow. When a router receives a PATH message, it will record which upstream router the PATH message was received from and forwards the PATH message to a downstream router. The PATH message is then passed from one to another downstream router and finally received by the recipient. The recipient will respond with a RESV message to make a resource reservation for the specific flow. The RESV message will be transmitted in reverse along the same path as the PATH message was originally transmitted. Upon receiving a RESV message, each router or host on the path will reserve resources for the specific flow if sufficient resources are 2 

available. However, two mobility impacts occur on the original RSVP signaling protocol.First, RSVP is not aware of mobility. According to the original RSVP signaling protocol, the resource reservation path cannot be dynamically adapted along with the movement of a mobile host. In other words, once a mobile host(MH) handoffs to a new region, its prior reserved resources are no longer available and the service quality of the MH may degrade significantly due to the lack of resources reserved for the MH in the new region. Second, IP-in-IP makes RSVP messages invisible. Mobile IP uses an IP-in-IP encapsulation technique [6] to route IP packets correctly to an MH that is away from its home network. If the RSVP protocol is applied,RSVP messages, PATH and RESV, will be encapsulated in an IP-in-IP encapsulated packet with a protocol number as integer 4 in the outer IP header, concealing the original RSVP protocol number46 in the inner IP header. As a consequence,the routers on the path of an IP tunnel cannot correctly recognize RSVP signals to provide the required QoS. 3. Related research In this MRSVP,proposed to resolve the mobility impact on RSVP in mobile environments. technologies,RSVP Tunnel and section, we address two important 3.1. RSVP Tunnel Terzis et al. [12] proposed RSVP Tunnel to resolve the RSVP message invisibility problem. The underlying principle of RSVP Tunnel is to establish nested RSVP sessions between the tunnel end-points, namely entry and exit points. That is, an extra pair of tunnel PATH and RESV messages, without encapsulating IP headers, is sent to establish a QoS-guaranteed communication path between the tunnel entry and exit points.Initially, a sender issues an end-to-end PATH message,which records the addresses of the sender and recipient in its IP header with the RSVP protocol number 46. When the end-to-end PATH message is delivered to the tunnel entry point, it is encapsulated with a new IP header, which records the addresses of the tunnel entry and exit points with the Mobile IP protocol number, 4. The tunnel entry point, after 3 

sending the encapsulated end-to-end PATH message, issues a new tunnel PATH message which records the addresses of the tunnel entry and exit points with the RSVP protocol number 46. On receiving the encapsulated end-to-end PATH message, each router on the path of the tunnel directly forwards the message downstream to the exit point. However, on receiving the tunnel PATH message, each router performs the pathfinding function as described in the original RSVP protocol because the RSVP protocol number 46 is visible in this message. When these tunnel and encapsulated end-to-end PATH messages arrive at the exit point, the encapsulated end-to-end.PATH message will be decapsulated and forwarded to the recipient, while the tunnel PATH message will be processed only by the exit point and need not be forwarded to the recipient. In response, the recipient, on receiving the end-to-end.PATH message, replies an end-to-end RESV message to the sender. In a similar way, when the tunnel exit point receives the end-to-end RESV message, it will tunnel the message to the sender as described before. In addition, the tunnel exit point will also issue a tunnel RESV message to the tunnel entry point. Thus, all routers on the tunnel path, when receiving the tunnel RESV message, can reserve the desired resources for the recipient if sufficient resources are available.Using the above nested RSVP session, RSVP Tunnel can actually resolve the RSVP signaling invisibility problem.However, it does not make advance resource reservations in its neighboring networks. Therefore, if an MH moves to a new foreign region, the MH’s service may be terminated be- cause of the lack of resources in the new region. 4