design and implementation of a software-defined mobility...

Design and Implementation of a Software-Defined MobilityArchitecture 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 onapplying Software Defined Networking (SDN) to mobile andwireless networking to make them adapt to the rapid develop-ment and popularity of the mobile Internet. SDN offers pro-grammable devices and centralized control which help to re-alize customizable and adaptive solutions to meet require-ments from diversified mobile networks, devices, applicationsand so forth. This paper focuses on extending SDN paradigmto mobility handling in the Internet which has been little stud-ied, and proposes design, implementation and deployment ofa software-defined IP mobility architecture. The paper alsodemonstrates evaluations and experiments of the proposalbased on both the Mininet platform and a cross-domainSDN testbed. Results prove the feasibility, scalability and highadaptability of the proposal.

Keywords Software defined network . OpenFlow .Mobilitymanagement . Mobile IP . Home agent

1 Introduction

In recent decades we have experienced rapid development ofwireless technology and wide spread of wireless coverage. Atthe same time, mobile devices, applications and data keepproliferating, making the Internet evolve from a staticinternetwork to a mobile-oriented one. This tendency alsobrings challenges to the architecture of the current cellularnetwork and the Internet.

Recently there is a growing trend to apply SoftwareDefined Networking (SDN) to the mobile Internet. SDN isan emerging network architectural approach whose key ideais to separate control and data plane of networks. In SDN,network structures, functions and performance can be definedin a simpler way which is usually achieved by providing pro-grammable devices and a centralized control logic. Therefore,SDN is helpful to realize customized mobile and wirelessnetworks in order to meet future goals of the mobileInternet, such as better resource utilization, interconnectionof heterogeneous wireless networks, improved Quality ofExperience (QoE) and so forth.

In this paper, we focus on integrating SDN and the currentInternet architecture. Our motivation comes from the follow-ing two aspects. On one hand, Most ongoing research payattention to applying SDN to cellular networks [1, 2].Although currently mobile users access the Internet mostlythrough cellular networks, cellular networking may not re-place Internet mobility architectures and protocols due to theirdisparate objectives, service models, capabilities, etc. [3, 4].Researching on Internet mobility is also necessary since it isnot appropriate to copy mobility solutions in cellular networksinto the Internet. Besides, Internet mobility research will alsocontribute to cellular networking, especially after IP is consid-ered as the core part of future cellular networks. We will givemore discussions on this topic in Section 5.1.1.

On the other hand, research on Internet mobility manage-ment is still open. Generally, offering mobility in the currentInternet architecture implies keeping survivability of end-to-end sessions when one or both communicating nodes changetheir attachment points in the network. Internet mobility solu-tions often assign a stable identifier to each mobile node andkeep a binding between the mobile node’s identifier and IPaddress. This binding is always dynamic and should be main-tained up-to-date since mobile nodes may change their IPaddresses when attaching to different subnets. Thus, one ofthe key functionalities of Internet mobility solutions is to

Y. Wang : J. Bi (*) :K. ZhangInstitute for Network Sciences and Cyberspace, Department ofComputer Science, Tsinghua National Laboratory for InformationScience and Technology (TNList), Tsinghua University,Beijing, Chinae-mail: [email protected]

Mobile Netw Appl (2015) 20:40–52DOI 10.1007/s11036-015-0579-2

properly distribute the identifier-to-address mapping of eachmobile node within the network so that correspondent nodescan reach the mobile node wherever it moves.

Existing Internet mobility approaches have adopted differ-ent ways to implement the mapping functionality. However,they are not flexible enough to face diversified mobility sce-narios in future Internet. For example, Mobile IP [5, 6] cen-tralizes the mapping functionality onHomeAgent deployed ineach mobile node’s home network, which causes trianglerouting and other problems when the mobile node is awayfrom its home network. To address the problem, later researchon Mobile IP, such as the Distributed Mobility Management(DMM) architectural paradigm [7, 8], suggests to distributethe mapping functionality tomultiple locations in the network.However, they still require development and deployment ofspecialized middle-boxes to maintain the mappings. On theother side, protocols such as HIP [9], ILNP [10] and LISPMobile Node [11] propose to move the mapping functionalityfrom the network side to the host side. Without the involve-ment of middle-boxes, these protocols avoid triangle routingin the data plane, but may face performance challengesbrought by inefficient control plane signaling since they high-ly rely on end hosts to handle all mobility related signaling.Moreover, recent research on future Internet architectures alsoaim to solve the Internet mobility problem [12–18], but mostof them are still under development and their protocol detailsas well as performance are not yet clear.

Driven by the above motivations, we propose the design,implementation and evaluations of a software-defined mobil-ity architecture for IP networks. We argue that providingInternet mobility support based on SDN has several advan-tages. Firstly, SDN simplifies the deployment of Internet mo-bility solutions by making each programmable device a can-didate carrier of the mapping function. It also facilitates thedistribution of mobility-related functionalities which con-forms to the current Mobile IP research trend to evolve fromcentralized mobility management (on Home Agent) to a dis-tributed one [19]. Secondly, the centralized control plane ofSDN is beneficial to generate optimized strategies to handlediversified mobility events of hosts by gathering all requiredinformation such as where the hosts are located, how they aremoving and to whom they are communicating, etc. In the dataplane, this advantage can show as avoiding triangle routing,while in the control plane, it can show as efficient mobilityhandling with short signaling delay and small signaling cost.

In the following sections, we first present an overview ofour proposal in Section 2 to show how we integrate Internetmobility and SDN, followed by detailed descriptions on theprotocol design in both intra and inter-domain scenarios. Thenwe demonstrate an alternative implementation of our proposaltogether with evaluations on both QoS and scalability metricsin Section 3. We also present our preliminary deployment andexperiments on a cross-domain testbed in Section 4. In

