On the Selection of Mobility Anchors in Mobile IP Networks

Transcription

1 On the Selection of Mobility Anchors in Mobile IP Networks You Wang, Jun Bi, Xiaoke Jiang Institute for Network Sciences and Cyberspace Department of Computer Science Tsinghua National Laboratory for Information Science and Technology (TNList) Tsinghua University, Beijing 84, China Abstract Many recent mobility solutions propose to achieve mobility management by distributing mobility anchors in the network. Thus, the algorithm to select a proper mobility anchor for mobile nodes is a key component of such solutions. In this paper, we study the selection algorithm and present an idea that allows a mobile node to select an independent mobility anchor for each correspondent node. Then we evaluate different selection algorithms and show that our proposal gains more performance benefits and brings acceptable additional cost compared with existing solutions. To handle particular cases that lead to high costs, we provide a light weight solution which is as effective while costing less. We also propose detailed protocol design to demonstrate how to realize our proposal in practice. Keywords mobility management; mobile ip; home agent; mobility anchor; route optimization I. INTRODUCTION A large number of proposals to support mobility in the network layer are extensions and derivatives of Mobile IP [][2]. Mobile IP is an Internet Engineering Task Force (IETF) standardized protocol which allows Mobile Nodes (MN) keep their session survivability while roaming around. To achieve this goal, Mobile IP introduces a mobility anchor point called Home Agent (HA) to intercept packets and tunnel them to and from the MN it serves. The employment of a fixed HA brings triangle routing problem when the MN is away from its anchor point. It results in non-optimal routes since all the traffic from Correspondent Nodes (CN) to MN have to take a detour to pass the HA. To deal with the problem, many approaches propose to distribute the mobility anchors (e.g. HAs) to make a more flat design [3]- [7]. They allow the roaming MN dynamically attach to the nearest HA to achieve the goal of improving route optimality, reducing signaling overhead and distributing traffic load, etc. Similar ideas are also employed by other mobility protocols [8][9] besides Mobile IP extensions. However, as shown in previous research, the effectiveness of such mechanism depends on the number of deployed mobility anchors and the placement strategy [6][7]. When anchors are partially deployed, a MN s nearest mobility anchor may still be quite far away from it, making the routes suboptimal between the MN and CN. Unfortunately, partial deployment scenarios may be a common case especially in the solutions require Internet-scale deployment [7][8][9]. Besides, as is demonstrated in some existing work on Hierarchical Mobile IPv6 (HMIPv6) [][2][3], selecting a near mobility anchor may introduce a high signaling overhead due to frequent switch between different anchors when the MN is roaming around. Therefore, it still worth researching on the selection of mobility anchors in mobile IP networks as well as other solutions that rely on distributed anchors for mobility management. However, the solution space seems to be small if the MN is allowed to select only one mobility anchor at one time. Thus in this paper we expand the problem and try to answer the question: how should we design the selection algorithm if the MN is able to select multiple mobility anchors simultaneously? We prove by evaluation that when the MN can select a specific mobility anchor for each of its CNs, both route optimality and switch overhead can be improved. We also explained that the cost of the proposal is acceptable in most scenarios. For the high-cost scenarios, we describe a trade-off between the performance improvements and additional cost and provide a light weight solution which aims to preserve most performance benefits while keeping a low cost. In the latter part of the paper, we present a protocol design which realizes discovering and selecting multiple mobility anchors to show that the proposed idea is not only theoretical but also feasible in practice. The rest of this paper is organized as follows: first we give a problem statement In Section II to further make clear the background and goal of our proposal. The problem statement includes reviews of related work, simulations and experiments to demonstrate existing problems and description of our solution. In Section III we make an evaluation of our proposal to illustrate its performance benefits as well as additional overhead, and in Section IV we provide a light weight version of our proposal to deal with the high-cost scenarios. Then we describe the protocol design and make some related discussion in Section V. Finally, we conclude the paper and present future work in Section VII. II. PROBLEM STATEMENT A. Existing Work Many solutions that address IP mobility in the Internet propose to distribute mobility anchors in globe scope or within a specific domain. They allow the MN to dynamically attach to

