Introducing Reliability and Load Balancing in Mobile IPv6 based Networks

Transcription

1 Introducing Reliability and Load Balancing in Mobile IPv6 based Networks Jahanzeb Faizan Southern Methodist University Dallas, TX, USA Hesham El-Rewini Southern Methodist University Dallas, TX, USA Mohamed Khalil Nortel Networks Richardson, TX, USA Abstract With the recent advances in portable devices and wireless networks, a new paradigm of computing has emerged which is known as mobile computing. In general mobile computing can be seen as an integration of portable device and networks that support mobility, providing anytime, anywhere communication. IP mobility allows seamlessly mobility between different access networks and technologies. Mobile IPv6 is an enabling platform for creating IP mobility in the evolution path towards next generation service offerings. However, Mobile IPv6 does not provide reliability and load balancing in the network. In this paper, we introduce Virtual HA Reliability Protocol. It is an extension to Mobile IPv6 that introduces reliability and load balancing in the Mobile IPv6 bases networks. It also provides solutions to the problems caused due to Home Agent failures in Mobile IPv6. These problems are: delayed failure detection, service interruption in the upper layer applications, increased workload on the Mobile Node, message overhead over the air interface, and IPsec Security Associations re-establishment. We also present the results of several experiments to assess the performance of our solution. The results show that our solution provides transparent Home Agent failure detection and recovery mechanisms. As a result, there is a significant reduction in message exchange over the air interface. Also, our solution provides high service availability in the upper layer applications. Moreover, there is reduced workload on the Mobile Node. Finally, the load balancing mechanism of our solution provides efficient, dynamic and transparent load balancing among the multiple Home Agents. Thus our solution improves the overall Mobile IPv6 and upper layer applications performance. 1. Introduction The goal of cellular mobility standards has been to provide global connectivity without involving network layer. Among these standards are, General Packet Radio Service (GPRS) and Wideband Code Division Multiple Access (WCDMA). They provide mobility using link layer. In link layer mobility, access to IP networks is through one specific IP router. This could result in inefficient routing in certain cases, especially if the node is roaming in a visited network that is located far away from the home network and local services are used. In this case, the routing will be inefficient. Another case is when multimode node moves from WCDMA coverage to a Bluetooth or Wireless Local Area Network (WLAN) coverage area. In this case, it is given a new IP address. As a result of IP address change, existing application connections will be lost and need to be restarted. A feasible solution is to use network layer mobility or IP mobility. It allows packets sent to the home address to be delivered to the Mobile Node regardless of its current location. It also hides any address changes from the transport and application layers. This enables the Mobile Node to roam seamlessly between different access networks and technologies. Mobile IP was originally defined in [1], as the mobility extension in IPv4. This definition has suffered from the fact that mobility support for IPv4 is an add-on, and the vast majority of IPv4 nodes do not support Mobile IP. It faced problems such as triangular routing, deployment problem, ingress filtering, authentication, authorization, shortage of globally routable IPv4 addresses and use of private IPv4 addresses with Network Address Translators. Above all, single point of failure problem of the Mobile IPv4 Home Agent, hampers its deployment in many cases. Detailed discussion of these problems can be found in [2], [3], [4], [5], [6] and [7]. 1

2 Mobile IPv6 [2] is the solution to the problems of Mobile IPv4. They both share similar ideas, but their infrastructure, overall operation and implementations are different. The benefits of Mobile IPv6 compared to Mobile IPv4 include some of the following: built-in multiple Home Agents support to avoid single point of failure problem, huge IPv6 address space, address auto configuration, simplified Care-of address assignment, ease of address management, optimized routing, reduced transport delay, efficient utilization of network capacity, no need for Foreign Agents, and IP Security [8] for all security requirements. Moreover, Mobile IPv6 is a highly feasible mechanism for implementing static IPv6 addressing for the Mobile Nodes. The Mobile Node can always be reached using the same globally unique IPv6 address, independent of its current location. In Mobile IPv6, each Mobile Node is identified with a static home address, independent of its current point of attachment to the Internet. The home address is stored at the Home Agent. When the Mobile Node is attached to a foreign link, it is addressable by a Care-of address, in addition to its home address. There may be several Careof addresses defined for the Mobile Node. However, only one is bound to a specific home address at any one time. It is known as the primary Care-of address. The Care-of address provides information about the Mobile Node s current location. The mapping or association between the current Care-of address and the home address is called Binding. In Mobile IPv6, Mobile Node registers and establishes a connection with only one Home Agent, which provides continuous service to it. The Mobile Node is reliant on this Home Agent for its connectivity. A Home Agent may be responsible for multiple Mobile Nodes on the Home Link. The failure of a single Home Agent may then result in the loss of connectivity for numerous Mobile Nodes. A Mobile Node cannot afford the loss of its serving Home Agent. Thus, Home Agent represents the possibility of a single point of failure for Mobile IPv6 network. To overcome this problem, in contrast to Mobile IPv4, the Mobile IPv6 allows deployment of multiple Home Agents on the Home Link. This is done so that upon the failure of the serving Home Agent, another Home Agent can take over the functions of failed Home Agent. This provides continuous service to the Mobile Nodes registered with the failed Home Agent. However, the transfer of service from the failed Home Agent to a new Home Agent is problematic. There are problems of delayed failure detection, service interruption in the upper layer applications, increased workload on the Mobile Node, message overhead over the air interface, and IPsec Security Associations re-establishment. The current specification of Mobile IPv6 does not provide solution to these problems. We identified these problems in our IETF draft [9]. In this paper we introduce Virtual Home Agent Reliability Protocol (VHARP) as a complete system architecture and extension to Mobile IPv6. It supports reliability and load balancing in Mobile IPv6 based networks. It also offers solutions to the reliability problems associated with Mobile IPv6. This work is the extension of our preliminary work presented in [10] and [11]. We also present performance analysis based on the simulation results collected using OPNET. In the rest of the paper, we will use the abbreviations listed in Table 1. The remainder of this paper is organized as follows. Section 2 presents the previous work done in this area. Section 3 proposes our solution. Section 4 presents the experimental results and makes comparison between our proposed solution, Mobile IPv6 and other related solutions. Finally, conclusion and future work are outlined in section 5. VHARP MN HA CN IPsec SA RAN DHAD BU BA GPRS WCDMA WLAN MTBF 2. Related work Virtual Home Agent Reliability Protocol Mobile Node Home Agent Correspondent Node IP Security Associations Radio Access Network Dynamic HA Address Discovery Binding Update Binding Acknowledgment General Packet Radio Service Wideband Code Division Multiple Access Wireless Local Area Network Mean Time Between Failures Table 1. Abbreviations Mobile IPv4 reliability and load balancing solutions have been proposed in [3], [4], [5], [6], [7], [12], [13] and [14]. For Mobile IPv6 related work was presented in [15], [16] and [17]. However, Mobile IPv4 solutions could not be applied to solve the reliability and load balancing problems in Mobile IPv6. This is due to the reasons stated below. In Mobile IPv4 there exists a single HA at the Home Link serving the MN. This makes the Mobile IPv4 prone to single point of failure problem. To overcome this problem, the Mobile IPv4 solutions propose HA redundancy. However, this is not the issue in Mobile IPv6. In Mobile IPv6, multiple HAs are supported at the Home Link. Thus, there is no single point of failure problem. 2