Section 5, we review related work including research onsoftware-defined mobile and wireless networks, and mobilitymanagement in the Internet. Finally we conclude the paperand 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-definedmobility management architecture consists of several collab-orating domains, each of which contains at least one control-ler. All the domains constitute a confederation which providesa large-scale mobility management service to its customers.This model can be realized in different ways. For instance, ifthe domains are operated by different Internet ServiceProviders (ISP), all ISPs can establish an agreement to allowMobile Nodes (MN) to roam freely among their networks; orsome 3rd party in the Internet Brents^ resources on SDN con-trollers and devices owned by different operators to deployand run its own cross-domain mobility service.

Based on the established confederation, a mobility man-agement Bapplication^ is required in the control plane. It isdeployed onto the collaborating controllers via SDN north-bound interfaces. The controllers communicate with each oth-er through an east/westbound interface to make the distributedmobility management application work. Finally, a southboundinterface is employed to realize interactions between the con-trol plane and data plane, which makes the controllers learn

MN

Controller

Controller

Controller

MN

MN

MobilityManagement

APP

Mobilityspecific Flow

Entries


Entries


Entries

Northbound interfaceSouthbound interfaceEast/westbound interface

Fig. 1 Software-defined mobility management architecture consists ofseveral collaborating domains

Mobile Netw Appl (2015) 20:40–52 41

activities of MNs as well as instruct SDN devices to forwardpackets to and from the MNs.

The control plane has two sub-functions. One maintains up-to-date identifier-to-locator mapping of each MN. It can berealized by making each SDN device report to the controlplane once it detects attachment of a MN. The other sub-function downloads a MN’s mapping to SDN devices whennecessary. There are two cases that require mappingdownloading: in the first case, an SDN device requests aMN’s mapping from the control plane so that it can reach theMN in the data plane; in the second case, once the controlplane receives an update of a MN’s address, it proactivelydownloads the MN’s new mapping to some SDN devices inorder to keep theMN’s reachability for all its ongoing sessions.

The data plane functionality is relatively simple: once datapackets leave Correspondent Nodes (CN) and reach the firstSDN device, they will be forwarded toward the MN by SDNdevices according to the mappings they stored locally. If somemapping required for packet forwarding is missing on an SDNdevice, it requests the specificmapping from the control plane,as is mentioned previously.

2.1.2 An instantiation

Based on the general design, we present an instantiation byusing Pox [20] as the northbound interface, OpenFlow [21] asthe southbound interface, and TCP sockets as the east/westbound interface.

In the instantiation, we use IP address of a MN as its iden-tifier and use the address prefix of the MN’s first-hopOpenFlow switch as its locator. Therefore, once a MN roamsto a new subnet, it keeps its own IP address unchanged and isassigned another routable address with the same prefix in thesubnet. Note that the MN is not aware of the routable address,but its first-hop switch handles the conversion between theroutable address and the MN’s identifier.

We assume that only the identifier of a MN is known to itsCNs. To ensure reachability of a MN, the first-hop switch ofeach CN needs to convert the MN’s identifier to the routableaddress which is realized by a specific flow entry downloadedfrom the controller. Therefore, the controller is responsible formaintaining mappings between each MN’s identifier and itscurrent routable address.

In the following two subsections, we describe in detail howthe instantiation protocol works in both intra-domain andinter-domain scenarios.

2.2 Intra-domain scenario

2.2.1 The single-controller case

First we describe how the protocol works in a single-controllercase in intra-domain scenario. Figure 2a demonstrates the

session initiation process. Once a MN attaches to anOpenFlow switch (S3 in Fig. 2), the switch reports this eventto the controller. To identify the attached MN, a simple ap-proach can be applied by relying on the MN’s MAC address.However, MAC addresses are not always secure identities, sosome authentication approach should be employed such as802.1× to prevent MN identity spoofing as well as other se-curity risks. Once the controller learns the new MN-to-switchrelationship, it assigns a routable address for the MN andstores the mapping between the MN’s identifier and theroutable address in a local mapping table.

When a CN initiates a session with the MN, packets sentfrom the CN first arrive at the first-hop OpenFlow switch (S1in Fig. 2). Since the destination address is the MN’s identifier,S1 queries the controller using Packet-in messages and down-loads a flow entry via Flow-mod message from the controllerto rewrite the destination address to the MN’s routable ad-dress. Then packets are routed to switch S3 according to theroutable address, and then forwarded to the MN. To make theMN recognize such packets, S3 is responsible for rewriting

S3

CN

MN

S1

Controller

S2

CN

MN

S1

S3

(a) Session ini�a�on

Controller

S2

4) AddressQuery and 5)

FlowTabledownloading

3) Forwardpacket to the

first SDNdevice

1) Addressupdate and

2) FlowTabledownloading

7) Rewritedst-IP andforward to

the MN

(b) Handoff handling

6) Rewritedst-IP andforward

toward S3

2) FlowTableUpdate




the MN


toward S4S4

MN

Fig. 2 How the protocol works in a single-controller case in intra-domain scenario. The figure above shows session initiation process andthe figure below shows handoff handling process

42 Mobile Netw Appl (2015) 20:40–52

destination addresses of such packets back to the MN’s iden-tifier, which is realized by another flow entry downloadedfrom the controller when the MN attaches to S3.

Figure 2b demonstrates the handoff handling process. Weassume that the MN leaves S3 and attaches to S4 when com-municating with the CN. Similarly, S4 learns the attachmentof the MN and reports to the controller. Since the controller isaware of the ongoing CN-to-MN session, it is responsible forredirecting the current CN-to-MN flow towards theMN’s newlocation. It is realized by downloading a flow entry to one ofthe switches on the CN-to-MN path (e.g., S2 in Fig. 2). Thestrategy applied to make such flow entry downloading mayhave large impacts on the protocol performance, and we willdiscuss this issue in a separate subsection below.