2 Fraction of the total routes Fraction of the total routes different mobility anchors when it roams to different locations in the network. However, they adopt different ways in selecting the mobility anchor for MNs. A large number of solutions make the MN choose its nearest mobility anchor in order to get better route optimality. Many of them [5][7][4]-[7] belong to Distributed Mobility Management (DMM) solutions [3][4] and can be regarded as Mobile IP derivatives. Some of them propose to place mobility anchors at the edge of networks in some specific domains [5][4][5] while others propose to deploy mobility anchors in global scope [7][6][7]. For the latter case, anycast [7][6] and P2P mechanism [7] are utilized to discover the nearest mobility anchor to the MNs. Except Mobile IP extensions, some mobility protocols that are based on new architecture designs, such as ROAM [8], TTR Mobility [9] and LISP Mobile Node [] etc., also share similar ideas in achieving mobility management. Some other solutions, especially extensions to HMIPv6 [5], present different algorithms in selecting mobility anchors. K. Kawano et al. [] propose an algorithm which selects mobility anchors according to the velocity of the MN to avoid frequent switch: faster MN chooses farther anchors while slower MN chooses nearer anchors. S. Pack et al. [2] use the ratio of the session arrival rate to the mobility rate as metric in selecting mobility anchors. D. Pragad et al. [3] address the selection problem by formulating a binary integer programming problem that aims to optimally distributing the incoming load while considering the QoS parameters including average packet delay and handover delay. B. Problem Statement In common cases, better route optimality can be obtained by selecting nearer mobility anchors. However, in some scenarios it cannot be guaranteed. For a simple example, we assume that a multi-homed domain C has no deployment of mobility anchors while its two providers P and P have. Considering a MN in domain C, it is possible that none of the anchors in P and P is always located on the direct paths between the MN and its CNs at diverse locations. Thus, the scenario described above may still leads to non-optimal routes. Besides, even if the mobility anchors are fully deployed in domain C, always selecting the nearest anchor may lead to a significant switch overhead. To further demonstrate the problem, we make some simulations to show the route stretch and switch overhead based on real Internet topologies. We also carry out a simple experiment using the wireless environment within our university to estimate the increasing of RTT due to larger route stretches. ) Simulation We use two different simulation topologies: one interdomain topology and one intra-domain topology. The interdomain topology is formed by gathering BGP data from 7 monitoring points in Route Views Project [8]. We extract allpairs AS-level hop count for 978 nodes from the RIB data collected from the project. The intra-domain topology contains 63 nodes with all-pairs router-level hop count using topology data of AS-239 from Rocketfuel [9]. Fig.. Hop- Hop-2 Hop (a) Inter-domain Topology Stretch (b) Intra-domain Topology Hop- Hop Stretch Cumulative Distribution Function (CDF) of the stretches in both inter-domain and intra-domain simulations To evaluate the route stretch, for each run of the simulation we randomly choose one node as the MN and nodes as its CNs in the topology, and place several HA (we use HA to replace mobility anchor for convenience in the following sections) at random locations with deployment rate of 5%. Then we select the HA nearest to CN as HA CN and the HA which is n-hops (n =, 2, 3 for inter-domain simulation and n =, 3, 5 for intra-domain simulation) away from the MN as HA MN. Since we have the all-pairs hop count data, we can calculate the stretch for each MN-CN pair using the following formula: ( ) ( ) ( ) ( ) We make 5 runs for each simulation scenario (two topologies with three n values each) and show the Cumulative Distribution Function (CDF) of the calculated stretches in Figure. As we can see from the figures, the simulation results show similarities in both topologies. Even if the HA is one hop away from the MN, it results in a large number of suboptimal routes (6% in inter-domain and 4% in intra-domain topology) and there exist about 2% of the routes that have a stretch larger than.5. The growing of the HA-MN distance leads to more suboptimal routes and larger stretches. Only 2% of the routes can be guaranteed optimal when the HA is 3 hops and 5 hops away from the MN respectively in two topologies. To evaluate the switch overhead, we first define a roaming event as the case that the MN moves from one node to another ()