3 Regarding the load balancing, the solutions related to Mobile IPv4 start by proposing multiple HA support extension and then provide load balancing mechanism. However, this is not the case for Mobile IPv6 in which multiple HAs support is built-in. Mobile IPv4 and Mobile IPv6 have different architecture, design and functionality. So any solution based on Mobile IPv4 could not be used to solve the problems associated with Mobile IPv6. However, in this paper we discuss Mobile IPv4 and Mobile IPv6 based solutions Mobile IPv4 based Solutions In [3], active and standby HAs are used to provide continuous service in case of HA failures. The HAs exist on the different links, but provide single virtual view. This was done by introducing a new addressing scheme for the HAs. According to it, all the HAs have unique Mobile-IP subnet addresses but same HARP peer address. All the requests are handled by the active HA and synchronized with the standby HA. Each HA continuously inform each other about its availability. In this solution, there is a significant application message overhead and service interruption involved during failure detection and recovery. The failure detection takes considerable amount of time. Moreover, no consideration is given to IPsec authentication. The approach presented in [4] is quite similar to that of [3]. In contrast to [3], multiple standby HAs could exist. There exist delayed failure detection and service interruption problems. Also IPsec authentication is not discussed in this approach. It also provides static load balancing among the HAs by assigning set of MNs to each HA. However, this load balancing solution is not flexible enough to accommodate the dynamic nature of subnets. In [5], to avoid registration synchronization, a new approach of check pointing and logging of MN Bindings in a stable storage was suggested. The overall operation is similar to [3] and [4]. But unlike [3] and [4], after any HA failure the lost Bindings could be restored from the stable storage. In this solution, it was assumed that the stable storage is invulnerable. Also, there exist delayed failure detection and service interruption problems. Also IPsec authentication is not discussed in this approach. In [6], the idea of active and standby HAs was extended to peer HAs. So instead of active HA processing all the requests, all peer HAs are involved in processing requests. The final result is then synchronized with all the HAs. It also provides load balancing among the peer HAs. However, there exist delayed failure detection and service interruption problems. Also IPsec authentication is not discussed in this approach. In [7], similar idea of active and standby HAs, used in [3], [4] and [5] is used with some modifications. A Token mechanism is introduced to assign any HA as the new active HA after the active HA failure. Also in contrast to previous solutions, only one advertisement message is sent. It does not discuss IPsec authentication mechanisms. It also provides dynamic load balancing based on floating token and load threshold. According to this protocol HA gets overloaded when its load exceeds the load threshold value. Upon this it will transfer some of its load to the least loaded HA. Alternatively, it could also release the floating token so that the least loaded HA could acquire the floating token and process the incoming requests. The approach of [12] is for Mobile IPv4 based Cellular networks. This protocol introduces some extra intelligence in the Radio Access Network (RAN). RAN initiates handoff to recover the failure of foreign agents. Also according to it, the HA failure detection and recovery is done by the routers present on the Home Link. This approach has a deployment problem due to dependency on RANs and other cellular components, instead of Mobile IPv4 components. Moreover, there exist delayed failure detection and service interruption problems. Also IPsec authentication is not discussed in this approach. In [13], dynamic load balancing based on serving time, packet count and queue threshold policies has been proposed. In this protocol when any HA gets overloaded it de-registers the MN Binding and sends registration message to the least loaded HA on the Home Link. The approach presented in [14] is quite similar to that in [13], except that double threshold policy is used for the queue instead of single threshold policy Mobile IPv6 based Solutions In [15], HA reliability and load balancing mechanisms are proposed for Mobile IPv6. According to it, the failure detection and recovery mechanisms are transparent to the MN. However, they are not completely transparent. Consider a case when a serving HA fails and Binding expiration happens, update or Prefix expiration occur at the same time. In this situation, since MN would not have any information about its new serving HA, it will send all the signaling packets to the failed HA. In return MN will not get any reply because the HA is not operational. This will let the MN determine that its serving HA has failed and it has to register with a new HA on the Home Link. The MN will then start a new Home Registration process. Thus, the failure detection and recovery are not transparent to the MN anymore. Moreover, MN does not have any information about the new serving HA. So it will continue tunneling the 3

4 packets destined for a Correspondent Node (CN) using the failed HA s IP address. As a result, the packets will eventually be dropped and the applications will face service interruptions. This solution does not encounter the problem of IPsec SA re-establishment with the new HA. Also in this protocol, a dynamic load balancing mechanism for Mobile IPv6 based on Dynamic HA Address Discovery (DHAD) [2] is provided. According to which, MN always performs DHAD to select the least loaded HA among multiple HAs on the Home Link. MN then registers its Bindings with this least loaded HA. However, it is not specified how the load balancing is going to take place when any HA gets overloaded because of the increased data traffic of the already registered MNs. In [16], HA reliability and load balancing solution for Mobile IPv6 is proposed. In this protocol multiple HAs are provided over different Home Links. MN has to register its Binding in one or few of them. MN then selects one of the HAs as its primary HA. Primary HA or any other HA can tunnel packets from CN to MN. Upon the failure of primary HA, MN can switch its service to any other HA on any Home Link. This protocol extends the fundamental requirement for the HA as defined in Mobile IPv6, that all the HAs should exist on the same link. It has modified this requirement by allowing the HAs to exist over different Home Links. This extension does not improve overall performance, rather it increase operational complexity and message overhead. Also similar to Mobile IPv6, failure of the primary HA is not transparent to the MN. This causes service interruption in the upper layer applications and extra workload on the MN. Also, it does not encounter the problems of delayed failure detection and IPsec SAs with the new HA. Moreover, it involves multiple Home Registrations overhead by the MN with different HAs over different Home Links. Similar to [15], the load balancing mechanism is based on DHAD. The extension is that when any HA gets overloaded it will notify the MN to reregister its Binding with another least loaded HA on the Home Link. In [17], a load balancing mechanism is proposed for Mobile IPv6. In this protocol MN registers its Binding with only one HA over the Home Link. When this HA gets overloaded due to increased network traffic, it selects a new HA on the Home Link. Then it sends a HA Switch Request message to some of its registered MNs. These MNs will then first deregister their Bindings with their currently serving HA and then register again with the new proposed HA. Thus, the load balancing mechanism proposed in this solution is based on DHAD and MN initiated load balancing, similar to [15] and [16]. Moreover, this protocol does not discuss HA failure and recovery and all the problems discussed in our IETF draft [9] are still unsolved. In all these protocols, except [7], failure detection, failure recovery and load balancing mechanisms are initiated by the MN. Also they are not transparent to the MN and CN. This results in extra message overhead over the air interface, unfair load distribution among the HAs, extra message processing workload on the MN, service interruption in upper layer mobile applications, and overall system performance degradation. 3. Virtual HA Reliability Protocol Our Proposed Solution We introduce VHARP as a solution to the reliability and load balancing problems in Mobile IPv6. We extend the Mobile IPv6 functionality, operation and architecture to provide HA failure detection, recovery and load balancing mechanisms. The main difference between VHARP and other solutions is that VHARP provides HA initiated failure detection, failure recovery and load balancing mechanisms. Whereas, in other protocols these mechanisms are MN initiated. This makes it possible to introduce transparent failure detection, recovery and load balancing in Mobile IPv6. Other solutions are not transparent to the MN. We also present the results of many experiments we conducted to assess the performance of our solution. The results show that our solution provides transparent HA failure detection and recovery mechanisms. As a result, there is a significant reduction in message exchange over the air interface. Also, our solution provides high service availability in the upper layer applications. Moreover, there is reduced a workload on the MN. Finally, the load balancing mechanism in our solution provides efficient, dynamic and transparent load balancing among the multiple HAs. Thus our solution improves the overall Mobile IPv6 and upper layer applications performance VHARP Architecture VHARP extends Mobile IPv6 to provide reliable and load balanced operation. It interacts with IPv6, ICMPv6, IKEv2, IPsec and other network layer protocols just like Mobile IPv6. VHARP achieves HA reliability and load balancing by introducing some modifications in Mobile IPv6. These modifications are related to addressing scheme, operating states, supported services, data structures, signaling and data delivery mechanisms of HA. It does not introduce any change in the architecture and functionality of the MN, CN, IPv6 routers or Host. The implementation and deployment of VHARP over existing Mobile IPv6 based networks only requires updating the HA software on the all the HAs on the Home Link. Thus, VHARP deployment over the existing Mobile IPv6 based 4