2.2.2 Flow entry downloading strategy

Considering the case in Fig. 2b, theoretically any switch onthe CN-to-MN flow path beforeMN’s movement (e.g., S1, S2and S3) can serve as a candidate switch to download the flowentry for traffic redirection. However, choosing some switchesmay lead to performance degradation. For instance, it is astraightforward method to download flow entry to the MN’sfirst-hop switch before movement (e.g., S3), but this methodwill 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 delayand overhead in the control plane since it indicates signalingwith the CN side regardless of its distance and number, eventhough the handoff can be handled more efficiently in a localscope.

To address the problem, we propose three goals of applyinga flow entry downloading strategy in the handoff handlingprocess. The first goal is to keep optimal forwarding path,which ensures the shortest forwarding path between MN andCN in the data plane and thus avoids triangle routing. Thesecond goal is to minimize the distance between the MN andthe switch that is about to download the flow entry, sincedownloading flow entry to a distant switch usually implieslarger possibility to trigger inter-controller communicationsand thus results in longer handoff delay. On the contrary,downloading to a nearby switch is helpful to confine signalingwithin a limited area and ensure an efficient handoff. The thirdgoal is to minimize the number of flow entry downloading perhandoff event. This goal can help to both limit the mobility-related flow entry maintained on switches and reduce the sig-naling overhead introduced by flow entry downloading.

In our previous work [22], we studied the algorithms tofind optimal strategies to satisfy the three goals. We find outthat under certain circumstance, goal 2 and 3 can be simulta-neously optimized using a linear algorithmwhen goal 1 servesas constraint. Otherwise an O(n2) greedy algorithm can beapplied to approximate the optimal result.

2.2.3 The multi-controller case

If the CN and the MN belong to different controllers, or if theMNmoves from one controller to another, multiple controllersare involved in the session initiation or handoff handling pro-cess. If the controllers belong to the same administrative do-main, 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 requiredwhich we will discuss below.

2.3 Inter-domain scenario

Figure 3a demonstrates an inter-domain session initiation pro-cess where the CN and theMNbelong to controller C1 and C2respectively. The main difference in this scenario is that, it is

CN

MN

Controller C2

S1

S3

Controller C1

CN

MN

(a) Session Ini�a�on

4) AddressQuery and 6)

FlowTabledownloading

3) Forwardpacket to the

first SDNdevice




the MN

(b) Inter-domain handoff handling


toward S3

4) FlowTableupdate

Controller C2


toward S4

S1

S3

Controller C1

5) Inter-controllerquery andresponse

Controller C3

MN

S4


the MN



3) Inter-controller

update

Fig. 3 How the protocol works with multiple controllers in inter-domainscenario. The figure above shows session initiation process and the figurebelow shows handoff handling process


not suitable for C1 to be aware of the MN’s exact location,otherwise each MN’s movements need be propagated to allthe controllers in the network, which is not scalable in inter-domain deployment scenarios. Therefore, we assume that on-ly the controller(s) in the MN’s current domain (C2 in Fig. 3)stores the up-to-date mapping of the MN, and controllers inthe other domains store a piece of indirect information of theMN instead, such as its current domain and controller. Withthis information, controllers in the other domains (e.g., C1 inFig. 3) can get the MN’s exact location by further queryingC2.

As for handoff handling, if the MN moves within the do-main, we make controller C2 handle the movement, which isanalogous to the case in Fig. 2b. If the MN moves to anotherdomain, inter-controller communication is necessary to handlethe movement. Figure 3b demonstrates an inter-domain hand-off scenario in which the MNmoves from S3 to S4 belongingto another controller C3. The challenge of this case lies in thefact that, unlike the intra-domain case, C3 lacks information ofthe CN-to-MN path to redirect the ongoing flow towards S4.Considering the fact that it may be inappropriate for eachcontroller to learn inter-domain topologies and end-to-endpaths, we employ a simple approach to modify the ongoingflow from its source, i.e., downloading a flow entry to S1. Totrigger this downloading, a straightforward method is that,since inter-domain movement is infrequent, C3 can broadcastthis event to all other controllers including C1. As the numberof collaborating controllers grows, the broadcast method canbe replaced by other methods that scale better. For instance, atwo-step method can be applied by firstly making C3 querythe MN’s previous controller C2 to get the CN’s current con-troller C1, and then notifying C1 of the MN’s movementevent.

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 bydetaching 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 inSection 2.2 and 2.3. However, there are some details we didnot mention in the previous section. For instance, in order toredirect all existing CN-to-MN traffic after theMNmoves to anew location, the controller needs to keep a record of all CN-MN pairs in a local Host Pair Table (HPT). Each time thecontroller downloads a flow entry for some CN in the sessioninitiation process, it adds one entry into the HPT indicatingBThere exists a flow from the CN (represented by its first-hop

switch) to theMN^.When the downloaded flow entry expires,the controller will be acknowledged and then delete the rele-vant entry in the HPT.

We also considered the limit of flow entry numbers onOpenFlow switches. To keep a minimized number of flowentries on each switch, we set a short lifetime (5 s) for eachflow entry downloaded from the controller in the session ini-tiation process. We assume that the expiration of the flowentry implies that the CN-to-MN traffic flow has ended, sothe switch can delete the entry to reduce its flow table size. Ifthe flow resumes after an interruption but the specific flowentry has been deleted, the switch just triggers anotherPacket-in and then recovers the deleted flow entry from thecontroller.

