A Design of SDN Based IP Mobility Management Considering Inter-Domain Handovers and Its Evaluation

To use IP services continually while users are moving with their mobile devices, IP mobility management that enables them to keep IP communication is necessary. Although Mobile IP is a popular method to manage IP mobility, Mobile IP has a problem that there is a possibility of a mobile node (MN) communicating over a redundant route. Then, Software Defined Network (SDN) based IP mobility management has emerged to solve this problem. Most of these solutions focus on intra-domain handovers and routing. However, since wireless network environment has spread, mobile devices move across domains during communication. To deal with this, we need to look upon inter-domain handovers and routing. In this paper, we propose a SDN based IP mobility management scheme considering situation of mobile devices moving across domains. This proposed scheme focuses on inter-domain handovers and introduces efficient functions of management information sharing and inter-domain routing. Experimental results show the desired effects of the proposed scheme: optimizing communication route and keeping the management information exchange traffic low.


Background and Overview
This paper is an extension of work originally presented in 2016 18th Asia-Pacific Network Operations and Management Symposium (APNOMS) [1]. Due to the widespread of wireless network environment, it is now possible to use Internet services in various places and scenes, and IP services like file transfer service, remote terminal service, and virtual desktop service are popularly used [2,3]. These services can be used with small-sized devices capable of wireless communication like laptop PCs, smart phones, tablet PCs. We call them mobile node (MN) from now on. MNs are portable, thus people tend to move around while using IP services with MNs. Especially with session continuous IP services, continuity of service during movement may be a problem. When a MN moves and connects to an access point in a different network domain, MN's IP address may change. If MN's IP address changes during communication and communication session is disconnected, this causes some problems that would affect the use of services may occur such as lack of data and logout from services. Thus, IP mobility management is essential for enabling use of IP services while moving.
Mobile IP is one of the IP mobility management standardized by Internet Engineering Task Force (IETF) [4][5][6]. Mobile IP is a technology to enable continuous communication when a MN moves during a communication. Even when a MN moves to a different domain, it enables the MN to continue its communication with the IP address that it was using before the movement. However, there are cases that a MN's communication route falls into a triangular routing. This might lead to a degrade in quality of service caused by communication delay. Moreover, it is necessary for a MN to be equipped with Mobile IP function, and this leaves a challenge of application to all MNs.
There are some researches that apply Software Defined Network (SDN) to IP mobility management to solve the problems ASTESJ ISSN: 2415-6698 * Misumi Hata, 2-1-1 Katahira, Aoba-ku, Sendai 980-8577, Japan, +81222175080, Email: m-hata@ci.cc.tohoku.ac.jp Advances in Science, Technology and Engineering Systems Journal Vol. 2, No. 3, 922-931 (2017) www.astesj.com Special Issue on Recent Advances in Engineering Systems mentioned above [7,8]. SDN is a technology to control a network dynamically with a software [9]. We show an overview of SDN in Figure 1. By using SDN, a SDN controller centrally manages SDN switches in their domain and this enables nodes to communicate with suitable route. However, existing researches focus on intradomain move. To cope with inter-domain movement with SDN, SDN controllers in different domains have to exchange information about movement of a MN. On this occasion, communication cost between SDN controllers may increase and it might become a problem in practical use. Therefore, it is difficult to maintain communication efficiently when a MN makes an interdomain move.
There were two major trends in ways to handle inter-domain handover with SDN. One approach is to use Mobile IP when interdomain handovers occurs [8]. By using Mobile IP, SDN controllers doesn't need to search for domains to exchange information of MNs. However, Mobile IP has difficulty in communication route optimization. Another is to announce information of MNs to every controllers in the network [7]. This approach allows the communication routes to be optimized. However, with a network consisted of many domains, communication for the announcement might compress the communication bandwidth. These conventional approaches could only realize efficient data exchange or route optimization.
To overcome both of the problems, we propose an SDN based IP mobility management scheme considering inter-domain handovers. Our proposed scheme consists of two functions. The Management Information Sharing Function (MISF) searches a destination domain of a moved MN effectively and chooses minimum SDN controllers to share minimum information related to MN's communication to manage information efficiently. The Inter-domain Routing Function (IDRF) calculates an appropriate route to allow the MN to continue effective communication.
We also conducted some simulation experiments to confirm the effectiveness of our proposed scheme. The simulation results show that our proposal achieved to optimize communication route and keep traffic between SDN controllers low.