5 Figure 1. Single Virtual HA view of the multiple HAs in VHARP networks is easy, feasible, inexpensive and fast. Global HA address: One of the major contributions of VHARP towards reliability and load balancing in Mobile IPv6 is the transparency of failure detection, recovery and load balancing. This would not be possible if VHARP would not have provided single virtual HA view for the multiple HAs on the Home Link. VHARP achieves this by changing the scheme HAs are assigned IP addresses in Mobile IPv6. According to the current specification of Mobile IPv6, all the HAs have unique link-local and global IP address. This way each HA is accessible directly to the MN and CN. However, according to VHARP, each HA has a unique link-local IP address but all the HAs have the same global IP address known as Global HA address. This Global HA address is resolved only to one of the multiple HAs on the Home Link. This HA is the owner of the Global HA address and it is known as the Active HA (explained in detail below). MN and CN are only aware of the Global HA address. This allows the MN and CN to send all the packets using Global HA address as the destination IP address. Also packets from any HA to MN and CN are sent using Global HA address as the source IP address. As a result, this modified HA addressing scheme of VHARP provides a single virtual HA view to MN and CN for the multiple HAs coexisting at the same Home Link. This leads to transparent HA failure detection, failure recovery and load balancing mechanisms. This transparency is provided in Mobile IPv6 and other reliability and load balancing protocols. HA Operating States: Besides the Global HA address, other major change introduced by VHARP in Mobile IPv6 is the operating states of the HA. In VHARP all the HAs at the Home Link do not operate equally. Each HA operates in one of three states, namely Active HA, Backup HA or Inactive HA. This results in efficient resource utilization. It also avoids unnecessary message overhead arises as the result of operating a router as a HA with all the Mobile IPv6 services enabled. HA Front End Process: Each HA provides Mobile IPv6 services based on its operating state. The number of supported services decreases as the HA state changes from Active to Backup and to Inactive. Thus, Active HA provides all the Mobile IPv6 services and Inactive HA provides minimum services. Backup HA provides a mid range of services. In VHARP, this set of services is known as Front End Process. HA Binding Cache: In order to provide resilience in the Binding established by the MN, VHARP has modified the Mobile IPv6 Binding Cache originally defined in [2]. VHARP has introduced some new fields required to provide reliability and load balancing. These new fields are Binding Owners List, Number of Binding Owners and 5

6 Load. For implementation details refer to our technical report [18]. HA List: In Mobile IPv6, the HA List is maintained by each HA, to record information about each HA on the Home Link. VHARP has modified it by adding two new fields, namely State and Load Factor. This modification is required to provide transparent failure detection, failure recovery and load balancing mechanisms. For details refer to out technical report [18]. Active HA: Active HA is the core entity of VHARP. There must be present an Active HA on the Home Link. There could be no more than one HA acting as the Active HA on the Home Link at any instance of time. Active HA is the owner of the Global HA address for the entire Home Link. Thus, the Global HA address will always be resolved to the Link Local IP address of the Active HA. Edge router or the directly intercepting HA will intercept the packets send by the MN. These packets will always have the destination IP address equal to the Global HA address. They will be forwarded to the Active HA for processing. The Active HA plays a unique role among all other HAs on the Home Link in terms of the services provided by it. It provides such HA services which are not provided by the Backup HA or Inactive HA. These are known as Exclusive Services. The Exclusive Services mainly includes Home Registration, De-registration, Registration Refresh, IKE, and DHAD. Besides these, it provides the regular HA services such as Tunneling, Reverse Tunneling, Return Routability, and IPv6 Neighbor Discovery. Thus, the Front End Process of the Active HA includes regular as well as Exclusive HA services. Detailed description of the Front End Process of the Active HA could be found in our technical report [18]. Active HA could hold [0-N] Bindings, where N is a positive integer. Active HA provides data delivery services for the Bindings contained in its Binding Cache as well as signaling services for the entire network. Backup HA: Besides Active HA, there could exist one or more Backup HAs on the Home Link. The purpose of the Backup HA is to provide continuous HA services in case of HA failures or overloading. The Backup HA could hold [1-N] Bindings in its Binding Cache. A HA must hold at least one Binding in order to become Backup HA. Any HA operating in the Backup state only provides its services to the Binding(s) stored in its Binding Storage. There is no limit on the number of Backup HAs on the Home Link. The Front End Process of the Backup HA includes all the services of Active HA except of the Exclusive Services. Inactive HA: The Inactive HA is the one which does not hold any Binding in its Binding Storage. Thus any HA on the Home Link other than the Active HA and Backup HA acts as an Inactive HA. Its Front End Process includes a subset of the Backup HA services. It mainly involves basic IPv6 routing and Mobile IPv6 HA forwarding and intercepting services. Based on the different HA states and the services provided by them, VHARP provides resilience in the MN Binding against HA failures and overloading. This results in uninterrupted and continuous Mobile IPv6 operation in case of HA failures and overloading. VHARP achieves this resilience by making more than one HA hold the Binding of MN. So that in case of a HA failure or overloading, another HA could provide service to the MN. VHARP requires that for each MN there should be at least two HAs holding its Binding in their Binding Storage (based on the simulation result presented in [18]). These HAs are known as the Binding Owners for the MN. For a single MN the Binding Owners could be the Active HA and one or more Backup HAs or could only be two or more Backup HAs. Besides the HA, VHARP utilizes Edge Routers in providing reliable Mobile IPv6 operation. The use of Edge Routers is optional. VHARP failure detection, recovery and load balancing mechanisms work with and without the Edge Routers. Edge Routers are basically entry points for the network and all the incoming and outgoing packets are intercepted and routed by them. The Edge Router could be an IPv6 Router dedicated as the Edge Router. If no dedicated Edge Router exists on the Home Link, then any HA could also act as an Edge Router. Due to the HA changes introduced by VHARP, the Edge Router has become more intelligent. It will forward all the incoming packets with the destination IP address equal to the Global HA address to the Active HA. Also it will forward all the incoming packets with the destination IP address equal to the MN s Home address to the least loaded HA among the Binding Owners of the MN. Figure 1 illustrates six HAs in different states. There is Active HA, Backup HA and Inactive HA. Based on the VHARP addressing scheme all the HAs present a single virtual HA view to the MN and CN Home Agent State Transition The state transition model of VHARP involves Active, Backup and Inactive as the HA states and several transitions. These transactions are explained below and illustrated in figure 2. Transition 1: Transition from Backup to Active state will occur when the current Active HA fails. In this situation a Backup HA will become the new Active HA if it has the lowest load among all other HAs on the Home Link. Ties are broken in favor of the lowest Link-Local address suffix. Transition 2: When a Backup HA fails, it will always be in the Inactive state after its restoration. 6