We run two sets of evaluations based on our Mininet im-plementation. In the first set, we employ a customized net-work topology and settings (communication models, mobilitypatterns, etc.) to simulate our proposal together with anothertwo mobility solutions. We show their respective pros andcons in different mobility scenarios in terms of QoS metrics.In the second set, we focus on our proposal’s scalability andemploy randomized topologies and settings to evaluate thecontrol plane overhead brought by our proposal. Before werun each evaluation on a Mininet topology, we pre-downloadflow entries to all the switches to ensure reachability of eachnode in the topology. The flow entries serve as static routingtables and are generated by controllers using shortest pathrouting.

3.2 QoS evaluations

3.2.1 Methodology

In this evaluation set, we compare our proposal with ProxyMobile IPv6 (PMIPv6) [26] and ILNP [10], which serve asrepresentatives of existing Internet mobility solutions, in termsof data plane QoS metrics. To this end, we also implementedanother two SDN applications to realize the basic mobilityfunctions of PMIPv6 and ILNP respectively. PMIPv6 is easierto implement based on Mininet since it is a network-basedprotocol. However, implementing ILNP is more difficult.Thus we simulate ILNP in an approximate way: we movethe mobility functions from hosts to their first-hop switches.

The evaluation topology is shown in Fig. 4 which consistsof three domains, two hosts and eight switches. Delays ofinter-domain links, intra-domain links and Bwireless links^(between a host and attached switch) are 20, 2 and 10 msrespectively. Bandwidths of the above three types of linksare 100Mbps, 100Mbps and 10Mbps respectively. Since inthe current version of Mininet, in-band control betweenswitches and controllers is not supported, the control planeis simulated using one controller with out-of-band control inthis evaluation set. We make H2 the MN and move back and


forth between switch S2 and S5, and make H1 the CN andkeep immobile. We ran Iperf, which is a commonly used net-work testing tool, between the two hosts and collect end-to-end performance metrics including Round Trip Time (RTT),packet loss rate as well as throughput.

When simulating PMIPv6 in this topology, we use S7 asHome Agent, S2, S3, S4 and S5 as Mobile Access Gateway(MAG), S7 and S8 as Local Mobility Anchor (LMA). H2’smoving from S3 to S4 indicates that it leaves its home networkand needs to rely on S7 and S8 for packet indirection. Whensimulating ILNP, each time H2moves, its first-hop switch willsend a mapping update message to S1 on behalf of H2, andthen S1 handles the update on behalf of H1. Note that thisevaluation actually favors PMIPv6 and ILNP for two reasons:firstly, IP re-configuration is ignored in the handoff process ofthe two protocols (origin PMIPv6 also needs IP re-configuration when moving between different PMIPv6 do-mains). Secondly, mapping update process is simplified andonly takes one-way delay: MN-to-HA delay in PMIPv6 caseand MN-to-CN delay in ILNP case. Both simplifications im-prove handoff efficiency of the two protocols.

3.2.2 Results

We first run Iperf between H1 and H2 for 10 s during whichperiod H2 moves from S2 to S5 and performs three handoffs.Figure 5 shows collected TCP sequence of PMIPv6, ILNP andour proposal within the simulation time. As for ILNP, the TCPsession experiences timeout and slow start during each hand-off. It is because ILNP needs to send a mapping update fromMN side towards CN side, and this may seriously degradehandoff efficiency especially when both sides are located far

away from each other. TCP session based on PMIPv6 experi-ences only one timeout during the second handoff, as the othertwo handoffs can be handled locally by LMA, while the inter-domain handoff requires interactions with Home Agent. Incontrast, TCP based on our proposal can always recover frompacket loss during handoff using fast retransmit since it alwaystries to handle the handoff event in local scope. However, if in-band control is applied by our proposal, the inter-domainmovement may also cause timeout as it requires inter-domain communication to handle the handoff event which issimilar to PMIPv6.

Figure 5 also shows RTT of the three protocols col-lected in the same scenario, where we observe that RTTvalue of all three protocols temporarily raises to ahigher value during handoffs. Besides, RTT of PMIPv6stays at a higher value after the second handoff. It isbecause when H2 leaves home network (after movingfrom S3 to S4), all packets to H2 are relayed byHome Agent S7 which results in triangle routing. Our

H1S6

S8 S7

S5 S4 S3S2

S1

H2 H2H2H2

Fig. 4 Topology of the QoS evaluation including 9 domains, 2 hosts and8 switches

Fig. 5 TCP sequence and RTT values of three simulated mobilitysolutions during three handoff events in the 1st evaluation set


proposal avoids triangle routing by ensuring optimalforwarding path, and in this scenario it is achieved bydownloading flow entry to S6. The above two evalua-tions prove that both PMIPv6 and ILNP do not performperfectly when applied to some cases, while the SDNbased mobility solution is more adaptable to fit differentmobility scenarios.

We also test average throughput and packet loss rateof the three solutions by running Iperf TCP and UDPbetween H1 and H2 for 1 min. We repeat each evalu-ation scenario for 100 times with different mobilityfrequencies (0, 0.5 and 1 per second). Figure 6 demon-strates the evaluation results, from which we can learnthat our proposal keeps a high average throughput andlow packet loss rate when compared with the other twoeven when mobility frequency grows to one per sec-ond. The results also prove that the advantage of ourproposal is more obvious when mobility frequency ishigher.

3.3 Scalability evaluations

3.3.1 Methodology

In this evaluation set, we build a Mininet topology consists of10 domains and 100 switches according to a transit-stub to-pology generated by GT-ITM topology generator [27]. Wedeploy one controller in each domain to control all theswitches in the domain.We deploy one host under each switchand make them communica t e w i th each o the r.Communication traffic is also generated using Iperf. We gen-erated two kinds of UDP traffic: a 64 kbps audio traffic with300 bytes packets, and a 250 kbps video traffic with 1kbytespackets. As for each host, we use exponential distribution todescribe both session arrival interval and session durationwithaverage 60 s.