Novelty and Contribution
To realize efficient inter-domain handovers, we propose a novel scheme to efficiently exchange MNs' information between SDN controllers in each domains and optimize communication route between a MN and a CN. Existing approaches don't realize these two requirements simultaneously because these approaches differ in target, purpose and assumed environment therefore they do not match the purpose of what we concentrate on this time. At the time Mobile IP emerged, route optimization had little meaning because there were not so many candidates of route to be selected. Moreover, it aimed for easy implementation without any modifications in network infrastructure, as it focused on practical use so Mobile IP doesn't have full support to route optimization. The SDN based methods don't aim at covering wide area network and they are approaches for environment with some limitation on scale. Hence they can handle inter-domain handovers but not efficiently. Our proposed scheme realizes 1) efficient information exchange between SDN controllers, and 2) route optimization simultaneously to achieve the inter-domain handovers in largescaled wide-area network efficiently with functional support of network infrastructure.
With this novelty, mobile communication will be more seamless and delayless. This leads to an improvement of communication quality for users moving around with their communicating MNs. For example, when users with mobile PCs move across domains while downloading data from a cloud server, the disconnection of communication would occur and lead to packet loss. Moreover, when the users move across domains while using interactive-type applications such as remote login terminal or remote virtual desktop environment (VDI), a session would be interrupted. In addition, redundant communication route leads to serious communication delay especially when users are handling large data. By using the proposed scheme, MN users will be able to download or upload their data smoothly and perfectly while moving around. As for the interactive-type applications, MN users will be able to use the services without any termination of the process, even without the applications having the function of switching connections when the IP address changes.

Paper Organization
In the following sections, we first summarize the problems of Mobile IP and SDN based IP mobility management in section 2. Then we propose the SDN based IP mobility management scheme in section 3, followed by details of functions. In section 4, we evaluate our proposed scheme and show its effectiveness. Finally in section 5, we conclude the paper and discuss future works.
Home Agent (HA). Binding-cache is a set of HoA and CoA of a MN. The HA transfers the packets sent to HoA, to CoA. However, there is a possibility that a MN communicate with a CN over a redundant route, which we call triangle routing problem, depending on the location of the HA.
Mobile IPv6 is also standardized by IETF [5]. In addition to functions of Mobile IPv4, Mobile IPv6 has a route optimization function which enables MNs to communicate with the most suitable route. However, this is an optional function so only the MNs with support for route optimization can use this function.
In order to realize IP mobility management, we need to share a variety of information such as HoA, CoA, lifetime of Binding Cache, etc. among a MN, a HA, and a Foreign Agent (FA). IETF standardized Mobile IPv6 Management Information Base [10]. It defines large amount of information needed for Mobile IPv6. It is essential to select where to share plentiful information efficiently to realize IP mobility management. In Mobile IPv4 and Mobile IPv6, the MN registers its binding cache to its HoA. Thus, there is no need of searching for where to share information.
In Mobile IPv4 and Mobile IPv6, the MN needs to conduct IP mobility management. On the other hand, Proxy Mobile IPv6 (PMIPv6) executes IP mobility management on network equipment. Figure 3 shows its overview. The network equipment execute process for IP mobility management in PMIP. Therefore, there is no need of MN to involve in IP mobility management. Local Mobility Anchor keeps bindings of HoA and Proxy-CoA. Mobile Access Gateway (MAG) detects MNs and registers bindings to LMA. After a MN moves, MAG registers the MN's HoA and Proxy-CoA binding to LMA. Packets sent to the MN's HoA are transferred to the MN via LMA. Like Mobile IPv4 and Mobile IPv6, PMIP also has some possibility of triangular routing.

SDN based IP mobility management
SDN enables us to control networks intensively and flexibly. Therefore, SDN has attracted attentions as a means to solve the route optimization problem. Using SDN, network devices execute all the IP mobility management processes. Thus, unlike Mobile IPv4 and Mobile IPv6, the MN does not need to be equipped with IP mobility management functions. For this reason, there are some IP mobility management approaches using SDN. Papers [7] and [8] show route optimization mechanisms in the case when intradomain handover occurs. However, in the case of inter-domain handover, the mechanism in [7] uses Mobile IP, therefore MNs need to be equipped with route optimization function to optimize route after handover. The mechanism in [8] regards inter-domain handover as infrequent and broadcasts this event to all other controllers. Therefore, amount of traffic increases when interdomain handover occurs frequently in a network consisted by many domains.