7 6 Inactive Active Backup 8 Figure 2. VHARP State Transition Model 7 Active HA gets overloaded due to the exclusive services and it is also serving as the Binding Owner for MN(s). This is different from transition 4, in which Active HA also gets overloaded due to the exclusive services but it is not serving as the Binding Owner for any MN i.e. its Binding Cache is empty. This transition will cause all the HAs to execute the failure recovery procedures (discussed in section 3.6) and as the result a new Active HA will take over VHARP Registration Process Transition 3: When an Active HA fails, it will always be in the Inactive state after its restoration. Also, in case Active HA gets overloaded due to its exclusive services and no Binding exists in its Binding Cache, then it will change its state from Active to Inactive. Transition 4: Transition from Inactive to Active state could occur when the current Active HA fails or it has changed its state from Active to Backup or Inactive. In this situation an Inactive HA will become the new Active HA if it has the lowest load among all other HAs on the Home Link. Ties are broken in favor of the lowest Link-Local address suffix. Transition 5: Transition from Inactive to Backup state could occur when a Binding Owner of certain Binding(s) fails. In this situation in order to keep the number of Binding Owners the same before and after the failure of the Binding Owner a new Binding Owner will be created for the Binding(s) hold by the failed Binding Owner. So any Inactive HA could become the new Binding Owner and as a result its state will change to Backup, if it has the lowest load among all other HAs on the Home Link. Ties are broken in favor of the lowest Link-Local address suffix. Same transition will also occur in case when Active HA or Backup HA gets overloaded and more Binding Owners needs to be created. In this situation an Inactive HA will become Backup HA if it is has the lowest load among all other HAs on the Home Link. Transition 6: This is self- transition of the Active HA and is similar to transition 5. In this transition, upon the failure of any Binding Owner or due to overloading of the Backup HA, the Active HA could become the new Binding Owner and as a result remains in the Active state, if it has the lowest load among all other HAs on the Home Link. Ties are broken in favor of the lowest Link-Local address suffix. Transition 7: This is self-transition of the Backup HA and similar to transition 5. In this transition, upon the failure of any Binding Owner or in case of overloading of the Active HA or the Backup HA, any Backup HA could become the new Binding Owner and as a result remains in the Backup state, if it has the lowest load among all other HAs on the Home Link. Transition 8: Transition from Active to Backup state could occur when the current In VHARP, more than one Binding Owner are created as part of the registration process. The Binding Owners are created by means of Binding Synchronization among the HAs on the Home Link. VHARP requires that only the Active HA should perform Home Registration. So when MN sends a registration request, a registration refresh or a de-registration request, known as Binding Update (BU), the Edge Router or any HA acting as the Edge Router will intercept it. Then it will be forwarded to the Active HA, because the Global HA address is owned by the Active HA. The Global HA address ownership could be known by any node (router, host or HA) through IPv6 Neighbor Discovery [19]. The steps performed by the Active HA in the Home Registration for a MN s Binding are discussed below. The result of these steps is that there exists at least two Binding Owners for the MN s Binding on the Home Link. 1. Active HA will perform IPsec Authentication. As specified by Mobile IPv6, all the packets received and sent by HA should contain valid ESP header [8]. The IPsec Authentication involves validating the ESP header through methods described in [20] and specified by Mobile IPv6. VHARP does not modify any of these. This authentication allows the HAs to protect the Mobile IPv6 network and CNs from malicious nodes masquerading as MN. 2. Active HA will perform Binding Update Validation according to normal specifications of Mobile IPv6. 3. Active HA will find out if there exist any Backup HA(s) already working as the Binding Owner(s) for this MN. 4. Active HA will process the Binding according to Mobile IPv6 specification and perform atomic database commit in its Binding Storage. 5. Active HA will perform Binding Synchronization process with already existing Binding Owner(s) found out in step 2 if any. Otherwise, it will select potential HA(s) and make them Binding Owner(s) by Binding Synchronization process. VHARP requires that at least two Binding Owners should exist on the Home Link for each MN at all times for high reliability and 7

8 Figure 3. Registration Process of VHARP service availability. Simulation was done in [18] to find out the optimal minimum number of Binding Owners. It was observed that maintaining at least two Binding Owners all the time on the Home Link for each MN will provide high service availability. 6. After successful Binding Synchronization, Active HA will perform IPsec SA Synchronization. It is done to synchronize the updated parameters of MN s IPsec SA with all other HAs on the Home Link. In IPsec SA Synchronization, IPsec SA is always multicast to all the HAs. 7. Active HA will send Binding Acknowledgment (BA) message to the MN. 8. All the Binding Owners will inform all other HAs about their Binding Ownership. 9. The least loaded Binding Owner will become the serving HA for the registered MN. (Selecting the least loaded Binding Owner will be discussed in detail in section 3.7) Figure 3 illustrates the registration process of VAHRP VHARP Data Delivery Mechanism VHARP has also modified the Mobile IPv6 data delivery mechanism. The purpose of modifying the data delivery mechanism is to provide efficient utilization of multiple HA present on the Home Link. As we discussed in the previous section, the registration process of VHARP will create multiple Binding Owners for each MN. Now for each MN there exists multiple HAs capable of providing data delivery service. VHARP requires that the least loaded Binding Owner will always serve the MN. Selecting the least loaded Binding Owner will be discussed in detail in section 3.7. This HA will be called as the serving HA for the MN. This is in contrast to Mobile IPv6, in which only one HA is always the serving HA. This modified data delivery mechanism of VHARP also helps in avoiding traffic bottleneck at a single HA. In Mobile IPv6 the data packets are known as Payload Packets. The data delivery mechanism of VHARP works differently for the following two cases. Case 1: CN MN Payload Packet sent by the CN to MN will be a normal packet. In the header the destination IP address will be the MN s Home address. The source IP address will be the CN s Internet IP address. An IPv6 Router or any HA acting as the Edge Router for the Home Link will intercept the packet. It will find out the Link-Local IP address for the MN s serving HA in its Neighbor Cache. If there is no entry, then it will send Neighbor Solicitation message as defined in [21] for the target MN s Home Address. As a result it will come to know about the serving HA of the MN. Then it will forward the packet to the serving HA of the MN. If the intercepting HA is itself the serving HA for the MN then it will process the packet. The following steps will be performed by the serving HA of the MN. 1. IPsec Authentication. 2. Tunneling, which includes encapsulating and routing the packet to the MN according to normal operation of Mobile IPv6. Case 2: MN CN Payload Packet sent by the MN to CN will be an encapsulated packet. The header will contain the 8

