Mobile Netw Appl (2015) 20:40–52 DOI 10.1007/s11036-015-0579-2
Design and Implementation of a Software-Defined Mobility Architecture for IP Networks You Wang & Jun Bi & Keyao Zhang
Published online: 5 February 2015 # Springer Science+Business Media New York 2015
Abstract Recently many research efforts have been spent on applying Software Defined Networking (SDN) to mobile and wireless networking to make them adapt to the rapid development and popularity of the mobile Internet. SDN offers programmable devices and centralized control which help to realize customizable and adaptive solutions to meet requirements from diversified mobile networks, devices, applications and so forth. This paper focuses on extending SDN paradigm to mobility handling in the Internet which has been little studied, and proposes design, implementation and deployment of a software-defined IP mobility architecture. The paper also demonstrates evaluations and experiments of the proposal based on both the Mininet platform and a cross-domain SDN testbed. Results prove the feasibility, scalability and high adaptability of the proposal. Keywords Software defined network . OpenFlow . Mobility management . Mobile IP . Home agent
1 Introduction In recent decades we have experienced rapid development of wireless technology and wide spread of wireless coverage. At the same time, mobile devices, applications and data keep proliferating, making the Internet evolve from a static internetwork to a mobile-oriented one. This tendency also brings challenges to the architecture of the current cellular network and the Internet. Y. Wang : J. Bi (*) : K. Zhang Institute for Network Sciences and Cyberspace, Department of Computer Science, Tsinghua National Laboratory for Information Science and Technology (TNList), Tsinghua University, Beijing, China e-mail:
[email protected]
Recently there is a growing trend to apply Software Defined Networking (SDN) to the mobile Internet. SDN is an emerging network architectural approach whose key idea is to separate control and data plane of networks. In SDN, network structures, functions and performance can be defined in a simpler way which is usually achieved by providing programmable devices and a centralized control logic. Therefore, SDN is helpful to realize customized mobile and wireless networks in order to meet future goals of the mobile Internet, such as better resource utilization, interconnection of heterogeneous wireless networks, improved Quality of Experience (QoE) and so forth. In this paper, we focus on integrating SDN and the current Internet architecture. Our motivation comes from the following two aspects. On one hand, Most ongoing research pay attention to applying SDN to cellular networks [1, 2]. Although currently mobile users access the Internet mostly through cellular networks, cellular networking may not replace Internet mobility architectures and protocols due to their disparate objectives, service models, capabilities, etc. [3, 4]. Researching on Internet mobility is also necessary since it is not appropriate to copy mobility solutions in cellular networks into the Internet. Besides, Internet mobility research will also contribute to cellular networking, especially after IP is considered as the core part of future cellular networks. We will give more discussions on this topic in Section 5.1.1. On the other hand, research on Internet mobility management is still open. Generally, offering mobility in the current Internet architecture implies keeping survivability of end-toend sessions when one or both communicating nodes change their attachment points in the network. Internet mobility solutions often assign a stable identifier to each mobile node and keep a binding between the mobile node’s identifier and IP address. This binding is always dynamic and should be maintained up-to-date since mobile nodes may change their IP addresses when attaching to different subnets. Thus, one of the key functionalities of Internet mobility solutions is to
Mobile Netw Appl (2015) 20:40–52
properly distribute the identifier-to-address mapping of each mobile node within the network so that correspondent nodes can reach the mobile node wherever it moves. Existing Internet mobility approaches have adopted different ways to implement the mapping functionality. However, they are not flexible enough to face diversified mobility scenarios in future Internet. For example, Mobile IP [5, 6] centralizes the mapping functionality on Home Agent deployed in each mobile node’s home network, which causes triangle routing and other problems when the mobile node is away from its home network. To address the problem, later research on Mobile IP, such as the Distributed Mobility Management (DMM) architectural paradigm [7, 8], suggests to distribute the mapping functionality to multiple locations in the network. However, they still require development and deployment of specialized middle-boxes to maintain the mappings. On the other side, protocols such as HIP [9], ILNP [10] and LISP Mobile Node [11] propose to move the mapping functionality from the network side to the host side. Without the involvement of middle-boxes, these protocols avoid triangle routing in the data plane, but may face performance challenges brought by inefficient control plane signaling since they highly rely on end hosts to handle all mobility related signaling. Moreover, recent research on future Internet architectures also aim to solve the Internet mobility problem [12–18], but most of them are still under development and their protocol details as well as performance are not yet clear. Driven by the above motivations, we propose the design, implementation and evaluations of a software-defined mobility architecture for IP networks. We argue that providing Internet mobility support based on SDN has several advantages. Firstly, SDN simplifies the deployment of Internet mobility solutions by making each programmable device a candidate carrier of the mapping function. It also facilitates the distribution of mobility-related functionalities which conforms to the current Mobile IP research trend to evolve from centralized mobility management (on Home Agent) to a distributed one [19]. Secondly, the centralized control plane of SDN is beneficial to generate optimized strategies to handle diversified mobility events of hosts by gathering all required information such as where the hosts are located, how they are moving and to whom they are communicating, etc. In the data plane, this advantage can show as avoiding triangle routing, while in the control plane, it can show as efficient mobility handling with short signaling delay and small signaling cost. In the following sections, we first present an overview of our proposal in Section 2 to show how we integrate Internet mobility and SDN, followed by detailed descriptions on the protocol design in both intra and inter-domain scenarios. Then we demonstrate an alternative implementation of our proposal together with evaluations on both QoS and scalability metrics in Section 3. We also present our preliminary deployment and experiments on a cross-domain testbed in Section 4. In
41
Section 5, we review related work including research on software-defined mobile and wireless networks, and mobility management in the Internet. Finally we conclude the paper and discuss future work in Section 6.
2 Architecture and protocol design 2.1 Architecture overview 2.1.1 General design As demonstrated in Fig. 1, we propose a software-defined mobility management architecture consists of several collaborating domains, each of which contains at least one controller. All the domains constitute a confederation which provides a large-scale mobility management service to its customers. This model can be realized in different ways. For instance, if the domains are operated by different Internet Service Providers (ISP), all ISPs can establish an agreement to allow Mobile Nodes (MN) to roam freely among their networks; or some 3rd party in the Internet Brents^ resources on SDN controllers and devices owned by different operators to deploy and run its own cross-domain mobility service. Based on the established confederation, a mobility management Bapplication^ is required in the control plane. It is deployed onto the collaborating controllers via SDN northbound interfaces. The controllers communicate with each other through an east/westbound interface to make the distributed mobility management application work. Finally, a southbound interface is employed to realize interactions between the control plane and data plane, which makes the controllers learn Northbound interface Southbound interface East/westbound interface
Mobility Management APP
MN
Mobility specific Flow Entries
Controller MN
Mobility specific Flow Entries
Controller Mobility specific Flow Entries
Controller
MN Fig. 1 Software-defined mobility management architecture consists of several collaborating domains
42
activities of MNs as well as instruct SDN devices to forward packets to and from the MNs. The control plane has two sub-functions. One maintains upto-date identifier-to-locator mapping of each MN. It can be realized by making each SDN device report to the control plane once it detects attachment of a MN. The other subfunction downloads a MN’s mapping to SDN devices when necessary. There are two cases that require mapping downloading: in the first case, an SDN device requests a MN’s mapping from the control plane so that it can reach the MN in the data plane; in the second case, once the control plane receives an update of a MN’s address, it proactively downloads the MN’s new mapping to some SDN devices in order to keep the MN’s reachability for all its ongoing sessions. The data plane functionality is relatively simple: once data packets leave Correspondent Nodes (CN) and reach the first SDN device, they will be forwarded toward the MN by SDN devices according to the mappings they stored locally. If some mapping required for packet forwarding is missing on an SDN device, it requests the specific mapping from the control plane, as is mentioned previously.
Mobile Netw Appl (2015) 20:40–52
2.2 Intra-domain scenario 2.2.1 The single-controller case First we describe how the protocol works in a single-controller case in intra-domain scenario. Figure 2a demonstrates the
CN
7) Rewrite dst-IP and forward to the MN
S1
MN
3) Forward packet to the first SDN device
Controller
S2 S3
6) Rewrite dst-IP and forward toward S3
(a) Session iniaon 1) Address update and 2) FlowTable downloading
CN S1 Controller
4) Rewrite dst-IP and forward to the MN
2.1.2 An instantiation Based on the general design, we present an instantiation by using Pox [20] as the northbound interface, OpenFlow [21] as the southbound interface, and TCP sockets as the east/ westbound interface. In the instantiation, we use IP address of a MN as its identifier and use the address prefix of the MN’s first-hop OpenFlow switch as its locator. Therefore, once a MN roams to a new subnet, it keeps its own IP address unchanged and is assigned another routable address with the same prefix in the subnet. Note that the MN is not aware of the routable address, but its first-hop switch handles the conversion between the routable address and the MN’s identifier. We assume that only the identifier of a MN is known to its CNs. To ensure reachability of a MN, the first-hop switch of each CN needs to convert the MN’s identifier to the routable address which is realized by a specific flow entry downloaded from the controller. Therefore, the controller is responsible for maintaining mappings between each MN’s identifier and its current routable address. In the following two subsections, we describe in detail how the instantiation protocol works in both intra-domain and inter-domain scenarios.
4) Address Query and 5) FlowTable downloading
1) Address update and 2) FlowTable downloading
2) FlowTable Update S2
MN
S3
MN
S4
3) Rewrite dst-IP and forward toward S4
(b) Handoff handling Fig. 2 How the protocol works in a single-controller case in intradomain scenario. The figure above shows session initiation process and the figure below shows handoff handling process
session initiation process. Once a MN attaches to an OpenFlow switch (S3 in Fig. 2), the switch reports this event to the controller. To identify the attached MN, a simple approach can be applied by relying on the MN’s MAC address. However, MAC addresses are not always secure identities, so some authentication approach should be employed such as 802.1× to prevent MN identity spoofing as well as other security risks. Once the controller learns the new MN-to-switch relationship, it assigns a routable address for the MN and stores the mapping between the MN’s identifier and the routable address in a local mapping table. When a CN initiates a session with the MN, packets sent from the CN first arrive at the first-hop OpenFlow switch (S1 in Fig. 2). Since the destination address is the MN’s identifier, S1 queries the controller using Packet-in messages and downloads a flow entry via Flow-mod message from the controller to rewrite the destination address to the MN’s routable address. Then packets are routed to switch S3 according to the routable address, and then forwarded to the MN. To make the MN recognize such packets, S3 is responsible for rewriting
Mobile Netw Appl (2015) 20:40–52
43
destination addresses of such packets back to the MN’s identifier, which is realized by another flow entry downloaded from the controller when the MN attaches to S3. Figure 2b demonstrates the handoff handling process. We assume that the MN leaves S3 and attaches to S4 when communicating with the CN. Similarly, S4 learns the attachment of the MN and reports to the controller. Since the controller is aware of the ongoing CN-to-MN session, it is responsible for redirecting the current CN-to-MN flow towards the MN’s new location. It is realized by downloading a flow entry to one of the switches on the CN-to-MN path (e.g., S2 in Fig. 2). The strategy applied to make such flow entry downloading may have large impacts on the protocol performance, and we will discuss this issue in a separate subsection below.
2.2.3 The multi-controller case
2.2.2 Flow entry downloading strategy
Figure 3a demonstrates an inter-domain session initiation process where the CN and the MN belong to controller C1 and C2 respectively. The main difference in this scenario is that, it is
Considering the case in Fig. 2b, theoretically any switch on the CN-to-MN flow path before MN’s movement (e.g., S1, S2 and S3) can serve as a candidate switch to download the flow entry for traffic redirection. However, choosing some switches may lead to performance degradation. For instance, it is a straightforward method to download flow entry to the MN’s first-hop switch before movement (e.g., S3), but this method will result in triangle routing in the data plane in most cases. Another method is to choose the CN’s first-hop switch (e.g., S1), but this method may bring unnecessary signaling delay and overhead in the control plane since it indicates signaling with the CN side regardless of its distance and number, even though the handoff can be handled more efficiently in a local scope. To address the problem, we propose three goals of applying a flow entry downloading strategy in the handoff handling process. The first goal is to keep optimal forwarding path, which ensures the shortest forwarding path between MN and CN in the data plane and thus avoids triangle routing. The second goal is to minimize the distance between the MN and the switch that is about to download the flow entry, since downloading flow entry to a distant switch usually implies larger possibility to trigger inter-controller communications and thus results in longer handoff delay. On the contrary, downloading to a nearby switch is helpful to confine signaling within a limited area and ensure an efficient handoff. The third goal is to minimize the number of flow entry downloading per handoff event. This goal can help to both limit the mobilityrelated flow entry maintained on switches and reduce the signaling overhead introduced by flow entry downloading. In our previous work [22], we studied the algorithms to find optimal strategies to satisfy the three goals. We find out that under certain circumstance, goal 2 and 3 can be simultaneously optimized using a linear algorithm when goal 1 serves as constraint. Otherwise an O(n2) greedy algorithm can be applied to approximate the optimal result.
If the CN and the MN belong to different controllers, or if the MN moves from one controller to another, multiple controllers are involved in the session initiation or handoff handling process. If the controllers belong to the same administrative domain, some existing work such as Onix [23] and HyperFlow [24] show solutions to such multi-controller scenarios. However, if the controllers belong to different domains, inter-domain communication between controllers is required which we will discuss below.
2.3 Inter-domain scenario
4) Address Query and 6) FlowTable downloading
5) Intercontroller query and response
CN 1) Address update and 2) FlowTable downloading
Controller C1 S1
Controller C2
S3
MN
3) Forward packet to the first SDN device
7) Rewrite dst-IP and forward toward S3
8) Rewrite dst-IP and forward to the MN
(a) Session Iniaon 4) FlowTable update 3) Intercontroller update
CN Controller C1 S1
Controller C2 6) Rewrite dst-IP and forward to the MN S3
Controller C3
S4 MN
5) Rewrite dst-IP and forward toward S4 1) Address update and 2) FlowTable downloading
MN
(b) Inter-domain handoff handling Fig. 3 How the protocol works with multiple controllers in inter-domain scenario. The figure above shows session initiation process and the figure below shows handoff handling process
44
not suitable for C1 to be aware of the MN’s exact location, otherwise each MN’s movements need be propagated to all the controllers in the network, which is not scalable in interdomain deployment scenarios. Therefore, we assume that only the controller(s) in the MN’s current domain (C2 in Fig. 3) stores the up-to-date mapping of the MN, and controllers in the other domains store a piece of indirect information of the MN instead, such as its current domain and controller. With this information, controllers in the other domains (e.g., C1 in Fig. 3) can get the MN’s exact location by further querying C2. As for handoff handling, if the MN moves within the domain, we make controller C2 handle the movement, which is analogous to the case in Fig. 2b. If the MN moves to another domain, inter-controller communication is necessary to handle the movement. Figure 3b demonstrates an inter-domain handoff scenario in which the MN moves from S3 to S4 belonging to another controller C3. The challenge of this case lies in the fact that, unlike the intra-domain case, C3 lacks information of the CN-to-MN path to redirect the ongoing flow towards S4. Considering the fact that it may be inappropriate for each controller to learn inter-domain topologies and end-to-end paths, we employ a simple approach to modify the ongoing flow from its source, i.e., downloading a flow entry to S1. To trigger this downloading, a straightforward method is that, since inter-domain movement is infrequent, C3 can broadcast this event to all other controllers including C1. As the number of collaborating controllers grows, the broadcast method can be replaced by other methods that scale better. For instance, a two-step method can be applied by firstly making C3 query the MN’s previous controller C2 to get the CN’s current controller C1, and then notifying C1 of the MN’s movement event.
3 Implementation and evaluations 3.1 Mininet implementation We implemented our proposal based on Mininet version 2.1.0 [25]. In Mininet, movement of a MN is simulated by detaching the MN from one switch and attaching it to another, which will trigger Port-status messages sent to the controller, making it be aware of the MN’s attachment and detachment. The implementation follows the protocol design in Section 2.2 and 2.3. However, there are some details we did not mention in the previous section. For instance, in order to redirect all existing CN-to-MN traffic after the MN moves to a new location, the controller needs to keep a record of all CNMN pairs in a local Host Pair Table (HPT). Each time the controller downloads a flow entry for some CN in the session initiation process, it adds one entry into the HPT indicating BThere exists a flow from the CN (represented by its first-hop
Mobile Netw Appl (2015) 20:40–52
switch) to the MN^. When the downloaded flow entry expires, the controller will be acknowledged and then delete the relevant entry in the HPT. We also considered the limit of flow entry numbers on OpenFlow switches. To keep a minimized number of flow entries on each switch, we set a short lifetime (5 s) for each flow entry downloaded from the controller in the session initiation process. We assume that the expiration of the flow entry implies that the CN-to-MN traffic flow has ended, so the switch can delete the entry to reduce its flow table size. If the flow resumes after an interruption but the specific flow entry has been deleted, the switch just triggers another Packet-in and then recovers the deleted flow entry from the controller. We run two sets of evaluations based on our Mininet implementation. In the first set, we employ a customized network topology and settings (communication models, mobility patterns, etc.) to simulate our proposal together with another two mobility solutions. We show their respective pros and cons in different mobility scenarios in terms of QoS metrics. In the second set, we focus on our proposal’s scalability and employ randomized topologies and settings to evaluate the control plane overhead brought by our proposal. Before we run each evaluation on a Mininet topology, we pre-download flow entries to all the switches to ensure reachability of each node in the topology. The flow entries serve as static routing tables and are generated by controllers using shortest path routing. 3.2 QoS evaluations 3.2.1 Methodology In this evaluation set, we compare our proposal with Proxy Mobile IPv6 (PMIPv6) [26] and ILNP [10], which serve as representatives of existing Internet mobility solutions, in terms of data plane QoS metrics. To this end, we also implemented another two SDN applications to realize the basic mobility functions of PMIPv6 and ILNP respectively. PMIPv6 is easier to implement based on Mininet since it is a network-based protocol. However, implementing ILNP is more difficult. Thus we simulate ILNP in an approximate way: we move the mobility functions from hosts to their first-hop switches. The evaluation topology is shown in Fig. 4 which consists of three domains, two hosts and eight switches. Delays of inter-domain links, intra-domain links and Bwireless links^ (between a host and attached switch) are 20, 2 and 10 ms respectively. Bandwidths of the above three types of links are 100Mbps, 100Mbps and 10Mbps respectively. Since in the current version of Mininet, in-band control between switches and controllers is not supported, the control plane is simulated using one controller with out-of-band control in this evaluation set. We make H2 the MN and move back and
Mobile Netw Appl (2015) 20:40–52
45
S1
H1
S6
S8
S5
H2
S7 S2
S4
S3
H2
H2
H2
Fig. 4 Topology of the QoS evaluation including 9 domains, 2 hosts and 8 switches
forth between switch S2 and S5, and make H1 the CN and keep immobile. We ran Iperf, which is a commonly used network testing tool, between the two hosts and collect end-toend performance metrics including Round Trip Time (RTT), packet loss rate as well as throughput. When simulating PMIPv6 in this topology, we use S7 as Home Agent, S2, S3, S4 and S5 as Mobile Access Gateway (MAG), S7 and S8 as Local Mobility Anchor (LMA). H2’s moving from S3 to S4 indicates that it leaves its home network and needs to rely on S7 and S8 for packet indirection. When simulating ILNP, each time H2 moves, its first-hop switch will send a mapping update message to S1 on behalf of H2, and then S1 handles the update on behalf of H1. Note that this evaluation actually favors PMIPv6 and ILNP for two reasons: firstly, IP re-configuration is ignored in the handoff process of the two protocols (origin PMIPv6 also needs IP reconfiguration when moving between different PMIPv6 domains). Secondly, mapping update process is simplified and only takes one-way delay: MN-to-HA delay in PMIPv6 case and MN-to-CN delay in ILNP case. Both simplifications improve handoff efficiency of the two protocols. 3.2.2 Results We first run Iperf between H1 and H2 for 10 s during which period H2 moves from S2 to S5 and performs three handoffs. Figure 5 shows collected TCP sequence of PMIPv6, ILNP and our proposal within the simulation time. As for ILNP, the TCP session experiences timeout and slow start during each handoff. It is because ILNP needs to send a mapping update from MN side towards CN side, and this may seriously degrade handoff efficiency especially when both sides are located far
Fig. 5 TCP sequence and RTT values of three simulated mobility solutions during three handoff events in the 1st evaluation set
away from each other. TCP session based on PMIPv6 experiences only one timeout during the second handoff, as the other two handoffs can be handled locally by LMA, while the interdomain handoff requires interactions with Home Agent. In contrast, TCP based on our proposal can always recover from packet loss during handoff using fast retransmit since it always tries to handle the handoff event in local scope. However, if inband control is applied by our proposal, the inter-domain movement may also cause timeout as it requires interdomain communication to handle the handoff event which is similar to PMIPv6. Figure 5 also shows RTT of the three protocols collected in the same scenario, where we observe that RTT value of all three protocols temporarily raises to a higher value during handoffs. Besides, RTT of PMIPv6 stays at a higher value after the second handoff. It is because when H2 leaves home network (after moving from S3 to S4), all packets to H2 are relayed by Home Agent S7 which results in triangle routing. Our
46
proposal avoids triangle routing by ensuring optimal forwarding path, and in this scenario it is achieved by downloading flow entry to S6. The above two evaluations prove that both PMIPv6 and ILNP do not perform perfectly when applied to some cases, while the SDN based mobility solution is more adaptable to fit different mobility scenarios. We also test average throughput and packet loss rate of the three solutions by running Iperf TCP and UDP between H1 and H2 for 1 min. We repeat each evaluation scenario for 100 times with different mobility frequencies (0, 0.5 and 1 per second). Figure 6 demonstrates the evaluation results, from which we can learn that our proposal keeps a high average throughput and low packet loss rate when compared with the other two even when mobility frequency grows to one per second. The results also prove that the advantage of our proposal is more obvious when mobility frequency is higher.
Mobile Netw Appl (2015) 20:40–52
3.3 Scalability evaluations 3.3.1 Methodology In this evaluation set, we build a Mininet topology consists of 10 domains and 100 switches according to a transit-stub topology generated by GT-ITM topology generator [27]. We deploy one controller in each domain to control all the switches in the domain. We deploy one host under each switch a n d m a k e t h e m c o m m u n i c a t e w i t h e a c h o t h e r. Communication traffic is also generated using Iperf. We generated two kinds of UDP traffic: a 64 kbps audio traffic with 300 bytes packets, and a 250 kbps video traffic with 1kbytes packets. As for each host, we use exponential distribution to describe both session arrival interval and session duration with average 60 s. Each time we simulate a session arrival event, the correspondent host is randomly chosen among all the other hosts. When simulating the movement of each host, we assume that the movement interval is also exponentially distributed with average 60 s. Before simulating each movement, we first judge whether it is an intra or inter-domain movement. We use inter-domain movement probability as a variable in this evaluation set. As for intra-domain movement, we make each host move to a random switch, and as for inter-domain movement, both the destination domain and switch are randomly selected. Each simulation turn lasts for 10 min, during which we collect statistics of Packet-in events and inter-controller sessions. Each result shown in Figs. 7 and 8 is gathered by running 10 simulation turns. 3.3.2 Results
Fig. 6 TCP throughput and UDP packet loss rate of three simulated mobility solutions in the 1st evaluation set when mobility frequency varies from zero per second to one per second
Packet-in is one of the largest overhead brought by our protocol to the control plane. Figure 7 shows Cumulative Distributed Function (CDF) of average and max number of Packet-in messages received by each controller per second. As we can see, 90 % controllers receive about 4 to 5 Packet-in messages on average per second, and 95 % controllers receive about 50 Packet-in messages at most per second. Inter-domain movement frequency has a small impact on this simulation because most Packet-in messages are triggered in the session initiation process. Therefore, theoretically this number will grow with the increasing of mobile hosts under one controller. However, we believe that the overhead is acceptable since it is impractical for one controller to control a network that is too large, and Packet-in processing speed of controllers also continues to update according to the literatures. Figure 8 shows CDF of average and max number of intercontroller sessions handled by each controller per second, which serves as another protocol overhead. Simulation results demonstrate that, inter-domain movement probability slightly affects the average session number, but has little impact on the
Mobile Netw Appl (2015) 20:40–52
Fig. 7 CDF of average and max number of Packet-in messages received by each controller per second in the 2nd evaluation set. Variable p stands for probability of inter-domain movement
max session number which is also dominated by the session initiation process. In conclusion, the largest overhead is caused by burst of Packet-in messages when sessions initiate, which can be further optimized by preventing switches from sending identical Packet-in messages to controllers.
4 Testbed deployment and experiments 4.1 Deployment on testbed The testbed deployment is based on an international federal SDN testbed we built previously [28]. The testbed consists of five SDN domains: Internet2 (United States open national research and education network), CERNET (China Education and Research Network), CSTNET (China Science and Technology Network), and SURFnet (the national research and
47
Fig. 8 CDF of average and max number of inter-controller sessions handled by each controller per second in the 2nd evaluation set. Variable p stands for probability of inter-domain movement
education network of the Netherlands). CERNET contains two domains in Tsinghua University and Beijing University of Posts and Telecommunications (BUPT) respectively. The domains are connected using GRE (Generic Routing Encapsulation) tunnels. We deploy our Pox-based controller onto the controllers in CERNET and utilize the switches and hosts in Tsinghua and BUPT to make several performance tests, aiming to find out how the extra actions introduced by mobility management, i.e., address rewrite on switches and Packet-in to controllers, affect normal data transmission. As shown in Fig. 9, the experiment topology includes two domains, each of which has deployed one controller, two OpenFlow switches and two hosts. The domain in Tsinghua deployed two hardware OpenFlow switches from Dell and Pica8, while the domain in BUPT deployed two software OpenFlow switches (Open vSwitch).
48
Mobile Netw Appl (2015) 20:40–52 Generated Iperf traffic
Tsinghua University Int
OpenFlow Switch (Pica8) 101.6.30.62
Host 101.6.30.104
erc
on tro
ller
cha
nn
Controller 101.6.30.59 GR
OpenFlow Switch (Dell) 101.6.30.54
ET
un
ne l
networks or WLAN. We present reviews of both categories below.
el
5.1.1 Research on WLAN
BUPT
OpenRoads [29, 30] proposes to improve robustness during mobility handoff using multicast in Openflow networks. The authors showed how this is done by demonstration and described their testbed deployment. In their following paper [31], they further abstract their idea as separating wireless services from infrastructures and rename OpenRoads to Openflow Wireless which serves as a blueprint for an open wireless network. OpenRadio [32] proposes programmable wireless devices by enabling programmability of the Physical and MAC layer. It is realized by introducing a software abstraction layer which decompose wireless protocols into decision rules and processing algorithms and provides modular APIs to programmers. Odin [33] focuses on enterprise WLAN and proposes light virtual Access Points (AP) that has stable associations with users and can be hosted by different physical APs. The virtual APs are controlled by a specific controller via OpenFlow. In this way, Odin facilitates programmers to implement mobility management functions such as seamless handoff, load balancing, etc.
Controller 210.25.132.164
Software Open vSwitch 210.5.132.166
Software Open vSwitch 210.5.132.167 Host 210.25.132.173 Host 210.25.132.171
Fig. 9 Demonstration of testbed deployment and experiments in Tsinghua University and BUPT
4.2 Experiments We first make intra-domain experiments in Tsinghua and BUPT respectively, and then make inter-domain experiments between Tsinghua and BUPT. In all experiments, we generate traffic between two hosts for an hour to evaluate the impacts on end-to-end performance caused by both destination IP address rewrite and Packet-in. Note that one round trip of a packet actually triggers two Packet-in events since both communicating hosts are sending packets using their identifiers. Besides, the Packet-in delay in the inter-domain experiments also contains latency caused by inter-controller query and response. Table 1 shows the experiment results. We compared TCP throughput with and without address rewrite, and packet RTT with and without Packet-in. We can see that address rewrite performed by OpenFlow switches has almost none impact on data transmission in both hardware and software implementations. As for RTT, Packet-in unavoidably brings a certain amount of delay. However, this delay only impacts the first packet of each end-to-end session.
5.1.2 Research on cellular networks Integrating SDN and cellular networks includes research on software defined Radio Access Networks (RAN) and core networks. SoftRAN [34] employs centralized control of all physical base stations in a geographical area which are regarded as radio elements. The authors take the latency between the controller and base stations into consideration and put some control plane functionalities down to the radio elements for better trade-off. OpenRAN [35] is another software defined RAN architecture which applies cloud computing. OpenRAN considers convergence of heterogeneous wireless networks, which is a desirable feature not supported by SoftRAN. CellSDN [36] is proposed with the goal of implementing a network operating system on LTE networks. Their later research is called Softcell [37] which focuses more on the core network.
5 Related work 5.1 Software-defined mobile and wireless networks Many efforts have been paid to apply SDN to mobile and wireless networks, most of which pay attention to cellular Table 1
impacts of address rewrite and Packet-in on throughput and RTT in three scenarios
Experiment scenarios
Intra-domain (hardware OpenFlow switches) Intra-domain (software OpenFlow switches) Inter-domain
TCP throughput (Mbps)
Round-trip time min/avg/max (ms)
Without rewrite
With rewrite
Without Packet-in
With Packet-in
93.7 631 17.8
93.7 630 17.8
0.196 / 0.253 / 0.389 0.411 / 0.578 / 1.052 3.478 / 7.472 / 106.346
5.907 / 30.421 / 55.911 3.473 / 29.574 / 54.364 80.790 / 204.774 / 3142.292
Mobile Netw Appl (2015) 20:40–52
We argue that research on cellular networks does not affect the importance of Internet mobility studies. Firstly, overlay Internet services and protocols above cellular network may make their performance not as efficient as running them directly in the Internet [4]. Secondly, the coupling of access control and mobility support in cellular networks binds users to specific service providers [3, 4], and thus limits possible future mobility scenarios such as handoff between different wireless networks, service providers and even mobile devices. On the other hand, mobility management research in the Internet and cellular network are closely related, especially after IP is considered as the core part of future cellular networks [38]. Since the evolution trend of cellular networking is moving towards an all-IP based infrastructure, which means all traffic leaving base stations becomes IP-based and is delivered over packet-switched networks, IP mobility management becomes a key role to support future wireless systems. Many IP mobility solutions serve as candidates to provide mobility management in cellular networks [39, 40], and some proposals have already been integrated into cellular networking. Current and future researches on Internet mobility management will continue to contribute to cellular networking. Recently, along with the development of 3GPP Long Term Evolution (LTE), there is a growing trend to provide a more flexible and dynamic mobility management, which is also a concern in the Internet research area. The Internet Engineering Task Force (IETF) has already been standardizing related protocols, which may be introduced into 3GPP to replace its existing mobility management functions [8]. 5.2 Internet mobility management Generally, supporting Internet mobility means to offer uninterrupted Internet connectivity to MNs which change their attachment points while roaming in the network. Due to the tight-coupling of TCP and IP [41], changing IP addresses will cause interruption of TCP sessions on MNs, which may seriously impact experiences of mobile users. Basically, Internet mobility solutions can be divided into routing-based and mapping-based approach [42]. Routingbased approach makes a MN use the same IP address while roaming, and thus requires dynamic routing to keep reachability of the MN. On the contrary, mapping-based approach allows a MN to change IP addresses but keep a stable identifier. To reach the MN using its identifier, a mapping mechanism is introduced to resolve identifier to the MN’s current locator. In these solutions, TCP sessions are always bound to identifiers instead of IP addresses, thus they can keep survivability facing changing IP addresses. As discussed by Zhang et al. [3], routing-based approach is not suitable to provide mobility support in large-scale networks due to scalability issues as the whole network requires to be informed of each MN’s movement.
49
Amongst all identifier-based proposals, Mobile IP and its extensions [26, 43] are the earliest and most well-known protocols. Later, a number of Mobile IP derivatives have been proposed to improve its basic functionality [44–47]. Recently, there are many individual IP mobility protocols which belong to Identifier-Locator Split (ILS) proposals, as well as future Internet architecture proposals arise to address mobility problems in the Internet. We review these solutions respectively in the following subsections. 5.2.1 Mobile IP and its derivatives Mobile IP derivatives are based on two baseline protocols: Mobile IP (MIP) [5] and Mobile IPv6 (MIPv6) [6]. We take MIPv6 as an example: the protocol uses a special IP address called Home Address (HoA) to identify a MN. When a MN moves to a new network, it obtains a Care-of Address (CoA) which can be used to reach the MN. Then the MN communicates with the Home Agent (HA) located in its home network to update the Binding Cache which maps the MN’s HoA to its current CoA. A CN sends packets to the MN using its HoA, thus the packets are forwarded to the HA. With up-to-date binding cache, the HA can encapsulate and redirect packets toward the MN’s current CoA. To reduce mobility signaling cost when the MN moves away from the HA, some MIPv6 extensions such as Hierarchical Mobile IPv6 (HMIPv6) [43] and Proxy Mobile IPv6 (PMIPv6) [26] have been proposed. The major drawback of Mobile IP is that all the packets from CN to MN have to take a detour to pass the HA, which is known as the triangle routing problem. Triangle routing can result in routing path stretch, which means the actual routing path is longer than the shortest one, as well as heavy load on HA. MIPv6 has offered a Route Optimization (RO) mode to address triangle routing by directly sending Binding Cache from MN to CN. However, RO mode is less-than-ideal due to some drawbacks in security and efficiency. In recent years, a series of Mobile IP derivatives [44–47], which follow Distributed Mobility Management (DMM) architectural paradigm [7, 8], arise to address the problem. DMM solutions distribute the functionality of HA to multiple mobility anchors deployed in the network so that the MN can always choose a nearby mobility anchor to maintain its binding cache and perform packet redirection. Thus, the MN’s HoA never represents a fixed location and triangle routing can be alleviated or even eliminated. DMM research is still in the early stage, but it is considered as a promising way to evolve Mobile IP networks and is currently under standardization in the IETF DMM group [48]. 5.2.2 Identifier-locator split solutions Identifier-locator split (ILS) is an architectural model which points out that IP address has embedded both identifier and
50
locator semantics and a split of the two is necessary. Such solutions often maintain identifier-to-locator mappings in a global mapping system. When CN starts communication with MN, it queries the mapping system to obtain the current locator of the MN. When the MN moves to a new network, it sends the new identifier-to-locator mapping to not only the mapping system but also the CN side so that CN can directly reach the MN’s current location as soon as possible. Therefore, mobility handoff is actually accomplished in an end-to-end way. Host Identity Protocol (HIP) [9], IdentifierLocator Network Protocol (ILNP) [10] and LISP Mobile Node [11] are typical solutions that fall into this category. HIP uses self-authenticating identifier called Host Identity (HI) to identify a mobile host. HI is obtained by hashing the public key of a key pair that belongs to the host. With selfauthenticating identifiers, each host is able to prove ownership to its HI through cryptographic methods. ILNP does not introduce new namespaces but utilizes IPv6 address space to identify mobile hosts. ILNP splits IPv6 address space into an identifier part and a locator part: the first 64bits of IPv6 address remains to be used for routing in the network, while the last 64bits are used to uniquely identify mobile hosts. LISP Mobile Node (LISP-MN) is developed base on Locator Identifier Separation Protocol (LISP) [49], which is a coreedge separation design. LISP proposes a separation of Endpoint Identifiers (EID) from Routing Locators (RLOC) and deploys ingress/egress Tunnel Routers (TR) to maintain EID-to-RLOC mappings. LISP-MN utilizes EID as identifier and RLOC as locators of mobile hosts. All three protocols modify TCP/IP stack on hosts to realize the mapping functions. HIP and ILNP rely on DNS to store the mappings, while LISP-MN makes use of several alternative Map-Servers proposed by LISP as its global mapping system. 5.2.3 Future internet architecture proposals MobilityFirst [12] is funded by Future Internet Architecture (FIA) Project in the United States. MobilityFirst uses Globally Unique Identifiers (GUIDs) to name network attached objects and employs a Global Name Resolution Service (GNRS) to dynamically map GUIDs to Network Addresses (NAs). As for mobility management, currently MobilityFirst highlights the design of a fast resolution service rather than the handoff handling. Named Data Networking (NDN) [13] is another FIA program which proposes to directly route on identifiers instead of employing resolution and indirection services. Therefore, the baseline NDN protocol has to support mobility using routing-based approach which is considered as unscalable. Some NDN extensions have been proposed to address the mobility issue [50, 51]. NetInf [14] belongs to 4WARD project supported by European Union seventh Framework Program (FP7). NetInf relies on a Name Resolution System (NRS) to resolve identifiers of Information Objects (IO) to
Mobile Netw Appl (2015) 20:40–52
their locations and other related data. NRS is realized using MDHT consists of multiple levels of DHT nodes called NetInf nodes. NetInf proposes one mobility management solution by utilizing the indirection features of NRS, which is analogous to that of the DMM solutions. Other proposals includes eXpressive Internet Architecture (XIA) [15], Data-Oriented Network Architecture [16], Publish-Subscribe Internet Technologies [17], Juno [18], etc. Currently it is difficult and inappropriate to compare future Internet architectures with existing IP-based mobility solutions. On one hand, most of them are still under development and lack protocol details. On the other hand, although they share similarities in handling host mobility with Mobile IP derivatives and ILS solutions, they usually focus on not only mobile hosts but also mobile contents, which always goes beyond the traditional concept of host-based mobility [52].
6 Conclusions and future work In this paper, we proposed an IP mobility architecture based on Software Defined Networking paradigm. We demonstrated architecture and protocol design, simulation and evaluations on Mininet platform as well as deployment and experiments on a cross-domain SDN testbed. Mininet evaluation results prove feasibility and scalability of the proposal, and testbed experiments further show that the implemented mobility management functionality brings negligible impacts on normal data transmission. There are several unsolved issues in the proposed SDNbased mobility solution which we include in our future work. Firstly, although the evaluations show advantages of the SDNbased solution, the results are collected based on the Mininet platform, and further research is still required to make clear how the SDN-based solution performs when deployed in real network environment. Secondly, the current solution is more focused on intra-domain scenarios and the inter-domain case is relatively simplified. Part of the reason is that SDN-based inter-domain cooperation has been little studied currently. Finally, a practical problem is that, the SDN-based solution requires SDN deployment in both control and data plane, while the incentive to make such deployment is unclear. To address the problems, we present our future work from two aspects. Theoretically, on one hand, we consider studying on integrating SDN and inter-domain routing in order to facilitate inter-domain mobility support. On the other hand, we need to pay attention to partial deployment scenarios and analyze on the deployment incentives of the SDN-based mobility proposal. Practically, we are further extending the scales of simulations on Mininet platform, and at the same time deploying the prototype onto the Internet2, SURFnet and CSTNET testbed to establish an international confederation
Mobile Netw Appl (2015) 20:40–52
for future experiments. We are also planning on implementing real mobility scenarios based on wireless environments. Acknowledgments This work is supported by the National High-tech R&D Program (B863^ Program) of China (No.2013AA013505) and the National Science Foundation of China (No.61472213).
References 1. Yang M, Li Y, Jin D, Zeng L, Wu X, Vasilakos AV (2014). SoftwareDefined and virtualized future mobile and wireless networks: a survey. Mobile Networks and Applications, 1–15 2. Jagadeesan NA, Krishnamachari B (2014) Software-defined networking paradigms in wireless networks: a survey. ACM Comput Surv (CSUR) 47(2):27 3. Zhang L, Wakikawa R, Zhu Z (2009) Support mobility in the global Internet. In: Proceedings of the 1st ACM workshop on mobile internet through cellular networks (pp. 1–6). ACM 4. Zhang P, Durresi A, Barolli L (2009) A survey of internet mobility. In: Network-Based Information Systems, 2009. NBIS’09. International Conference on (pp. 147–154). IEEE 5. Perkins C (2010). IP mobility support for IPv4, revised. RFC 5944 6. Arkko J, Perkins C, Johnson D (2011) Mobility support in IPv6. RFC 6275 7. Chan HA, Yokota H, Xie J, Seite P, Liu D (2011) Distributed and dynamic mobility management in mobile internet: current approaches and issues. J Commun 6(1):4–15 8. Zuniga JC, Bernardos CJ, de la Oliva A, Melia T, Costa R, Reznik A (2013) Distributed mobility management: a standards landscape. IEEE Commun Mag 51(3):80–87 9. Nikander P, Moskowitz R (2006) Host identity protocol (hip) architecture. RFC 4423 10. Atkinson R, Bhatti S (2012). Identifier-Locator Network Protocol (ILNP) Architectural Description. RFC 6740 11. White C, Lewis D, Meyer D, Farinacci D (2014) LISP mobile node 12. Venkataramani A, Sharma A, Tie X, Uppal H, Westbrook D, Kurose J, Raychaudhuri D (2013). Design requirements of a global name service for a mobility-centric, trustworthy internetwork. In Communication Systems and Networks (COMSNETS), 2013 Fifth International Conference on (pp. 1–9). IEEE 13. Zhang L, Afanasyev A, Burke J et al. (2014). Named data networking. Technical Report NDN-0019, Revision 1:10 14. Ohlman B, Ahlgren B, Brunner M et al. (2009) 4WARD deliverable 6.2: second NetInf architecture description. Tech. Rep 15. Anand A, Dogar F, Han D, et al. (2011). XIA: an architecture for an evolvable and trustworthy Internet. In: Proceedings of the 10th ACM Workshop on Hot Topics in Networks (p. 2). ACM 16. Koponen T, Chawla M, Chun BG, Ermolinskiy A, Kim KH, Shenker S, Stoica I (2007) A data-oriented (and beyond) network architecture. ACM SIGCOMM Comput Commun Rev 37(4):181–192 17. Fotiou N, Trossen D, Polyzos GC (2012) Illustrating a publishsubscribe internet architecture. Telecommun Syst 51(4):233–245 18. Tyson G, Mauthe A, Kaune S, Grace P, Taweel A, Plagemann T (2012) Juno: a middleware platform for supporting delivery-centric applications. ACM Trans Internet Technol (TOIT) 12(2):4 19. Liu D, Yokota H, Korhonen J, Chan A, Seite P (2014). Requirements for distributed mobility management. RFC 7333 20. POX Controller. http://www.noxrepo.org/pox/about-pox/ 21. McKeown N, Anderson T, Balakrishnan H et al (2008) OpenFlow: enabling innovation in campus networks. ACM SIGCOMM Comput Commun Rev 38(2):69–74
51 22. Wang Y, Bi J (2014) A solution for IP mobility support in software defined networks. The 23rd IEEE International Conference on Computer Communications and Networks (ICCCN14), 481–488 23. Koponen T, Casado M, Gude N, et al. (2010) Onix: A distributed control platform for large-scale production networks. In: OSDI, 10: 1–6 24. Tootoonchian A, Ganjali Y (2010) HyperFlow: a distributed control plane for OpenFlow. In: Proceedings of the 2010 internet network management conference on research on enterprise networking (pp. 3–3). USENIX Association 25. Mininet: an instant virtual network on your laptop (or other PC), http://mininet.org/ 26. Gundavelli S, Leung K, Devarapalli V, Chowdhury K, Patil B (2008). Proxy mobile ipv6. RFC 5213 27. GT-ITM: modeling topology of large internetworks, http://www.cc. gatech.edu/projects/gtitm/ 28. Lin P, Bi J, Chen Z, et al. (2014) WE-bridge: West-East Bridge for SDN inter-domain network peering. The 33rd IEEE International Conference on Computer Communications (INFOCOM14). 111– 112 29. Yap KK, Huang TY, Kobayashi M, Chan M, Sherwood R, Parulkar G, McKeown N (2009) Lossless Handover with n-casting between WiFi-WiMAX on OpenRoads. ACM Mobicom (Demo) 12(3):40–52 30. Yap KK, Kobayashi M, Underhill D, Seetharaman S, Kazemian P, McKeown N (2009) The stanford openroads deployment. In: Proceedings of the 4th ACM international workshop on Experimental evaluation and characterization (pp. 59–66). ACM 31. Yap KK, Sherwood R, Kobayashi M et al. (2010). Blueprint for introducing innovation into wireless mobile networks. In: Proceedings of the second ACM SIGCOMM workshop on Virtualized infrastructure systems and architectures (pp. 25–32). ACM 32. Bansal M, Mehlman J, Katti S, Levis P (2012) Openradio: a programmable wireless dataplane. In: Proceedings of the first workshop on Hot topics in software defined networks (pp. 109–114). ACM 33. Suresh L, Schulz-Zander J, Merz R, Feldmann A, Vazao T (2012) Towards programmable enterprise wlans with odin. In: Proceedings of the first workshop on Hot topics in software defined networks (pp. 115–120). ACM 34. Gudipati A, Perry D, Li LE, Katti S (2013) SoftRAN: software defined radio access network. In Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking (pp. 25–30). ACM 35. Yang M, Li Y, Jin D, Su L, Ma S, Zeng L (2013) OpenRAN: a software-defined ran architecture via virtualization. In Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM (pp. 549– 550). ACM 36. Li LE, Mao ZM, Rexford J (2012). Toward software-defined cellular networks. In Software Defined Networking (EWSDN), 2012 European Workshop on (pp. 7–12). IEEE 37. Jin X, Li LE, Vanbever L, Rexford J (2013). Softcell: scalable and flexible cellular core network architecture. In: Proceedings of the ninth ACM conference on Emerging networking experiments and technologies (pp. 163–174). ACM 38. Chiussi FM, Khotimsky DA, Krishnan S (2002) Mobility management in third-generation all-IP networks. IEEE Commun Mag 40(9): 124–135 39. Saha D, Mukherjee A, Misra IS, Chakraborty M (2004) Mobility support in IP: a survey of related protocols. IEEE Netw 18(6):34–40 40. Akyildiz IF, Xie J, Mohanty S (2004) A survey of mobility management in next-generation all-IP-based wireless systems. IEEE Wirel Commun 11(4):16–28 41. Chiappa JN (1999) Endpoints and Endpoint names: a proposed enhancement to the internet architecture 42. Zhu Z, Zhang L, Wakikawa R (2011) A survey of mobility support in the Internet. RFC 6301
52 43. Soliman H, Bellier L, Elmalki K, Castelluccia C (2008) Hierarchical mobile IPv6 (HMIPv6) mobility management. RFC 5380 44. Wakikawa R, Valadon G, Murai J (2006) Migrating home agents towards internet-scale mobility deployments. In: Proceedings of the 2006 ACM CoNEXT conference (p. 10). ACM 45. Fischer M, Andersen FU, Kopsel A, Schafer G, Schlager M (2008). A distributed IP mobility approach for 3G SAE. In: Personal, Indoor and Mobile Radio Communications, 2008. PIMRC 2008. IEEE 19th International Symposium on (pp. 1–6). IEEE 46. Cuevas R, Guerrero C, Cuevas A, Calderón M, Bernardos CJ (2007) P2P based architecture for global home agent dynamic discovery in IP mobility. In: Vehicular Technology Conference, 2007. VTC2007Spring. IEEE 65th (pp. 899–903). IEEE 47. Mao Y, Knutsson B, Lu H, Smith JM (2005) Dharma: distributed home agent for robust mobile access. In: INFOCOM
Mobile Netw Appl (2015) 20:40–52
48. 49. 50. 51.
52.
2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE (Vol. 2, pp. 1196–1206). IEEE IETF, BDistributed Mobility Management (DMM) IETF Working Group^. Farinacci D, Lewis D, Meyer D, Fuller V (2013) The locator/ID separation protocol (LISP). RFC 6380 Zhu Z, Afanasyev A, Zhang L (2014) A new perspective on mobility support. Tech Rep Zhang Y, Zhang H, Zhang L (2014) Kite: a mobility support scheme for ndn. In: Proceedings of the 1st international conference on Information-centric networking (pp. 179–180). ACM Tyson G, Sastry N, Cuevas R, Rimac I, Mauthe A (2013) A survey of mobility in information-centric networks. Commun ACM 56(12): 90–98