Problems of related works
We summarized the problems of the related works in Table. We confirm that existing works cannot realize intra-domain route optimization, inter-domain route optimization, and efficient selection of domain to share information all together.
The papers [7] and [8] applied SDN to solve the problem of Mobile IP, route optimization, but SDN controllers can only control the network under their managed domain. This means that these approaches focus on intra-domain route. However, in recent network environment, users move freely to various domain networks while using IP services. Therefore, we have to consider the IP mobility management in multiple domain networks.
To realize IP mobility management in multiple domain networks, we need SDN controller in each domain to share information of MNs. However, if a SDN controller broadcasts the information to all other SDN controllers, it might cause large amount of traffic in a situation that inter-domain handover occurs frequently. Hence, we need a mechanism to share information efficiently in multiple domain networks.

SDN Based IP Mobility Management Scheme
Considering Inter-Domain Handovers

Overview
In this section, we propose a SDN based IP mobility management scheme considering inter-domain handovers to solve the problems explained in section 2. We first show the    We assume that inter-domain topology changes do not occur frequently. Therefore, the SDN controllers have an inter-domain topology information. Inter-domain topology information consists of SDN controller's IP address of each domain, network address of each domain, and inter-domain link information. The functions we mentioned above use this inter-domain topology information to search domain and calculate routes.
We show the components of our proposal in Figure 5. The components include SDN controllers, SDN switches, a MN, and a CN. Our scheme supports IPv4 network with two layers of network: a SDN controller network and a SDN switch network. SDN controller network is consisted of each domain's SDN controller and is used for SDN controllers to exchange information to optimize MN-CN route. SDN switch network is consisted of SDN switches. We call the SDN switch network managed by one SDN controller "domain".

Management Information Sharing Function
We describe the detailed design of MISF with an example. The network we use for explanation is shown in Figure 4. We assume that a MN moves to a destination domain from a source domain during a communication with a CN and the SDN controller of the destination domain detects the connection of the MN. The MN's IP address changes after move. We show below the MAC address, IP address which the MN was using in the source domain (former IP address) and IP address which the MN is using currently in the destination domain (current IP address).

Cd searches for Ds based on MAC address of MN.
Cd sends queries in order from neighboring domains like in Figure 6. SDN controllers of the domains that received the query search their domain to check if MN belonged to, and sends the result to Cd for a reply. When MN was not in their domain, they reply the absence of MN. When MN was in their domain, they reply the IP address MN was using.
2. Cd generates node connection information from the IP address sent from Cs.
Node connection information consists of following information.
• MAC address of MN • former IP address • current IP address 3. Cd sends node connection information to Cc.
Cd sends the information as shown in Figure 7. On this occasion, Cd gets the IP address of CN from header of the packet sent from MN to CN and derive the information of Cc.

Inter-domain routing function
Next, we explain the detailed design of IDRF following the example we used in the explanation of MISF in section 3.2.

Cd calculates the MN-CN inter-domain route.
We regard each domain as a node and calculate interdomain route. We take the number of inter-domain hops (Nhop) and the total number of flow entries that are needed to be installed in SDN switches (Nflow) into account to select a route that is the shortest and able to suppress the resource consumption of SDN controllers.

Cd announces the route information to the SDN controllers
of the domains to go via the selected route.
In the example, Cd announces the route to the domains shown in Figure 8.
3. Each SDN controller generates flow entries based on the received route information and installs them to their corresponding SDN switches.
Especially, the SDN switch that the CN connects to check flow entries and rewrites the packets sent between the MN and the CN based on the node connection information. This keeps the IP address of the MN seen from the CN the same as before and it enables the communication to continue between the MN and the CN as before movement. Concretely, we set the flow entries as shown below.
• Rewrite the destination IP address of the packets sent from the CN to the MN from former IP address to current IP address.
• Rewrite the source IP address of the packets sent from the MN to the CN from current IP address to former IP address.
We would explain the detail of Step 1 mentioned above. Concretely, we choose the route with minimum Nflow in the routes with minimum Nhop in the following steps.