9 destination IP address as the Global HA address and the source IP address as the Care-of address. If the IPv6 Router or an Inactive HA intercepts the packet, it will forward it to the Active HA. The Active HA or Backup HA could also intercept this packet directly if it is acting as the Edge Router on the Home Link. The following steps will take place by the Active HA or Backup HA. 1. IPsec Authentication. 2. Find out the Link-Local IP address for the MN s serving HA in its Neighbor Cache. If there is no entry, it will send Neighbor Solicitation message as defined in [21] for the target MN s Home Address. 3. Forward the packet to the serving HA of the MN. If the HA is itself the serving HA for the MN, it will process the packet. 4. The serving HA of the MN will perform Reverse Tunneling which includes packet de-encapsulation, validation and forwarding to the CN according to normal operation of Mobile IPv6. It is also possible that MN and CN exchange packets directly without involving the HAs on the Home Link. This will only happen when the CN is Mobile IPv6 enabled and MN has registered its Binding through Return Routability procedure defined by Mobile IPv6. In this case there is no need to route the packets through HA and the current routing mechanism defined by Mobile IPv6 will be sufficient. Moreover, according to VHARP the Prefix Discovery mechanism of Mobile IPv6 is similar to the data delivery case 2 except that the least loaded Binding Owner will process the request and send reply to the MN. Also the Return Routability mechanism of Mobile IPv6 will follow the data delivery cases 1 and Failure Detection in VHARP VHARP provides a transparent, HA initiated and fast failure detection mechanism. This is in contrast to Mobile IPv6 and other reliability solutions, where failure detection is not transparent, MN initiated and slow. VHARP achieves these benefits by adopting an approach similar to the one introduced by one of the authors in [7]. It involves exchange of Heart Beat messages on the Home Link. The Heart Beat messages are multicast by each HA over the Home Link at a constant rate. Each HA expects Heart Beat messages from all other HAs at this rate. When any HA fails, all other HAs will not receive Heart Beat from it and thus find out that this HA has failed. Also each HA has its state identified in the Heart Beat. So this way all the HAs on the Home Link know about the state of the failed HA. This allows the MN to remain unaware of the HA failures taking place on the Home Link. Experiments show that this transparent and HA initiated failure detection mechanism of VHARP significantly reduces message overhead over the air interface. Moreover, it reduces workload on the MN which usually operates under limited power and less processing capabilities constraints. The Heart Beat message is actually the Router Advertisement message of Mobile IPv6 which is multicast by each router at a constant rate R H. In Mobile IPv6 this message is used for IPv6 Neighbor Discovery [21] mechanism. VHARP has modified this message (as defined in our technical report [18]) to accommodate the HA failure detection as well. In VHARP, HA failure detection time depends on the value of R H. The smaller the value of R H, the quicker will be the failure detection. However, the overhead at the Home Link will be higher as R H gets smaller Failure Recovery in VHARP Similar to failure detection, Mobile IPv6 and other reliability solutions propose non transparent, MN initiated and slow HA failure recovery mechanism. VHARP provides failure recovery mechanism, which is completely transparent to the MN, HA initiated and fast. After HA failure and its successful detection, no action is required by the MN. The entire HA recovery is taken care of the by HAs on the Home Link. MN remains unaware of the failure recovery just like failure detection. This helps reduce the message overhead due to multiple Home Registrations and re-establishment of IPsec SAs. VHARP achieves this by making all other HAs delete the entries for the failed HA from their data structures and executing VHARP_Recovery procedure, listed in figure 4. This procedure actually executes two other procedures called Active_HA_Recovery and Backup_HA_Recovery. The purpose of Active_HA_Recovery procedure is to recover the failure of the Active HA. When the failure of Active HA is detected, all the HAs will execute this procedure and the HA with the lowest load and lowest Link-Local address suffix will be selected as the new Active HA. The detail of this procedure is presented in figure 5. The purpose of Backup_HA_Recovery procedure is to maintain same number of Binding Owners before and after the failure of any HA. This is required for keeping the performance for each Binding unaffected due to HA failures. This procedure is only executed by the Active HA and Backup HAs. Inactive HAs do not include this procedure as part of their Front End Process. The detail of this procedure is presented in figure 6. 9

10 Procedure: VHARP_Recovery (HAfailed) Begin Procedure if HAfailed was Active HA then forall HAx, where 1 x n and x failed, execute in parallel delete entries of HAfailed from all data structures execute Active_HA_Recovery(x) else if HAfailed was Backup HA then forall HAx, where 1 x n and x failed, execute in parallel delete entries of HAfailed from all data structures execute Backup_HA_Recovery(x) else if HAfailed was Inactive HA then delete entries of HAfailed from all data structures End Procedure Figure 4. VHARP_Recovery Procedure Procedure: Active_HA_Recovery(x) Begin Procedure if HAx has the lowest Link Local address suffix among HAy, where 1 y n and y x, then HA becomes Active HA and Acquire Global HA address Ownership and Send Heart Beats as Active HA and Activate Exclusive Services if HAx is Active HA or Backup HA then execute Backup_HA_Recovery(x) End Procedure Figure 5. Active_HA_Recovery Procedure 3.7. VHARP Load Balancing Mechanism As discussed earlier, Mobile IPv6 does not provide load balancing mechanism among the HAs on the Home Link. Solutions [15], [16] and [17] provide load balancing mechanism. However, these solutions provide MN initiated and non-transparent load balancing. This results in message exchange over the air interface, service interruption in the mobile applications and increased workload on the MN during load balancing. VHARP solves these problems by introducing HA initiated and transparent load balancing mechanism among the HAs on the Home Link. As the result of this, VHARP Procedure: Backup_HA_Recovery(x) Begin Procedure VictimBindings Binding(s) with Binding Owners less than before failure if VictimBindings φ then NewBindingOwner HAz where HAz Active HA, HAz Binding Owner of VictimBindings and HAz has the lowest Link Local address suffix perform Binding Synchronization of VictimBindings with the NewBindingOwner NewBindingOwner inform all HAs about its Binding Ownership End Procedure Figure 6. Backup_HA_Recovery Procedure causes some extra message exchange over the Home Link. But no message exchange occurs at the air interface. Since Home Link is fast, reliable and inexpensive in contrast to air interface, it improves the over all performance of Mobile IPv6. Moreover, it significantly reduces the workload on the MN. In VHARP the Load of a HA is defined as the average packet flow over the air interface and it is expressed as packets/sec. Also the acceptable packet forwarding rate for each HA is defined as Threshold of a HA. This is a configurable parameter, defined by the router manufacturer and expressed as packets/sec. The ratio of Load and Threshold is known as the Load Factor of a HA. The Victim Binding is the Binding among all the Bindings of a HA which is causing the highest packet flow over the air interface. The load balancing policy of VHARP is as follows: 1. The Active HA, Backup HAs and Inactive HAs always monitor their Load Factors and inform all other HAs on the Home Link about their Load Factors as part of the periodic multicast Heart Beat messages. 2. The Load Factor for the Inactive HA (LF I ) does not change and is always expressed as LF I = 0. This is because, the Inactive HA does not hold any Binding nor provides any signal processing service for the MNs. It only performs basic IPv6 routing and Mobile IPv6 HA forwarding and intercepting services. 3. The Load Factor for the Active HA and the Backup HA is defined differently based on the Mobile IPv6 services they provide. Total load on the Active HA will include; a. L E : Load due to the exclusive services involving packet flow over the air interface For example, registration, de-registration, IKE [22], DHAD and stateful address auto 10

