private address managed by a mobile router and a topologically ..... monitor. The mobile router used code developed in [13] and was connected to the current ...
HarMoNy - HIP Mobile Networks Stephen Herborn, Luke Haslett, Roksana Boreli, Aruna Seneviratne National ICT Australia Sydney, Australia {firstname.lastname}@nicta.com.au Abstract—We present arguments to support the co-existence of two or more mobility management schemes, and detail a novel approach to integrate the mobility and multi-homing support provided by a higher level mobility mechanism, the Host Identity Protocol (HIP), with a lower level mobility mechanism, NEtwork MObility (NEMO, i.e. Mobile IPv6 enabled routers). Our design integrates a context aware handoff system that triggers the dynamic switching of the HIP host identity binding between a private address managed by a mobile router and a topologically correct address, in order to simultaneously take advantage of the efficient handover offered by vehicular networks with NEMO support, and the infrastructure-less operability of HIP when mobile routers become unavailable. We discuss implementation and detail how our scheme uses context cues such as vehicle speed to switch between NEMO and HIP mobility handling. We present results of emulation experiments that support our design.
I.
M
INTRODUCTION
uch recent research on seamless connectivity for vehicular environments has focused on extensions to link layer protocols and various versions of mobile IP [1][20] coupled with mobile routers [11]. At the same time many advances in networking research have been in the development of schemes that manage mobility at a higher level by bypassing the need to maintain a static IP address. The Host Identity Protocol (HIP) [2][6], the Session Initiation Protocol (SIP) [7], and the Stream Control Transmission Protocol with mobile extension (mSCTP) [8] are all prominent examples of higher layer mobility solutions. Many additional higher level proposals exist in the literature[9][10] [19]. The benefits and drawbacks of any mobility scheme depend greatly on the layer(s) of the communication stack at which it functions. Lower level mobility schemes provide fast and seamless transition from the perspective of applications; however entail high deployment costs in terms of required additional network infrastructure, and are generally limited to handling mobility of one type of network interface rather than of a whole device. Higher level schemes, on the other hand may be designed to minimise or negate the need for additional infrastructure, as well as enable logical mobility between network interfaces within the same device. Most such schemes require some modifications to endpoint operating systems unless connection-oriented sessions are allowed to break,. Another potential drawback of higher level mobility schemes is increased signalling and processing load and subsequent increased energy consumption, on individual endpoint devices
which are likely to be small and battery powered. Considering the large number of schemes which have been proposed, it is possible that a number of different mobility schemes may be, deployed simultaneously, each with varying levels of infrastructural and end-system support throughout the global network. It is desirable to ensure that such schemes cooperate to provide gains in efficiency and/or functionality. In this paper we present the design and analysis of HarMoNy: a scheme for interoperation of two well known techniques, namely HIP and NEtwork MObility (NEMO), which offer higher and lower level mobility support respectively. The interoperation is based context aware handoff selection that is transparent to the mobility protocols themselves. We show that the proposed scheme minimises costs related to handover latency, infrastructure, and end-system requirements. The rest of the paper is organised as follows. In section II we briefly detail several well-known schemes for higher and lower level mobility, as well as hybrid schemes. In section III we provide an introduction and discussion of mobility management in two mobility schemes, namely HIP and NEMO, including their respective strengths and limitations. In section IV we present the design of HarMoNy: a scheme that uses context cued to switch between NEMO and HIP mobility handling techniques. Section V contains analysis and details of implementation efforts, and in section VI we conclude. II.
OVERVIEW OF EXISTING MOBILITY SOLUTIONS
For our work the OSI network layer serves as the demarcation boundary between higher and lower level. Some schemes can be further classified as hybrids of high or low level schemes. In the rest of this section we provide an overview of the stateof-the art in low level, high level, and hybrid mobility schemes. Our main focus is on the network layer and above. A. Low level schemes Solutions at the network layer and below are collectively grouped as ‘lower level’ since their purpose is to keep the IP address static from the perspective of transport layer sockets, as opposed to higher level solutions which may bypass the need for static IP addresses altogether. Lower level schemes also require infrastructural support, such as Home Agents, and possibly specific hardware such as multiple network interfaces. Network layer solutions provide traffic redirection to the new location of the mobile entity. Mobile IP (MIP) is the best known network layer mobility mechanism, which assigns each
host a home IP address which is constant regardless of the host movement in different networks. MIP, and by extension MIPv6 and NEMO, may be classified as lower level since their intent is to present a static IP address to transport sockets. Other such mobility schemes include Cellular IP[21], Hawaii [22], and other optimisations on MIP such as S-MIP [20]. B. Higher level schemes Higher level schemes operate at the layers above the OSI network layer. Session Initiation Protocol (SIP) [7] performs mobility handling at the application layer and can re-start or re-direct the current session after mobility using a SIP proxy. A number of proposals seek to handle mobility between the transport and session layer, and thus handle communication state / process migration and allow for flexible binding of network connections. MIGRATE [9] and SLM[19], are both examples of proposals that handle mobility at the session layer. SCTP [8] is a transport layer approach which enables an endpoint to use multiple IP addresses for a connection and to dynamically change IP addresses associated with a connection. HIP provides a method of separating the end-point identifier and locator roles of IP addresses in a newly defined layer that sits between network and transport. It introduces a new Host Identity name, which is based on public keys. A large amount of work has being done to enhance support for multi-homing and mobility in HIP [2][3][4][5][6].
vehicular network connectivity to mobile devices without requiring each device to manage or even be aware of the movement of the vehicle. The mobile router (MR) presents a static address prefix to MNs and performs all MIPv6 signalling on their behalf. This allows the use of non-MIPv6 enabled mobile nodes within the vehicular area network (VAN) serviced by the MR. Furthermore, MRs are able to provide connectivity to MNs via a wired local network, thus saving multi-homed MNs from engaging in expensive communication over wireless links and also providing service to nodes that are not able to communicate with the access router, for example if the ARs use WiMAX the MR may offer connectivity via 802.11 to nodes that do not support WiMAX. In this paper we focus on the scenario in which MNs are able to communicate to both the MR and AR directly. The major drawback of NEMO is that once the mobile node leaves the coverage area of the mobile router, then the mobility handling support disappears. Figure 1 depicts an operational scenario of MIPv6 with MR support. Note that in large vehicles it is possible for there to be more than one MR within a VAN, each with their own address prefix, thus MNs travelling through the VAN may need to change IP address.
C. Hybrid schemes Hybrid mobility schemes use a combination of mobility protocols, to handle either different traffic or different mobility types. MIP and SIP [14] is an example, and other pairings e.g. SIP and HIP [15][16] have also been proposed. III.
MOBILITY MANAGEMENT IN HIP AND NEMO/MIPV6
Mobile IP and Host Identity Protocol are two well researched, independent solutions that perform mobility management at and above the network layer respectively. A. Mobile IPv6 and NEMO Mobile IPv6 (MIPv6) is a standardised extension to IPv6. In MIPv6 each MN is identified by a static globally unique home address (HoA) which is allocated by a home agent (HA). The HA is a router supporting mobility services for MNs belonging to the home network. When the MN moves to a new network it acquires a new network address called a careof-address (CoA). The MN informs the HA of the new CoA and the HA updates an internal binding between the MN HoA and its current CoA. Using this information the HA tunnels any incoming packets from correspondent nodes (CN) to the MN via its current CoA. Each time the MN acquires a new CoA it informs the HA. In the context of vehicular communications MIPv6 may be implemented in mobile routers (NEMO) [12] to provide intra-
Figure 1: Mobile router operational scenario B. Host Identity Protocol HIP handles mobility by introducing a thin layer of additional resolution between the network and transport layers, decoupling transport sockets from network level addresses. Instead of binding to IP addresses, HIP enabled applications bind to 128-bit Host Identity Tags (HIT), a global identifier generated by hashing a public key. In order for HITs to be globally reachable, some kind of infrastructural support is required to be able to map HITs to routable network level addresses. At present several mechanisms including DNS [5], distributed hash tables Error! Reference source not found., and rendezvous servers [5] are being investigated as a means to provide this mapping. However, once both hosts engaged in end-to-end communication are aware of each others HIT, no further infrastructural support is required unless both hosts change network location simultaneously with no prior notification. Due to the decoupling between network and transport layers, HIP enables applications on the mobile node to continue communication oblivious to changes in available
network addresses and also provides a mechanism to directly signal a change in network address to the correspondent node. An authentication process precedes each HIP communication session. HIP uses a four-way key exchange to verify the identity of the hosts, termed Initiator (I) and Responder (R). The built-in security functions of HIP are a drawback in terms of increased signalling overhead, alongside the requirement for both ends of the communication session to have HIP integrated into their operating systems’ communication stack. However, NEMO at the very least requires the infrastructural support a mobile router and one home agent, whereas HIP requires no support to maintain connectivity if the endpoint nodes do not move simultaneously. IV.
OPERATIONAL OVERVIEW OF HARMONY
HIP
Get C
g din bin
6
g in
1.
Whether the MN should directly configure a care-ofaddress from the AR. This occurs if the ‘speed’ of the vehicle falls below a threshold, T1 as in Fig 4(b).
2.
Whether the MN’s HIP daemon should bind to an address offered by the static access router, or to an address managed by the MR, if the ‘speed’ of the vehicle falls below a second threshold T2 as in Fig 4(c).
An additional metric that may be included in our heuristic is the number of MNs currently within range of the MR. In general, it is best to allow the MR to handle mobility when the vehicle is moving fast, and especially when there is more than one MN within range. The rationale behind this is that the MR is more likely to be capable of dealing with rapid changes in ARs, and may reduce the overall signalling overhead if it performs mobility handling on behalf of many MNs. This is validated by emulation results in the following section.
P HI
v IP M
nd Bi
oA
In section III it was noted that, while both of the introduced protocols perform well, both schemes also have a number of limitations. Such limitations are not specific to MIPv6 or HIP, but are evident in all mobility management schemes to some degree. In general, lower level mobility management is more efficient and require less involvement from end-systems, but entail greater infrastructural requirements and does not provide intuitive support for multi-homing without modification [18], whereas higher level mobility requires endsystem support, additional signalling and encapsulation overhead while requiring less infrastructural support and providing intuitive handling of multi-homing. The interactions with security mechanisms like IPSec are more suitably performed by higher level schemes.
about wether it should configure new IP addresses and/or use them by switching to a the network. The goal of the system is to reduce the total cost due to signalling, processing and delay overhead and/or provide connectivity in scenarios where previously there was none, while avoiding changes to the internal operation of the mobility protocols. In section V we analyse our solution against these and other criteria. Our design is based on a terrestrial vehicular scenario (as in Figure 2), and we use the rate of change of access routers, coupled with information about the frequency of router advertisements from the MR and the AR, to construct a coarse grained approximation to the speed of the vehicle in order to form a heuristic that makes the following decisions:
Figure 2: Illustration of context based HIP binding switch In HarMoNy, we leverage the strengths and weaknesses of HIP and MIPv6 by using HIP-enabled Mobile Nodes that are capable of dynamically rebinding to any available address. HarMoNy nodes are also able to delegate their mobility handling to MIPv6 enabled mobile routers based on available context information. This involves a small modification to the mobile node and the mobile router to enable the MN to configure addresses from both the mobile router and the access router when router advertisements from either entity are detected and when context indicates that an address should be configured. In some cases, for example when the rate of change of ARs is high, it is not worthwhile for the MN to configure a topologically correct address. An additional modification to the MN is required in order to enable it to make an intelligent decision based on context cues
V.
ANALYSIS
We have implemented a prototype of the proposed system for validation, and performed a series of tests on the handover latency of HIP and NEMO under various network conditions. The mobile node was based on public source code from the HIPL project [17]. The kernel was altered to accept modified router advertisement messages containing both the delegated prefix of the mobile router as well as the prefix of the current access router. On the receipt of such an advertisement and assuming the context conditions are met (e.g. the rate of change of ARs is low), IPv6 addresses corresponding to both prefixes are configured using stateless address configuration. The selection of which configured address to set as the default to which application sessions may bind is driven by a context monitor. The mobile router used code developed in [13] and was connected to the current access router and mobile node via an emulated wireless connection. The mobile router was modified to includeth its delegated prefix as well as the prefix of the current access router within its router advertisements. Such a modification does not interfere with the standard operation of IPv6. If the mobile node was multi-homed, with
interfaces connected to both the AR and the MR, then the MR would not need to include the AR prefix in its advertisements since this information would be directly available to the MN. We emulated changes in AR by moving the MR and/or MN between two access routers. Figure 3 depicts observed messages exchanged in our prototype at stages (a), (b), (c) of the scenario from Figure 2. HA
AR 1
AR 2
MR
MN Router Adv.
Router Adv. Neighbour Solic
MR Performs MIPv6 Handoff from AR 1 to AR 2
Neighbour Solic MIPv6 bind update MIPv6 bind update MIPv6 bind ACK MIPv6 bind ACK
(a) Rate of change of AR > T1, MN does not configure CoA from AR 2. HA
AR 2
AR 3
MR
A set of experiments were performed on an emulation platform in order to compare the handover latencies of HIP and NEMO under varying network conditions. For the purpose of our experiments, handover latency refers to the time taken to re-establish end-to-end connectivity after a handover. The ARs were configured to send out route advertisements at a rate high enough to mitigate random additive delay due to address configuration without overloading ARs or their network links. We compare the maximum packet inter-arrival time for three handover scenarios: NEMO (MR moves to a new AR), HIP-a (MN changes IP address but remains in same network), HIP-b (MN moves to a new network). The primary difference between the HIP-a and HIP-b scenarios is that the latter requires re-keying, whereas the former does not.
MN
Router Adv.
Router Adv.
Neighbour Solic
Neighbour Solic
Neighbour Solic
Neighbour Solic
MR Performs MIPv6 Handoff from AR 2 to AR 3
MIPv6 bind update MIPv6 bind ACK MIPv6 bind ACK
(b) Rate of change of AR < T1, MN configures CoA from AR 3 but does not use it. CN
HA
AR 3
MR
MN
HIP Readdress HIP Readdress ACK + challenge HIP Readdress challenge response HIP Readdress challenge ACK
MN selects CoA from AR 3 as default address & performs HIP handoff directly with CN
(c) Rate of change of AR < T2, MN configures switches to CoA offered by AR 3 End-to-end TCP Session (indirection points as black dots) ICMPv6 Router Advertisement (modified) MIPv6 Rebind / ICMPv6 Neighbor Solicitation / HIP Readress message
Figure 4: Handover latency vs. end-to-end delay
Figure 3: Message flow diagram A. Analysis of performance gains We provide an analysis of the performance gains possible with HarMoNy, including quantitative analysis of handover latency, as well qualitative analysis of core infrastructure and end-system support requirements. 1)
Handover latency
The MIPv6 rebind message must travel to and be acknowledged by the MR’s HA, regardless of it’s current location, or the location of any corresponding hosts towards which there are ongoing sessions. Thus the MIPv6 component of the handoff delay is RTTMR-HA or RTTMN-CN depending on wether route optimisation is being used. A HIP re-address requires, in the worst case, 2.RTTMN-CN before the session can continue. Therefore, it can be seen that if RTTMR-HA < 2.RTTMN-CN then the MIPv6 binding update will occur faster than the HIP re-address. As such it is desirable to use available mobile routers in scenarios where the RTT between communicating endpoints is high relative to the potential rate of changes of access routers e.g. the scenario depicted in Fig. 1 involving a high latency satellite link.
Figure 5: Handover latency vs. packet loss rate Handover requires one or more message exchanges between the endpoints and/or the HA, as shown in Fig. 3, Figure 4 shows the average handover time in seconds against an average end-to-end propagation delay ranging from 0 to 10ms. It can be concluded from this result that the RTT is not a major factor in the handover latency and this implies that the major component of handover latency is due to processing. Figure 5 shows the average handover time in seconds against
an average end-to-end bi-directional packet loss ranging from 0 to 10%. The results imply that the relative delay due to handover in the three scenarios remains roughly constant, regardless of instability in the communication channel. The results presented in Figures 4 and 5 indicate that the average handover latency for NEMO is consistently lower than for the HIP-b handover case and slightly less than 50% higher than for the HIP-a case. From this it can be concluded that it is preferable to handle mobility with NEMO in cases where a HIP re-keying exchange is required. In HIPL rekeying is required for transition between addresses with different prefixes; however this is a matter of local policy. Of course the MN may simply opt to never require a re-key however there is no guarantee that the CN will not require a re-key, whereas NEMO handover is transparent to the CN. From the experimental results it is also clear that the assumptions upon which the design of HarMoNy is based are independent of the physical characteristics of the channel since the relative handover latency of HIP and NEMO remains constant despite variations in link loss and delay. This means that the solution is valid for in any radio or fixed network. 2)
Infrastructure and end-system requirements
Higher lever mobility management requires a minimal infrastructural investment (i.e. one HA or zero to one RVS[5]), and thus is the desired option when no support for lower level mobility handling is available. Our proposal introduces no new infrastructure requirements, but rather allows MNs to be mobile in networks that have no mobile router support. Since the changes we propose do not interfere with the normal operation of either MIPv6 or HIP (as it is currently defined), we believe the implications of integrating our proposal into end-systems that already have HIP and/or MIPv6 support in-built are negligible. Our implementation required a small modification to the operating system kernel, however even this could possibly be avoided. VI.
CONCLUSIONS AND FUTURE WORK
We have presented a scheme for dual layered mobility management based on two well known mobility schemes that are in the process of standardisation and dynamic context driven heuristics that make the decision regarding the scheme to be used. We have detailed how our scheme complements mobility handling in HIP by reducing the signalling overhead and delay of the handover process. We observe that it is likely that in the future it may be possible that many mobility schemes will be deployed, with various levels of support throughout the global network. It is important to note that our approach could also be applied to other protocols, since we make no explicit modifications to the protocols themselves, but merely externally manipulate their operation in order to achieve more efficient interoperation. Therefore, although we have based our design on the
assumption that mobility will be supported via a combination of vehicular mobile routers with MIPv6, and mobile nodes with HIP support communicating with correspondents that also speak HIP, a similar approach could also possibly be applied to MIPv4 and SCTP, for example. We plan to continue the work on the dynamic scheme selection heuristics in HarMoNy and also consider other mobility schemes that could benefit from this approach. ACKNOWLEDGEMENTS The authors gratefully acknowledge Henrik Petander for his advice and National ICT Australia for its support of this work. REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]
H. Soliman, “Mobile IPv6”, Boston: Addison Wesley, 2004 Pekka Nikander, Jukka Ylitalo, and Jorma Wall, "Integrating Security, Mobility, and Multi-Homing in a HIP Way," in Proc. NDSS, February 6-7, 2003, San Diego, CA, pp T. Henderson, “End-Host Mobility and Multihoming with the Host Identity Protocol”, IETF draft, http://www.ietf.org/internet-drafts/draftietf-hip-mm-02.txt P. Nikander, J. Laganier, “Host Identity Protocol (HIP) Domain Name System (DNS) Extensions”, IETF draft, http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-02.txt J. Laganier, L. Eggert, “Host Identity Protocol (HIP) Rendezvous Extension”, IETF draft, http://www.ietf.org/internet-drafts/draft-ietf-hiprvs-03.txt T. Koponen, A. Gurtov, P. Nikander, Application Mobility with HIP, in Proc. of ICT'05, May 2005 E. Wedlund, H. Schulzrinne, “Mobility support using SIP”, in IEEE/ACM Multimedia conference WOWMOM, 1999 RFC 2960: Stream Control Transmission Protocol, October 2000 A. Snoeren, “A Session-Based Architecture for Internet Mobility”, PhD thesis, MIT, 2002 Yun Mao, Bjorn Knutsson, Honghui Lu, Jonathan M. Smith. DHARMA: Distributed Home Agent for Robust Mobile Access. IEEE INFOCOM 2005, Miami, Florida, March 2005 E. Perera, V. Sivaraman, A. Seneviratne, “Survey on Network Mobility Support”, Mobile Computing Communications Review, volume 8, 2004. Draft-lach-nemo-experiments-overdrive-01.txt E. Perera, A. Seneviratne, V. Sivaraman, ‘OptiNets : An architecture to enable optimal router for network mobility ‘, International Workshop on Wireless Ad-hoc Networks, Oulu, Finland, 31 May – 3 June, 2004. J. Jung, H. Kahng, R. Mudumbai, D. Montgomery, “Performance evaluation of two layered mobility management using mobile IP and session initiation protocol”, In Proc. IEEE Globecom 2004. So, J.Y.H.; Jidong Wang; Jones, D., “SHIP Mobility Management Hybrid SIP-HIP Scheme”, In Proc. ACIS ICSE , May 2005 Page(s):226 – 230 T. Henderson, “Can SIP use HIP?”, Workshop on HIP and Related Architectures, Washington DC, November 6, 2004 HIP for Linux (HIPL), http://infrahip.hitt.fl Multihoming with Mobile IP, C. Åahlund, A. Zaslvsky, In Proc. 6th International Conference on High Speed Networks and Multimedia, Portugal, 2003. B. Landfeldt, T. Larsson, Y. Ismailov, A. Seneviratne, SLM, a Framework for Session Layer Mobility Management, ICCCN99, Boston, Oct. 1999. Robert Hsieh, Zhe Guang Zhou, Aruna Seneviratne: S-MIP: A Seamless Handoff Architecture for Mobile IP. INFOCOM 2003 A. Valko, “Cellular IP: A new approach to host mobility”, ACM SIGCOMM CCR, Volume 29, Issue 1, January 1999 R. Ramjee et al., “HAWAII: A Domain-Based Approach for Supporting Mobility in Wide-Area Wireless Network”, ICNP1999