Each time we simulate a session arrival event, the corre-spondent host is randomly chosen among all the other hosts.

When simulating the movement of each host, we assumethat the movement interval is also exponentially distributedwith average 60 s. Before simulating each movement, we firstjudge whether it is an intra or inter-domain movement.We useinter-domain movement probability as a variable in this eval-uation set. As for intra-domain movement, we make each hostmove 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 wecollect statistics of Packet-in events and inter-controller ses-sions. Each result shown in Figs. 7 and 8 is gathered by run-ning 10 simulation turns.

3.3.2 Results

Packet-in is one of the largest overhead brought by our proto-col to the control plane. Figure 7 shows CumulativeDistributed Function (CDF) of average and max number ofPacket-in messages received by each controller per second. Aswe can see, 90 % controllers receive about 4 to 5 Packet-inmessages on average per second, and 95 % controllers receiveabout 50 Packet-in messages at most per second. Inter-domainmovement frequency has a small impact on this simulationbecause most Packet-in messages are triggered in the sessioninitiation process. Therefore, theoretically this number willgrow with the increasing of mobile hosts under one controller.However, we believe that the overhead is acceptable since it isimpractical for one controller to control a network that is toolarge, and Packet-in processing speed of controllers also con-tinues to update according to the literatures.

Figure 8 shows CDF of average and max number of inter-controller sessions handled by each controller per second,which serves as another protocol overhead. Simulation resultsdemonstrate that, inter-domain movement probability slightlyaffects the average session number, but has little impact on the

Fig. 6 TCP throughput and UDP packet loss rate of three simulatedmobility solutions in the 1st evaluation set when mobility frequencyvaries from zero per second to one per second


max session number which is also dominated by thesession initiation process. In conclusion, the largestoverhead is caused by burst of Packet-in messages whensessions initiate, which can be further optimized bypreventing switches from sending identical Packet-inmessages to controllers.

4 Testbed deployment and experiments

4.1 Deployment on testbed

The testbed deployment is based on an internationalfederal SDN testbed we built previously [28]. Thetestbed consists of five SDN domains: Internet2(United States open national research and education net-work), CERNET (China Education and ResearchNetwork), CSTNET (China Science and TechnologyNetwork), and SURFnet (the national research and

education network of the Netherlands). CERNET con-tains two domains in Tsinghua University and BeijingUniversity of Posts and Telecommunications (BUPT) re-spectively. The domains are connected using GRE(Generic Routing Encapsulation) tunnels.

We deploy our Pox-based controller onto the control-lers in CERNET and utilize the switches and hosts inTsinghua and BUPT to make several performance tests,aiming to find out how the extra actions introduced bymobility management, i.e., address rewrite on switchesand Packet-in to controllers, affect normal data transmis-sion. As shown in Fig. 9, the experiment topology in-cludes two domains, each of which has deployed onecontroller, two OpenFlow switches and two hosts. Thedomain in Tsinghua deployed two hardware OpenFlowswitches from Dell and Pica8, while the domain inBUPT deployed two software OpenFlow switches(Open vSwitch).

Fig. 7 CDF of average and max number of Packet-in messages receivedby each controller per second in the 2nd evaluation set. Variable p standsfor probability of inter-domain movement

Fig. 8 CDF of average and max number of inter-controller sessionshandled by each controller per second in the 2nd evaluation set.Variable p stands for probability of inter-domain movement


4.2 Experiments

We first make intra-domain experiments in Tsinghua andBUPT respectively, and then make inter-domain experimentsbetween Tsinghua and BUPT. In all experiments, we generatetraffic between two hosts for an hour to evaluate the impacts onend-to-end performance caused by both destination IP addressrewrite and Packet-in. Note that one round trip of a packetactually triggers two Packet-in events since both communicat-ing hosts are sending packets using their identifiers. Besides,the Packet-in delay in the inter-domain experiments also con-tains latency caused by inter-controller query and response.

Table 1 shows the experiment results. We compared TCPthroughput with and without address rewrite, and packet RTTwith and without Packet-in. We can see that address rewriteperformed by OpenFlow switches has almost none impact ondata transmission in both hardware and softwareimplementations. As for RTT, Packet-in unavoidably bringsa certain amount of delay. However, this delay only impactsthe first packet of each end-to-end session.

5 Related work

5.1 Software-defined mobile and wireless networks

Many efforts have been paid to apply SDN to mobile andwireless networks, most of which pay attention to cellular

networks or WLAN. We present reviews of both categoriesbelow.

5.1.1 Research on WLAN

OpenRoads [29, 30] proposes to improve robustness duringmobility handoff using multicast in Openflow networks. Theauthors showed how this is done by demonstration and de-scribed their testbed deployment. In their following paper[31], they further abstract their idea as separating wirelessservices from infrastructures and rename OpenRoads toOpenflow Wireless which serves as a blueprint for an openwireless network. OpenRadio [32] proposes programmablewireless devices by enabling programmability of thePhysical and MAC layer. It is realized by introducing a soft-ware abstraction layer which decompose wireless protocolsinto decision rules and processing algorithms and providesmodular APIs to programmers. Odin [33] focuses on enter-prise WLAN and proposes light virtual Access Points (AP)that has stable associations with users and can be hosted bydifferent physical APs. The virtual APs are controlled by aspecific controller via OpenFlow. In this way, Odin facilitatesprogrammers to implement mobility management functionssuch as seamless handoff, load balancing, etc.

5.1.2 Research on cellular networks

