A Service-Oriented Framework for Mobility and Multihoming Support

A Service-Oriented Framework For Mobility And Multihoming Support Amine Dhraief

Issam Mabrouki

Abdelfettah Belghith

HANA Research Group University of Manouba, Tunisia Email: [email protected]

HANA Research Group University of Manouba, Tunisia Email: [email protected]

HANA Research Group University of Manouba, Tunisia Email: [email protected]

Abstract—

Mobility and multihoming are usually considered as separate concepts and thus, they are handled by distinct protocols. Instead, our approach in this paper reverses that paradigm by proposing a unified solution that jointly manages both mobility and multihoming. Our solution is based on two protocols standardized by the IETF: Shim6 which provides a multihoming support to the end-hosts and mobile IPv6 (MIPv6) which manages node mobility. We have evaluated our proposal on a dedicated testbed and have shown that our solution efficiently manages both mobility and multihoming. This solution is of threefold interest. Compared to Shim6, our framework efficiently detects node movement and resolves the double jump problem. Similarly, compared to MIPv6, our framework provides a lightweight routing optimization which does not require a return routability check. Finally, our framework ensures a fault-tolerant home network. Index Terms—Mobility, Multihoming, MIPv6, Shim6

I. I NTRODUCTION Mobility and multihoming were generally perceived as separate concepts mainly because of their different nature of interaction with the set of the available addresses [10], [8]. Mobility protocols assume that mobile nodes (MNs) discover their new addresses consequently upon moving; whereas multihoming protocols assume that all the available addresses are pre-configured in advance int the MN. In addition, mobility protocols assume that the set of available addresses is subject to frequent changes due to the node movement. On the contrary, multihoming protocols assume that the set of available addresses is more or less stable as changes caused by failures or ISP renumbering operations are less frequent than node movement. These assumptions led to the separate development of mobility and multihoming protocols. However, mobility and multihoming are not so different in the end, since both of them aim at providing session survivability during the changes of the addresses currently in use. Moreover, both of them provide mechanisms to monitor the used path between the communicating peers: mobility protocols usually support for movement detection, while multihoming protocols usually embed failure detection functionalities. Failures and movements may be viewed as perturbations affecting the used path: for example, a movement can be considered as a failure

978-1-4673-0784-0/12/$31.00 ©2012 IEEE

in the first hop of the path. Thus, mobility and multihoming are in principal not different as mobility can be perceived as a dynamic multihoming. Current network protocol stacks provide an exclusive support for either mobility or multihoming and do not meet the requirements of the new multi-interfaced mobile terminals. Thus, we need to define a new network protocol stack that jointly enables both mobility and multihoming. Even though some solutions already exist to support both concepts [11], [5], [13], they usually just add the missing functionality to an existing protocol. We believe that such solutions are not efficient as they usually implement the missing mechanisms into an existing protocol while these mechanisms are already provided by another protocol. Our studies previously presented in [7] and [9] show that there is no solution that fully manages mobility and multihoming and can be deployed in the current Internet. Hence, we propose in this paper a novel framework that fully supports mobility and multihoming. Our framework is based on merging together two standards proposed by the IETF: Shim6 [14] and MIPv6 [12]. We delegate the mobility management to MIPv6, and the multihoming management to Shim6. The remaining of this paper is organized as follows. We firstly highlight in section II the limitations of the current standards of both mobility and multihoming, namely MIPv6 and Shim6. In section III, we focus on building blocks of the solutions to our problem. In section IV, we present the general architecture of our proposed framework. Finally, we evaluate our proposal through measurements on a real testbed and we conclude this paper in section VI. II. L IMITATIONS OF

THE CURRENT STANDARDS

We detail in this section the limitations of the current standards MIPv6 and Shim6 to efficiently handle multihoming and mobility respectively. The MIPv6 protocol is the current standard for end-host mobility management in the Internet [12]. Some extensions to MIPv6 aim at extending the original specification with a multihoming support. The multiple care-off address (MCoA) registrations with the flow binding [15] extensions provide a support for multiple address management to MIPv6; whereas the Home Agent (HA) reliability extension [16] implements mechanisms for HA failure detection and recovery. These

489