11 configuration [2]. b. L B : Load due to the Binding(s) for which it is the Binding Owner. It involves the signaling and data delivery services causing packet flow over the air interface. For example, tunneling, reverse tunneling, prefix discovery and return routability. Therefore, the Load Factor for the Active HA (LF A ) could be expressed as, LF A = (L E + L B ) / Threshold The Backup HA is not performing any exclusive services. It is only responsible for the signaling and data delivery services for its Bindings. Therefore, its Load Factor (LF B ) could be expressed as, LF B = (L B ) / Threshold 4. The Active HA and Backup HAs will be considered as overloaded when their load exceeds the Threshold. So, the overloading condition for the Active HA and Backup HA could be expressed as LF A 1 and LF B 1, respectively. 5. The Active HA or Backup HA will multicast Proxy Neighbor Advertisement message [12] for its Binding (S B ), whenever the following condition become true: It has the lowest Load Factor among all the HAs serving as the Binding Owners for S B. Tie on the Load Factor is broken based on the lowest Link- Local address suffix. The purpose of this message is to inform all the HAs and Edge Routers on the Home Link that the sender is the least loaded Binding Owner for S B. This way packets destined for S B could always be forwarded to the least loaded Binding Owner of S B Load balancing by the Active HA The Active HA could get overloaded due to the Binding(s) for which it is serving as the Binding Owner or the exclusive services. It will be considered as overloaded due to the Binding(s) when LF A 1 and L B L E. In this case, LF A could be reduced by making L B < L E. In order to achieve this, Active HA will create more Binding Owners for the Victim Binding. As a result, the load due the Victim Binding could be shared with more number of HAs on the Home Link. The Active HA will be considered as overloaded due to the exclusive services when LF A 1 and L E > L B. In this case, LF A could not be reduced by creating more Binding Owners because L E is not dependent on the Bindings. Hence, the Active HA has to give up its Active HA state and become Backup HA or Inactive HA depending on its Binding Cache entries. This will trigger any other HA on the Home Link to become the new Active HA and service Procedure: Active_HA_Overloading Begin Procedure if (L B L E ) then /*Bindiings are causing overloading*/ B : set of all Bindings in the Binding Cache VB : set of Victim Bindings. Initially NULL. Victim Binding(x) : Binding with the highest load among all the Bindings in (B VB) S : All the HAs on the Home Link Current Binding Owners of the Victim Binding(x) do while (S == NULL) VB = VB + Victim Binding(x) if ( B VB = = NULL) Return /*All the Bindings in the Binding Cache have been inspected and the network is overloaded.*/ else // Inspect Next Victim Binding. Update Victim Binding(x) Update S HA X : HA with the lowest Load Factor and lowest Link- Local address suffix in S Make HA X new Binding Owner for the Victim Binding(x). Update S while (L B L E ) else if (L E > L B ) then /*Exclusive Services are causing overloading*/ if (Any other least loaded HA on the Home Link exists) Process already submitted requests if (B == NULL) // Binding Cache is empty Change state to Inactive HA else Change state to Backup HA else Return /*No least loaded HA exists on the Home Link. Network is overloaded.*/ End Procedure Figure 7. Active HA load balancing procedure 11

12 L E. The selection criteria for the new Active HA is that it should have the lowest Load Factor among all the HAs on the Home Link. Tie on the Load Factor is broken in favor of the lowest Link-Local address suffix. The complete load balancing procedure for the Active HA is given in figure Load balancing by the Backup HA The Backup HA could only be overloaded due to the Binding(s) for which it is serving as the Binding Owner. In this case, LF B could be reduced by creating more Binding Owners for the Victim Binding. As a result, the load due the Victim Binding could be shared with more HAs on the Home Link and thus reduce the total load on the overloaded Backup HA. The complete load balancing procedure for the Backup HA is given in figure 8. Procedure: Backup_HA_Overloading Begin Procedure B : set of all Bindings in the Binding Cache VB : set of Victim Bindings. Initially NULL. Victim Binding(x) : Binding with the highest load among all the Bindings in (B VB) S : All the HAs on the Home Link Current Binding Owners of the Victim Binding(x) do while (S == NULL) VB = VB + Victim Binding(x) if ( B VB = = NULL) Return /*All the Bindings in the Binding Cache have been inspected and the network is overloaded.*/ else // Inspect Next Victim Binding. Update Victim Binding(x) Update S HA X : HA with the lowest Load Factor and lowest Link- Local address suffix in S Make HA X new Binding Owner for the Victim Binding(x). Update S while (LF B 1) End Procedure Figure 8. Backup HA load balancing procedure 4. Performance Evaluation We used OPNETv10.5 to simulate VHARP. Currently OPNET does not provide Mobile IPv6 model. However, it provides Mobile IPv4 and IPv6 which we used to develop Mobile IPv6 model. Finally, we extend it to have VHARP model. We simulated HA failure, recovery and load balancing scenarios to evaluate the performance of our solution. Regarding failure detection and recovery, we considered Mobile IPv6 as the representative model for other Mobile IPv6 based reliability solutions. We compared it with VHARP. This is due to the fact that all other Mobile IPv6 based reliability solutions propose MN initiated and non-transparent failure detection and recovery mechanisms. Regarding load balancing we compared VHARP with [16], referred to as Deng. This is due to the fact that in Mobile IPv6 there is no load balancing mechanism. Also other load balancing solutions offer similar MN initiated, non-transparent and DHAD based load balancing mechanisms. So we considered Deng as the representative model and compared VHARP with it. We extended the Mobile IPv6 model to provide Deng s load balancing mechanism. For this paper, the network model we used for all the simulations includes six HAs and two Edge Routers on the Ethernet (10 Gbps) based Home Link. CN belongs to the Home Link and have Ethernet (100bastT) link with one of the Edge Routers. MN has a wireless link (11 Mbps b) with the Access Point on the foreign link. Access Point and Home Link s Edge Router are connected to each other through Ethernet based Internet. We did performance analysis of VHARP based on five metrics. These are message exchange, time required, service interruption, HA load distribution and workload on the MN. In the following sub-sections we are presenting the experimental results for these metrics Message Exchange One of the criteria for declaring that a solution is better than another is the message exchange over the air interface. Air interface is unreliable, slow, expensive and bandwidth sensitive. So a better protocol is one which involves less number of messages over the air interface. Also message exchange over the Home Link is important. Home Link is usually Ethernet based. It is reliable, fast and inexpensive. For this purpose we did simulations to find out the message exchange for VHARP, Mobile IPv6 and Deng over the air interface and Home Link. We collected packets/sec statistic for HA failure detection, failure recovery, MN Home Registration and HA load balancing scenarios. 12