3 Fraction of the total runs Fraction of the total runs Fraction of the total runs node in the simulation topology. Then we generate a series of roaming events of the MN using Pareto model [8]. In this model the probability that the MN s roaming distance from its current location is larger than d (hop) is /d 2 (d>=). At the beginning of each run, we randomly place one MN and associate a nearest HA (also randomly placed with deployment rate of 3%, 6% and 9%) to the MN. We assume that when the MN roams to a new location where another HA is nearer to the MN than the current one, it should perform a HA switch and associate with the new HA. We gather the HA switch number in runs with roaming events in each run and show the CDF results in Figure 2, which illustrates that the number of HA switch is larger than 9 in most cases. It implies that the probability of performing HA switch is over 9% after each roaming and the number grows when more HAs are deployed, which indicates a high switch overhead. 2) Experiment We make a simple experiment to estimate the increase of RTT when suboptimal routes are employed in real Internet environment. In the experiment, we choose a mobile device to serve as the MN and a desktop computer to serve as the CN. Both the MN and CN are located within the university. CN accesses to the Internet via a provider called Cernet while MN can switch among three different providers: Cernet, ChinaNet and ChinaMobile. We assume that all three providers have deployed HA function on their first-hop routers to the MN and we call them HA-Cernet, HA-ChinaNet and HA-ChinaMobile respectively. Thus all three HAs have the same distance to the MN. Then the goal of the experiment is to measure the RTT of 3 different routes from CN to MN. Considering that unstable wireless environment may have an impact on the experiment, we only consider CN-to-HA part of the route while ignoring the last one HA-to-MN hop. We use Ping and Traceroute to get RTT (average of runs) and hop count of all three routes. Table I shows the experiment results. When the MN selects HA-Cernet, both RTT and hop count are relatively low since during this phase both MN and CN are within the same domain. When the MN selects HA-ChinaNet or HA-ChinaMobile, both RTT and hop count show a large increase because the CN needs to make a detour to reach the MN. Thus the experiment implies an improper HA may lead to larger end-to-end delay and thus larger bandwidth usage on the path from CN to MN. C. Proposed Solution To deal with these problems, we propose to allow a MN select different HAs for different CNs. Specifically, we assign each MN a Candidate HA Set which contains multiple HAs that are close to the MN. Then for each CN, the MN triggers a HA selection procedure and chooses an optimal from as the mobility anchor point which satisfy TABLE I. EXPERIMENT RESULT Average/min/max RTT (ms) Hops CN to HA-Cernet.7 / / 7 7 CN to HA-ChinaNet 6.3 / 3 / 9 3 CN to HA-ChinaMobile.2 / 4 / 45 5 Fig % deployment 6% deployment 9% deployment Number of HA switching (b) Intra-domain Topology 3% deployment 6% deployment 9% deployment Cumulative Distribution Function (CDF) of the HA switch number in both inter-domain and intra-domain simulations ( )= ( ( )) (2) Where ( ) means the stretch of the route from CN to MN via.therefore, will always lead to a route with lowest stretch possible for each MN-CN pair and at the same time reduce the possibility to perform HA switch since may be located relatively farther from the MN. To find out how much performance benefits it will bring as well as what additional overhead it may introduce, we make evaluations to test our proposal in the next section. III. (a) Inter-domain Topology Number of HA switching EVALUATION A. Methodology We make four simulations to evaluate the performance and overhead of our proposal. We use the same simulation topology as that presented in the previous section. We also randomly place the MN, CNs and HAs and vary the deployment rate of HA from % to 9% to demonstrate results in different deployment scenarios. The Candidate HA Set is chosen as HAs that are within 3 hops and 5 hops from a MN in inter-domain and intra-domain topologies respectively, because keep up increasing the set size can hardly bring any more performance benefits as is illustrated by the evaluation results. Two extreme cases are also evaluated as the basis for comparison: Nearest- and. Nearest- means the Candidate HA Set only contains the nearest HA (represent current solutions), and means all the HAs deployed are included in the set (represent the optimal case). The scenario in which the HA-MN distance is hop is excluded from our

4 Fraction of the total routes Fraction of the total routes (a) Inter-domain Topology (c) Inter-domain Topology (e) Inter-domain Topology.7 Nearest-.9.6 Hop Nearest- Hop Deployment rate of of HA HA Deployment rate of of HA HA Deployment rate of of HA HA Nearest Nearest Fig. 3. Proportion of the optimal routes (a, b), average stretch (c, d) and average switch cost (e, f) with HA deployment rate varies from % to 9%.3. Nearest- Hop (b) Intra-domain Topology (d) Intra-domain Topology (f) Intra-domain Topology Deployment rate of HA Deployment rate of HA Deployment rate of HA Nearest evaluation since the hop- HA is always the optimal one and thus it is unnecessary to perform HA selection. For each of the simulation below, the result is generated using the average value of 5 runs for each case. In the first three simulations we show the benefit of our proposal in the form of a higher proportion of optimal routes, lower average stretch and switch cost. However, our proposal introduces extra overhead due to the utilization of multiple HAs, e.g. it leads to more signaling cost during the binding update procedure since the MN needs to interact with each of the chosen HAs to make its Binding Cache up-to-date. Thus, we also evaluated the binding update cost in the last simulation. B. Evaluation Results ) Route optimality The first simulation evaluates the proportion of optimal routes. Optimal routes here are defined as routes that have stretch equals to one, and the stretch is calculated using Formula (). The results are shown in Figure 3 (a) and (b), in which x-axis represents HA deployment rate, and y-axis represents the average proportion of optimal routes. We make three observations from the figures: first, route optimality grows along with the increasing of HA deployment rate. It is because when more HAs are deployed, they are more likely to be located on the optimal route between CN and MN. Second, our proposal increases the number of optimal route in Nearest- by 5% to 7% which varies in different topologies with different HA deployment rate. Third, the results of Hop-3 and in two topologies are close to the optimal case (), which means Hop-3 and are sufficient to generate a Candidate HA Set that offers optimal performance. Keeping on increasing the size of Candidate HA Set is not cost-effective since it brings limited benefits but considerable potential costs. 2) We show the average stretch in Figure 3 (c) and (d). As we can learn, similar conclusions can be derived from the figures: average stretch also drops with the increasing of HA deployment rate since the detour becomes less severe when the HA are located nearer to the MN. Nearest- results in a relatively higher stretch while our proposal brings a noticeable decrease of the stretch (removes about 2% to 3% of the routing overhead). When the deployment rate of HA approaches %, the average stretch of our proposal almost drops to. 3) Switch cost The switch cost is calculated as the total number of messages sent to all the CNs after a roaming event for HA switch (we assume only one message is required for each CN) divided by the number of CNs, i.e. the average number of messages sent to each CN. The average result is shown in Figure 3 (e) and (f). We find that higher HA deployment rate leads to larger switch cost because the probability to trigger HA switch is also higher. Nearest- has a high switch overhead as is shown in the previous section, while our proposal has a much lower overhead since the chosen HAs in our proposal are more CN specific and thus have a higher probability to keep optimal after a roaming event of the MN. Additional evaluations are made based on other topologies and are demonstrated in Appendix A. All evaluations show similar results, which proves the universality of the evaluation conclusions.