Cd checks for routes with minimum Nhop based on interdomain topology information.
We use breadth first search algorithm for this search.
2. If there is only one route with minimum Nhop, we choose this route as the shortest route. If there are two or more routes with minimum Nhop, we then compare Nflow of each route.Cd asks SDN controllers of each domain via listed route the number of flow entries they need to install for each route like in Figure 9. The SDN controllers reply the number of flow entries to Cd and Cd calculates Nflow of each route.
3. Cd chooses the route with minimum Nflow as the finally decided route.

Overview
We carried out simulation experiments to validate an effectiveness of our proposed scheme. Especially, we confirmed the reduction on both communication load between SDN controllers by MISF and reduction effect on communication delay between a MN and a CN by IDRF.
We used OpenDaylight Lithium [11] as SDN controllers, Open vSwitch [12] as SDN switches, and OpenFlow1.3 [13] as the communication protocol between the SDN controllers and the SDN switches. We implemented the two functions we introduced in section 3 into SDN controllers.
We equipped two approaches for comparison with our proposed scheme.

• approach 1: announces move of MN to all domains
We replaced MISF to a function to announce the movement of MN to all the SDN controllers [8].
• approach 2: transfers packets sent to MN from source domain We replaced IDRF to a function to set route via the domain where the MN belongs to before moving [4][5][6][7].
We constructed a virtual network as an experimental network with Mininet2. 2.1 [14]. The bandwidth capacity of the links between SDN switches are set to 1Mbps and delay of each links is set to 10ms.
The experiments are conducted in the following scenario: In this paper, we carried out three types of experiments.

Experiment 1: Evaluation of MISF
In Experiment 1, we focused on traffic loads of communication between SDN controllers. We arranged three networks: each network consists 5, 10, and 15 domains, respectively. The number of inter-domain hops between source domain and destination  domain is 1. The domains increase concentrically like shown in Figure 10. Figure 11 shows how the traffic load changed as the number of domains changed. In case of approach 1, traffic load increased according to the increase of number of domains. In contrast, traffic load in the case of proposed scheme did not raise even though the number of domains increased.

Experiment 2: Evaluation of IDRF
In Experiment 2, we focused on the delay of communication (Round Trip Time: RTT) between the MN and the CN after MN's move. We arranged a network with 10 domains and set the number of inter-domain hops between Dd and Ds to 1, 2, and 3, respectively, as shown in Figure 12. Figure 13 shows the result of Experiment 2. In the case of approach 2, RTT increased according to the increase of number of inter-domain hops between Dd and Ds. In contrast, the proposed approach succeeded to keep RTT less than that of approach 2 in any case.

Experiment 3: Comprehensive evaluation of the proposed scheme
In Experiment 3, we compared traffic load between SDN controllers and the RTT between the MN and the CN of the proposed scheme, approach 1, and approach 2. We set the parameters as below:   We show the traffic load between the SDN controllers for each number of hops between the MN and the CN in Figure 15. Traffic loads increase as Ds gets farther from Dd with the proposed scheme and the approach 2, whereas with the approach 1, traffic load was not affected by the number of hops but influenced by the number of domains. Figure 16 shows the RTT of the communication between the MN and the CN for each number of domains. With the proposed scheme and the approach 1, RTT differs by the number of hops but is always smaller than that of the approach 2 in any case. With the approach 2, RTT increased as the number of hops between Ds and Dd got bigger. However, the results of the proposed scheme and the approach 1 showed no relevance to the number of hops between Ds and Dd.

