Accepted Manuscript

Software-defined Networking: Challenges and Research Opportunities for Fu-

ture Internet

Akram Hakiri, Aniruddha Gokhale, Pascal Berthou, Douglas C. Schmidt,

Gayraud Thierry

PII: S1389-1286(14)00370-3

DOI: http://dx.doi.org/10.1016/j.comnet.2014.10.015

Reference: COMPNW 5414

To appear in: Computer Networks

Received Date: 25 April 2013

Revised Date: 12 October 2014

Accepted Date: 13 October 2014

Please cite this article as: A. Hakiri, A. Gokhale, P. Berthou, D.C. Schmidt, G. Thierry, Software-defined

Networking: Challenges and Research Opportunities for Future Internet, Computer Networks (2014), doi: http://

dx.doi.org/10.1016/j.comnet.2014.10.015

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers

we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and

review of the resulting proof before it is published in its final form. Please note that during the production process

errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

Software-dened Networking: Challenges and Research Opportunities for FutureInternet

Akram Hakiria,b, Aniruddha Gokhalec, Pascal Berthoua,b, Douglas C. Schmidtc, Gayraud Thierrya,b

aCNRS, LAAS, 7 avenue du colonel Roche, F-31400 Toulouse, FrancebUniv de Toulouse, UPS, LAAS, F-31400 Toulouse, FrancecInstitute for Software Integrated Systems, Dept of EECS

Vanderbilt University, Nashville, TN 37212, USA

Abstract

Currently many aspects of the classical architecture of the Internet are etched in stone a so called ossication ofthe Internet which has led to major obstacles in IPv6 deployment and diculty in using IP multicast services. Yet,there exist many reasons to extend the Internet, e.g., for improving intra-domain and inter-domain routing for highavailability of the network, providing end-to-end connectivity for users, and allowing dynamic QoS management ofnetwork resources for new applications, such as data center, cloud computing, and network virtualization. To addressthese requirements, the next-generation architecture for the Future Internet has introduced the concept of Software-Dened Networking (SDN). At the core of this emerging paradigm is the separation and centralization of the controlplane from the forwarding elements in the network as opposed to the distributed control plane of existing networks.This decoupling allows deployment of control plane software components (e.g., OpenFlow controller) on computerplatforms that are much more powerful than traditional network equipment (e.g., switches/routers) while protectingthe data and intellectual property of the vendors of such equipment.

A critical understanding of this emerging paradigm is necessary to address the multiple challenges in realizing theFuture Internet and to resolve the ossication problem of the existing Internet. To address these requirements, thispaper surveys existing technologies and the wide range of recent and state-of-the-art projects on SDN followed by anin-depth discussion of the major challenges in this area.

Keywords: Future Internet, Software-Dened Networking (SDN), OpenFlow, Network Function Virtualization,Forwarding Plane, Control Plane.

1. Introduction

1.1. The Need for a New Network Architecture.

The capacity of the current Internet is rapidly becominginsucient to cater to the large volumes of trac patternsdelivered by the new services and modalities (e.g., mobile

Email addresses: hakiri@laas.fr (Akram Hakiri),a.gokhale@vanderbilt.edu (Aniruddha Gokhale),berthou@laas.fr (Pascal Berthou), d.schmidt@vanderbilt.edu(Douglas C. Schmidt), gayraud@laas.fr (Gayraud Thierry)

devices and content, server virtualization, cloud services,big data), which is generated due to a large number ofusers, sensors and applications [1, 2].

Existing networks built with multiple tiers of static Eth-ernet switches arranged in a tree structure are ill-suitedfor the dynamic computing and storage needs of todaysand future enterprise hyper-scale data centers, campuses,and carrier environments. Instead, new networking infras-tructures are desired that will provide high performance,energy eciency, and reliability. Moreover, they shouldimprove the network speedup, scalability and robustness

Preprint submitted to Elsevier October 15, 2014

with the eective creation and delivery of versatile digi-tal services that provide stringent quality of service (QoS)guarantees. Meeting these requirements is impossiblewith existing network equipment due to their limited ca-pabilities. Additionally, todays protocols tend to be de-ned in isolation and are meant to solve a specic problemwithout the benet of any fundamental abstractions.

In addition, to implement network-wide policies and tosupport any new services, managers today have to con-gure thousands of network devices and protocols, whichmakes it dicult to apply a consistent set of QoS, security,and other policies. Networks become vastly more com-plex with the addition of thousands of network devicesthat must be congured and managed. These devices havetheir control and forwarding logic parts both integratedin monolithic, closed, and mainframe-like boxes. Con-sequently, only a small number of external interfaces arestandardized (e.g., packet forwarding) but all of their in-ternal exibility is hidden. The internals dier from ven-dor to vendor, with no open software platform to experi-ment with new ideas.

A lack of standard open interfaces limits the ability ofnetwork operators to tailor the networks to their individ-ual environments and to improve either their hardwareor software. Hence, there is a need for a new networkequipment architecture that decouples the forwarding andcontrol planes of the routers to dynamically associate for-warding elements and control elements.

1.2. Software-Dened Networking.

Software-Dened Networking (SDN) [3, 4] hasemerged as the network architecture where the controlplane logic is decoupled from the forwarding plane. SDNis a new approach for network programmability, whichrefers to the ability to control, change, and manage net-work behavior dynamically through software via open in-terfaces in contrast to relying on closed boxes and pro-prietary dened interfaces. The SDN framework enablescentralized control of data path elements independently ofthe network technology used to connect these devices thatcan originate from dierent vendors. The centralized con-trol embeds all the intelligence and maintains a network-wide view of the data path elements and links that con-nect them. This centralized up-to-date view makes thecontroller suitable to perform network management func-

tions while allowing easy modications to the networkingfunctions through the centralized control plane.

Figure 1 depicts the SDN architecture illustrating theseparation between the applications, control plane anddata plane. Applications use the northbound API sup-ported by the control plane to enforce their policies in thedata plane without directly interacting with the data plane.The interface between the control and data plane is sup-ported by southbound APIs, where a SDN controller willuse these APIs to communicate with the network equip-ments in the data plane. These equipments are required tosupport the standardized APIs at this level.

Net App 2 Net App nNet App 1

Network Abstraction (e.g., topology abstraction, QoS)

OpenFlow Router

Global Network View

Open Northbound APIs

Abstract Network ViewC

ontro

l Pla

neD

ata

Plan

e

Network Operating System (SDN Controller)

Open Southbound APIs (e.g., OpenFlow)

Figure 1: Simplied view of an SDN architecture

SDN makes it possible to manage the entire networkthrough an intelligent orchestration and provisioning sys-tem that enables on-demand resource allocation, self-service provisioning, truly virtualized networking, and se-cure cloud services. Thus, the static network can evolveinto an extensible vendor-independent service delivery

2

platform capable of responding rapidly to changing busi-ness, end-user, and market needs, which greatly simpli-es the network design and operation. Consequently, thedevices themselves no longer need to understand and pro-cess thousands of protocol standards but merely acceptinstructions from the SDN controllers.

A concrete realization of the SDN approach is Open-Flow (OF) [5, 6]. OpenFlow aims to allow providers toreengineer their trac to test out new protocols in existingnetworks without disrupting production applications. Thekey elements of this technology consists of three parts: (i)ow tables installed in OpenFlow-aware switches, (ii) acontroller installed in a remote host machine, and (iii) anOpenFlow protocol for the controller to talk securely withswitches. The OpenFlow approach of splitting the controllogic from the forwarding behavior provides a exible ca-pability for on-the-y addition and update of several for-warding roles in the data plane.

1.3. Paper Objectives and Organization

The goal of this paper is to understand the challengesand research opportunities for SDN in dening the FutureInternet. The rest of the paper is organized as follows:Section 2 outlines the key use cases of SDN and standard-ization eorts, which help to understand the realm of SDNand the spectrum of avenues for research and standard-ization; Sections 3 through 8 outline the key areas wheremore SDN research is needed to solve a number of unre-solved challenges. Finally, Section 9 provides concludingremarks.

2. SDN Use Cases and Standardization Eorts

This section highlights the important use cases of SDNand current standardization activities. The goal of thissection is to help the reader to situate their interests andresearch investigations in the context of ongoing standard-ization activities and use cases of the SDN technology.

2.1. SDN Use Cases in Service Provider Networks

The industry has recently undergone a signicant trans-formation of their network infrastructure to support bothcurrent and future business models of SDN. This trans-formation oers a means to reduce the costs of service

delivery and increase the service velocity using SDN tech-nologies. In this section we present a number of SDN usecases.

2.1.1. Data Center Interconnects Use CaseModern data centers are composed of tens of thousands

of resources (e.g., processors, memory, storage, high-speed network interfaces), which in turn are packaged intoracks and allocated as clusters consisting of thousands ofhosts that are tightly connected with a high bandwidth net-work. These clusters are orchestrated to exploit thread-level parallelism to handle many Internet-based work-loads. The trac in the data center networks often ex-hibits bursty behavior where a large number of packets getinjected in the network over a short time, which in turninduces a transient load imbalance that can aect otherows, and thereby signicantly degrade the performanceof the entire network [7].