5 Fraction of the total runs Binding update cost Fig HA deployment rate CN Number Average binding update cost with HA deployment rate varies from % to 9% and CN number varies from 2 to Inter-AS.55 Intra-AS Fig. 5. Hottest N HAs Heat of the hottest N HAs 4) Binding update cost The binding update cost is calculated as the total number of binding update messages sent to all chosen HAs after each network-layer handover (again, we assume only one message is required for each HA). Considering that the more CNs there are, the more HAs may be chosen and, thus, the higher binding update cost will become, we also varies the amount of CNs from to in this simulation. Figure 4 shows the result of the Hop-3 case in inter-domain scenario. Since Nearest- always only generates one binding update message per handover, it is not plotted in the figure. The z-axis in the figure represents the binding update cost, x-axis represents the number of CN, y-axis represents HA deployment rate. Figure 4 proves that binding update cost grows with the increasing of both the number of CNs and HA deployment rate. However, considering that the CN number of most MNs can be very few, the binding update cost of our proposal, though higher than existing solutions, is still acceptable in most scenarios. IV. A LIGHT WEIGHT SOLUTION The evaluation results from the previous section show that the binding update cost in the network layer handover of the proposal grows with the increasing of both HA deployment rate and number of CNs. Thus in some scenarios, e.g. when the MN provides some kind of service and, thus, has a large number of CN, or when the MN frequently switches between different IP addresses, the binding update will bring a heavy overhead to the network. In this section we further research into the mobility anchor selection problem and propose a light weight solution to deal with the high-cost scenarios. The idea is to reduce the size of the Candidate HA Set, so that the chosen HAs of a specific MN will drop which leads to lower binding update cost. TABLE II. PERFORMANCE TRADE-OFF IN SELECTING HAS Solution Average Performance and Cost Route Average Binding Switch Cost Optimality Stretch Update Cost Hop Hop Hop To study the performance changes when fewer HAs are chosen, we repeat the simulations in the previous section while reducing the upper limit of hop count between MN and HAs in the Candidate HA Set. Table II shows the simulation results of Hop-3, Hop-2 and Hop- in inter-domain topology with 5% HA deployment rate. We find a trade-off exists on the selection of HAs for a MN: reducing the size of the Candidate HA Set leads to fewer binding update cost, but it also reduces route optimality, increases average stretch and switch cost. Therefore, the goal of the light weight solution is to reduce the cost as much as possible while still maintain a high performance. A. Heat of HA The light weight solution relies on the fact that most performance benefits come from a small number of HAs (we call them hot HAs). We define the Heat of a HA as: Thus a HA with a higher heat means it is serving more MN-CN pairs and thus should be considered as a more weighty one. We make a simulation to show the heat of different HAs. The simulation is similar to that in Section III with the same topologies and methodology. We also randomly place the MN, CN and HA nodes and choose 5% as the deployment rate of HAs. The average result of 5 runs is shown in Figure 5, which illustrates the sum of heat of the hottest-n HAs. We find that in both inter-domain and intra-domain scenarios, the hottest HA always owns 5-6% of the total routes and the hottest 5 HAs owns about 8% of the total routes. Based on the fact that most routes are relayed by a small number of HAs, we suppose that a majority of performance benefits will be preserved by keeping several hottest HAs and removing the others. B. Find Hot HAs In this subsection we propose four different ways to find the hot HAs. The most obvious factor that make a HA hot is its nearness to the MN. It is a simple but reasonable assumption that the MN s nearest HAs will own most of the routes towards the CNs. Thus we use Nearest-N as the first and easiest way to find the hot HAs, which means the nearest N HAs to the MN are chosen as the Candidate HA Set. (3)