Integrating SDN and cellular networks includes research onsoftware defined Radio Access Networks (RAN) and corenetworks. SoftRAN [34] employs centralized control of allphysical base stations in a geographical area which areregarded as radio elements. The authors take the latency be-tween the controller and base stations into consideration andput some control plane functionalities down to the radio ele-ments for better trade-off. OpenRAN [35] is another softwaredefined RAN architecture which applies cloud computing.OpenRAN considers convergence of heterogeneous wirelessnetworks, which is a desirable feature not supported bySoftRAN. CellSDN [36] is proposed with the goal ofimplementing a network operating system on LTE networks.Their later research is called Softcell [37] which focuses moreon the core network.

TsinghuaUniversity

BUPT

GRE Tunnel

OpenFlowSwitch (Pica8)101.6.30.62Host

101.6.30.104

Host210.25.132.171

Host210.25.132.173

OpenFlowSwitch (Dell)101.6.30.54 Software

Open vSwitch210.5.132.167Software

Open vSwitch210.5.132.166

Controller101.6.30.59

Controller210.25.132.164

Inter-controller channel

GeneratedIperf traffic

Fig. 9 Demonstration of testbed deployment and experiments inTsinghua University and BUPT

Table 1 impacts of address rewrite and Packet-in on throughput and RTT in three scenarios

Experiment scenarios TCP throughput (Mbps) Round-trip time min/avg/max (ms)

Without rewrite With rewrite Without Packet-in With Packet-in

Intra-domain (hardware OpenFlow switches) 93.7 93.7 0.196 / 0.253 / 0.389 5.907 / 30.421 / 55.911

Intra-domain (software OpenFlow switches) 631 630 0.411 / 0.578 / 1.052 3.473 / 29.574 / 54.364

Inter-domain 17.8 17.8 3.478 / 7.472 / 106.346 80.790 / 204.774 / 3142.292


We argue that research on cellular networks does not affectthe importance of Internet mobility studies. Firstly, overlayInternet services and protocols above cellular network maymake their performance not as efficient as running them di-rectly in the Internet [4]. Secondly, the coupling of accesscontrol and mobility support in cellular networks binds usersto specific service providers [3, 4], and thus limits possiblefuture mobility scenarios such as handoff between differentwireless networks, service providers and even mobile devices.

On the other hand, mobility management research in theInternet and cellular network are closely related, especiallyafter IP is considered as the core part of future cellular net-works [38]. Since the evolution trend of cellular networking ismoving towards an all-IP based infrastructure, which meansall traffic leaving base stations becomes IP-based and is deliv-ered over packet-switched networks, IP mobility managementbecomes a key role to support future wireless systems. ManyIP mobility solutions serve as candidates to provide mobilitymanagement in cellular networks [39, 40], and some pro-posals have already been integrated into cellular networking.Current and future researches on Internet mobility manage-ment will continue to contribute to cellular networking.

Recently, along with the development of 3GPP Long TermEvolution (LTE), there is a growing trend to provide a moreflexible and dynamic mobility management, which is also aconcern in the Internet research area. The Internet EngineeringTask Force (IETF) has already been standardizing related pro-tocols, which may be introduced into 3GPP to replace itsexisting mobility management functions [8].

5.2 Internet mobility management

Generally, supporting Internet mobility means to offer unin-terrupted Internet connectivity to MNs which change theirattachment points while roaming in the network. Due to thetight-coupling of TCP and IP [41], changing IP addresses willcause interruption of TCP sessions on MNs, which may seri-ously impact experiences of mobile users.

Basically, Internet mobility solutions can be divided intorouting-based and mapping-based approach [42]. Routing-based approach makes a MN use the same IP address whileroaming, and thus requires dynamic routing to keep reachabil-ity of the MN. On the contrary, mapping-based approach al-lows a MN to change IP addresses but keep a stable identifier.To reach the MN using its identifier, a mapping mechanism isintroduced to resolve identifier to the MN’s current locator. Inthese solutions, TCP sessions are always bound to identifiersinstead of IP addresses, thus they can keep survivability facingchanging IP addresses. As discussed by Zhang et al. [3],routing-based approach is not suitable to provide mobilitysupport in large-scale networks due to scalability issues asthe whole network requires to be informed of each MN’smovement.

Amongst all identifier-based proposals, Mobile IP and itsextensions [26, 43] are the earliest and most well-known pro-tocols. Later, a number of Mobile IP derivatives have beenproposed to improve its basic functionality [44–47]. Recently,there are many individual IP mobility protocols which belongto Identifier-Locator Split (ILS) proposals, as well as futureInternet architecture proposals arise to address mobility prob-lems in the Internet. We review these solutions respectively inthe 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 takeMIPv6 as an example: the protocol uses a special IP addresscalled Home Address (HoA) to identify a MN. When a MNmoves to a new network, it obtains a Care-of Address (CoA)which can be used to reach the MN. Then the MN communi-cates with the Home Agent (HA) located in its home networkto update the Binding Cache which maps the MN’s HoA to itscurrent CoA. A CN sends packets to the MN using its HoA,thus the packets are forwarded to the HA. With up-to-datebinding cache, the HA can encapsulate and redirect packetstoward the MN’s current CoA. To reduce mobility signalingcost when the MN moves away from the HA, some MIPv6extensions 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 packetsfrom CN toMN have to take a detour to pass the HA, which isknown as the triangle routing problem. Triangle routing canresult in routing path stretch, which means the actual routingpath is longer than the shortest one, as well as heavy load onHA. MIPv6 has offered a Route Optimization (RO) mode toaddress triangle routing by directly sending Binding Cachefrom MN to CN. However, RO mode is less-than-ideal dueto some drawbacks in security and efficiency.

In recent years, a series of Mobile IP derivatives [44–47],which follow Distributed Mobility Management (DMM) ar-chitectural paradigm [7, 8], arise to address the problem.DMM solutions distribute the functionality of HA to multiplemobility anchors deployed in the network so that the MN canalways choose a nearby mobility anchor to maintain its bind-ing cache and perform packet redirection. Thus, the MN’sHoA never represents a fixed location and triangle routingcan be alleviated or even eliminated. DMM research is stillin the early stage, but it is considered as a promising way toevolve Mobile IP networks and is currently under standardi-zation in the IETF DMM group [48].