Applications and Eco-system Integration

Virtual MachinesOpenStack

Plug-ins

Analytics App1 AppNApp2 .

Applications

OpenFlowController

Resource AbstractionsDiscovery, Topology, Configuration, QoS, Performance, Flow/Resource Management

Common Services

Data Center Interconnect

RESTAPI

REST API

Tool 1 Tool 2 Tool 3 Tool 4Third Party

Tools

OpenFlowProtocol OpenFlow

Protocol

Figure 2: The use of OpenFlow for Cloud and Data-Center

The value of SDN in a data center interconnect liesspecically in its ability to provide network virtualiza-tion, abstraction and automation. In Figure 2, a cen-tralized OpenFlow controller is used to provide dynamictrac steering between applications that can be locatedin virtual machines or physical computers in data cen-ters. Those applications use RESTful programming inter-

3

faces to expose their requirements to the underlying net-work over large-scale networks. The RESTful APIs en-able them to perform a wide range of advanced networkoperations, such as topology discovery, QoS allocation,and load balancing. They also enable exible networkmanagement with deterministic behavior by eliminatingthe need for resource over provisioning. Moreover, SDN-compliant third party tools can be easily plugged into datacenters to perform faster recovery from link and node fail-ures. That is, the OpenFlow controller reects a uniedview of the data center and simplies the control of theentire network.

2.1.2. Network Slicing Use CaseNetwork slicing is a mechanism to divide the avail-

able network infrastructure into dierent partitions to al-low multiple instances to coexist. Each slice controlsits own packet forwarding without interfering with otherslices even if they share the same underlying physical net-work. Figure 3 shows a multi tenant infrastructure con-nected through OpenFlow switches over a virtual over-lay network to provide private or even public cloud ser-vices. This use case shows how slicing the network re-sources into multiple partitions provides tenants access totheir virtual L2 slices without interfering with others. TheSDN controller can achieve policy-based network man-agement and exible resource allocation, and at the sametime can continue to support per-tenant/per-slice instanti-ation. This means that the controller can honor its ruleto provide robustness, stability and scalability in termsof number of tenants, support for concurrent experimentsand number of managed resources.

2.1.3. Wireless Settings Use CaseWireless networks require specic features like mo-

bility management, dynamic channel conguration, andrapid client re-association. As depicted in Figure 4, thevalue of SDN in wireless networks lies specically in itsability to provide new capabilities, such as network slic-ing, and the creation of new services on top of the virtual-ized resources in secure and isolated networks.

In Figure 4 Flowvisor and OpenVirteX are OpenFlow-based proxy layers that allow creating slices basedon multiple parameters such as bandwidth, ow-space(src/dst MAC, src/dst IP, and src/dst TCP ports), and CPUswitch load. Each slice is independent, e.g., trac from

OF Switch

Underlying Network

Virtual L2 Slice 2

Virtual L2 Slice 1

Computing Cluster

VM 5VM 6

Tenant1

VM 11VM 12

Tenant2

OF Switch

VM 3 Tenant 1

VM 4 Tenant 1

VM 1VM 2

Tenant 1

VM 1VM 2

Tenant 1

VM 4Tenant 3

VM 3Tenant 2

Computing Cluster

Computing ClusterOF Switch

SDN Controller

Figure 3: OpenFlow Network Slicing use case

Alices mobile application does not alter Bobs and Alexstrac in the other slices. Moreover, wireless virtualiza-tion enables the migration of the switch conguration thatmanages Alices application to another device seamlesslywithout disrupting the active network trac of Bob andAlex. Such a conguration was introduced by the Odinframework [8], which is a programmable wireless dataplane with modular and declarative programming inter-faces across the wireless stack. This decoupling providesvirtual access point abstractions to simplify network man-agement for a wide range of enterprise requirements (e.g.,an airport, a restaurant, public library) [9].

Additionally, one of the most interesting complemen-tary technologies that can benet from SDN are smarthome gateways, which aim to interconnect residentialhome-gateway to their network providers. It also oersseamless and mobile connectivity without compromisingsecurity. For example, [10] introduced a Virtual Home-gateway Control (VHC) to improve seamless mobility,service delivery and home energy management.

2.1.4. Network Trac Engineering Use CaseTrac Engineering is a soft method for optimizing the

performance of the ISP networks. It oers IP-based L2or L3 enterprise VPN services and enables transmittingtrac to non IP networks like ATM and frame relay net-works. Network providers use trac engineering to sup-port high transmission capacity and resilient communica-tion by dynamically analyzing, predicting and regulating

4

Diverse MobileApplications

Alice Mobile App

Bob Mobile App

Alex Mobile App

NOX Floodlight RyuOpenFlow Controller

Flexible Network Slicing & Orchestration OpenVirteX

Flowvisor

LaptopLaptop

Heterogeneous Underlying Network

WiMax AP

Wi-Fi APWAN Router

OpenVSwitch

OpenFlow Protocol

Figure 4: Wireless OpenFlow Infrastructure

the behavior of the transmitted data. In traditional net-works, some protocols such as OSPF and BGP allow thenodes to share their control information between their im-mediate neighbors and in a limited way to avoid networkcongestion. This means that there is no global view of thenetwork available. If the users need to control or modify aparticular path for a particular ow, the administrator hasto test with parameters and priorities to achieve the ex-pected behavior of the network. Each modication in thenetwork policy requires individual conguration directlyor remotely from each device.

The added value of SDN is to provide exible and pro-grammable network devices to optimize and enable ne-grained control to dierent customers ow data with re-spect to the services they provide.

Figure 5 shows how a centralized SDN controller canmanage three dierent trac streams (HTTP trac, VoIP,and VoD) over dierent underlying network technologies.For example, at the Toulouse access network, the user ap-plications send their data through an OpenFlow-enabledrouter to the Bern network through the core network,which can be a circuit-based ATM technology. The cen-tralized controller is able to control, manage and supervisethe overall network equipment in the path between end-users. It performs trac engineering with common con-trol over packet and circuit networks using OpenFlow as

Toulouse (France)

Nashville (USA)

Bern (Suisse)

Video traffic, dynamic bandwidth, free jitter,

Voice over IP, delay sensitive, dynamic bandwidth

Web traffic, static, predefined path

OpenFlow Controller

Gigabit EthernetHTTP trafficVoIP Traffic

VoD TrafficBGP RoutingOpenVSwitch

Figure 5: Trac engineering with OpenFlow-based SDN

a multi-layer Unied Control Plane (UCP). Thus, insteadof using traditional distributed routing protocols like BGP,the centralized controller installs all routing decisions inthe network equipment without using the traditional full-mesh of packet links[11], thereby enhancing the networkexibility and the scalability. Further, the controller cansupport application-specied routing as well as trac ag-gregation based on IP source/destination addresses.

2.2. Standardization Activities around SDN

Driven by their attractive features and potential advan-tages, the development and deployment of SDN-based in-frastructures have gained tremendous momentum in theindustry and research community in recent years. In thissection, we briey discuss the standardization trends inSDNOpenFlow.

2.2.1. Clean Slate Design InitiativeThe Internet has evolved to this day based on incremen-

tal changes to the protocols and by retrotting the archi-tecture to solve the current problems. However, it has notbeen possible to introduce any major changes to the de-ployed base of the Internet. The small and incrementalchanges that solve the current problems have introducedother problems so that the incremental approaches havearguably stretched the current design to its limit a socalled ossication of the Internet [12].

A new architectural design called the Clean Slate De-sign [13] considered how the Internet could be redesigned

5

from a clean slate without being restrained by the accu-mulated complexity of the incremental approaches. Theresearch funding agencies all over the world are support-ing the world-wide eorts to develop the next generationInternet [14].

The United States National Science Foundation (NSF)was among the rst to announce the GENI (Global En-vironment for Networking Innovations) [15] program fordeveloping and testing new Internet architectural designsas part of its FIND (Future Internet Design) program. Thiseort was followed by the FIRE (Future Internet Researchand Experimentation) [16] program, the OFELIA (Open-Flow in Europe: Linking Infrastructure and Applications)program [17, 18], and the SPARC (Split Architecture Car-rier Grade Networks) program [19] to support numerousnext generation networking projects under the 7th Frame-work Program of the European Union, the AKARI Archi-tecture Design Project [20] and the RISE (Research In-frastructure for large-Scale network Experiments) [21] inJapan.

2.2.2. Open Networking Foundation for SDNThe Open Networking Foundation [22] (ONF) was the

rst organization dedicated to the growth and successof SDN. Its mission was to evolve the OpenFlow pro-tocol from its academic roots to a commercially viablesubstrate for building networks and networking products.The ONF has formed working groups including carrieroperators, software vendors, switch chip vendors, net-work equipment vendors, and system virtualization ven-dors to conduct the technical standardization tasks ofSDN/OpenFlow. These groups continue to analyze SDNrequirements, evolve the OpenFlow Standard to addressthe needs of commercial deployments, and research newstandards to expand SDN benets that cover the standard-ized protocols and technology points shown in Figure 6.The example scenario described in this Figure consist ofinterconnecting three dierent networks: a conventionalIP network (legacy network), SDN-based core networkand a SDN-enabled data center (cloud). The dierentSDN interfaces shown in the gure are as follows:

Northbound Interface: It enables the exchange ofdata between the SDN controller and the applica-tion running on top of the network a so calledapplication-driven network. The kind of informa-

tion that is exchanged, its form, and its frequencydepends on each network application. There is nostandardization for this interface.

Southbound Interface: It refers to the APIs exposedto lower layers that allow the externalization of theSDN control plane to the data plane. OpenFlow andthe Network Conguration Protocol (NetConf) arethe southbound APIs used for a majority of SDN im-plementations to date.

Eastbound Interface: It allows interconnecting con-ventional IP networks with SDN networks. Stan-dardization of this interface is not provided and itsimplementation depends on the technology used bythe non-SDN network. Usually, a translation mod-ule between SDN and legacy technology is required.For example, the SDN domain should be able to uselegacy routing protocol to react to message requests(e.g., Path Computation Element protocol, (PCE),MPLS).

Westbound Interface: They serve as the informa-tion conduit between multiple SDN control planesof dierent SDN domains. They help to achieve aglobal network view and inuence routing decisionsof each controller. They also allow seamless setupof network ow across heterogeneous SDN domains.Some conventional protocols like BGP can be usedbetween remote SDN domains as westbound inter-face.

2.2.3. The Open Daylight FrameworkThe OpenDaylight Project [23] is a collaborative open

source project hosted by The Linux Foundation. It aimsto create platform-neutral, and open-source SDN tech-nology. The OpenDaylight project provides a commoncontroller infrastructure, protocol plug-ins, SDN applica-tions, virtual overlay networks and standards-based north-bound interfaces. It also provides support for a vari-ety of southbound protocols, including OpenFlow, I2RS,Path Computation Element (PCE), Network Congura-tion (NetConf) and Application Layer Trac Optimiza-tion (ALTO), as well as a Topology Manager modulebased on most of the active YANG data models for net-work topologies.

6

SDN Application Logic

NBI Driver

SDN Application

SDN Application Logic

NBI Driver

SDN Application

SDN Southbound Interface (SBI)

Network DeviceSDN DataPath

SBI Agent

Forwarding Engine

Network DeviceSDN DataPath

SBI Agent

Forwarding Engine

Element Setup

Configure PolicyMonitor Performance

NBI Agent

SDN Control Logic

SBI Driver

SDN controller

Contract (SLA)Da

ta P

lane

Cont

rol P

lane

Appl

icatio

n Pl

ane

Application explicit

requirements

Net

wor

k St

ates

, St

ats,

heal

th

Enforce Behavior, Low-level control, Capability discovery,

stats, events, health

Expose APIsTranslate requirements down;

report Stats, events up

Lega

cy N

etw

ork

cont

rol P

lane

SDN N

etwork control Plane

Man

agem

ent P

lane

Legacy Network

Hypervisor

OpenVSwitchHypervisor

OpenVSwitchHypervisor

Cloud

OpenVSwitchSDN WAN

Eastbound Interface

Westbound Interface

Figure 6: ONF Reference Architecture for SDN

2.2.4. IETF and ITU-T Standardization Eorts for SDN

The IETF has recently begun to extend their speci-cations to support SDN principles [24]. In the IETF,the ForCES (Forwarding and Control Element Separa-tion) project [25] denes a new architecture for net-work devices by specifying a framework [26] and a well-dened communication protocol (using a XML-based for-mal modeling language) to standardize the informationexchange between the control and forwarding plane in aForCES network element (NE) [27]. The ForCES NE fol-lows a master-slave mode in which the forwarding ele-ments (FE) are slaves and the control elements (CE) are

masters.

ForCES physically separates the control and the for-warding plane by breaking the closed box of existing net-work equipment (i.e., routers) and replaces them with twoseparate network elements (FE and CE) each of whichcan connect to existing routers transparently, for examplebased on MPLS LSP (Label Switch Path) [28]. DespiteForCES being a mature standard solution with publishedRFCs and drafts [29, 30, 31, 32, 27, 33], it was not de-ned for SDN, and a limited number of vendor imple-mentations exist. However, it can be used to design a newprotocol in SDN [34].

7

Additionally, since many research and industrial SDNcommunities provided dierent SDN applications, con-trollers and routers, it became hard to inter-operate themwith standardized interfaces. Therefore, the IETF denedthe Interface to the Routing System (I2RS) [35] with twomajor goals. The rst is to standardize network-wide,multilayer topologies that include both virtual and real el-ements, network overlays and underlays. The second is tostandardize the routing information base (RIB) program-ming of a device (virtual or real). Another goal of I2RSwas to program Network Features Virtualization (NFV)service chains. The NFV aims to provide modern pro-grammatic interfaces that oer fast, interactive access andcan easily be manipulated by modern applications andprogramming methods.

Additionally, the Focus Group On Next GenerationNetworks (FGNGN) proposed the concept of Soft-router [36]. Softrouter advocates disaggregating the con-trol and forwarding plane of a router. It separates the con-trol plane processing functions (e.g., routing protocol pro-cessing) from the packet forwarding plane. These func-tions are implemented in outsourced dedicated serversthat communicate with the forwarding elements via spe-cic standard interfaces, i.e., Softrouter protocol.

2.2.5. Object Management Group eorts for SDN

The Object Management Group (OMG) is recentlylooking to provide its own specication to support north-bound SDN ecosystem for middleware and related plat-form [37]. In the OMG, the Software Dened Networking(SDN) Working Group was established to investigate theopportunities for the development of open specication tosupport standard Information Model that represents theobservable and controllable state of SDN network ele-ments.

One of the issues being considered at the OMG on SDNis the use of the Data Distribution Service [38] (DDS) asa mechanism to monitor and congure SDN controllers.The OMG envisions DDS as a transport mechanism usedto carry the OpenFlow commandscongurations as wellas to observe the statestatistics of the SDN switches.

3. Challenges and Opportunities in the Evolution ofSDN Architecture

SDN supports both centralized and distributed con-troller models. Each model has dierent infrastructureelements and requirements to consider. This section de-scribes each SDN model along with a discussion abouttheir advantages and drawbacks. Finally, we introduce thehybrid SDN models which combines the benets of bothapproaches.

3.1. Pros and Cons of the Centralized SDN Model

The centralized SDN model is based on a single cen-tralized controller that manages and supervises the en-tire network. This model is supported by the Open Net-working Foundation (ONF). The network intelligence andstates are logically centralized inside a single decisionpoint. OpenFlow is the ocial protocol for use by the cen-tralized controller to make global management and con-trol operations.

Since only one centralized controller is used to pro-gram the entire network, it must have a global visionabout the load on each switch across the routing path. Itmust also keep track of which ow inside which routerpresents a bottleneck on certain links between the remoteSDN nodes. Additionally, the controller communicateswith OpenFlow switches to collect statistics, errors andfaults from each network device, and sends these datato the management plane. The latter is often a softwarecomposed of a database module and analytic algorithmsthat can detect the switch overloads and predict the futureloads that may occur in the network.

Although the centralized control plane promises a sin-gle point of management and better control over the con-sistency of the network state, it incurs several key limi-tations. First, the controller needs to update OpenFlowswitches more frequently than traditional routers. Thus,the topology discovery produces higher overload becauseall ports must be scanned linearly, which increases the re-sponse time and may impose a higher overload. For ex-ample, the controller may classify ows with dierent pri-orities into multiple classes, where each class requires aspecic QoS setting that should be approved individuallyat setup time for every new ow received by OpenFlowswitches [39]. Such an approach can incur substantial

8

exibility and robustness challenges for large-scale net-works.

Second, the simplicity of the centralized model cancome at the cost of control plane scalability. That is,grouping all the functionalities in a single node requiresmore computation power, data storage and throughputto deliver the trac causing its response time to be de-graded. For example, as the size of data centers andcloud computing networks keeps increasing, neither theover-provisioning mechanisms nor load-balancing solu-tions can solve the scalability problems. Also, with re-spect to the hardware limitations, the switches may im-pose greater scalability bottlenecks and quickly hit real-life limits.

Third, in the centralized model, the rst packet of ev-ery new ow that is introduced in the system must rst beforwarded to a centralized SDN controller for inspection.The controller determines the future path for the ow hop-by-hp and programs the ow entries into every switch onthe path including both the aggregation and core switches.Thus, when a new ow is to be programmed, the con-troller has to contact all the switches in the path, whichis a scalability challenge for large networks and might re-sult in an explosion in the number of forwarding states inthe ow tables if ne-grained ow matching is required.The consequence is extra latency and the possibility ofnetwork failure as the number of new ows programmedincreases. The centralized controller could also representa single point of failure which makes the network highlyvulnerable to disruptions and attacks. Also, the time re-quired by the controller to setup all the properties for theow will add to the latency. Any failure at any step mayresult in instability and convergence problems in the net-work.