extensions are currently under standardization in the IETF. However, their interoperability remains unproved, as each extension does not take into account its applicability with the other one. In addition, each extension introduces its own mobility header options and its own signaling messages which may lead to a storm of control messages and to a nonoptimized execution on their future implementations. MIPv6 with its extensions has a limited failure detection support, that is, only the failure between the MN and the HA can be detected. Thus, it cannot provide a full fault-tolerant communication support. The Shim6 protocol is an IPv6 host-centric multihoming approach and one of the most promising multihoming solution standardized by the IETF [14]. Our studies in [7], [9] showed that Shim6 cannot handle some of the node mobility aspects, such as the efficient movement detection. Shim6 cannot efficiently detect nodes movement, since it uses its failure detection capabilities for movement detection. In fact, Shim6 perceives node movement as a failure in the current used path. To detect a failure, Shim6 relies on a dedicated protocol (REAP) which generates end-to-end signaling message. REAP assumes that failures are rare events and adjusts its internal timers consequently. To make REAP detects node movement, we have to frequently probe the current path and reduce the REAP internal timers. This will result in a storm of end-to-end signaling messages. We believe that it is more efficient to couple MIPv6 with an existing multihoming protocol rather than adding a multihoming support to MIPv6. The same thing can be applied to Shim6. It is more coherent to use an existing mobility protocol jointly with Shim6 rather than adding a mobility support to Shim6. We propose then to design a novel framework that provides both mobility and multihoming support. In our framework, we reuse the services provided by MIPv6 to support mobility and by Shim6 to support multihoming. For this purpose, we propose first to identify the building blocks for a protocol stack to provide both mobility and multihoming support. III. T HE BUILDING

BLOCKS

In this section, we detail the building blocks of our network protocol stack which supports both mobility and multihoming. A. Session survivability Session survivability is a common functionality provided by both mobility and multihoming protocols. It can be defined as the fact of preserving node running sessions after a change in the network layer connectivity. This functionality is of special interest to our network protocol stack for two reasons. First, MN change frequently their access networks while having ongoing communications. Second, multihomed nodes in general and multi-interfaced node more particularly should be able to seamlessly handoff from one address/interface to another without breaking their running session. In order to ensure the session survivability, we decouple node identity from its localization: the application handles the identifiers while IP routing layer handles the locators. Both

identifiers and locators are IP addresses and our network layer rewrites locators into identifiers and vice versa in case of outages or movements. B. Path monitoring Current multihomed MN are simultaneously reachable through several paths which are subject to change due to outages or node mobility. Events which occur in the segment between endpoints and their respective access routers are different from those that occur in the intermediate segment. Node movement is defined as the change of the point of attachment in the network. From a path perspective, movement is an event that affects the first hop of the path and happens more often than failures. We define movement detection as the capability of a node to detect its detachment from one link and reattachment to a new one in the network. By reducing the movement detection latency, we reduce the overall handover latency and we minimize the packet loss ratio during the movement. Unlike movements which affect the first hop of the path, failures affect the intermediate segment of the path and they occur rarely compared to movement. Thus, failure detection strategies should not be aggressive approaches that generate a lot of signaling messages. A conservative approach is more suitable for failure detection. We can use a dedicated protocol for this purpose (such as REAP [1] used by Shim6), or we can rely on hints from the upper layer protocols such as the TCP RTO timeout. C. Simultaneous movement The simultaneous movement or the double jump refers to the case where both communicating peer simultaneously execute an L3 handover and get attached to a new access network. As the number of the MNs in the Internet is constantly growing, the probability that two communicating peer simultaneously move has become non negligible. Thus, new network protocol stacks should be able to manage this case. In order to manage the double jump, we need to insert a new registrar element in the network architecture which plays the role of a meeting point. In the beginning, each node registers itself in this registrar node, and each time it changes its current position in the network and acquires a new address, it updates its own information recorded in the registrar element. D. Secure peer update Both the node and the registrar element have to maintain a context structure holding some information such as node identity, its location, and its currently available addresses. Upon the acquisition of a new address, nodes have to update their records in the registrar and in their correspondent peers. The update of node information raises a security problem. A malicious node may create a false binding between its identity and the victim’s location to hijack the victim’s session. It can also start a communication with its identity and then create a false binding between its identity and the victim’s location in order to flood its victim with unwanted traffic.

490

In order to secure the update of its peer information, each node has to prove the ownership of its addresses. The Shim6 protocol achieves this by using both CGA and HBA addresses[2], [3]. The MIPv6 protocol secures the update of the binding cache of its correspondent peers through the return routability procedure. IV. A RCHITECTURE