6 Fraction Average of the Stretch total runs Fraction of the total runs Fig. 6. Heat of the N HAs chosen by Nearest-N, Nearest-N+, First-N and Hottest-N respectively with different N value Besides the nearness, the location of the HA in the topology is also a key factor in finding hot HAs. Considering one HA which is the nearest to the MN but located in a stub network and another HA which is at the same distance or a bit farther from the MN but located in the core, the latter one may own more routes in most cases. Thus we propose Nearest-N+ which also regards distance as the highest priority but prefers the HA that resides in a domain with a larger degree when selecting among HAs with the same distance. A HA will become hot if is located on the optimal route from the MN towards a large number of CNs. Thus the heat of a HA is also affected by the distribution of the CNs. But in common practice a MN may not learn all of its CNs at the beginning of its first session. So we use First-N to represent the method of selecting the optimal HAs for the first N CNs of a MN can gather the chosen HAs as the Candidate HA Set. TABLE III. PERFORMANCE RESULTS OF THE LIGHT WEIGHT SOLUTION Solution Nearest-N.3 Nearest-N+ First-N Hottest-N (a) Inter-domain Topology Size of candidate HA Set (b) Intra-domain Topology Nearest-N.3 Nearest-N+ First-N Hottest-N Size of candidate HA Set Average Performance and Cost Route Optimality Switch Cost inter intra inter intra inter intra Nearest Nearest At last, if a MN has prior knowledge of all its CNs at the beginning, it can obtain the Hottest-N HAs by running a simple algorithm to calculate the optimal HA for each CN. However, it is not applicable in most cases, and we only regard it as the optimal result in the evaluation of the previous three methods. C. Evaluation We make another simulation to show the behaviors of the proposed methods to find hot HAs. The results are shown in figure 6, where x-axis represents the size of the Candidate HA Set, i.e. the N value in Nearest-N, Nearest-N+, First-N and Hottest-N, and the y-axis represents the heat of the chosen HAs. There are two useful findings: first, topology information is helpful in finding hot HAs as the result of Nearest-N+ is always higher than Nearest-N. Second, Nearest-N+ is better at finding hot HAs when Candidate Set Size is small (smaller than 6 in inter-domain scenario, and 8 in intra-domain scenario), while First-N is better at finding hot HAs when Candidate Set Size is larger. Since the goal is to reduce the number of chosen HAs as much as possible, we consider Nearest-N+ as the most suitable method to obtain the Candidate HA Set in our light weight solution. Then we make simulations to test the light weight solution by comparing the performance and overhead among Nearest-, Nearest-+, and. We only show the simplified results here in Table III. Please refer to Appendix B for more detail of the simulation. Table III shows that, though not as good as the optimal case (), the light weight solutions outperform current solutions with a low cost. Nearest-+ has a better performance than Nearest-, and they share the same binding update cost since they only choose one HA at a time. Nearest-3 has a better performance at the cost of slightly higher binding update cost (3 binding update messages is the upper bound). V. PROTOCOL DESIGN In this section we describe the ways to realize the ideas proposed and evaluated in the previous sections to show that they are not only theoretical but also feasible in practice. It is notable that there may exist various ways to achieve the required functions, and we are only proposing one alternative way in this paper. We mainly describe how to implement the required functions into Mobile IPv6 framework since it is the most widely discussed mobility protocol. However, similar approaches can be employed to implement the functions based on other mobility protocols. There are three new function modules required to realize the proposed idea, i.e. protocols to discover nearby HAs, algorithms to select HA and mechanisms to switch between HAs. First we describe an overview of the new functions and then since the functions are relatively independent, we show their design details respectively in three subsections. A. Overview We illustrate the overview design in Figure 7. We assign each MN a Primary Home Agent (PHA) which serves as its default mobility anchor point for incoming sessions. The MN can also associate itself with other HAs for route optimization. Associated HAs are responsible for keeping Binding Cache for the MN. The Binding Cache stores the relationship between