Finally, SDN networks are becoming more complexand heterogeneous since they are designed to support ver-satile communication services and provide diverse func-tionalities such as security enforcement, rewall, networkvirtualization, and load balancing. These services need tocoordinate their activities in the control plane to realizecomplicated control objectives and maintain a global vi-sion of the entire network. However, it is hard to tightlycoordinate the control actions and keep the consistencyof network states among distributed functions. For exam-ple, inconsistent routing decisions may be generated frominconsistent topology information collected from rout-

ing protocols, which could create forwarding loops andbroadcast storms in the network, and involve serious per-formance and correctness problems.

3.2. Pros and Cons of the Distributed SDN ModelThe distributed SDN model aims to eliminate the sin-

gle point of failure and enables scale up by sharing theload among several controllers. Distributed SDN controlplanes have been designed to be more responsive to han-dle local network events in data centers, where the con-troller instances share a huge amount of information toensure ne-grained, network-wide consistency. In par-ticular, for multi-domain SDNs with a large variety ofnetwork technologies ranging from high-capacity opticalber to bandwidth-limited wireless links, the distributedSDN architecture is easily able to adapt to the users andapplications requirements. Moreover, a distributed con-troller is more responsive, robust and can react faster andeciently to global event handling.

The research eorts closely related to the distributedSDN model can be classied into three classes. Therst class focuses on improving the performance of spe-cic controllers like Maestro [40] and McNettle [41].These controllers exploit switch-level parallelism to pro-cess ows from dierent switches concurrently. A secondclass of solutions proposes to distribute controllers. Hy-perFlow [42], Onix [43], and Devolved [44] controllerstry to distribute the control plane between dierent net-work partitions while maintaining a logically centralizedcontrol using rendezvous synchronization points betweenlocally selected events, distributed hash table to supportcontroller clustering, or even distributed le system.

A third class of solutions proposes multi layered dis-tributed controllers. Kandoo [45] distinguishes two-layersof hierarchical distributed controllers: (i) bottom-layer,a group of locally non-connected distributed controllers,i.e., each managing one or more switches without anyknowledge of the network-wide state, and (ii) the top-layer, a logically centralized root controller that main-tains the network-wide state. In addition, authors in [46]propose a cluster-based distributed model where a mastercontroller is selected based on the load in the network sothat if the load increases, the master node can be switchedto a less loaded one. Likewise, authors in [47] introduce aSDN Controller Cluster (SCC) composed of multiple con-troller instances interconnected over East-West interfaces.

9

Similarly, [48] describes a controller placement problemto decide the optimal number of controllers needed andtheir placement in a SDN network.

Despite the ability of those solutions to provide a dis-tributed SDN model, several key challenges must be ad-dressed in the future SDN to improve scalability and ro-bustness of networks. First, the above approaches re-quire a consistent network-wide view in all controllers.Also, the mapping between control planes and forward-ing planes must be automated instead of the current staticconguration which can result in uneven load distributionamong the controllers. Second, these approaches cannotobtain a global optimal view of the entire network. Fur-ther, nding an optimal number of distributed controllersthat ensure linear scale up of the SDN network whentheir number increases is hard. Finally, most of theseapproaches use local algorithms to develop coordinationprotocols in which each controller needs to respond onlyto events that take place in its local neighborhood. Thus,there remains the need to synchronize the overall localand distributed events to provide a global picture of thenetwork.

3.3. Opportunities in Evolving towards a Hybrid SDNControl architecture

To address the limitations in each of the approaches de-scribed above, hybrid SDN architectures are being con-sidered. However, a critical challenge stems from deter-mining how much of network abstraction modules can becentralized and eciently designed to support logicallycentralized control tasks, and at the same time providephysically distributed protocols. Consequently, to derivethe advantages of both the centralized and the distributedarchitectures, a hybrid control plane is required to achievesuch coordination. The hybrid SDN model leverages thebenets of the simple control of managing specic dataows as in the centralized model with the scalability andresilience of the distributed model.

It requires several key components to orchestrate thecommunication between SDN controllers. These orches-trators will require standard interfaces, mechanisms, andpolicies to manipulate and interact with the control planesin distributed environments, and support high-availabilityand fault-tolerance capabilities [49].

The hybrid SDN model may be useful in providing an-swers as to what state belongs in distributed protocols,

what state must stay local in switches, and what stateshould be centralized. It could enhance network perfor-mance by enabling ecient resource usage because it willbe possible to adjust more nely and automate each aspectof the network at the application level. Furthermore, thehybrid SDN model could provide management policiesto solve state synchronization, security issues, and enablenetwork optimization in cases of control plane overload.Also, hybrid SDN deployment model could allow trulynon-disruptive migration. It allows upgrading existing in-frastructure without the need to change the overall system.

4. Enhanced Programmability Needs for SDN-basedNetwork Visibility and Management

With the increasing adoption of SDN, monitoring theactivity between the controller and the switch to deter-mine potential future impact, e.g., security vulnerabilities,is becoming more complex and error prone. This sectiondescribes key issues in SDN-based network visibility andmanagement highlighting the challenges in enabling con-sistent SDN models, and provides promising directions tohandle these challenges.

4.1. Network Visibility and Management Challenges withSDN

SDN introduces new management and monitoring ca-pabilities that can improve performance and reduce thebottlenecks in the network. Although SDN monitoringtools can be powerful in small and medium sized net-work topologies, yet debugging, troubleshooting, moni-toring and enforcing security compliance are very di-cult tasks in distributed SDN. OpenFlow makes this evenharder due to the poor choice of the monitoring locationand the statistics that should be output for the OpenFlowSDN session. Diagnosing the network performance andbottlenecks without visibility into the trac characteris-tics introduces new complexity with regard to the consis-tency of the SDN network.

SDN monitoring tools should be able to capture the net-works information and behavior to help in carrying outmanagement decisions. In particular, network congu-ration remains a dicult task in carrier-grade networksbecause administrators are required to grapple with low-level, vendor-specic interfaces to implement high-level

10

functions. Ideally, network operators should be able to en-force various high-level policies, respond to a wide rangeof network events (e.g., intrusions). However, specify-ing high-level policies in terms of distributed, low-levelcongurations remains dicult because SDN provideslittle to no mechanism for automatically responding toevents that may occur. To enable these possibilities, ser-vice providers need programming interfaces to support anevent-driven model to coordinate dierent asynchronousevents associated with their networks.

Several tools for testing OpenFlow networks had beendeveloped to provide monitoring functionality. For exam-ple, ENVI [50] and SAGE [51] can retrieve switch cong-urations, query link utilizations, or even modify a switchsow table to alter routing. Moreover, they provide userinterfaces to supervise the network bottlenecks in case ofcongestion, monitor ow status (e.g., bandwidth, delay,and loss) and computing/networking resources (e.g., net-work I/O, CPU, memory). Despite these capabilities, botheorts incur critical limitations in terms of their real-timeperformance.

4.2. Promising Directions in Network Visibility and Man-agement for SDN

The SDN monitoring tools should provide a proactivecapability that leverages the exibility and programma-bility of SDN to create elastic network monitoring. Theyshould provide high-level, declarative management lan-guages to ensure the consistency of the network statesand detect failures in real-time. These languages shouldimplement a wide range of network policies for dierentmanagement tasks (i.e., QoS, VLAN, network isolation,slicing, etc.) to prevent errors as they arise, indepen-dent of any specic controllers implementation. Thus,existing tools need to be extended to support service-awareness [52] to interactively map the ows onto ser-vices, identify selected ows from all lists of ows(i.e., owspace), and monitor the status of the selectedows [53].

Moreover, the proactive capabilities of the monitoringtools should be able to classify the ows into dierentcategories based on their behaviors and allocate dier-ent ports to each class based on multiple packet match-ing (e.g., IP, TCP port, VLAN, etc.) [54]. Additionally,they should provide individual functional modules to su-pervise the topology discovery either of the entire network

or specic slices. Furthermore, a proactive SDN monitor-ing tool should be able to scale to wide area networks todeal with multiple controllers, alternate ow paths dur-ing troubleshooting, and monitor the ows status such asbandwidth statistics [55].

The expected impact of SDN monitoring tools is to beable to scale to large-scale networks to deal with multiplecontrollers (i.e., in a distributed SDN model). They haveto provide closed control loop functions dedicated to self-conguration, self-optimization, and self-healing. Thecontrol loop diagnostics and decision making processesneed to be adapted automatically, e.g., by predicting thefuture actions based on the results of the previous ones.This proactive capability should leverage the exibilityand programmability of SDN, and improve its eective-ness and eciency, owing to the cognitive processes thatwill enable creating more elastic network management ei-ther for the entire network or specic slices [56].

To further enhance the monitoring eciency, Dy-namic Measurement-Aware (DMR) Routing was intro-duced in [57]. The DMR selects ows based on theirimportance, i.e., big ows are split into several small sub-ows, and the most important ows are routed using aseparate ow table entry. The sub-ows belonging to thesame category can be inspected using Deep Packet In-spection (DPI) box [58]. The DPI can be used to learnand update ows dynamically and send them back to themonitoring tools.