13 Regarding HA failure detection and recovery, we created a HA failure scenario and collected statistics for Mobile IPv6 and VHARP models. The simulation time was 320s and failure of HA took place at 120s. The Mean Time Between Failures (MTBF) for the HA was 100sec. This simulation was run for different number of MNs i.e. 1, 5, 10, 100, 1000, and 10,000. Each time total number of messages exchanged statistic was collected. Figure 9 illustrates total number of messages exchanged for 10,000 MNs during the entire simulation for 320s Mobile IPv6 VHARP Mobile IPv6 VHARP Figure 9. Failure Detection & Recovery Message Exchange for 10,000 MNs in 320s It could be concluded that message exchange involved in VHARP is almost half that of Mobile IPv6. This is the result of the transparent and HA initiated failure detection and recovery mechanisms of VHARP. It was observed that in VHARP there was no message exchange over the air interface and the entire message exchange was at the Home Link. Although VHARP causes more message exchange at the Home Link alone as compared to Mobile IPv6, but it is acceptable and affordable. This is because the Home Link is fast, reliable and inexpensive. Therefore, VHARP message exchange over the Home Link does not cause performance degradation. The number of messages involved in Home Registration is another important metric to compare the performance of the solutions. Regarding this we created a Home Registration scenario and collected statistics for Mobile IPv6 and VHARP models. The simulation time was 30 minutes. This simulation was run for different number of MNs i.e. 1, 5, 10, 100, 1000, and 10,000. Each time total number of messages exchanged statistic was collected. Figure 10 illustrates total number of messages exchanged for 10,000 MNs during the entire simulation for 30 minutes. From figure 10, it could be observed that message exchange of VHARP is greater than that of Mobile IPv6. This increased message exchange in VHARP is at the benefit of increased resilience of the MN s Binding. It was observed that all this message exchange took place at the Figure 10. Total Number of Messages Exchanged for 10,000 MNs during Home Registrations in Mobile IPv6 and VHARP Home Link. As discussed earlier, Home Link is fast, reliable, inexpensive and capable of affording this overhead without performance degradation. Therefore, this increased message exchange is totally acceptable. Regarding load balancing message exchange, we compared VHARP and Deng network models. We collected total number of messages exchanged over the air interface and Home Link. The simulation time was 320s. Figure 11 illustrates the total number of messages exchanged during the entire simulation for Deng and VHARP models over the air Interface and Home Link. It could be observed that in Deng the Home Link is not utilized for the message exchange at all during load balancing. However, in case of VHARP, all the message exchange during load balancing takes place at the Home Link. Moreover, in VHARP the load balancing message exchange over the Home Link is nearly half the message exchange in Deng over the air interface. Thus VHARP provides efficient utilization of network resources and reduced message exchange during load balancing. Figure 11. Total number of messages exchanged during entire load balancing simulation (320s) for Deng and VHARP 13

14 Failure Detection & Recovery Time (secs) Mobile IPv6 VHARP Number of MNs Figure 12. Failure Detection & Recovery Time for 10,000 MNs in 320s Home Registration Time (secs) Mobile IPv6 VHARP Number of MNs Figure 13. Home Registration Time in Mobile IPv6 and VHARP 4.2. Time Required We also compared VHARP and Mobile IPv6 in terms of time required for failure detection, failure recovery, and Home Registration. This is also important to consider because in real time applications even small delay could affect the overall performance of the application. Moreover, the failure detection, failure recovery, and Home Registration mechanisms are key metrics to judge any reliability solution. Figure 12 illustrates the failure detection and recovery time for different number of MNs i.e. 1, 5, 10, 100, 1000 and 10,000. It could be observed that in VHARP the failure detection and recovery is much faster than Mobile IPv6. This is due to the fact that the failure detection and recovery mechanisms are performed by the HAs, which are relatively faster than MN. Also these mechanisms involve message exchange over the Home Link, instead of air interface. Since Home Link is much faster, reliable and inexpensive medium compared to the air interface, so failure detection is fast and efficient. applications running over Mobile IPv6. For this purpose we did simulations to study the behavior of Voice Over IP (VoIP) applications running between 100 MNs and 100 CNs over Mobile IPv6, Deng and VHARP. We chose UDP as the transport protocol. Figure 14 illustrates the average packets received per second for the Deng and Mobile IPv6. Figure 15 illustrates the average packets received per second in VHARP. The simulation time was 320s and MTBF was 100s. The VoIP application starts at 100s and first HA failure and overloading took place at 110s. Also we modeled HA overloading with the same interval. It could be observed that in case of Mobile IPv6 and Deng, applications suffered service unavailability i.e. there is no packet flow after the HA failure and overloading. But in case of VHARP there is no service interruption at all and HA failure, recovery and load balancing are completely transparent to the MN and CN. Regarding the Home Registration we collected the Home Registration time for different number of MNs i.e. 1, 5, 10, 100, 1000 and 10,000. Figure 13 illustrates the output of this simulation. It could be observed that there is not much difference between Mobile IPv6 and VHARP. However, VHARP requires slightly more time for the Home Registration. Again, this increased time is at the benefit of increased resilience of the MN s Binding in VHARP Service Availability in Mobile Applications It is important to study the effect of HA failure detection, recovery and load balancing on the upper layer Figure 14. Average Service Availability in Voice Over IP Applications for 100 MNs and CNs in Mobile IPv6 and Deng during Failure Detection, Recovery and Load Balancing 14