7 MSP HA Primary HA HA CN Route Route 2 Fig. 7. MN HA 2 CN Route 3 HA N Overview of the protocol design HoA assigned to that MN and the CoA of the MN. Thus, when data packets arrive at the HA, it is able to redirect the packets towards the MN s current address. To keep Binding Cache upto-date, the MN should send Binding Update messages to associated HAs when its CoA changes. Similar to the Home Agent discovery mechanism described in MIPv6 [2][7], the MN can find close-by HAs by sending a Dynamic Home Agent Address Discovery (DHAAD) request to a specific anycast address, and the request will be routed to the nearest HA. The MN is also allowed to change its associations with current HAs by sending another DHAAD request after location changes. We propose two ways for the MN to discover other nearby HAs as its Candidate HA Set. If the mechanism works in an intra-domain scenario, it is possible to make each HA in the domain join a multicast address. Then the MN is able to find HAs in the domain by sending a modified DHAAD request to the specific multicast address. If multicast is not supported by some domain, or if the mechanism works in an inter-domain scenario, we propose another way to realize HA discovery. As is described by RFC 526 [2], a MN can perform Home Agent address discovery based on DNS as a bootstrapping solution. We modify the solution here for the MN to get a list of nearby HAs. The details are shown in the next subsection. There are two communication modes between the MN and CN. The first mode is called Default Routing (DR), which is used in the initial phase of each session. DR mode behaves similarly to that described in Home Agent Migration [7], i.e., the MNs are assigned to the same IPv6 prefix and the CNs use anycast routing to reach them. Specifically, data packets from the CN will reach the nearest HA (we call HA CN ) who stores a binding between the MN s HoA to its PHA. Thus the packets can be redirected to the PHA of the MN, who has the MN s Binding Cache and will then forward the packets to the MN s CoA, shown as the solid line (route ) in Figure 9. The second mode is called Optimized Routing (OR). It is up to the MN that whether OR mode should be enabled. When enabled, Route Optimization Procedure is triggered to find a better route possible for the MN. After switching to OR mode, each route via a specific HA in the candidate HA Set (dotted line in Figure 9) is evaluated according to the Route Selection Algorithm and then an optimal one is selected. Some message exchanges are required among the MN, CN and HAs to Fig. 8. HA MN HA 2 Distance measurement Query & Response DNS HA N Cache HA- HA-2 HA-N Server Query & Response Discover nearby Home Agents based on DNS perform the route optimization. The Route Optimization Procedure can be triggered anytime by the MN to re-evaluate the candidate HAs, especially after the MN moves to a new network or changes its association to HAs. B. Home Agent Discovery According to the specifications in RFC 526, the MN is able to discover the address of available Home Agents based on DNS. The precondition of such mechanism is that the MN must be configured with a DNS server, which is a common case in the current Internet. We use the Service Resource Record (SRV RR) to store related information of each HA including its FQDN, priority, weight, life-time, IP address, etc. When the MN needs to find nearby HAs, it sends a DNS request with QNAME set to _mip6._ipv6.example.com and QTYPE set to SRV. example.com refers to the Mobile Service Provider (MSP) that provides Mobile IPv6 services to MNs, which also comes from the same RFC. After getting the DNS response, the MN stores a local cache of the HAs listed in the SRV RR. At the DNS side, we describe two possible ways to generate SRV RR that stores information of nearby HAs. One is a static way that relies on manual configuration. The information of nearby HAs is configured manually and seldom needs updates since the locations of the HAs are relatively fixed. It is a simple way especially when the solution works in an intra-domain scenario. Considering the scenarios in which manual configuration is difficult to realize (for example, inter-domain scenarios), we introduce another dynamic way for HA discovery as shown in Figure 8, which however needs additional servers and operations from MSP. Inspired by the server selection mechanisms in Content Distribution Networks (CDN) [2], we assume that a global MSP server (can be logically centralized but practically distributed) makes all the HAs measure the distances to a specific DNS resolver that requires the SRV RR and gathers the measurement result. Then the server responds the DNS resolver with a SRV RR contains a subset of all the HAs that are close to it (by setting a distance upper bound measured by, e.g., router or AS hop). The MSP server is also responsible to set the information of each HAs in the SRV RR. The MSP server can set a relatively larger lifetime value in order to avoid frequent updates. Also,