In summary, implementing SDN trac monitoringtools pose a series of challenges. First, there is substan-tial diculty in creating network baselines with dier-ent taxonomies. For example, simplistic approaches tryto describe trac in terms of protocols and port num-bers. Other approaches concentrate on bandwidth uti-lization and network topology to provide a global viewof ows on the network. More advanced monitoring ap-proaches try to classify trac according to the ows im-portance. Additional diculties include nding the righttools which provide visualization at scale. Unfortunately,existing tools that are able to depict dozens or hundredsof nodes, face severe limitations when working with thou-sands or millions of nodes. They also face problems sup-porting multiple strategies, i.e., they suer from topologylocation problem, cannot place instruments in enough lo-cations, and are unable to visualize the network based onobserved trac patterns. Doing this in an automated way

11

would prove extremely useful to network administratorsand defenders. Finally, these tools must operate in anopen SDN and vendor-independent environment, i.e., net-working teams should be willing to consider deployingtheir tools and techniques on open platforms so they candevise and deploy their own network appliances.

5. Routing and Service Convergence using SDN

The value of SDN for service providers with dense andhighly distributed networks lies specically in the abil-ity to provide them more options on locating resourcesthereby conferring a competitive advantage when deliv-ering certain kinds of services. SDN may reduce the pol-icy complexity by enabling scalability in inter-domain andproviding validation for the claims of seamless evolution.

The major challenges for operators in the near fu-ture pertain to providing convergent, dynamic and adap-tive networks in the context of a multi-services, multi-protocols, and multi-technology environment. Also, theyare likely to face other key issues concerning the nec-essary network resources required to deliver dierenti-ated and measurable quality of service (QoS). In this sec-tion we describe the key challenges and open issues inOpenFlow-based SDN for network operators.

5.1. SDN-based Routing AlgorithmsThe design of routing algorithms with OpenFlow can

be performed either using native forwarding or tunnelingmechanisms. With the native OpenFlow forwarding, thecontroller installs ow entries for specic header elds ofthe trac. The selected elds should be unique within theentire network to allow the controller to perform conictresolution and ensure the isolation of the trac. For thetunneling mechanism, the controller should allow routingstrategies by establishing a tunnel between the ingress andthe egress nodes to perform packet encapsulation and de-capsulation. The latter solution eliminates the need forconict resolution and reduces the size of ow table en-tries in the switch. Such a functionality can be imple-mented either with MPLS-TE (i.e., MPLS Trac Engi-neering) or Q-in-Q VLAN (i.e., 802.1Q). It also avoidsthe complex and error-prone process of per-packet veri-cation in favor of creating a globally-consistent policy.Both mechanisms should provide the ability to add andremove an end-to-end path easily.

Using the approach outlined above, SDN should beable to deploy permanent and transient paths based on theinstantiation of the OpenFlow rules. For the permanentpath deployment, OpenFlow rules are injected as perma-nent entries in the ow table. However, this approach lim-its the scalability of the network because the rules willnever be removed, which restricts the deployed ows tothe number of available ow entries.

The transient path deployment allows the injection ofthe ow rules on demand as temporary entries. That is,when a switch cannot nd a ow table entry that matchesan incoming packet, the switch forwards the packet tothe controller to dynamically compute the path onlineand determine the appropriate policy to be applied and in-jected. These operations increase the delay for ow setupbut could improve scalability when combined with a suit-able replacement policy for ow table entries.

5.2. SDN for Coordination between Routing protocolsThe coordination between Interior Gateway Protocols

(IGP), such as RIP2 [59], and Exterior Gateway Proto-cols (EGP), such as BGP [60], is one of the most impor-tant challenges in SDN networks. The limitation of theexisting routing systems arises from their inability to co-ordinate their activities in an autonomous system (AS).For example, the violation of the SLA (Service LevelAgreement) in the network may limit the automatic reac-tion of IGP protocols even if the link characteristics (e.g.,link weight) allow the delivery of the packets because thescope of IGP protocols is limited to ingress routers insidea given AS. The violation of the SLA outside its AS ishidden and cannot be detected. Thus, the outgoing traf-c may increase drastically in the network in the absenceof load balancing and trac management policies in thenetwork.

Traditional approaches, such as the Routing ControlPlatform (RCP) [61], coordinate the inter-domain com-munication and route all the trac on behalf of the BGProuters. Nevertheless, RCP incurs a couple of issues whenchoosing the best forwarding path: (i) it does not providea clear separation between control and data planes; (ii)the enhancement of RCP based on the externalization ofrouting tables inside the hash tables compliant with Open-Flow routing tables [62] helped to improve the conver-gence time of nding the best path selection [63], but itdoes not provide a way to split trac over multiple paths.

12

SDN can provide full coordination within intra-AS andinter-AS by simplifying the forwarding plane and let-ting the SDN controller deal with the routing algorithms.Pushing routing strategies into separate controllers mayenhance trac management and load balancing, and ab-sorb temporary picks in the network. Authors in [64]introduced the CONTRACT framework to dynamicallyadapt routing policies and improve SLA requirements.CONTRACT provides a set of algorithms for SDN routersto coordinate their routing actions. It evaluates routingdecisions against the SLA and performs load balancing,trac policing and ltering as necessary. However, inlarge-scale networks the interconnection of BGP routersshould cope with forwarding loop management, signal-ing, and routing decisions. These tasks may increasethe trac congestion when packets traverse inter-domainmulti-paths.

To cope with SDN congestion issues, we believe thatrouting with SDN should provide the controller with sim-pler and less error-prone policies that allow the best pathselection to deliver SDN packets. For example, in thiscontext the OpenFlow SDN wild-card rules must be re-visited. These rules match on certain packet-header elds(e.g., MAC addresses, IP addresses, and TCP/UDP ports)with a timeout that triggers the switch to delete the ruleafter a xed time interval (i.e., a hard timeout) or a spec-ied period of inactivity (i.e., a soft timeout) to limit theconvergence time of the routing algorithm.

5.3. Multicast CommunicationMulticast communication is another important criterion

for scalable communications. To demonstrate the feasibil-ity of implementing multicast in OpenFlow switches, theauthors in [65] implemented a prototype to demonstratethe feasibility of stateless multicast with Bloom lters.Even if the Bloom controller implements exible multi-cast policies on the ow table entries, it does not provideany approach to manage multicast groups. Likewise, theauthors in [66] extended a SDN controller with a DomainTitle Service Agents (DTSA) to act as a logical bus thatspans the applications and the switches. The DTSA es-tablishes and maintains OpenFlow sessions between endapplications by intercepting incoming messages from thecontroller to modify the ow tables accordingly. Simi-larly, authors in [67] extended OpenFlow to support mul-ticast communication in a data center. They implemented

a Layer 2 (MAC address) SDN controller that encapsu-lates MAC addresses into IP headers and creates virtualtunnels over overlay network between end points. How-ever, tunneling mechanisms require that end-to-end pathmust be xed a priori between source and destinations.

Future SDN networks should address this issue by en-couraging further investigation in facilitating IP multicast.We believe that OpenFlow could provide a promising andexible solution to solve the dynamic group member join-ing/leaving problem in IP multicast supported in overlaynetworks.

5.4. Network Convergence and QoS

With the need for exibility and the ecient coex-istence of multiple services (i.e., telephone, video anddata) within a single switch, enterprises have to copewith a large demand for Quality of Service (QoS), Qual-ity of Experience (QoE), robustness, ease of modica-tion/upgrading, security and privacy [68, 69]. Providersmust be able to create virtual network slices in the samenetwork equipment while simultaneously assuring per-formance and isolation required across dierent servicesto enable application-driven QoS. However, SDN and itsOpenFlow specication do not provide any support fordierentiated QoS.

Recently, some researchers focused on providing QoSsupport for SDN-enabled applications without involvingOpenFlow. For example, [70, 71, 72] introduced theOpenQoS framework to enable route optimization andper-ow granularity management. OpenQoS helps net-work administrators specify the QoS strategy that owsshould follow, and how the controller can allocate the net-work resources and perform service dierentiation. Like-wise, authors in [39] proposed enhancing SDN controllerswith QoS API to provide service dierentiation and ne-grained automated QoS control in networks having mul-tiple slices. Additionally, authors in [73] introduced thePort Control Protocol (PCP) to provide application-drivenQoS. Applications explicitly signal their QoS require-ments to the PCP, which uses the applications meta-datato implement the required QoS into the network equip-ment.

Although these dierent approaches aim to provideQoS mechanisms to support exible and dierentiatedservice management across dierent applications, none

13

of them can automate QoS provisioning in real-time. In-stead, a human in the loop, e.g., a network administra-tor, is required to specify the conguration of each servicebefore the communication begins. This strategy unfortu-nately loses the exibility of network. We believe thatthe integration of session control protocols as a north-bound interface is a promising approach to enable end-to-end QoS signaling among distributed SDN domains.This layer may provide proactive application-driven con-guration of dynamic resource allocation with supportfor authentication and authorization [74]. From this per-spective, the ability to predict the network behavior asa function of the network services to be delivered is ofparamount importance for service providers. This waythey can assess the impact of introducing new services,activating additional network features or enforcing a givenset of (new) policies from both a nancial and technicalstandpoints.