15 Figure 16. Load distribution in Deng Figure 15. Average Service Availability in Voice Over IP Applications for 100 MNs and CNs in VHARP during Failure Detection, Recovery and Load Balancing 4.4. Load distribution among Home Agents Another performance evaluation metric is the load distribution among the HAs. It is important to consider because we could not achieve high system performance without fairly and efficiently utilizing the available resources. Thus, fair distribution of load among all the HAs on the Home Link would result in efficient resource utilization and high performance. We conducted simulations to study how Deng and VHARP perform load distribution among the HAs. The simulation time is 3000s for both Deng and VHARP models. Also same scenario is used for both the models. The scenario includes 100 MNs performing payload packet exchange with 100 CNs. The Home Registration of these 100 MNs occurred from 100s to 200s. This is almost the worst case scenario for MNs registrations i.e. occurring within the close interval. Figures 16 and 17 illustrate the output of the simulations for Deng and VHARP models respectively. Since both the models have different criteria for defining load of the HA so different statistics are collected for both the models. For VHARP we collected the Load Factor statistic and for Deng we collected the Number of Bindings statistic for each HA. Also they are compared based on their respective statistics. It could be observed that in case of Deng, the MNs are not fairly distributed among the HAs. HA1 registered 85 MNs, HA2 registered 10 MNs, and HA3 registered 5 MNs. HA4,,HA6 don t register any MN. The main reason behind this poor distribution is that every MN executes DHAD to find out the available HAs on the Figure 17. Load distribution in VHARP Home Link and then select the most preferable HA to get registered with. Since, based on our scenario, all the MNs perform Home Registrations very close to each other. Therefore, several MNs selected the same HA and thus got registered with it. However, in case of VHARP it could be observed that the all the HAs on the Home Link are serving as the Binding Owners for the MNs. Initially the load distribution is not that fair but with the passage of time all the HAs appear to operate almost at the same Load Factor. This fair load distribution resulted due to transparent and MN independent HA assignment mechanisms of VHARP. Also the load balancing is based on the packet flow and not on the registered number of MNs which also plays an important role in the fair load distribution among the HAs on the Home Link Workload on the Mobile Node Usually MN has constraints on power, processing speed, storage capacity and interface link bandwidth. So it is important to measure the average workload on MN in 15

16 Thus VHARP improves the overall Mobile IPv6 and upper layer applications performance. The formal verification of VHARP is left for future work. This will mainly involve model checking and proving the fundamental and interesting properties. 6. Acknowledgment The authors would like to thank the anonymous reviewers for their feedback, suggestions and comments. References Figure 18. Work load on the MN during failure detection, recovery and load balancing in Mobile IPv6, Deng and VHARP case of HA failure detection, recovery and load balancing. Regarding this, we used the HA failure, recovery and overloading scenarios and collected average CPU Utilization statistic for Mobile IPv6, Deng and VHARP models. The simulation time was 300s and HA failure and overloading took place at 120 seconds. Figure 18 illustrates the output of the simulation. It shows average CPU utilization for Mobile IPv6 and Deng in one curve and the other curve shows VHARP CPU utilization. It could be observed that after the occurrence of HA failure and overloading at 120s in Mobile IPv6, MN has increased workload due to processing of messages. Where as, in case of VHARP this is not the case and MN continues to operate at normal workload. 5. Conclusion In this paper we introduce VHARP as a complete system architecture and extension to Mobile IPv6. It supports reliability and load balancing in Mobile IPv6 based networks. It also offers solution to the reliability problems associated with Mobile IPv6. We also present the results of several experiments to assess the performance of VHARP. The results show that VHARP provides transparent HA failure detection and recovery mechanisms. As a result, there is a significant reduction in message exchange over the air interface, which is unreliable, expensive and slow. Also, VHARP efficiently utilizes Home Link, which is reliable, inexpensive and fast. VHARP provides high service availability in the upper layer applications. It also reduces the workload on the MN which is usually high in case of Mobile IPv6 and other protocols. Moreover, the load balancing mechanism of VHARP is efficient, fair, dynamic and transparent. [1] C. Perkins, IP Mobility Support, IETF-RFC (Proposed Standard) 3344, August [2] Perkins, C., Johnson, D. and J. Arkko, Mobility Support in IPv6, IETF Draft, draft-ietf-mobileip-ipv6-24 (work in progress), August [3] Chambless, B. and J. Binkley, HA Redundancy Protocol, IETF Draft, draft-chambless-mobileip-harp-00.txt (work in progress), October [4] Ghosh, R and G. Varghese, Fault Tolerant Mobile IP, Washington University, Technical Report (WUCS-98-11), [5] Ahn, J and C.S. Hwang, Efficient Fault-Tolerant Protocol for Mobility Agents in Mobile IP, Proc. 15th Int l Parallel and Distributed Processing Symp., pp , [6] Leung, K and M. Subbarao, HA Redundancy in Mobile IP, IETF Draft, draft-subbarao-mobileip-redundancy- 00.txt (work in progress), June [7] M. Khalil, Virtual Distributed HA Protocol (VDHAP), United States Patent 6,430,698, August [8] Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, IETF- RFC 2401, November [9] Faizan, J., El-Rewini, H. and M. Khalil, Problem Statement: HA Reliability, IETF Draft, draft-jfaizanmipv6-ha-reliability-00.txt (work in progress), November [10] J. Faizan, H. El-Rewini, and M. Khalil, VHARP: Virtual Home Agent Reliability Protocol for Mobile IPv6 based Networks, in Proc. International Conf. on Wireless Networks, Communications, and Mobile Computing, Wireless Com 2005, Hawaii, USA, June 13-16, [11] J. Faizan, H. El-Rewini, and M. Khalil, Efficient Dynamic Load Balancing for Multiple Home Agents in Mobile IPv6 based Networks, In Proceedings of IEEE International Conference on Pervasive Services - ICPS 2005, Santorini, Greece, July 11-14, [12] Lin, J and J. Arul, An Efficient Fault-Tolerant Approach for Mobile IP in Wireless Systems, IEEE Transactions on Mobile Computing, Vol. 2, No. 3, pp , July-Sept [13] J. Jue, and D. Ghosal, Design and analysis of a replicated server architecture for supporting IP-host mobility, Cluster Computing Special Issue on Mobile Computing, vol. 1, issue 2, pp

17 [14] Vasilache, J. Li, and H. Kameda, Threshold-Based Load Balancing for Multiple HAs in Mobile IP Networks, Telecommunications Systems, vol. 22, issue 1-4, pp , January-April, [15] Wakikawa, R., Devarapalli, V. and P.Thubert, Inter HAs Protocol (HAHA), IETF Draft, draft-wakikawa-mip6- nemo-haha-00.txt (work in progress), October [16] Deng, H., Zhang, R., Huang, X. and K. Zhang, Load Balance for Distributed HAs in Mobile IPv6, IETF Draft, draft-deng-mip6-ha-loadbalance-00.txt (work in progress), November [17] F. Heissenhuber, W. Fritsche, and A. Riedl, HA Redundancy and Load Balancing in Mobile IPv6, in Proc. 5th International Conf. Broadband Communications, Hong Kong, [18] J. Faizan, H. El-Rewini, and M. Khalil, Virtual Home Agent Reliability Protocol Implementation Details, Southern Methodist University, Technical Report (04-CSE- 03), May [19] Deering, S. and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, IETF- RFC 2460, December [20] Arkko, J., Devarapalli, V. and F. Dupont, Using IPsec to Protect Mobile IPv6 Signaling between MNs and HAs, IETF Draft, draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress), June [21] Narten, T., Nordmark, E. and W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, December [22] Kaufman, Internet Key Exchange (IKEv2) Protocol, IETF Draft, draft-ietf-ipsec-ikev2-12.txt (work in progress), January