5.2.2 Identifier-locator split solutions

Identifier-locator split (ILS) is an architectural model whichpoints out that IP address has embedded both identifier and


locator semantics and a split of the two is necessary. Suchsolutions often maintain identifier-to-locator mappings in aglobal mapping system. When CN starts communication withMN, it queries the mapping system to obtain the current loca-tor of the MN. When the MN moves to a new network, itsends the new identifier-to-locator mapping to not only themapping system but also the CN side so that CN can directlyreach the MN’s current location as soon as possible.Therefore, mobility handoff is actually accomplished in anend-to-end way. Host Identity Protocol (HIP) [9], Identifier-Locator Network Protocol (ILNP) [10] and LISP MobileNode [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 thepublic key of a key pair that belongs to the host. With self-authenticating identifiers, each host is able to prove ownershipto its HI through cryptographic methods. ILNP does not in-troduce new namespaces but utilizes IPv6 address space toidentify mobile hosts. ILNP splits IPv6 address space into anidentifier part and a locator part: the first 64bits of IPv6 ad-dress remains to be used for routing in the network, while thelast 64bits are used to uniquely identify mobile hosts. LISPMobile Node (LISP-MN) is developed base on LocatorIdentifier Separation Protocol (LISP) [49], which is a core-edge separation design. LISP proposes a separation ofEndpoint Identifiers (EID) from Routing Locators (RLOC)and deploys ingress/egress Tunnel Routers (TR) to maintainEID-to-RLOC mappings. LISP-MN utilizes EID as identifierand RLOC as locators of mobile hosts. All three protocolsmodify TCP/IP stack on hosts to realize the mapping func-tions. HIP and ILNP rely on DNS to store the mappings, whileLISP-MN makes use of several alternative Map-Servers pro-posed 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 GloballyUnique Identifiers (GUIDs) to name network attached objectsand employs a Global Name Resolution Service (GNRS) todynamically mapGUIDs to Network Addresses (NAs). As formobility management, currently MobilityFirst highlights thedesign of a fast resolution service rather than the handoff han-dling. Named Data Networking (NDN) [13] is another FIAprogram which proposes to directly route on identifiers in-stead of employing resolution and indirection services.Therefore, the baseline NDN protocol has to support mobilityusing routing-based approach which is considered as unscal-able. Some NDN extensions have been proposed to addressthe mobility issue [50, 51]. NetInf [14] belongs to 4WARDproject supported by European Union seventh FrameworkProgram (FP7). NetInf relies on a Name Resolution System(NRS) to resolve identifiers of Information Objects (IO) to

their locations and other related data. NRS is realized usingMDHTconsists of multiple levels of DHT nodes called NetInfnodes. NetInf proposes one mobility management solution byutilizing the indirection features of NRS, which is analogousto 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 futureInternet architectures with existing IP-based mobility solu-tions. On one hand, most of them are still under developmentand lack protocol details. On the other hand, although theyshare similarities in handling host mobility with Mobile IPderivatives and ILS solutions, they usually focus on not onlymobile hosts but also mobile contents, which always goesbeyond the traditional concept of host-based mobility [52].

6 Conclusions and future work

In this paper, we proposed an IP mobility architecture basedon Software Defined Networking paradigm.We demonstratedarchitecture and protocol design, simulation and evaluationson Mininet platform as well as deployment and experimentson a cross-domain SDN testbed. Mininet evaluation resultsprove feasibility and scalability of the proposal, and testbedexperiments further show that the implemented mobility man-agement functionality brings negligible impacts on normaldata transmission.

There are several unsolved issues in the proposed SDN-based mobility solution which we include in our future work.Firstly, although the evaluations show advantages of the SDN-based solution, the results are collected based on the Mininetplatform, and further research is still required to make clearhow the SDN-based solution performs when deployed in realnetwork environment. Secondly, the current solution is morefocused on intra-domain scenarios and the inter-domain caseis relatively simplified. Part of the reason is that SDN-basedinter-domain cooperation has been little studied currently.Finally, a practical problem is that, the SDN-based solutionrequires 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 fromtwo aspects. Theoretically, on one hand, we consider studyingon integrating SDN and inter-domain routing in order to facil-itate inter-domain mobility support. On the other hand, weneed to pay attention to partial deployment scenarios and an-alyze on the deployment incentives of the SDN-based mobil-ity proposal. Practically, we are further extending the scales ofsimulations on Mininet platform, and at the same timedeploying the prototype onto the Internet2, SURFnet andCSTNET testbed to establish an international confederation


for future experiments. We are also planning on implementingreal mobility scenarios based on wireless environments.

Acknowledgments This work is supported by the National High-techR&D Program (B863^ Program) of China (No.2013AA013505) and theNational Science Foundation of China (No.61472213).

References

1. YangM, Li Y, Jin D, Zeng L,Wu X, Vasilakos AV (2014). Software-Defined and virtualized future mobile and wireless networks: a sur-vey. Mobile Networks and Applications, 1–15

2. Jagadeesan NA, Krishnamachari B (2014) Software-defined net-working paradigms in wireless networks: a survey. ACM ComputSurv (CSUR) 47(2):27

3. Zhang L, Wakikawa R, Zhu Z (2009) Support mobility in the globalInternet. In: Proceedings of the 1st ACM workshop on mobile inter-net 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 59446. Arkko J, Perkins C, Johnson D (2011)Mobility support in IPv6. RFC

62757. Chan HA, Yokota H, Xie J, Seite P, Liu D (2011) Distributed and

dynamic mobility management in mobile internet: current ap-proaches 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) archi-tecture. 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 node12. Venkataramani A, Sharma A, Tie X, Uppal H, Westbrook D, Kurose