5.5. Shortest Path Forwarding using OpenFlow

Spanning Tree Protocols (STPs) were proposed for dif-ferent controller platforms to ensure loop-free topologiesand to prevent broadcast storms for Ethernet-based net-works, such as data centers and cloud computing. TheNOX Basic Spanning Tree module is an example of a con-troller with built-in STP. In contrast to their ability to pre-vent broadcast radiation, the existence of dierent STPstogether in the same network may introduce several inter-operability problems as they are not able to communicatewith existing L2 forwarding protocols. In particular, thecontrollers lack control of the active topology and topol-ogy recovery after a link failure. Topology discovery isneeded by the STP module to allow removing ows forsubsequent frames after failure. Also, SDN controllerswill suer from suboptimal path calculation, interruptionand long convergence every time topologies change [75].Path re-calculation should be triggered thereby yielding anew active path.

5.6. Inter SDN Domain Communication

SDN is gradually being adopted by carrier-gradeproviders over heterogeneous, multi-technologies (e.g.,WiFi, WiMax, UMTS/3G/4G, satellite, IP/Ethernet/ATM,etc.), and large-scale networks [76]. Each portion of thesenetworks can be seen as independent isolated domains,

typically controlled by a set of SDN controllers acrossmultiple SDN domains, perhaps under the authority ofa single operator or collaborating operators. Intercon-necting isolated SDN domains involves some coordina-tion to dene who will be allowed to manage the entirenetwork, install/update new program on the core infras-tructure, what actions can each program execute, and howthey can be performed within each tier of the network.

One way to match isolated SDN domains can be per-formed through novel SDN-specic protocols. For ex-ample, Inter-SDN domain protocol (SDNi) [77] can beseen as an interface between isolated SDN domains tocoordinate the controllers behaviors. It should enablethem to exchange control information related to topolo-gies, events, energy consumption, and QoS requirementson each domain. Additionally, the SDNi protocol shouldbe able to exchange reachability information and propa-gate the Service Level Agreement (SLA) end-to-end overheterogeneous networks.

However, SDNi still lacks a semantic network model toensure the extensibility of its transport mechanisms andsyntax. We suggest dening new types of message for-mats that may be used inside SDNi to ensure interop-erability across multi-technologies, multi-domain SDNinetworks. We believe SDNi can be implemented as anextension to BGP and SIP signaling to provide policy-based, vertical integration between an overlay-virtual-network technology (including SIP/SBC) and the dataplane. SBCs (Session Border Controllers) may be imple-mented as northbound interface to pool the intelligencefrom the application/session layers within the networklayer. The session management may be integrated withapplication-enabled SDN (A-SDN) provisioning mecha-nisms [73]. The A-SDN enables dynamic and automaticresource provisioning on network switches thereby allow-ing service providers to eectively deal with the surge intrac without resorting to over provisioning of networkstypically required in the past. Ideally, a fully automatedservice is required [78], from negotiation to ordering [79],through delivery assurance and charging should be sup-ported.

6. SDN for Cloud-based Networks

The introduction and deployment of cloud-based ser-vices have emerged as an important solution that oers

14

enterprises a cost-eective business model. However,many network functions have extreme characteristics andperformance requirements, which have created new chal-lenges such as servers and network virtualization, mobileclouds, and security. These need to be addressed withintelligent network virtualization, high-speed packet pro-cessing, and load-balancing. SDN can be seen as a newand complementary technology to virtualization, which ispoised to tackle the challenges of network-enabled cloudand web-scale deployments. In this section we describethe dierent challenges and opportunities in this space.

6.1. SDN Model for Information-Centric NetworkingInformation-Centric Networking (ICN) is receiving

substantial attention in cloud networks because it pro-vides users with data content that is based on naming theinformation instead of the communication channels be-tween hosts. It also introduces new features such as in-network caching or content-based service dierentiation.Yet, ICN still faces a number of challenges in realizing itsfull potential. In particular, a typical deployment of ICNschemes employs dierent transmission techniques andpacket formats that are not interoperable. Also, deployingICN-capable equipment in existing networks is hard, andrequires replacing and/or updating existing operationalnetwork equipment with ICN-aware ones. Moreover, ICNschemes need to ensure the uniqueness of names in thenetwork to handle lookups from large name spaces whichcan be greater than IP address spaces.

SDN oers a promising solution to facilitate the de-ployment of dierent ICN schemes without requiring re-deployment of new ICN capable hardware. The au-thors in [80] propose a unied framework over virtu-alized networks to enable interoperability between dif-ferent ICN architectures. Similarly, the CONET (COn-tent NETwork) framework [81] provides content-centricusers access to remote named resources rather than to re-mote hosts. CONET extensions provide northbound in-terfaces to interconnect ICN nodes to the OpenFlow con-troller [82]. A unied packet format achieves end-to-end connectivity among dierent ICN schemes. Like-wise, the SAIL (Scalable and Adaptive Internet Solutions)project [83] supports the notion of a ash network to en-able dynamic resource provisioning on a time-scale com-parable to existing compute and storage resources. Flashnetwork slices are used to construct and connect scalable

and distributed virtual services across data centers to endusers across the globe.

Despite these solutions not requiring the replacement ofexisting network nodes, they incur several key limitationsrelated to packet fragmentation introduced by their packetformat. In particular, since supporting ICN over SDN re-quires ICN information in each packet, packet fragmenta-tion remains a bottleneck that decreases the performanceof the network. An approach that may resolve this is-sue is to let SDN controllers assign xed-length labels touniquely identify the dierent network paths and allowthem to forward packets based on these path labels [84].

6.2. SDN for Data Centers and CloudThe value of SDN in clouds and data centers lies

specically in its ability to provide new capabilities likenetwork virtualization, automating resource provision-ing, and creating new services on top of the provisionednetwork resources [85]. SDN promises an interactivesolution to implement new capabilities, e.g., to enablecloud applications and services to retrieve network topol-ogy, monitor the underlying network conditions suchas failures, and initiate and adjust network connectiv-ity/tunneling. For instance, FlowN [86] virtualizes the ad-dress space of each application based on the elds in thepacket headers and maps these virtual address spaces tophysical addresses. The FlowN virtualized layer allowsresource isolation and customized control logic for eachtenant running its own controller.

Although data center interconnects allow bypassingthe existing control plane protocols such as STP, yet in-terconnecting heterogeneous data centers to form feder-ated clouds raises a challenging issue for SDN. Some re-searchers have extended the controllers northbound in-terfaces to develop customized real-time forwarding pro-cesses as cloud plug-ins, such as Neutron OpenStack, thatenable virtualized address space and bandwidth isolationfor each virtual link [87]. The northbound interfaces maybe used by third party applications to monitor the SLAviolation and adjust the network resources, if needed.

However, SDN-based virtualization incurs several keychallenges, including the data center performance (e.g.,coping with the increasing memory and processing over-head), slicing (e.g., network partitioning), resource provi-sioning (e.g., operators may over provision network linksto overcome potential network congestion and packet

15

drop within data centers, which makes it unpredictableand costly in many networking scenarios), and QoS man-agement (e.g., many SDN applications require north-bound interfaces to communicate with third party appli-cations, which requires monitoring the SLA violation toadjust the network resource if necessary). Since SDNis part of the network service evolution, we believe thata global solution should be provided to cope with theseissues. Such an architecture may introduce a modulatorSDN layer to orchestrate the communication between theapplications, services and the data center infrastructure asshown by [85].

6.3. Network Function VirtualizationNetwork function virtualization provides a powerful

way to run multiple concurrent virtual networks over ashared substrate. Cloud providers can oer virtual net-works with a topology and a conguration customized tothe users needs. With a growing dependence on the net-work conguration, we argue that the ability to migratethe entire network would enable important new capabili-ties such as simplifying network resource allocation. Suchan approach has motivated a novel business model calledNetworking-as-a-Service (NaaS) to enable customers toaccess virtualized network functions. For example, virtu-alized home gateways can be implemented as virtualizedfunctions inside virtual machines in the cloud. Users canaccess the most recent versions without the need to up-grade the content by themselves.

As network functions are deployed in virtual ma-chines, cloud operators may upgrade their infrastructureby adding new racks, installing new virtual machines oreven deleting and migrating existing ones [88]. Networkmigration can also be applied to create green networks be-cause virtual networks can be placed on dierent physicalrouters according to the trac demand to reduce energyconsumption. Moreover, factors such as server consolida-tion, load balancing, and security enforcement are drivingmost experiments with virtual network migration. For ex-ample, a link shared by dierent virtual networks couldbe jammed because of a DDoS attack to one of the virtualnetworks. In such a case, the non compromised networkscould be migrated to dierent physical routers until theattack is resolved.

Often there are unintended consequences from virtualnetwork migration that directly aect the physical un-