8 the weight and priority values can be set flexibly by the MSP server to influence the MN s selection of the HAs. For example, the MSP server can set weight of each HA as their distances to the DNS resolver, which can be utilized by the route selection algorithm. C. Route Selection Algorithm The goal of the route selection algorithm is to find the optimal route that leads to smallest stretch as is described in Section III. To achieve the goal, we assign a cost value to each candidate route and select the route with the lowest cost value. Generally, we assume that there exists an overlay route r between a specific MN-CN pair, which passes N overlay nodes including both end nodes. We mark these nodes as Node to Node N, and define that the route is constituted of contiguous overlay links between adjacent nodes on the route. Then we calculate the cost of the route by adding up a series of link distances: ( ) (4) However, we do not need to calculate each distance value in practice because, at least, ( ) is a fixed value for all candidate routes. Thus, we only need to consider the remaining distances between HA CN, HA MN and MN: ( ) ( ) (5) Using this method, the pre-task of the route selection algorithm is to get the distances between HA-HA pairs and HA-MN pairs. To maintain HA-to-HA distances, each HA is required to store the distances to all the other HAs in a local HA list [2]. The distance values can be measured by sending and responding probe packets among the HAs. Ping results can be used to calculate the distance for simplicity. To get HA-to-MN distances, we adopt the following approximation ( ) ( ) (6) based on the assumption that the MN is always close to its DNS resolver. Then ( ) can be obtained from the weight field stored in the SRV RR as described in the previous subsection. Considering that collecting ( ) values may bring a relatively heavy overhead, we also propose an approximate algorithm for route selection which calculates the cost of each route using ( ) (7) where ( ) is ignored. The simplified algorithm can make a good approximation when the all the HAs in the Candidate HA Set are close to the MN. TABLE IV. SIMULATION RESULTS OF APPROXIMATE ALGORITHM Solutions (inter / intra) Absolute error Discrepancy rate Relative error (hops) inter intra inter intra inter intra Hop-3/ Hop-2/Hop Hop-/Hop- MN PHA HA CN CN HA MN Data Data Data RO Init RO Notification Route Selection Query RO Notification Store Binding Cache Response Modify Binding Cache Data Data Data Fig. 9. Route Optimization Procedure in OR mode We also made a simulation of the approximate algorithm. The simulation methodology is the same as that in Section IV except that we only concern the differences between the approximate and the original algorithm in different scenarios. Table IV shows the simulation results, where discrepancy rate represents the probability that HA chosen by the approximate algorithm is different from the original algorithm, absolute error represents the increased hop count of the approximate algorithm compared with the original algorithm, and relative error is obtained by dividing absolute error by the total hop count of the route in the original algorithm. We noticed that with the decreasing of HA-MN distance (e.g. from Hop-3 to in inter-domain topology), two algorithms become less distinct, and when HA is only one hop away from the MN, the approximate algorithm has the same results as the original one. Even if the HA is 3 or 5 hops away (which can bring almost the largest performance benefits as is proved in Section III), the differences between the MN-CN distances in two algorithms are small, which demonstrates that the approximate algorithm can replace the original one in most scenarios. D. Route Optimization Procedure The Route Optimization Procedure is shown in Figure 9. If a MN in DR mode decides to optimize the route to a specific CN, it enters OR mode by firstly sending a Route Optimization Init message to its PHA indicating the target CN and related HA CN. The message should also contain the Candidate HA Set as well as all the ( ) if needed. Then the PHA queries the HA CN to get all the ( ). After receiving the response, the PHA has got all the distances required for route selection. Then the PHA starts the algorithm to obtain an optimal HA for the MN-CN pair. The results are kept in a local table storing all candidate routes for each CN together with associated HA, cost and a flag indicating whether the route is currently being used. If the route selection results in a different route from the current one, the MN should send a Route Optimization Notification message to HA CN, MN and the chosen HA MN. The message should contain the address of the chosen HA MN in order to achieve HA switch. When receiving the notification, HA MN stores the MN s Binding Cache locally while HA CN modifies its local Binding Cache and redirect data packets towards the MN via the new route.