J, Raychaudhuri D (2013). Design requirements of a global nameservice for a mobility-centric, trustworthy internetwork. InCommunication Systems and Networks (COMSNETS), 2013 FifthInternational Conference on (pp. 1–9). IEEE

13. Zhang L, Afanasyev A, Burke J et al. (2014). Named data network-ing. Technical Report NDN-0019, Revision 1:10

14. Ohlman B, Ahlgren B, Brunner M et al. (2009) 4WARD deliverable6.2: second NetInf architecture description. Tech. Rep

15. Anand A, Dogar F, Han D, et al. (2011). XIA: an architecture for anevolvable and trustworthy Internet. In: Proceedings of the 10th ACMWorkshop on Hot Topics in Networks (p. 2). ACM

16. Koponen T, Chawla M, Chun BG, Ermolinskiy A, Kim KH, ShenkerS, 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 publish-subscribe 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-centricapplications. ACM Trans Internet Technol (TOIT) 12(2):4

19. Liu D, Yokota H, Korhonen J, Chan A, Seite P (2014). Requirementsfor 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 SIGCOMMComputCommun Rev 38(2):69–74

22. Wang Y, Bi J (2014) A solution for IP mobility support in softwaredefined networks. The 23rd IEEE International Conference onComputer Communications and Networks (ICCCN14), 481–488

23. Koponen T, Casado M, Gude N, et al. (2010) Onix: A distributedcontrol platform for large-scale production networks. In: OSDI, 10:1–6

24. Tootoonchian A, Ganjali Y (2010) HyperFlow: a distributed controlplane for OpenFlow. In: Proceedings of the 2010 internet networkmanagement 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, LeungK, 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 forSDN inter-domain network peering. The 33rd IEEE InternationalConference on Computer Communications (INFOCOM14). 111–112

29. Yap KK, Huang TY, Kobayashi M, Chan M, Sherwood R, ParulkarG, McKeown N (2009) Lossless Handover with n-casting betweenWiFi-WiMAX onOpenRoads. ACMMobicom (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 onExperimental evaluation and characterization (pp. 59–66). ACM

31. Yap KK, Sherwood R, Kobayashi M et al. (2010). Blueprint forintroducing innovation into wireless mobile networks. In:Proceedings of the second ACM SIGCOMM workshop onVirtualized infrastructure systems and architectures (pp. 25–32).ACM

32. BansalM,Mehlman J, Katti S, Levis P (2012)Openradio: a program-mable wireless dataplane. In: Proceedings of the first workshop onHot 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: Proceedingsof 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 de-fined radio access network. In Proceedings of the second ACMSIGCOMM 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: asoftware-defined ran architecture via virtualization. In Proceedingsof the ACM SIGCOMM 2013 conference on SIGCOMM (pp. 549–550). ACM

36. Li LE, Mao ZM, Rexford J (2012). Toward software-defined cellularnetworks. In Software Defined Networking (EWSDN), 2012European Workshop on (pp. 7–12). IEEE

37. Jin X, Li LE, Vanbever L, Rexford J (2013). Softcell: scalable andflexible cellular core network architecture. In: Proceedings of theninth ACM conference on Emerging networking experiments andtechnologies (pp. 163–174). ACM

38. Chiussi FM, Khotimsky DA, Krishnan S (2002) Mobility manage-ment in third-generation all-IP networks. IEEE CommunMag 40(9):124–135

39. Saha D, Mukherjee A, Misra IS, Chakraborty M (2004) Mobilitysupport 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 manage-ment in next-generation all-IP-based wireless systems. IEEE WirelCommun 11(4):16–28

41. Chiappa JN (1999) Endpoints and Endpoint names: a proposed en-hancement to the internet architecture

42. Zhu Z, Zhang L,Wakikawa R (2011) A survey of mobility support inthe Internet. RFC 6301


http://www.noxrepo.org/pox/about-pox/

http://mininet.org/

http://www.cc.gatech.edu/projects/gtitm/

http://www.cc.gatech.edu/projects/gtitm/

43. Soliman H, Bellier L, Elmalki K, Castelluccia C (2008) Hierarchicalmobile IPv6 (HMIPv6) mobility management. RFC 5380

44. Wakikawa R, Valadon G, Murai J (2006) Migrating home agentstowards internet-scale mobility deployments. In: Proceedings of the2006 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, Indoorand Mobile Radio Communications, 2008. PIMRC 2008. IEEE 19thInternational 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 inIP mobility. In: Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th (pp. 899–903). IEEE

47. Mao Y, Knutsson B, Lu H, Smith JM (2005) Dharma: distrib-uted home agent for robust mobile access. In: INFOCOM

2005. 24th Annual Joint Conference of the IEEE Computerand Communications Societies. Proceedings IEEE (Vol. 2, pp.1196–1206). IEEE

48. IETF, BDistributed Mobility Management (DMM) IETF WorkingGroup^. <http://tools.ietf.org/wg/dmm/>

49. Farinacci D, Lewis D, Meyer D, Fuller V (2013) The locator/IDseparation protocol (LISP). RFC 6380

50. Zhu Z, Afanasyev A, Zhang L (2014) A new perspective on mobilitysupport. Tech Rep

51. Zhang Y, Zhang H, Zhang L (2014) Kite: a mobility support schemefor ndn. In: Proceedings of the 1st international conference onInformation-centric networking (pp. 179–180). ACM

52. Tyson G, Sastry N, Cuevas R, Rimac I, Mauthe A (2013) A survey ofmobility in information-centric networks. Commun ACM 56(12):90–98


http://tools.ietf.org/wg/dmm/

design and implementation of a software-defined mobility...

Documents