Summary of evaluations
We discuss the results of Experiment 1. In case of the proposed scheme, the closer the source domain was to destination domain, the smaller the traffic load was because our scheme queries from neighbors.
However, the traffic load of the approach 1 increased as the number of domains increased. This is because the approach 1 announces to all the domains in the network regardless of the position of the source domain.
Next, we discuss the results of Experiment 2. In case of the proposed scheme, the number of inter-domain hops does not become larger than the number that can be taken by the approach 2. Therefore, the communication delay in proposed scheme gets smaller than approach 2. This is due to the fact that the longest route the proposed scheme chooses is the same route as the one chosen by approach 2.
Finally, we analyze the results of Experiment 3 according to the following viewpoints: traffic load between SDN controllers and RTT of communication between the MN and the CN after MN's movement.
First we talk about traffic load between SDN controllers. The proposed scheme and approach 1 exceeded approach 2 in traffic load between the SDN controllers. However, as the number of inter-domain hops between source domain and destination domain got bigger, traffic load of the proposed scheme and approach 2 tended to get bigger. For examples, we understand that when Ds and Dd were 3 hops away, traffic load of proposed scheme was pretty similar to that of approach 1 as we can see from Figure 15 (c). As Ds was 3 hops away from Dd, Cd ended up searching all the domains. When Ds and Dd was 2 hops away, traffic load of approach 2 was the biggest of all approaches. Approach 2 used MISF, the same function as the one proposed scheme uses. Thus, the traffic load of this function was the same as that of the proposed scheme. The difference came from the traffic load of IDRF. The difference in the communication route  set after MN's movement caused the difference in amount of communication made between SDN controllers and this affected the overall traffic load. Figure 15 (b) shows that when Ds and Dd were 2 hops away, the traffic load of the proposed scheme and approach 1 exceeded the traffic load of approach 2 greatly. In this case, there were several routes with minimum inter-domain hops. Therefore, IDRF queried for the number of flow entries that was needed to be installed for each route. This querying caused the increase of the traffic load. This fact shows that by asking the number of needed flow entries, the traffic load between the SDN controllers increases.
Next, RTT of communication between the MN and the CN after MN's movement. With approach 2, RTT increased as the number of hops between Ds and Dd increased. In approach 2, packets sent to the MN were first sent to Ds and then got transferred to the MN. Thus, the communication route gets longer as the MN moves farther. In contrast, the proposed scheme and approach 1 selected the shortest route regardless of the position of Ds. Therefore, RTT did not get too big. Besides, the transferring route was the longest route that could be chosen in the proposed scheme and approach 2. Thus, these approaches could keep RTT the same as that of approach 2 or smaller.  From the results mentioned above, the approach 1 and the approach 2 can only hold back the RTT of communication between the MN and the CN after MN's move, or traffic load between SDN controllers. However, the proposed scheme is able to deal with both.

Discussion
These quantitative experimental results mentioned above reveal the contribution of our proposed scheme in practical use. This achievement enables the suppression of the consumption of limited network resources while enabling users of MNs to move around keeping seamless and fast communication even if they moved across domains. For example, consider the situation where many users work with laptop PC or tablet PC to download data from cloud servers or to upload data. The users can smoothly download/upload large data from/to cloud servers while they are moving, like during transit time. Concerning interactive-type applications such as remote login terminal or VDI environment, the users can use the services continuously when the connecting network domain changes.
Generally speaking, to avoid the termination of services or processes when MNs move across network domains, applicationlevel handover function is usually implemented in the applications. When IP address of a MN changes according to the MN's movement, the handover function terminates the transport connection on the previous IP address, and then establishes a new transport connection on the new IP address. By this function, the data communication sessions seem to continue transparently and application logic can handle the sessions seamlessly. However, not all the applications have this feature implemented. This is because the mechanism is relatively complicated and it is necessary to deal with the server side as well. Our approach enables this functionality in network level. It means that all the Internet applications can utilize their network-dependent functions seamlessly in case that MNs move across the network domain.
Furthermore, when a user is at a place that the service areas of different access points overlap, the MN shifts its connecting access point back and forth depending on the link condition even when the user is not moving physically. Proposed scheme can manage this kind of handover and keep communication quality. Meanwhile, a standardization activity of a fast initial setup of Wi-Fi link is progressing as IEEE802.11ai [15]. This function would enable a Wi-Fi client to establish a secure link setup within 100ms. If this standard will widely be used in the above environment, switching of access point may occur very rapidly frequently in near future. There are no technologies currently available to deal with such situations, and we can expect that our proposed scheme will work effectively in such situations.

Conclusion
This paper aimed at realizing seamless connection and route optimization in SDN based IP mobility management on interdomain handovers. It is difficult to realize efficient information exchange between SDN controllers and route optimization together. To solve this problem, we proposed the SDN based IP mobility management scheme considering inter-domain handovers. As simulation results show, we achieved to optimize route while keeping management information exchange traffic between SDN controllers low.
As the future works, we need to improve IDRF. By extending the algorithm to handle weight of paths, we can take more kinds of information into account, such as bandwidth of inter-domain links and network usage.