by definition) into an HoA. Shim6 can also rewrite the ULID into a CoA, if the MN has just moved and obtained a new CoA. In this case, the MIPv6 rewriting is not activated and packets modified by the Shim6 sublayer are directly sent to the correspondent peers. We call this operation mode Shim6-RO (RO for routing optimization) as packet are directly forwarded to the correspondent peers without flowing via any HA. If the MN has several HoA, the Shim6 sublayer selects one HoA as a ULID. If the selected HoA become invalid, due to the failure of the correspondent HA for example, Shim6 rewrites this HoA into a new valid one and transfers the obtained result to MIPv6. If the node is located in its home network, then the MIPv6 rewriting is not activated. If the node is located in a visited network and the Shim6-RO mode is not activated, then MIPv6 rewrites the source of the packet sent by the Shim6 sublayer (HoA) into a valid CoA. In some cases, only MIPv6 rewriting can be performed. For example, when the MN starts a communication with a correspondant node (CN), it does not immediately establish a Shim6 context, thus, only the MIPv6 rewriting can be supported. Similarly, if one of the communicating peers does not support the Shim6 protocol, only the MIPv6 rewriting is activated. V. E VALUATION

Fig. 1: Reference model In this section, we present our proposed framework which supports both mobility and multihoming (see Fig. 1). Bagnulo et al. [4] proposed a similar network architecture, but their target was to study the interoperability between MIPv6 and Shim6. Our framework extends this architecture by restraining the set of the services provided by each sub-layer in order to efficiently handles both mobility and multihoming. For example, even though MIPv6 has some failure detection capabilities and Shim6 can detect movements, we delegate to MIPv6 the movement detection and to Shim6 the failure detection. Thus, we select the service from the layer which best performs it. In our proposed architecture, we have several levels of address rewriting. The transport layer handle MIPv6 home addresses, which are considered as permanent identifiers or ULID (upper layer identifier). The first level of address rewriting is performed by the Shim6 sublayer which rewrites the ULID into a locator. This locator can be either an HoA or a CoA. The second level of address rewriting is performed by the MIPv6 sublayer which rewrites an HoA into a CoA. The Shim6 sublayer performs an address rewriting only when the Shim6 context is established. Shim6 can rewrite the ULID into an HoA. A MN can obtain several HoA because its home network is multihomed or it has several network interfaces. In this case and if the MN has not yet moved, then the Shim6 sublayer may rewrite the ULID (which is an HoA

We present in this section an evaluation of our framework performed on real testbeds. Our framework is the result of the combination of the LinShim6 Shim6 suite with the UMIP MIPv6 suite. In this evaluation, we aim at studying the impact of the HA failure on a TCP session. For this purpose, we set up the following testbed presented in Fig. 2. In our experiment, we set all the wireless accesses to 802.11g at 54Mbit/s. The wired link is a fast Ethernet link at 100Mbit/s. In the LinShim6 software, we set up the REAP Tsend Timer to 1s. We experiment, the following scenario. The MN boots in the visited network and then it discovers the HA. After registering with it, the MN starts a secure copy (scp) session with a CN located in a distinct network. The MN establishes then a Shim6 context with the CN. The packets are sent via the tunnel between the MN and the HA (we do not enable the Shim6-RO mode). After 60s from the beginning of the scp session, we provoke a failure in the HA. The MN detects this failure and rehomes the scp session to the path defined by the address pair (CoA, address CN). In this experiment we first focus on the evolution of TCP throughput measured on the MN side before, during, and after the HA failure. Then we measure the Application Recovery Time (ART) metric which was firstly defined in [6]. The ART is the latency between the last TCP data segment before the HA failure and the first TCP data segment after recovering from the HA failure. We measure the ART for different REAP Tsend values. The curve presented in Fig. 3 illustrates the variation of the TCP throughput during the HA failure. Before the failure occurs (60s from the beginning of the experiment), data packets are exchanged via the HA tunnel. After the recovery

491

ART vs. Tsend 18

ART (s)

16

ART (s)

14 12 10 8 6 4 2

4

6

8

10

12

14

16

Tsend (s)

Fig. 4: Application Recovery Time vs Tsend Fig. 2: Testbed: HA failure impact on a TCP session VI. C ONCLUSION Throughput vs. Time 2.5e+07

Throughput (bit/s)

Throughput (bit/s)

2e+07

1.5e+07

1e+07

5e+06

0 0

20

40

60 80 Time (s)

100

120

140

Fig. 3: Evolution of the TCP throughput during a failure of home agent

from the HA failure, packets are directly exchanged between the communicating nodes. The absence of the tunnel with the HA explains the ”slight“ improvement of the TCP throughput after the HA failure recovery compared with the throughput before the failure. This curve shows that our framework is tolerant to the HA failure;whereas, in the case of the usage of a standalone MIPv6, the communication will not resume after the HA failure.

In this paper we proposed a novel framework that provides both mobility and multihoming functionalities at the end-host level. Firstly, we designed a framework that combined two existing protocols Shim6 and MIPv6, where multihoming services are provided by the Shim6 protocol, while mobility services are provided by the MIPv6 protocol. But, as explained before, some services are supported in both sublayers. so we design our framework to be service-oriented solution, i.e., we select the service from the sublayer which best performs it even if it is provided by both sublayer. For example, even though both MIPv6 and Shim6 can detect node movement, we delegate this functionality to MIPv6 because Shim6 considers movements as failures and thus are detected at a late time. Secondly, we evaluated our proposal on a real testbed. This evaluation highlighted our solution capabilities in terms of mobility and multihoming management. We showed through our experimentations that our solution efficiently detects failures and recovers from them in a mobile environment. Furthermore, the HA is a single-point of failure for MIPv6 protocol and its MCoA extension since it is the key element in the mobility architecture. So in the case of a HA failure, all the MN will have their running communications interrupted. We demonstrated that our framework alleviates this constraint through the Shim6 sublayer that detects the HA failure and rehomes the running communication to an alternate path.

The curve presented in Fig. 4 illustrates the measured ART for each REAP Tsend time value. We can see that increasing the Tsend timer value, increases the ART. This means that, for small Tsend values, REAP quickly discovers the HA failure; whereas it takes much more time for failure discovery for high Tsend timer values. Moreover, we can see that the ART follows a linear curve (ART ≃ T send + 1.69s). In fact, in our experiment we use the TCP optimization proposed in [6]: we set up the TCP RTO timer to 0 when Shim6 recovers from a failure.

492

R EFERENCES [1] J. Arkko and I. van Beijnum. Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming. RFC 5534 (Proposed Standard), June 2009. [2] T. Aura. Cryptographically Generated Addresses (CGA). RFC 3972 (Proposed Standard), March 2005. Updated by RFCs 4581, 4982. [3] M. Bagnulo. Hash-Based Addresses (HBA). RFC 5535 (Proposed Standard), June 2009. [4] Marcelo Bagnulo, Alberto Garc´ıa-Mart´ınez, and Arturo Azcorra. Fault tolerant scalable support for network portability and traffic engineering. In WWIC ’07: Proceedings of the 5th international conference on Wired/Wireless Internet Communications, pages 129–140, Berlin, Heidelberg, 2007. Springer-Verlag.

[5] Ł. Budzisz, R. Ferr´us, A. Brunstrom, K. J. Grinnemo, R. Fracchia, G. Galante, and F. Casadevall. Towards transport-layer mobility: Evolution of sctp multihoming. Comput. Commun., 31(5):980–998, 2008. [6] Antonio de la Oliva, Marcelo Bagnulo, Alberto Garcia-Martinez, and Ignacio Soto. Performance Analysis of the REAchability Protocol for IPv6 Multihoming. In Next Generation Teletraffic and Wired/Wireless Advanced Networking 7th International Conference, NEW2AN 2007, pages 443–454, September 2007. [7] Amine Dhraief and Abdelfettah Belghith. Mobility impact on session survivability under the shim6 protocol and enhancement of its rehoming procedure. Journal of Networks, 2011. Accepted and to appear Nov 2011. [8] Amine Dhraief and Nicolas Montavont. Toward Mobility and Multihoming Unification- The SHIM6 Protocol: A Case Study. In Wireless Communications and Networking Conference, 2008. WCNC 2008. IEEE, pages 2840–2845, Las Vegas, Nevada/USA, March/April 2008. [9] Amine Dhraief and Nicolas Montavont. Rehoming decision algorithm : design and empirical evaluation. IEEE Symposium on Embedded and Pervasive Systems, EPS’09, 2009. [10] Amine Dhraief, Tanguy Ropitault, and Nicolas Montavont. Mobility and multihoming management and strategies. In IFIP, editor, 14th Eunice Open European Summer School 2008. RSM Dept (Institut TELECOM ;TELECOM Bretagne), 2008. [11] Jahanzeb Faizan, Hesham EL-Rewini, and Mohamed Khalil. Introducing reliability and load balancing in mobile ipv6-based networks. Wirel. Commun. Mob. Comput., 8(4):483–500, 2005. [12] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775 (Proposed Standard), June 2004. [13] Jenn-Wei Lin and Ming-Feng Yang. Fault-tolerant design for wide-area mobile ipv6 networks. The Journal of Systems and Software, 2008. [14] E. Nordmark and M. Bagnulo. Shim6: Level 3 Multihoming Shim Protocol for IPv6. RFC 5533 (Proposed Standard), 2009. [15] H. Soliman, G. Tsirtsis, N. Montavont, G. Giaretta, and K. Kuladinithi. Flow Bindings in Mobile IPv6 and Nemo Basic Support. Internet draft, draft-ietf-mext-flow-binding-02.txt, work in progress, April 2009. [16] R. Wakikawa. Home Agent Reliability Protocol. Internet-Draft draftietf-mip6-hareliability-04.txt (work in progress), July 2008.

493