9 Though it takes several round-trips time to complete the Route Optimization Procedure, the procedure does not interrupt on-going data transfer. Besides, the procedure may not be frequently triggered since the results of Route Selection will not change much as long as the MN does not take a large-scale roaming (which is already proved by the simulation of HA switch in Section III). E. Discussion We make a discussion on what impact will the protocol design have on the performance and overhead evaluated in Section III. Specifically, we explain whether the protocol design will bring down the theoretical performance and what extra overhead it introduces. The first impact to performance comes from the route optimization procedure. Since the precondition of the evaluation in Section III is that an optimal HA is already chosen, but in practice there exists a period during which the suboptimal HA is used for communication, i.e. the DR mode in our protocol design. Though very short, the period before switching to OR mode is difficult to eliminate unless the HA (or MN) owns the distances values among the overlay nodes as prior knowledge. So triggering route optimization is more costefficient if it can longer benefit the on-going session. Another impact comes from the distance measurement. As is already shown, a certain level of distance approximation can lead to a solution which is as effective while costing less. It demonstrates to some extent that our proposal does not demand high accuracy on distance measurement. However it still worth studying what would be the impact of measurement inaccuracy and variation, and we include the topic in the future work. Except the overhead from HA switch and binding update, extra overhead is introduced due to the distance measurement and the propagation (query and response) of the measurement results in the form of extra traffic load to the network and processing overhead to the overlay nodes. However, if the approximation algorithm is used, only HA-to-HA distances require measurement. Besides, the overhead can be further reduced by locally caching the measurement results as is already described above. VI. CONCLUSION AND FUTURE WORK In this paper we research into the problem of selecting mobility anchors for mobile nodes in Mobile IP networks as well as other mobility protocols. We show that selecting the nearest mobility anchor to a MN is less-than-ideal in most scenarios. Then we prove that by allowing a MN to select independent mobility anchors for different CNs, both route optimality and switch overhead can be improved with acceptable extra cost. We also present an alternative way to realize the proposed idea in practice. However, there is certainly room for improvements. First, the algorithm to find hot HAs is suboptimal due to practical constraints. Second, the DNS-based HA discovery mechanism relies on additional services and real time measurements, and we wonder if other ways can be employed, e.g. using heuristic methods, to obtain nearby HAs together with their distances. Third, in the current protocol design the route optimization procedure may not lead to better performance if the MN s current HA is already the optimal one, thus it is to develop an algorithm to trigger route optimization only when it can bring benefits. Besides, we are also planning more simulations based on richer scenarios to further evaluate the proposal as well as protocol prototyping, deployment and experiment in real Internet environment. REFERENCES [] C. Perkins. IP Mobility Support for IPv4, RFC 3344, 22. [2] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775, 24. [3] IETF, Distributed Mobility Management (DMM) IETF Working Group. [Online]. Available: [4] H. A. Chan, H. Yokota, P. S. J. Xie, and D. Liu. Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues. Journal of Communications, vol. 6, no., pp. 4-5, Feb 2. [5] H. Soliman, C. Castelluccia, K. El Malki and L. Bellier. Hierarchical Mobile IPv6 Mobility Management (HMIPv6), RFC 44, 25. [6] Y. Mao, B. Knutsson, H. Lu, and J. Smith. DHARMA: Distributed Home Agent for Robust Mobile Access. in Proc of the IEEE Infocom 25 Conference, March 25. [7] R. Wakikawa, G. Valadon, and J. Murai. Migrating Home Agents Towards Internet-scale Mobility Deployment. ACM CoNEXT, 26. [8] S. Zhuang, K. Lai, I. Stoica, et.al. Host Mobility Using an Internet Indirection Infrastructure. In Proc. of the First International Conference on Mobile Systems, Applications, and Services. May 23 [9] R. Whittle and S. Russert. TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet s Routing Scale Problem. Technical report, Rosanna, Vic, Australia, Aug. 28. [] D. Farinacci, D. Lewis, D. Meyer and C. White. LISP Mobile Node. draft-meyer-lisp-mn-8, Oct. 22. [] K. Kawano, K. Kinoshita, K. Murakami. Multilevel hierarchical distributed IP mobility management scheme for wide area networks. in Proceedings of the IEEE ICCCN 22, October 22. [2] S. Pack, M. Nam, T. Kwon, and Y. Choi. An Adaptive Mobility Anchor Point Selection Scheme in Hierarchical Mobile IPv6 Networks. Elsevier Computer Comm., vol. 29, no. 6, pp , Oct. 26. [3] D. Pragad, A. Jaron, P. Pangalos, and A.H. Aghvami. Dynamic mobility anchor selection mechanism with QoS constraints. Communications Letters, IEEE, 5(), 94 96, Oct 2. [4] M. Fisher, F.U. Anderson, A. Kopsel, G. Schafer, and M. Schlager. A Distributed IP Mobility Approach for 3G SAE, 9th International Symposium on Personal, Indoor and Mobile Radio Communications, (PIMRC 28). [5] P. Bertin, S. Bonjour, and J-M Bonnin. Distributed or Centralized Mobility? Proceedings of Global Communications Conference (GlobeCom 29), Honolulu, Hawaii, Nov 29. [6] H. Chan. Proxy Mobile IP with Distributed Mobility Anchors. GlobeCom 2 Workshop on Seamless Wireless Mobility, Miami, USA, 6- December 2. [7] R. Cuevas, C. Guerrero, A. Cuevas, M. Caldern, C.J. Bernardos. P2P based architecture for global home agent dynamic discovery in IP mobility. 65th IEEE Vehicular Technology Conference, 27. [8] University of Oregon Route Views Project. [9] Rocketfuel: An ISP topology mapping engine. [2] G. Giaretta, J. Kempf, V. Devarapalli. Mobile IPv6 Bootstrapping in Split Scenario, RFC 526, 27. [2] J. Pan, Y. Thomas Hou, and B. Li, An Overview DNS-Based Server Selection in Content Distribution Networks, Computer Networks, vol. 43, no. 6, Dec. 23

10 Fraction of the total routes Fraction of the total routes Fraction of the total routes APPENDIX A Figure shows the simulation results using another two intra-as topologies also from Rocketfuel [9]. One is AS 3257 which contains 322 nodes and the other is AS 646 which contains 276 nodes. As we can learn, they show similar results as that in Section III. (a) AS 3257 (c) AS 3257 (e) AS Nearest-.2.3 Nearest- Nearest Deployment rate of of HA HA Deployment rate of of HA HA Deployment rate rate of of HA (b) AS 646 (d) AS 646 (f) AS 646 Nearest- Hop Nearest- Hop Deployment rate of HA Deployment rate of HA Deployment rate of HA Nearest- Hop Fig.. Proportion of the optimal routes (a, b), average stretch (c, d) and average switch cost (e, f) with HA deployment rate varies from % to 9% APPENDIX B Figure shows the Propotion of the optimal routes (a,b), average stretch (c, d) and average switch cost (e, f) of the light weight solution. The simulation topology is the same as that in Section III (a) Inter-domain Topology (c) Inter-domain Topology Nearest- Nearest Nearest- Nearest Deployment rate of of HA HA Deployment rate of HA Deployment rate of HA (e) Inter-domain Topology Nearest- Nearest

11 Fraction of the total routes (b) Intra-domain Topology (d) Intra-domain Topology Nearest- Nearest Nearest- Nearest Deployment rate of HA Deployment rate of HA Deployment rate rate of of HA (f) Intra-domain Topology Nearest- Nearest Fig.. Propotion of the optimal routes (a,b), average stretch (c, d) and average switch cost (e, f) of the light weight solution