derlying network. SDN controllers may stop an arbi-trary number of applications during the migration opera-tions, which could have signicant performance degrada-tion and high bandwidth costs to redirect trac to othervirtual network slices. Furthermore, the network mayhave a large amount of state collected from a set of dis-tributed SDN switches that should be kept consistent toavoid outages, transient loops, and violation of SLAs dur-ing the migration process. Meanwhile, controllers shouldmaintain connectivity and forward path re-routing with-out interruption. As such, the centralized SDN model isa single point of failure and not suitable to guarantee theconsistency of the network states. It does not reduce thedowntime and packet loss during the migration of networkfunctions between virtual machines [89].

Migrating network functions requires a real-timescheduling model that can prevent failures caused by con-gestion and bandwidth violation. Such a model is per-ceived to be NP-hard and not guaranteed all the time [90].In resolving these issues, there is a need to rethinkthe mapping of virtual slice requirements throughout acommunication matrix onto the physical infrastructureas introduced by CloudNaaS controller framework [91].The controller uses a placement optimizer to choose thebest virtual network placement and dynamic provision-ing model to reallocate resources based on their avail-ability. We believe that a self-service provisioning modelprovided by the cloud can provide a rich set of networkservices such as seamless network isolation, customizednetwork addressing as well as service dierentiation.

Another possible direction to enhance virtual networkmigration can be achieved by synchronizing networkstates among distributed switches and create overlay tun-nels to relay trac between network slices [92]. How-ever, this approach requires an additional proxy layer tocreate synchronization points for redundancy and stateduplication. We believe that more advanced algorithmsfor scheduling virtual network migration need to be ex-plored to leverage technologies like redundancy elimina-tion, and reduce the overhead of copying the state for mul-tiple slices. The NetGraph [93] framework is an examplethat supports incremental algorithms with practical com-putation time and memory requirements.

16

7. SDN in Wireless and Mobility Settings

Software Dened Wireless Networking (SDWN) is aSDN technology for wireless that provides radio resourceand mobility management, routing, and multi homing.SDWN can provide a programmable wireless data planeto allow modular and declarative programming inter-faces across the wireless stack. It also enables refac-toring wireless protocols into processing and decisionplanes [9] as introduced by the OpenWRT [94] and In-digo [95] rmware. This decoupling allows programmingthe enterprise-specic requirements (e.g., an airport, arestaurant, public library) in a wireless access point (AP).This section describes the key challenges in SDWN.

7.1. Mobility and Multi homing Management with SDN

By 2020 it is predicted that there will be thousand timesmore connected mobile devices than today with dierentQoS requirements, which will interconnect to all kindsof heterogeneous and customized Internet-based servicesand applications. Accordingly, these developments de-mand a rethinking of the network design, which in turnrequires us to understand the implications of using SDNin the most common wireless networking scenarios. It isalso important to understand the key challenges that existin this realm and how they can be addressed.

IP mobility support has been specied in traditionalIPv4 and IPv6 networks, but presently there is not muchdiscussion regarding mobility support in SDN. Thus,SDWN should provide radio resource management, mo-bility management and routing [96]. It should includenovel mobility management mechanisms to maintain ses-sion continuity from the applications perspective. Inparticular, hando management is a challenging issue insupporting SDN mobility because mobile terminals moverapidly between virtualized APs. Thus, SDWN shouldprovide network connectivity through dynamic channelconguration.

The authors in [10] introduced the concept of slicingthe wireless infrastructure into logical virtualized parti-tions, each managed by virtual APs. Similarly, the ef-fort described in [8] introduced the Odin framework asa mobile agent that communicates with SDN controllersto keep a global view of ows in the network. It dele-gates the handomanagement to a virtual AP that invokesthe physical AP to manage the mobility and maintain host

reachability with respect to the receiver signal. Althoughthese approaches help to simplify the mobility manage-ment, SDN mobility functions must be enhanced to pro-vide rapid client re-association, load balancing, and pol-icy management such as charging, QoS, authentication,and authorization.

Another key challenge in wireless/broadband networksconcerns multi homing[97]. Multi homing implies the at-tachment of an end-host to multiple networks at the sametime so users can freely move between wireless infrastruc-tures. This approach can be realized by applying SDNcapabilities to the relay between the home network andedge networks. For example, within home networks, avirtualized residential gateway can improve service de-livery between the core home network and the network-enabled devices [98]. The target architecture (i.e., virtu-alized residential gateway) is realized by applying SDNand NFV between the home gateway and the access net-work, and moving most of the gateway functionality to avirtualized execution environment. Since the virtualizedresidential gateway is cloud-based, it forms the core of ausers home network by connecting their network-enableddevices while beneting from broadband Internet servicessuch as connection sharing, Firewall security, VPN con-nectivity, IP telephony, audio/video streaming, WirelessLAN connectivity, etc.

Another important key challenge in wireless SDN isrelated to routing packets in Wireless Mesh Networks(WMNs). A WMN is a multihop wireless ad-hoc networkin which stationary wireless mesh routers relay trac onbehalf of other mesh routers or client stations to form awireless backbone [99]. The primary advantages of wire-less ad-hoc networks lie in their ability to provide highfault tolerant communication even when a large number ofnodes fail, simplicity of conguring wireless nodes, andtheir capacity to provide broadband connectivity. Thesenetworks require dynamic routing algorithms to cope withthe limitations of wireless channels such as fading, inter-ference, and broadcast [100].

SDN can partially solve these challenges by enablingprogrammability of the network [101]. For example, theauthors in [102] introduced SDN-based CloudMAC ar-chitecture to enhance the recongurability and the exi-bility of wireless ad-hoc networks. CloudMAC helps toimprove the wireless connectivity through seamless APswitching, which provides fast packet processing and re-

17

duced packet loss. However, several key issues of WMNsremain unresolved [103]. In particular, the topology ofad-hoc wireless networks changes at a much higher pacethan in wired networks due the variation in link qualityand node movement. Additionally, wireless nodes mayjoin and leave the network at any time so any SDN-basedrouting protocol must provide autonomous topology dis-covery as well as adaptive neighbor discovery to reactswiftly to changes in the network [104].

7.2. SDN for Mobile CloudMobile cloud computing is one of the technologies that

are converging into a rapidly growing eld of mobile andwireless network. It provides an excellent backend forapplications on mobile devices giving access to resourcessuch as storage and computing power, which are limitedin the mobile device itself. The close interaction withthe cloud may create an environment in which mobiledevices appear attached locally to the cloud with low la-tency [105]. Both SDN and NFV can extend wireless ac-cess infrastructure to cloud computing and enable logicalslicing of resources to multiple devices. SDN promisesan attractive solution to implement new capabilities tocloud applications and services. It can help to retrievenetwork topology, monitor the underlying network condi-tions (e.g., failures), initiate and adjust network connec-tivity and support tunneling.

Additionally, given the dynamic needs and supply ofthe network resources due to the rich set of resourcesavailable in the cloud, mobile users can benet from re-source virtualization to accommodate dierent require-ments of their mobile terminals moving within the mobilecloud. Weaving dierent wireless access technologies to-gether in a uid fashion and creating smart gateways inthe cloud in a transparent manner is important to realizethe full potential of mobile clouds. To this end, virtualizedaccess networks should support ne-grained isolation perperson or per application for each device in the cloud.

Despite SDN having some advantages, such as resourcesharing and session management, it incurs several limita-tions in the context of mobile clouds. In particular, sincemobile users can repeatedly trigger the embedded con-troller for marshalling and unmarshalling of ow rules(e.g., in OpenFlow messages), the overhead increasesmore signicantly because of the limited computing capa-bilities and resources of mobile devices (i.e., extra mem-

ory consumption and extra latency). For example, mobileinteractive applications (e.g., mobile gaming, virtual vis-its) require reliable connectivity to the cloud as well aslow latency and impose higher bandwidth requirementsfrom wireless access networks to cloud service.

Furthermore, mobile users move frequently betweenmultiple access networks, using either the same or dif-ferent mobile terminals, but often with a unique persona.In general, it is dicult to realize a Mobile Personal Grid(MPG), which requires maintaining seamless connectiv-ity of a set of devices that belong to a particular individualto a remote public and private cloud. Maintaining seam-less wireless connectivity for the MPG introduces mul-tidimensional challenges including the need to deal withdynamic mobility management across heterogenous net-works, power saving, resource availability, uctuating op-erating conditions, and limitations on the movement ofcontent across multiple devices and the cloud [105].

Addressing these limitations simultaneously may in-crease device complexity, degrade the network perfor-mance, and cause connectivity problems. The key chal-lenge for mobile clouds lies in transforming physical ac-cess networks to multiple virtual and isolated networkswhile maintaining and managing seamless connectivity.Virtualized switch functions such as those provided byOpenVSwitch may enable controllers to connect to a spe-cic virtual partition with autonomic reconguration andlossless connectivity. The virtualization of mobile proto-col stacks could abstract mobile resources to accommo-date their dierent requirements. We argue that a closeinteraction with the cloud may help achieve the multi-dimensional mobility requirements [105] and relieve thenetwork infrastructure from complex network tasks (e.g.,conguration, trac analysis) to the cloud [106].

7.3. SDN for WPANSince SDN promises to reduce the complexity of the

conguration and management of networks, its function-ality can also be applied to many wireless infrastructurenetworks such as the Low-Rate Wireless Personal AreaNetworks (LR-WPANs). Extending SDN to LR-WPANwas considered impractical because these networks arehighly constrained. LR-WPAN requires numerous low-cost nodes communicating over multiple hops to cover alarge geographical area. These nodes require duty cyclesto provide low energy consumption to operate for multi

18

year lifetimes on batteries with modest lifetimes. Theyalso require small software footprint due their limitedamount of memory storage and CPU processing speeds.

Additionally, to enable SDN for LR-WPANs, severalchallenges must be resolved to provide cross-layer op-timization [107] as well as data aggregation. We arguethat future SDN controllers should provide an appropriatemodule to dene the rules that consider specic match-ing elds for LR-WPAN environment [108]. These rulesmay route packets based on their specic values includedwithin the payload they carry. For example, packets mayinclude a specic value of temperature sensors that exceeda given threshold. SDN controllers will need to conguremultipath routing algorithms to route LR-WPAN pack-ets based on multilevel thresholds. Moreover, controllersmust address several key problems related to node mobil-ity, topology discovery, self-conguration as well as self-organization [109]. They should also deal with link un-reliability, and robustness to the failure of generic nodesand the control node [110].

7.4. SDN for Cellular networksThe growing demand and the diverse patterns of mo-

bile trac place an increasing strain on cellular networks.The best way to increase per-user capacity is to make cellssmall and bring the base station closer to the mobile client.SDN may provide rapid response to mobile terminals andavoid disruptions in the service across dierent technolo-gies. However, supporting an increasing number of sub-scribers with frequent changes in user location incurs se-rious issues [111]. Cellular network infrastructures mustredirect users data to load balancing servers to accom-modate changing network conditions and handle trac inreal-time with specic QoS priority [8]. Presently, cel-lular systems have a single direct link between the basestation and the terminal. However, multihop networks re-quire maintaining multilink between multiple transmitterand receiver to form multipath communication the socalled multihop cooperative network. Compared to ex-isting technology, which include mechanisms for retrans-mission and multiple acknowledgments, multihop coop-erative networks can overcome these limitations by pro-viding high density access networks. However, they oftensuer throughput penalties since they operate in a half du-plex mode and therefore introduce insuciency of spec-trum usage.

To increase the capacity of cellular systems, SDN canprovide solutions to overcome the limitations of multihopwireless networks. Cellular SDN networks (or briey,CellSDN) [112] could maintain a Subscriber InformationBase (SIB) to translate a subscribers attributes into theswitch rules to set up and recongure services exibly.To this end, ner grained control of trac in CellSDNmust be adapted to cellular infrastructures to handle noti-cations from the users terminals. The authors in [113]introduce a Deep Packet Inspection (DPI) engine to en-able ner grained classication at the application layer.Section 4 described the use of DPI in monitoring tools,whereas here it is used for routing ows across multi-channel cellular networks. Application level control couldthen provide exible and ne-grained control of the usersdata and analyze packet contents to identify malicioustrac. Despite these possibilities, CellSDN requires spe-cic SDN protocols to orchestrate the remote virtualizedresources [114]. Moreover, these protocols must enablenetwork slicing, trac engineering, minimizing delaysand reduction in packet loss [115].

In cellular communications, an architecture based onSDN techniques may give operators greater freedomto balance operational parameters, such as network re-silience, service performance and QoE. CellSDN con-trollers may implement Radio Resource Management(RRM) protocol [116] as northbound interfaces to sim-plify the QoS provisioning. Similarly, CellSDN routerscould support techniques like header compression and de-compression to reduce the overhead with small packetpayloads on low bandwidth links. Another importantchallenge in CellSDN is designing the architecture of thenetwork. Traditionally, CellSDN was designed with cen-tralized control and data structures in mind to improve itsperformance. Centralized SDN model in CellSDN resultsin a single point of failure. Thus, when the cellular in-frastructure fails, the entire network will be unavailable.Hence, a rethinking of architecting CellSDN using a dis-tributed SDN model is needed.

Distributed CellSDN could provide high-performance,cost-eective and distributed mobility management [117]in CellSDN. We believe that a distributed SDN modelcould also provide multiple parallel virtualized transmis-sion channels to support the increasing number of mobileterminals requesting the network resources [114]. As forxed network virtualization, there is a need to reconsider

19

the issue of isolating trac into multiple wireless slices,where each slice could support a specic trac pattern.Such an approach may help to create virtual base sta-tions and orchestrate the available resources among dif-ferent mobile devices, thereby saving power and memoryusage.

8. Challenges and Opportunities for Security in SDN

Security in SDN networks poses signicant challengesbecause its programmable aspect presents a complex setof problems to cope with [118]. It is expected that theincreasing number of DDoS and malware attacks, spam,and phishing activities will change the dynamics aroundsecuring SDN infrastructures. In this context, mobilewireless networks are more vulnerable than xed wirednetworks since broadcast wireless channels easily allowmessage eavesdropping and injection (i.e., vulnerabilityof channels). Moreover, mobile ad-hoc networks in-cur more complex security challenges due to their lackof infrastructure (e.g., security servers), which rendersclassical security solutions infeasible. Traditional secu-rity approaches require downtime to orchestrate topologychanges while the network is recongured, new securityconguration is inserted, and multiple security servicesare turned on and debugged.

8.1. Security Challenges in SDNSecurity is minimally specied in SDN; thus the Open-

Flow specication does not describe the certicate for-mat to ensure data integrity. SDN security will requiremore sophisticated encryption and authentication mech-anisms to prevent hackers and to recover packets fromfailure. For example, multiple controllers may mutuallyauthenticate each other by exchanging certicates signedby third party private keys. The dierence between thesekeys, however, raises unexpected security vulnerabilitiesin the entire network. Thus, the controllers may be unableto interoperate with each other since they have dierentkeys. The OpenFlow specication recommends using aplain TCP connection for the secure channel but gives noindication about what sort of alternatives can be used tothat end. Optionally, TLS sessions can be used to provideencrypted and secure channels in both directions to pre-vent eavesdropping but without details about the interop-erable version that could be used. The specication makes

no mention about how a secure connection can be estab-lished nor how the certicate can be checked between thecontrollers and the switches. Security issues also stemfrom the diversity in network congurations. The securitymechanisms dened by the specication are ill-suited toprotect the network against eavesdropping and controllerimpersonation.

In developing solutions to address the myriad of secu-rity challenges in SDNs, we need to cope with one pri-mary challenging issue: managing the trade-os betweenthe network security and performance.

8.2. Opportunities for Addressing Security Concerns inSDNs

A promising approach to address the dierent securityproblems in SDN involves developing security policieswith a unied syntax for the OpenFlow protocol. Thesepolicies should enable authentication, authorization, ac-cess control, and secure transport between applicationsand SDN controllers, or even between multiple controllersand a set of switches. These policies can be dened viathe Security Assertion Markup Language (SAML) to ex-change public/private keys as part of the OpenFlow poli-cies, e.g., within condential OpenFlow messages thatmay be transported using the Datagram Transport LayerSecurity (DTLS) protocol.

Supporting intrusion detection is a crucial part of a se-cure SDN framework. A promising approach is to pro-vide an Intrusion Prevention System (IPS) based on theopen source SNORT project [119]. In particular, Open-Flow security algorithms should provide role-based au-thentication to check for contradictions in ow rules whenapplications attempt to insert disallowed ow rules. Itmay be possible to add customized security services intothe network, either on a per-ow basis or per-group ofow [120]. Another approach to resolving the mobileSDN security challenges could consider separating thesefunctions or outsource them to a third party server, as de-scribed in the OpenWiFi project [121].

Yet another promising approach involves inserting dif-ferent security policies in the OpenFlow protocol usingL4 to L7 services, such as URL ltering between an end-point, rejecting ows toward a specic destination, redi-recting HTTP and HTTPS trac using a proxy, rewall,etc. Extending the OpenFlow matching rules to incor-porate new security rules using dierent elds, such as

20

wild-cards, physical/virtual ports and IP addresses is an-other possibility. However, exposing IP addresses to net-work attacks may hand the adversaries signicant advan-tage to remotely scan networks and identify their targetsaccurately and quickly. The authors in [122] introduced atechnique called OpenFlow Random Host Mutation (OF-RHM) to hide real IP addresses from external attacks.They assign virtual IP addresses to hosts so that they canbe reached only by authorized entities.

9. Conclusions

Most researchers argue that the current Internet ar-chitecture is inadequate and has reached a tipping pointwhere most of the time and eort is spent addressing ex-isting aws rather than developing new ideas. To addressthe challenge of ossication of the Internet, researchershave started to focus on redesigning the overall architec-ture by breaking the tight integration of the forwardingand control plane implementations. As a result, majorresearch projects focus on the SDN architecture to con-struct and present a logically centralized map of the net-work. The next-generation of SDN networks will benetnot only from the simplicity of the implementation, butalso from the fact that maintaining and updating applica-tions will be easier as well.

In this pape