software-defined networking: challenges and research ...wiki.occc.ir/images/sdn7.pdf · 2.1. sdn...

1

2

4

5

6

7

8 Q1

9

101112

5253

54

55

56

Q2Q1

Computer Networks xxx (2014) xxx–xxx

COMPNW 5414 No. of Pages 20, Model 3G

24 October 2014

Q1

Contents lists available at ScienceDirect

Computer Networks

journal homepage: www.elsevier .com/ locate/comnet

Survey Paper

Software-Defined Networking: Challenges and researchopportunities for Future Internet

http://dx.doi.org/10.1016/j.comnet.2014.10.0151389-1286/� 2014 Published by Elsevier B.V.

⇑ Corresponding author at: CNRS, LAAS, 7 avenue du colonel Roche,F-31400 Toulouse, France.

E-mail addresses: [email protected] (A. Hakiri), [email protected](A. Gokhale), [email protected] (P. Berthou), [email protected](D.C. Schmidt), [email protected] (T. Gayraud).

Please cite this article in press as: A. Hakiri et al., Software-Defined Networking: Challenges and research opportunities for Future InComput. Netw. (2014), http://dx.doi.org/10.1016/j.comnet.2014.10.015

Akram Hakiri a,b,⇑, Aniruddha Gokhale c, Pascal Berthou a,b, Douglas C. Schmidt c,Thierry Gayraud a,b

a CNRS, LAAS, 7 avenue du colonel Roche, F-31400 Toulouse, Franceb Univ de Toulouse, UPS, LAAS, F-31400 Toulouse, Francec Institute for Software Integrated Systems, Dept of EECS, Vanderbilt University, Nashville, TN 37212, USA

a r t i c l e i n f o a b s t r a c t

30313233343536373839404142

Article history:Received 25 April 2013Received in revised form 12 October 2014Accepted 13 October 2014Available online xxxx

Keywords:Future InternetSoftware-Defined Networking (SDN)OpenFlowNetwork function virtualizationForwarding planeControl plane

4344454647484950

Currently many aspects of the classical architecture of the Internet are etched in stone – aso called ossification of the Internet – which has led to major obstacles in IPv6 deploymentand difficulty in using IP multicast services. Yet, there exist many reasons to extend theInternet, e.g., for improving intra-domain and inter-domain routing for high availabilityof the network, providing end-to-end connectivity for users, and allowing dynamic QoSmanagement of network resources for new applications, such as data center, cloud com-puting, and network virtualization. To address these requirements, the next-generationarchitecture for the Future Internet has introduced the concept of Software-Defined Net-working (SDN). At the core of this emerging paradigm is the separation and centralizationof the control plane from the forwarding elements in the network as opposed to the distrib-uted control plane of existing networks. This decoupling allows deployment of controlplane software components (e.g., OpenFlow controller) on computer platforms that aremuch more powerful than traditional network equipment (e.g., switches/routers) whileprotecting the data and intellectual property of the vendors of such equipment.

A critical understanding of this emerging paradigm is necessary to address the multiplechallenges in realizing the Future Internet and to resolve the ossification problem of theexisting Internet. To address these requirements, this paper surveys existing technologiesand the wide range of recent and state-of-the-art projects on SDN followed by an in-depthdiscussion of the major challenges in this area.

� 2014 Published by Elsevier B.V.

51

57
1. Introduction delivered by the new services and modalities (e.g., mobile 58
59

60

61

62

1.1. The need for a new network architecture

The capacity of the current Internet is rapidly becominginsufficient to cater to the large volumes of traffic patterns

63

64

65

66

67

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 staticEthernet switches arranged in a tree structure are ill-suitedfor the dynamic computing and storage needs of today’sand future enterprise hyper-scale data centers, campuses,and carrier environments. Instead, new networking infra-structures are desired that will provide high performance,energy efficiency, and reliability. Moreover, they should

ternet,

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

mailto:[email protected]






http://www.sciencedirect.com/science/journal/13891286

http://www.elsevier.com/locate/comnet


127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

Net App 2 Net App nNet App 1

Network Abstrac�on (e.g., topology abstrac�on , QoS)

Global Network View

Open Northbound APIs

Abstract Network View

Con

trol P

lane

Dat

a Pl

ane

Network Opera�ng System (SDN Controller)

Open Southbound APIs (e.g., OpenFlow)

OpenFlow Router

Fig. 1. Simplified view of an SDN architecture.

2 A. HakiriQ1 et al. / Computer Networks xxx (2014) xxx–xxx


24 October 2014

Q1

improve the network speedup, scalability and robustnesswith the effective creation and delivery of versatile digitalservices that provide stringent quality of service (QoS)guarantees. Meeting these requirements is impossible withexisting network equipment due to their limited capabili-ties. Additionally, today’s protocols tend to be defined inisolation and are meant to solve a specific problem withoutthe benefit of any fundamental abstractions.

In addition, to implement network-wide policies and tosupport any new services, managers today have to config-ure thousands of network devices and protocols, whichmakes it difficult to apply a consistent set of QoS, security,and other policies. Networks become vastly more complexwith the addition of thousands of network devices thatmust be configured and managed. These devices have theircontrol and forwarding logic parts both integrated inmonolithic, closed, and mainframe-like boxes. Conse-quently, only a small number of external interfaces arestandardized (e.g., packet forwarding) but all of their inter-nal flexibility is hidden. The internals differ from vendor tovendor, with no open software platform to experimentwith 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 forwardingand control planes of the routers to dynamically associateforwarding elements and control elements.

1.2. Software-defined networking

Software-Defined Networking (SDN) [3,4] has emergedas the network architecture where the control plane logicis decoupled from the forwarding plane. SDN is a newapproach for network programmability, which refers tothe ability to control, change, and manage network behav-ior dynamically through software via open interfaces incontrast to relying on closed boxes and proprietary definedinterfaces. The SDN framework enables centralized controlof data path elements independently of the network tech-nology used to connect these devices that can originatefrom different vendors. The centralized control embedsall the intelligence and maintains a network-wide viewof the data path elements and links that connect them. Thiscentralized up-to-date view makes the controller suitableto perform network management functions while allowingeasy modifications to the networking functions throughthe centralized control plane.

Fig. 1 depicts the SDN architecture illustrating the sep-aration between the applications, control plane and dataplane. Applications use the northbound API supported bythe control plane to enforce their policies in the data planewithout directly interacting with the data plane. The inter-face between the control and data plane is supported bysouthbound APIs, where a SDN controller will use theseAPIs to communicate with the network equipments inthe data plane. These equipments are required to supportthe standardized APIs at this level.

SDN makes it possible to manage the entire networkthrough an intelligent orchestration and provisioning

Please cite this article in press as: A. Hakiri et al., Software-Defined NetwComput. Netw. (2014), http://dx.doi.org/10.1016/j.comnet.2014.10.015

system that enables on-demand resource allocation, self-service provisioning, truly virtualized networking, andsecure cloud services. Thus, the static network can evolveinto an extensible vendor-independent service deliveryplatform capable of responding rapidly to changing busi-ness, end-user, and market needs, which greatly simplifiesthe 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 OpenFlow(OF) [5,6]. OpenFlow aims to allow providers to reengineertheir traffic to test out new protocols in existing networkswithout disrupting production applications. The key ele-ments of this technology consists of three parts: (i) flowtables installed in OpenFlow-aware switches, (ii) a control-ler installed in a remote host machine, and (iii) an Open-Flow protocol for the controller to talk securely withswitches. The OpenFlow approach of splitting the controllogic from the forwarding behavior provides a flexiblecapability for on-the-fly 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 defining the FutureInternet. The rest of the paper is organized as follows: Sec-tion 2 outlines the key use cases of SDN and standardiza-tion efforts, which help to understand the realm of SDNand the spectrum of avenues for research and standardiza-tion; Sections 3, 5, 6, 7, 8 outline the key areas where more

orking: Challenges and research opportunities for Future Internet,


210

Applications and Eco-system IntegrationPlug-ins Applications

A. HakiriQ1 et al. / Computer Networks xxx (2014) xxx–xxx 3


24 October 2014

Q1

SDN research is needed to solve a number of unresolvedchallenges. Finally, Section 9 provides concluding remarks.

Virtual MachinesOpenStack Analytics App1 AppNApp2 ….

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

Fig. 2. The use of OpenFlow for cloud and data-center.

2. SDN Use cases and standardization efforts

This section highlights the important use cases of SDNand current standardization activities. The goal of this sec-tion 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 significanttransformation of their network infrastructure to supportboth current and future business models of SDN. Thistransformation offers a means to reduce the costs of ser-vice delivery and increase the service velocity using SDNtechnologies. In this section we present a number of SDNuse cases.

2.1.1. Data Center interconnects use caseModern data centers are composed of tens of thousands

of resources (e.g., processors, memory, storage, high-speednetwork interfaces), which in turn are packaged into racksand allocated as clusters consisting of thousands of hoststhat are tightly connected with a high bandwidth network.These clusters are orchestrated to exploit thread-level par-allelism to handle many Internet-based workloads. Thetraffic in the data center networks often exhibits burstybehavior where a large number of packets get injected inthe network over a short time, which in turn induces atransient load imbalance that can affect other flows, andthereby significantly degrade the performance of the entirenetwork [7].

The value of SDN in a data center interconnect lies spe-cifically in its ability to provide network virtualization,abstraction and automation. In Fig. 2, a centralized Open-Flow controller is used to provide dynamic traffic steeringbetween applications that can be located in virtualmachines or physical computers in data centers. Thoseapplications use RESTful programming interfaces to exposetheir requirements to the underlying network over large-scale networks. The RESTful APIs enable them to performa wide range of advanced network operations, such astopology discovery, QoS allocation, and load balancing.They also enable flexible network management with deter-ministic behavior by eliminating the need for resource overprovisioning. Moreover, SDN-compliant third party toolscan be easily plugged into data centers to perform fasterrecovery from link and node failures. That is, the OpenFlowcontroller reflects a unified view of the data center andsimplifies the control of the entire network.

2.1.2. Network slicing use caseNetwork slicing is a mechanism to divide the available

network infrastructure into different partitions to allowmultiple instances to coexist. Each slice controls its ownpacket forwarding without interfering with other sliceseven if they share the same underlying physical network.


Fig. 3 shows a multi tenant infrastructure connectedthrough OpenFlow switches over a virtual overlay networkto provide private or even public cloud services. This usecase shows how slicing the network resources into multi-ple partitions provides tenants access to their virtual L2slices without interfering with others. The SDN controllercan achieve policy-based network management and flexi-ble resource allocation, and at the same time can continueto support per-tenant/per-slice instantiation. This meansthat the controller can honor its rule to provide robustness,stability and scalability in terms of number of tenants, sup-port for concurrent experiments and number of managedresources.

2.1.3. Wireless settings use caseWireless networks require specific features like mobil-

ity management, dynamic channel configuration, and rapidclient re-association. As depicted in Fig. 4, the value of SDNin wireless networks lies specifically in its ability to pro-vide new capabilities, such as network slicing, and the cre-ation of new services on top of the virtualized resources insecure and isolated networks.

In Fig. 4 Flowvisor and OpenVirteX are OpenFlow-basedproxy layers that allow creating slices based on multipleparameters such as bandwidth, flow-space (src/dst MAC,src/dst IP, and src/dst TCP ports), and CPU switch load. Eachslice is independent, e.g., traffic from Alice’s mobile appli-cation does not alter Bob’s and Alex’s traffic in the otherslices. Moreover, wireless virtualization enables the migra-tion of the switch configuration that manages Alice’s appli-cation to another device seamlessly without disrupting theactive network traffic of Bob and Alex. Such a configurationwas introduced by the Odin framework [8], which is a pro-grammable wireless data plane with modular and declara-tive programming interfaces across the wireless stack. Thisdecoupling provides virtual access point abstractions tosimplify network management for a wide range of enter-prise requirements (e.g., an airport, a restaurant, publiclibrary) [9].

Additionally, one of the most interesting complemen-tary technologies that can benefit from SDN are smart



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

Fig. 3. OpenFlow network slicing use case.

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

Fig. 4. Wireless OpenFlow infrastructure.



24 October 2014

Q1

home gateways, which aim to interconnect residentialhome-gateway to their network providers. It also offersseamless and mobile connectivity without compromisingsecurity. For example, [10] introduced a Virtual Home-gateway Control (VHC) to improve seamless mobility, ser-vice delivery and home energy management.

2.1.4. Network traffic engineering use caseTraffic Engineering is a soft method for optimizing the

performance of the ISP networks. It offers IP-based L2 orL3 enterprise VPN services and enables transmitting trafficto non IP networks like ATM and frame relay networks.Network providers use traffic engineering to support hightransmission capacity and resilient communication bydynamically analyzing, predicting and regulating thebehavior of the transmitted data. In traditional networks,some protocols such as OSPF and BGP allow the nodes toshare their control information between their immediateneighbors and in a limited way to avoid network conges-tion. This means that there is no global view of the network


available. If the users need to control or modify a particularpath for a particular flow, the administrator has to testwith parameters and priorities to achieve the expectedbehavior of the network. Each modification in the networkpolicy requires individual configuration directly or remo-tely from each device.

The added value of SDN is to provide flexible and pro-grammable network devices to optimize and enable fine-grained control to different customers flow data withrespect to the services they provide.

Fig. 5 shows how a centralized SDN controller can man-age three different traffic streams (HTTP traffic, VoIP, andVoD) over different underlying network technologies. Forexample, at the Toulouse access network, the user applica-tions send their data through an OpenFlow-enabled routerto the Bern network through the core network, which canbe a circuit-based ATM technology. The centralized con-troller is able to control, manage and supervise the overallnetwork equipment in the path between end-users. It per-forms traffic engineering with common control over packetand circuit networks using OpenFlow as a multi-layer Uni-fied Control Plane (UCP). Thus, instead of using traditionaldistributed routing protocols like BGP, the centralized con-troller installs all routing decisions in the network equip-ment without using the traditional full-mesh of packetlinks[11], thereby enhancing the network flexibility andthe scalability. Further, the controller can support applica-tion-specified routing as well as traffic aggregation basedon 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-basedinfrastructures have gained tremendous momentum inthe industry and research community in recent years. Inthis section, we briefly discuss the standardization trendsin SDNOpenFlow.

2.2.1. Clean slate design initiativeThe Internet has evolved to this day based on incremen-

tal changes to the protocols and by retrofitting the



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

Fig. 5. Traffic engineering with OpenFlow-based SDN.



24 October 2014

Q1

architecture to solve the current problems. However, it hasnot been possible to introduce any major changes to thedeployed 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 ossification of the Internet [12].

A new architectural design called the Clean Slate Design[13] considered how the Internet could be redesigned froma ‘‘clean slate’’ without being restrained by the accumu-lated complexity of the incremental approaches. Theresearch funding agencies all over the world are support-ing the world-wide efforts to develop the next generationInternet [14].

The United States National Science Foundation (NSF)was among the first to announce the GENI (Global Environ-ment for Networking Innovations) [15] program for devel-oping and testing new Internet architectural designs aspart of its FIND (Future Internet Design) program. Thiseffort was followed by the FIRE (Future Internet Researchand Experimentation) [16] program, the OFELIA (OpenFlowin Europe: Linking Infrastructure and Applications) pro-gram [17,18], and the SPARC (Split Architecture CarrierGrade Networks) program [19] to support numerous nextgeneration networking projects under the 7th FrameworkProgram of the European Union, the AKARI ArchitectureDesign Project [20] and the RISE (Research Infrastructurefor large-Scale network Experiments) [21] in Japan.

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

first organization dedicated to the growth and success ofSDN. Its mission was to evolve the OpenFlow protocol fromits academic roots to a commercially viable substrate forbuilding networks and networking products. The ONF hasformed working groups including carrier operators, soft-ware vendors, switch chip vendors, network equipmentvendors, and system virtualization vendors to conduct


the technical standardization tasks of SDN/OpenFlow.These groups continue to analyze SDN requirements,evolve the OpenFlow Standard to address the needs ofcommercial deployments, and research new standards toexpand SDN benefits that cover the standardized protocolsand technology points shown in Fig. 6. The example sce-nario described in this Figure consist of interconnectingthree different networks: a conventional IP network (leg-acy network), SDN-based core network and a SDN-enableddata center (cloud). The different SDN interfaces shown inthe figure are as follows:

� Northbound interface: It enables the exchange of databetween the SDN controller and the application runningon top of the network – a so called application-drivennetwork. The kind of information that is exchanged,its form, and its frequency depends on each networkapplication. There is no standardization for thisinterface.� Southbound interface: It refers to the APIs exposed to

lower layers that allow the externalization of the SDNcontrol plane to the data plane. OpenFlow and the Net-work Configuration Protocol (NetConf) are the south-bound APIs used for a majority of SDNimplementations to date.� Eastbound interface: It allows interconnecting conven-

tional IP networks with SDN networks. Standardizationof this interface is not provided and its implementationdepends on the technology used by the non-SDN net-work. Usually, a translation module between SDN andlegacy technology is required. For example, the SDNdomain should be able to use legacy routing protocolto react to message requests (e.g., Path ComputationElement protocol, (PCE), MPLS).� Westbound interface: They serve as the information

conduit between multiple SDN control planes of differ-ent SDN domains. They help to achieve a global networkview and influence routing decisions of each controller.



SDN Applica�on Logic

NBI Driver

SDN Applica�on

SDN Applica�on Logic

NBI Driver

SDN Applica�on

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)

Data

Pla

neCo

ntro

l Pla

neAp

plic

a�on

Pla

ne

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

Fig. 6. ONF reference architecture for SDN.



24 October 2014

Q1

They also allow seamless setup of network flow acrossheterogeneous SDN domains. Some conventional proto-cols like BGP can be used between remote SDN domainsas westbound interface.

2.2.3. The open daylight frameworkThe OpenDaylight Project [23] is a collaborative open

source project hosted by The Linux Foundation. It aims tocreate platform-neutral, and open-source SDN technology.The OpenDaylight project provides a common controllerinfrastructure, protocol plug-ins, SDN applications, virtualoverlay networks and standards-based northbound inter-faces. It also provides support for a variety of southboundprotocols, including OpenFlow, I2RS, Path ComputationElement (PCE), Network Configuration (NetConf) andApplication Layer Traffic Optimization (ALTO), as well asa Topology Manager module based on most of the activeYANG data models for network topologies.

2.2.4. IETF and ITU-T standardization efforts for SDNThe IETF has recently begun to extend their specifica-

tions to support SDN principles [24]. In the IETF, the ForCES(Forwarding and Control Element Separation) project [25]defines a new architecture for network devices by specify-ing a framework [26] and a well-defined communication


protocol (using a XML-based formal modeling language)to standardize the information exchange between the con-trol and forwarding plane in a ForCES network element(NE) [27]. The ForCES NE follows a master–slave mode inwhich the forwarding elements (FE) are slaves and the con-trol 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 withtwo separate 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–32,27,33], it was not defined forSDN, and a limited number of vendor implementationsexist. However, it can be used to design a new protocolin SDN [34].

Additionally, since many research and industrial SDNcommunities provided different SDN applications, control-lers and routers, it became hard to inter-operate them withstandardized interfaces. Therefore, the IETF defined theInterface to the Routing System (I2RS) [35] with two majorgoals. The first is to standardize network-wide, multilayertopologies that include both virtual and real elements, net-work overlays and underlays. The second is to standardizethe routing information base (RIB) programming of a





24 October 2014

Q1

device (virtual or real). Another goal of I2RS was to pro-gram Network Features Virtualization (NFV) servicechains. The NFV aims to provide modern programmaticinterfaces that offer fast, interactive access and can easilybe manipulated by modern applications and programmingmethods.

Additionally, the Focus Group On Next Generation Net-works (FGNGN) proposed the concept of ‘‘Softrouter’’ [36].Softrouter advocates disaggregating the control and for-warding plane of a router. It separates the control planeprocessing functions (e.g., routing protocol processing)from the packet forwarding plane. These functions areimplemented in outsourced dedicated servers that com-municate with the forwarding elements via specific stan-dard interfaces, i.e., Softrouter protocol.

2.2.5. Object management group efforts for SDNThe Object Management Group (OMG) is recently look-

ing to provide its own specification to support northboundSDN ecosystem for middleware and related platform [37].In the OMG, the Software Defined Networking (SDN)Working Group was established to investigate the oppor-tunities for the development of open specification to sup-port standard Information Model that represents theobservable and controllable state of SDN networkelements.

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

3. Challenges and opportunities in the evolution of SDNarchitecture

SDN supports both centralized and distributed control-ler models. Each model has different infrastructure ele-ments and requirements to consider. This sectiondescribes each SDN model along with a discussion abouttheir advantages and drawbacks. Finally, we introducethe hybrid SDN models which combines the benefits ofboth approaches.

3.1. Pros and cons of the centralized SDN model

The centralized SDN model is based on a single central-ized controller that manages and supervises the entire net-work. This model is supported by the Open NetworkingFoundation (ONF). The network intelligence and statesare logically centralized inside a single decision point.OpenFlow is the official protocol for use by the centralizedcontroller to make global management and controloperations.

Since only one centralized controller is used to programthe entire network, it must have a global vision about theload on each switch across the routing path. It must alsokeep track of which flow inside which router presents abottleneck on certain links between the remote SDN nodes.


Additionally, the controller communicates with OpenFlowswitches to collect statistics, errors and faults from eachnetwork device, and sends these data to the managementplane. The latter is often a software composed of a data-base module and analytic algorithms that can detect theswitch overloads and predict the future loads that mayoccur 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 keylimitations. 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 theresponse time and may impose a higher overload. Forexample, the controller may classify flows with differentpriorities into multiple classes, where each class requiresa specific QoS setting that should be approved individuallyat setup time for every new flow received by OpenFlowswitches [39]. Such an approach can incur substantial flex-ibility and robustness challenges for large-scale networks.

Second, the simplicity of the centralized model cancome at the cost of control plane scalability. That is, group-ing all the functionalities in a single node requires morecomputation power, data storage and throughput to deli-ver the traffic causing its response time to be degraded.For example, as the size of data centers and cloud comput-ing networks keeps increasing, neither the over-provision-ing mechanisms nor load-balancing solutions can solve thescalability problems. Also, with respect to the hardwarelimitations, the switches may impose greater scalabilitybottlenecks and quickly hit real-life limits.

Third, in the centralized model, the first packet of everynew flow that is introduced in the system must first beforwarded to a centralized SDN controller for inspection.The controller determines the future path for the flowhop-by-hp and programs the flow entries into everyswitch on the path including both the aggregation andcore switches. Thus, when a new flow is to be pro-grammed, the controller has to contact all the switchesin the path, which is a scalability challenge for large net-works and might result in an explosion in the number offorwarding states in the flow tables if fine-grained flowmatching is required. The consequence is extra latencyand the possibility of network failure as the number ofnew flows programmed increases. The centralized control-ler could also represent a single point of failure whichmakes the network highly vulnerable to disruptions andattacks. Also, the time required by the controller to setupall the properties for the flow will add to the latency.Any failure at any step may result in instability andconvergence problems in the network.

Finally, SDN networks are becoming more complex andheterogeneous since they are designed to support versatilecommunication services and provide diverse functional-ities such as security enforcement, firewall, network virtu-alization, and load balancing. These services need tocoordinate their activities in the control plane to realizecomplicated control objectives and maintain a globalvision of the entire network. However, it is hard to tightly





24 October 2014

Q1

coordinate the control actions and keep the consistency ofnetwork states among distributed functions. For example,inconsistent routing decisions may be generated frominconsistent topology information collected from routingprotocols, which could create forwarding loops and broad-cast storms in the network, and involve serious perfor-mance and correctness problems.

3.2. Pros and cons of the distributed SDN model

The distributed SDN model aims to eliminate the singlepoint of failure and enables scale up by sharing the loadamong several controllers. Distributed SDN control planeshave been designed to be more responsive to handle localnetwork events in data centers, where the controllerinstances share a huge amount of information to ensurefine-grained, network-wide consistency. In particular, formulti-domain SDNs with a large variety of network tech-nologies ranging from high-capacity optical fiber to band-width-limited wireless links, the distributed SDNarchitecture is easily able to adapt to the users’ and appli-cations’ requirements. Moreover, a distributed controller ismore responsive, robust and can react faster and efficientlyto global event handling.

The research efforts closely related to the distributedSDN model can be classified into three classes. The firstclass focuses on improving the performance of specificcontrollers like Maestro [40] and McNettle [41]. These con-trollers exploit switch-level parallelism to process flowsfrom different switches concurrently. A second class ofsolutions proposes to distribute controllers. HyperFlow[42], Onix [43], and Devolved [44] controllers try to distrib-ute the control plane between different network partitionswhile maintaining a logically centralized control using ren-dezvous synchronization points between locally selectedevents, distributed hash table to support controller cluster-ing, or even distributed file system.

A third class of solutions proposes multi layered distrib-uted controllers. Kandoo [45] distinguishes two-layers ofhierarchical distributed controllers: (i) bottom-layer, agroup 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 maintainsthe network-wide state. In addition, authors in [46] pro-pose 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.Similarly, [48] describes a controller placement problem todecide the optimal number of controllers needed and theirplacement in a SDN network.

Despite the ability of those solutions to provide a dis-tributed SDN model, several key challenges must beaddressed in the future SDN to improve scalability androbustness of networks. First, the above approachesrequire a consistent network-wide view in all controllers.Also, the mapping between control planes and forwardingplanes must be automated instead of the current static


configuration which can result in uneven load distributionamong the controllers. Second, these approaches cannotobtain a global optimal view of the entire network. Further,finding an optimal number of distributed controllers thatensure linear scale up of the SDN network when theirnumber 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 SDN controlarchitecture

To address the limitations in each of the approachesdescribed above, hybrid SDN architectures are being con-sidered. However, a critical challenge stems from deter-mining how much of network abstraction modules canbe centralized and efficiently 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 thebenefits of the simple control of managing specific dataflows 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 orchestra-tors will require standard interfaces, mechanisms, and pol-icies to manipulate and interact with the control planes indistributed environments, and support high-availabilityand fault-tolerance capabilities [49].

The hybrid SDN model may be useful in providinganswers 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 efficient resource usage because it willbe possible to adjust more finely and automate each aspectof the network at the application level. Furthermore, thehybrid SDN model could provide management policies tosolve 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 existinginfrastructure without the need to change the overallsystem.

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-





24 October 2014

Q1

sistent SDN models, and provides promising directions tohandle these challenges.

4.1. Network visibility and management challenges with SDN

SDN introduces new management and monitoringcapabilities that can improve performance and reduce thebottlenecks in the network. Although SDN monitoringtools can be powerful in small and medium sized networktopologies, yet debugging, troubleshooting, monitoringand enforcing security compliance are very difficult tasksin distributed SDN. OpenFlow makes this even harderdue to the poor choice of the monitoring location and thestatistics that should be output for the OpenFlow SDN ses-sion. Diagnosing the network performance and bottleneckswithout visibility into the traffic characteristics introducesnew complexity with regard to the consistency of the SDNnetwork.

SDN monitoring tools should be able to capture the net-work’s information and behavior to help in carrying outmanagement decisions. In particular, network configura-tion remains a difficult task in carrier-grade networksbecause administrators are required to grapple with low-level, vendor-specific interfaces to implement high-levelfunctions. Ideally, network operators should be able toenforce various high-level policies, respond to a wide rangeof network events (e.g., intrusions). However, specifyinghigh-level policies in terms of distributed, low-level con-figurations remains difficult because SDN provides littleto no mechanism for automatically responding to eventsthat may occur. To enable these possibilities, service pro-viders need programming interfaces to support an event-driven model to coordinate different asynchronous eventsassociated 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 configura-tions, query link utilizations, or even modify a switch’sflow table to alter routing. Moreover, they provide userinterfaces to supervise the network bottlenecks in case ofcongestion, monitor flow status (e.g., bandwidth, delay,and loss) and computing/networking resources (e.g., net-work I/O, CPU, memory). Despite these capabilities, bothefforts incur critical limitations in terms of their real-timeperformance.

4.2. Promising directions in network visibility andmanagement for SDN

The SDN monitoring tools should provide a proactivecapability that leverages the flexibility and programmabil-ity 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 differentmanagement tasks (i.e., QoS, VLAN, network isolation, slic-ing, etc.) to prevent errors as they arise, independent of anyspecific controller’s implementation. Thus, existing toolsneed to be extended to support service-awareness [52] to


interactively map the flows onto services, identify selectedflows from all lists of flows (i.e., flowspace), and monitorthe status of the selected flows [53].

Moreover, the proactive capabilities of the monitoringtools should be able to classify the flows into different cat-egories based on their behaviors and allocate differentports to each class based on multiple packet matching(e.g., IP, TCP port, VLAN, etc.) [54]. Additionally, theyshould provide individual functional modules to supervisethe topology discovery either of the entire network orspecific slices. Furthermore, a proactive SDN monitoringtool should be able to scale to wide area networks to dealwith multiple controllers, alternate flow paths during trou-bleshooting, and monitor the flow’s status such as band-width 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 have toprovide closed control loop functions dedicated to self-configuration, self-optimization, and self-healing. The con-trol loop diagnostics and decision making processes needto be adapted automatically, e.g., by predicting the futureactions based on the results of the previous ones. This pro-active capability should leverage the flexibility and pro-grammability of SDN, and improve its effectiveness andefficiency, owing to the cognitive processes that willenable creating more elastic network management eitherfor the entire network or specific slices [56].

To further enhance the monitoring efficiency, DynamicMeasurement-Aware (DMR) Routing was introduced in[57]. The DMR selects flows based on their importance,i.e., big flows are split into several small sub-flows, andthe most important flows are routed using a separateflow table entry. The sub-flows belonging to the samecategory can be inspected using Deep Packet Inspection(DPI) box [58]. The DPI can be used to learn and updateflows dynamically and send them back to the monitoringtools.

In summary, implementing SDN traffic monitoring toolspose a series of challenges. First, there is substantial diffi-culty in creating network baselines with different taxono-mies. For example, simplistic approaches try to describetraffic in terms of protocols and port numbers. Otherapproaches concentrate on bandwidth utilization and net-work topology to provide a global view of flows on the net-work. More advanced monitoring approaches try toclassify traffic according to the flow’s importance. Addi-tional difficulties include finding the right tools which pro-vide visualization at scale. Unfortunately, existing toolsthat are able to depict dozens or hundreds of nodes, facesevere limitations when working with thousands or mil-lions of nodes. They also face problems supporting multi-ple strategies, i.e., they suffer from topology locationproblem, cannot place instruments in enough locations,and are unable to visualize the network based on observedtraffic patterns. Doing this in an automated way wouldprove extremely useful to network administrators anddefenders. Finally, these tools must operate in an openSDN and vendor-independent environment, i.e., network-ing teams should be willing to consider deploying their





24 October 2014

Q1

tools and techniques on open platforms so they can deviseand 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 specifically in the abilityto provide them more options on locating resourcesthereby conferring a competitive advantage when deliver-ing certain kinds of services. SDN may reduce the policycomplexity by enabling scalability in inter-domain andproviding validation for the claims of seamless evolution.

The major challenges for operators in the near futurepertain to providing convergent, dynamic and adaptivenetworks in the context of a multi-services, multi-proto-cols, and multi-technology environment. Also, they arelikely to face other key issues concerning the necessarynetwork resources required to deliver differentiated andmeasurable quality of service (QoS). In this section wedescribe the key challenges and open issues in Open-Flow-based SDN for network operators.

5.1. SDN-based routing algorithms

The design of routing algorithms with OpenFlow can beperformed either using native forwarding or tunnelingmechanisms. With the native OpenFlow forwarding, thecontroller installs flow entries for specific header fields ofthe traffic. The selected fields should be unique withinthe entire network to allow the controller to perform con-flict resolution and ensure the isolation of the traffic. Forthe tunneling mechanism, the controller should allowrouting strategies by establishing a tunnel between theingress and the egress nodes to perform packet encapsula-tion and decapsulation. The latter solution eliminates theneed for conflict resolution and reduces the size of flowtable entries in the switch. Such a functionality can beimplemented either with MPLS-TE (i.e., MPLS Traffic Engi-neering) or Q-in-Q VLAN (i.e., 802.1Q). It also avoids thecomplex and error-prone process of per-packet verificationin favor of creating a globally-consistent policy. Bothmechanisms should provide the ability to add and removean end-to-end path easily.

Using the approach outlined above, SDN should be ableto 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 flow table. However, this approach lim-its the scalability of the network because the rules willnever be removed, which restricts the deployed flows tothe number of available flow entries.

The transient path deployment allows the injection ofthe flow rules on demand as temporary entries. That is,when a switch cannot find a flow table entry that matchesan incoming packet, the switch forwards the packet to thecontroller to dynamically compute the path ‘‘online’’ anddetermine the appropriate policy to be applied andinjected. These operations increase the delay for flow setupbut could improve scalability when combined with a suit-able replacement policy for flow table entries.


5.2. SDN for coordination between routing protocols

The coordination between Interior Gateway Protocols(IGP), such as RIP2 [59], and Exterior Gateway Protocols(EGP), such as BGP [60], is one of the most important chal-lenges in SDN networks. The limitation of the existingrouting systems arises from their inability to coordinatetheir activities in an autonomous system (AS). For example,the violation of the SLA (Service Level Agreement) in thenetwork may limit the automatic reaction of IGP protocolseven if the link characteristics (e.g., link weight) allow thedelivery of the packets because the scope of IGP protocolsis limited to ingress routers inside a given AS. The violationof the SLA outside its AS is hidden and cannot be detected.Thus, the outgoing traffic may increase drastically in thenetwork in the absence of load balancing and traffic man-agement policies in the network.

Traditional approaches, such as the Routing ControlPlatform (RCP) [61], coordinate the inter-domain commu-nication and route all the traffic on behalf of the BGP rou-ters. 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 finding the best path selection [63], but itdoes not provide a way to split traffic over multiple paths.

SDN can provide full coordination within intra-AS andinter-AS by simplifying the forwarding plane and lettingthe SDN controller deal with the routing algorithms. Push-ing routing strategies into separate controllers mayenhance traffic management and load balancing, andabsorb 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,traffic policing and filtering as necessary. However, inlarge-scale networks the interconnection of BGP routersshould cope with forwarding loop management, signaling,and routing decisions. These tasks may increase the trafficcongestion when packets traverse inter-domain multi-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 this con-text the OpenFlow SDN wild-card rules must be revisited.These rules match on certain packet-header fields (e.g.,MAC addresses, IP addresses, and TCP/UDP ports) with atimeout that triggers the switch to delete the rule after afixed time interval (i.e., a hard timeout) or a specified per-iod of inactivity (i.e., a soft timeout) to limit the conver-gence time of the routing algorithm.

5.3. Multicast communication

Multicast communication is another important crite-rion for scalable communications. To demonstrate the fea-





24 October 2014

Q1

sibility of implementing multicast in OpenFlow switches,the authors in [65] implemented a prototype to demon-strate the feasibility of stateless multicast with Bloom fil-ters. Even if the Bloom controller implements flexiblemulticast policies on the flow table entries, it does not pro-vide any approach to manage multicast groups. Likewise,the authors in [66] extended a SDN controller with aDomain Title Service Agents (DTSA) to act as a logical busthat spans the applications and the switches. The DTSAestablishes and maintains OpenFlow sessions betweenend applications by intercepting incoming messages fromthe controller to modify the flow tables accordingly.Similarly, authors in [67] extended OpenFlow to supportmulticast communication in a data center. They imple-mented a Layer 2 (MAC address) SDN controller thatencapsulates MAC addresses into IP headers and createsvirtual tunnels over overlay network between end points.However, tunneling mechanisms require that end-to-endpath must be fixed a priori between source anddestinations.

Future SDN networks should address this issue byencouraging further investigation in facilitating IP multi-cast. We believe that OpenFlow could provide a promisingand flexible solution to solve the dynamic group memberjoining/leaving problem in IP multicast supported in over-lay networks.

5.4. Network convergence and QoS

With the need for flexibility and the efficient coexis-tence of multiple services (i.e., telephone, video and data)within a single switch, enterprises have to cope with alarge demand for Quality of Service (QoS), Quality of Expe-rience (QoE), robustness, ease of modification/upgrading,security and privacy [68,69]. Providers must be able to cre-ate virtual network slices in the same network equipmentwhile simultaneously assuring performance and isolationrequired across different services to enable application-driven QoS. However, SDN and its OpenFlow specificationdo not provide any support for differentiated QoS.

Recently, some researchers focused on providing QoSsupport for SDN-enabled applications without involvingOpenFlow. For example, [70–72] introduced the OpenQoSframework to enable route optimization and per-flowgranularity management. OpenQoS helps network admin-istrators specify the QoS strategy that flows should follow,and how the controller can allocate the network resourcesand perform service differentiation. Likewise, authors in[39] proposed enhancing SDN controllers with QoS API toprovide service differentiation and fine-grained automatedQoS control in networks having multiple slices. Addition-ally, authors in [73] introduced the Port Control Protocol(PCP) to provide application-driven QoS. Applicationsexplicitly signal their QoS requirements to the PCP, whichuses the application’s meta-data to implement therequired QoS into the network equipment.

Although these different approaches aim to provide QoSmechanisms to support flexible and differentiated servicemanagement across different applications, none of themcan automate QoS provisioning in real-time. Instead, ahuman in the loop, e.g., a network administrator, is


required to specify the configuration of each service beforethe communication begins. This strategy unfortunatelyloses the flexibility of network. We believe that the inte-gration of session control protocols as a northbound inter-face is a promising approach to enable end-to-end QoSsignaling among distributed SDN domains. This layermay provide proactive application-driven configuration ofdynamic resource allocation with support for authentica-tion and authorization [74]. From this perspective, the abil-ity to predict the network behavior as a function of thenetwork services to be delivered is of paramount impor-tance for service providers. This way they can assess theimpact of introducing new services, activating additionalnetwork features or enforcing a given set of (new) policiesfrom both a financial and technical standpoints.

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 different 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 topologyrecovery after a link failure. Topology discovery is neededby the STP module to allow removing flows for subsequentframes after failure. Also, SDN controllers will suffer fromsuboptimal path calculation, interruption and long conver-gence every time topologies change [75]. Path re-calcula-tion should be triggered thereby yielding a new activepath.

5.6. Inter SDN domain communication

SDN is gradually being adopted by carrier-grade provid-ers over heterogeneous, multi-technologies (e.g., WiFi,WiMax, UMTS/3G/4G, satellite, IP/Ethernet/ATM, etc.),and large-scale networks [76]. Each portion of these net-works can be seen as independent isolated domains, typi-cally controlled by a set of SDN controllers acrossmultiple SDN domains, perhaps under the authority of asingle operator or collaborating operators. Interconnectingisolated SDN domains involves some coordination todefine who will be allowed to manage the entire network,install/update new program on the core infrastructure,what actions can each program execute, and how theycan be performed within each tier of the network.

One way to match isolated SDN domains can be per-formed through novel SDN-specific protocols. For example,Inter-SDN domain protocol (SDNi) [77] can be seen as aninterface between isolated SDN domains to coordinatethe controller’s behaviors. It should enable them toexchange control information related to topologies, events,energy consumption, and QoS requirements on eachdomain. Additionally, the SDNi protocol should be able toexchange reachability information and propagate the Ser-





24 October 2014

Q1

vice Level Agreement (SLA) end-to-end over heteroge-neous networks.

However, SDNi still lacks a semantic network model toensure the extensibility of its transport mechanisms andsyntax. We suggest defining new types of message formatsthat may be used inside SDNi to ensure interoperabilityacross multi-technologies, multi-domain SDNi networks.We believe SDNi can be implemented as an extension toBGP and SIP signaling to provide policy-based, verticalintegration between an overlay-virtual-network technol-ogy (including SIP/SBC) and the data plane. SBCs (SessionBorder Controllers) may be implemented as northboundinterface to pool the intelligence from the application/session layers within the network layer. The session man-agement may be integrated with application-enabled SDN(A-SDN) provisioning mechanisms [73]. The A-SDN enablesdynamic and automatic resource provisioning on networkswitches thereby allowing service providers to effectivelydeal with the surge in traffic without resorting to over pro-visioning of networks typically required in the past. Ide-ally, a fully automated service is required [78], fromnegotiation to ordering [79], through delivery assuranceand charging should be supported.

6. SDN for cloud-based networks

The introduction and deployment of cloud-based ser-vices have emerged as an important solution that offersenterprises a cost-effective business model. However,many network functions have extreme characteristicsand performance requirements, which have created newchallenges such as servers and network virtualization,mobile clouds, and security. These need to be addressedwith intelligent network virtualization, high-speed packetprocessing, and load-balancing. SDN can be seen as anew and complementary technology to virtualization,which is poised to tackle the challenges of network-enabled cloud and web-scale deployments. In this sectionwe describe the different challenges and opportunities inthis space.

6.1. SDN model for information-centric networking

Information-Centric Networking (ICN) is receiving sub-stantial attention in cloud networks because it providesusers with data content that is based on naming the infor-mation instead of the communication channels betweenhosts. It also introduces new features such as in-networkcaching or content-based service differentiation. Yet, ICNstill faces a number of challenges in realizing its full poten-tial. In particular, a typical deployment of ICN schemesemploys different transmission techniques and packet for-mats that are not interoperable. Also, deploying ICN-capa-ble equipment in existing networks is hard, and requiresreplacing and/or updating existing operational networkequipment with ICN-aware ones. Moreover, ICN schemesneed to ensure the uniqueness of names in the networkto handle lookups from large name spaces which can begreater than IP address spaces.


SDN offers a promising solution to facilitate the deploy-ment of different ICN schemes without requiring re-deployment of new ICN capable hardware. The authors in[80] propose a unified framework over virtualized net-works to enable interoperability between different ICNarchitectures. Similarly, the CONET (COntent NETwork)framework [81] provides content-centric users access toremote named resources rather than to remote hosts. CON-ET extensions provide northbound interfaces to intercon-nect ICN nodes to the OpenFlow controller [82]. A unifiedpacket format achieves end-to-end connectivity amongdifferent ICN schemes. Likewise, the SAIL (Scalable andAdaptive Internet Solutions) project [83] supports thenotion of a flash network to enable dynamic resource pro-visioning on a time-scale comparable to existing computeand storage resources. Flash network slices are used toconstruct and connect scalable and distributed virtual ser-vices across data centers to end users across the globe.

Despite these solutions not requiring the replacementof existing network nodes, they incur several key limita-tions related to packet fragmentation introduced by theirpacket format. In particular, since supporting ICN overSDN requires ICN information in each packet, packet frag-mentation remains a bottleneck that decreases the perfor-mance of the network. An approach that may resolve thisissue is to let SDN controllers assign fixed-length labelsto uniquely identify the different network paths and allowthem to forward packets based on these path labels [84].

6.2. SDN for data centers and cloud

The value of SDN in clouds and data centers lies specif-ically in its ability to provide new capabilities like networkvirtualization, automating resource provisioning, and cre-ating new services on top of the provisioned networkresources [85]. SDN promises an interactive solution toimplement new capabilities, e.g., to enable cloud applica-tions and services to retrieve network topology, monitorthe underlying network conditions such as failures, andinitiate and adjust network connectivity/tunneling. Forinstance, FlowN [86] virtualizes the address space of eachapplication based on the fields in the packet headers andmaps these virtual address spaces to physical addresses.The FlowN virtualized layer allows resource isolation andcustomized control logic for each tenant running its owncontroller.

Although data center interconnects allow bypassing theexisting control plane protocols such as STP, yet intercon-necting heterogeneous data centers to form federatedclouds raises a challenging issue for SDN. Some researchershave extended the controller’s northbound interfaces todevelop customized real-time forwarding processes ascloud plug-ins, such as Neutron OpenStack, that enable vir-tualized address space and bandwidth isolation for eachvirtual link [87]. The northbound interfaces may be usedby third party applications to monitor the SLA violationand 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-





24 October 2014

Q1

sioning (e.g., operators may over provision network linksto overcome potential network congestion and packet dropwithin data centers, which makes it unpredictable andcostly in many networking scenarios), and QoS manage-ment (e.g., many SDN applications require northboundinterfaces to communicate with third party applications,which requires monitoring the SLA violation to adjust thenetwork resource if necessary). Since SDN is part of thenetwork service evolution, we believe that a global solu-tion should be provided to cope with these issues. Suchan architecture may introduce a modulator SDN layer toorchestrate the communication between the applications,services and the data center infrastructure as shown by[85].

6.3. Network function virtualization

Network function virtualization provides a powerfulway to run multiple concurrent virtual networks over ashared substrate. Cloud providers can offer virtual net-works with a topology and a configuration customized tothe users’ needs. With a growing dependence on the net-work configuration, 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, virtual-ized home gateways can be implemented as virtualizedfunctions inside virtual machines in the cloud. Users canaccess the most recent versions without the need toupgrade the content by themselves.

As network functions are deployed in virtual machines,cloud operators may upgrade their infrastructure by add-ing new racks, installing new virtual machines or evendeleting and migrating existing ones [88]. Network migra-tion can also be applied to create green networks becausevirtual networks can be placed on different physical rou-ters according to the traffic demand to reduce energy con-sumption. Moreover, factors such as server consolidation,load balancing, and security enforcement are driving mostexperiments with virtual network migration. For example,a link shared by different virtual networks could bejammed because of a DDoS attack to one of the virtual net-works. In such a case, the non compromised networkscould be migrated to different physical routers until theattack is resolved.

Often there are unintended consequences from virtualnetwork migration that directly affect the physical under-lying network. SDN controllers may stop an arbitrary num-ber of applications during the migration operations, whichcould have significant performance degradation and highbandwidth costs to redirect traffic to other virtual networkslices. Furthermore, the network may have a large amountof state collected from a set of distributed SDN switchesthat should be kept consistent to avoid outages, transientloops, and violation of SLAs during the migration process.Meanwhile, controllers should maintain connectivity andforward path re-routing without interruption. As such,the centralized SDN model is a single point of failure andnot suitable to guarantee the consistency of the network


states. It does not reduce the downtime and packet lossduring the migration of network functions between virtualmachines [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 infrastructure asintroduced by CloudNaaS controller framework [91]. Thecontroller uses a placement optimizer to choose the bestvirtual network placement and dynamic provisioningmodel to reallocate resources based on their availability.We believe that a self-service provisioning model providedby the cloud can provide a rich set of network services suchas seamless network isolation, customized networkaddressing as well as service differentiation.

Another possible direction to enhance virtual networkmigration can be achieved by synchronizing networkstates among distributed switches and create overlay tun-nels to relay traffic between network slices [92]. However,this approach requires an additional proxy layer to createsynchronization points for redundancy and state duplica-tion. We believe that more advanced algorithms for sched-uling virtual network migration need to be explored toleverage technologies like redundancy elimination, andreduce the overhead of copying the state for multipleslices. The NetGraph [93] framework is an example thatsupports incremental algorithms with practical computa-tion time and memory requirements.

7. SDN in wireless and mobility settings

Software Defined 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 interfacesacross the wireless stack. It also enables refactoring wire-less protocols into processing and decision planes [9] asintroduced by the OpenWRT [94] and Indigo [95] firm-ware. This decoupling allows programming the enter-prise-specific requirements (e.g., an airport, a restaurant,public library) in a wireless access point (AP). This sectiondescribes 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 differentQoS requirements, which will interconnect to all kinds ofheterogeneous and customized Internet-based servicesand applications. Accordingly, these developmentsdemand a rethinking of the network design, which in turnrequires us to understand the implications of using SDN inthe most common wireless networking scenarios. It is alsoimportant to understand the key challenges that exist inthis realm and how they can be addressed.

IP mobility support has been specified in traditionalIPv4 and IPv6 networks, but presently there is not much



1297



24 October 2014

Q1

discussion regarding mobility support in SDN. Thus, SDWNshould provide radio resource management, mobility man-agement and routing [96]. It should include novel mobilitymanagement mechanisms to maintain session continuityfrom the application’s perspective. In particular, handoffmanagement is a challenging issue in supporting SDNmobility because mobile terminals move rapidly betweenvirtualized APs. Thus, SDWN should provide network con-nectivity through dynamic channel configuration.

The authors in [10] introduced the concept of slicing thewireless infrastructure into logical virtualized partitions,each managed by virtual APs. Similarly, the effortdescribed in [8] introduced the Odin framework as amobile agent that communicates with SDN controllers tokeep a global view of flows in the network. It delegatesthe handoff management to a virtual AP that invokes thephysical AP to manage the mobility and maintain hostreachability with respect to the receiver signal. Althoughthese approaches help to simplify the mobility manage-ment, SDN mobility functions must be enhanced to providerapid client re-association, load balancing, and policy man-agement such as charging, QoS, authentication, andauthorization.

Another key challenge in wireless/broadband networksconcerns multi homing[97]. Multi homing implies theattachment of an end-host to multiple networks at thesame time so users can freely move between wirelessinfrastructures. This approach can be realized by applyingSDN capabilities to the relay between the home networkand edge networks. For example, within home networks,a virtualized residential gateway can improve servicedelivery between the core home network and the net-work-enabled devices [98]. The target architecture (i.e.,virtualized residential gateway) is realized by applyingSDN and NFV between the home gateway and the accessnetwork, and moving most of the gateway functionalityto a virtualized execution environment. Since the virtual-ized residential gateway is cloud-based, it forms the coreof a user’s home network by connecting their network-enabled devices while benefiting from broadband Internetservices such as connection sharing, Firewall security, VPNconnectivity, IP telephony, audio/video streaming, Wire-less LAN 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 traffic 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 numberof nodes fail, simplicity of configuring wireless nodes,and their capacity to provide broadband connectivity.These networks require dynamic routing algorithms tocope with the limitations of wireless channels such as fad-ing, interference, and broadcast [100].

SDN can partially solve these challenges by enablingprogrammability of the network [101]. For example, theauthors in [102] introduced SDN-based CloudMAC archi-tecture to enhance the reconfigurability and the flexibilityof wireless ad-hoc networks. CloudMAC helps to improve


the wireless connectivity through seamless AP switching,which provides fast packet processing and reduced packetloss. However, several key issues of WMNs remain unre-solved [103]. In particular, the topology of ad-hoc wirelessnetworks changes at a much higher pace than in wired net-works due the variation in link quality and node move-ment. Additionally, wireless nodes may join and leavethe network at any time so any SDN-based routing proto-col must provide autonomous topology discovery as wellas adaptive neighbor discovery to react swiftly to changesin the network [104].

7.2. SDN for mobile cloud

Mobile cloud computing is one of the technologies thatare converging into a rapidly growing field 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 with thecloud may create an environment in which mobile devicesappear attached locally to the cloud with low latency[105]. Both SDN and NFV can extend wireless access infra-structure to cloud computing and enable logical slicing ofresources to multiple devices. SDN promises an attractivesolution to implement new capabilities to cloud applica-tions and services. It can help to retrieve network topology,monitor the underlying network conditions (e.g., failures),initiate and adjust network connectivity and supporttunneling.

Additionally, given the dynamic needs and supply of thenetwork resources due to the rich set of resources availablein the cloud, mobile users can benefit from resource virtu-alization to accommodate different requirements of theirmobile terminals moving within the mobile cloud. Weav-ing different wireless access technologies together in afluid fashion and creating smart gateways in the cloud ina transparent manner is important to realize the full poten-tial of mobile clouds. To this end, virtualized access net-works should support fine-grained isolation per person orper 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 control-ler for marshaling and unmarshaling of flow rules (e.g., inOpenFlow messages), the overhead increases more signifi-cantly because of the limited computing capabilities andresources of mobile devices (i.e., extra memory consump-tion and extra latency). For example, mobile interactiveapplications (e.g., mobile gaming, virtual visits) requirereliable connectivity to the cloud as well as low latencyand impose higher bandwidth requirements from wirelessaccess networks to cloud service.

Furthermore, mobile users move frequently betweenmultiple access networks, using either the same or differ-ent mobile terminals, but often with a unique persona. Ingeneral, it is difficult to realize a Mobile Personal Grid(MPG), which requires maintaining seamless connectivityof a set of devices that belong to a particular individual



1411

1412 1473



24 October 2014

Q1

to a remote public and private cloud. Maintaining seamlesswireless connectivity for the MPG introduces multidimen-sional challenges including the need to deal with dynamicmobility management across heterogenous networks,power saving, resource availability, fluctuating operatingconditions, and limitations on the movement of contentacross multiple devices and the cloud [105].

Addressing these limitations simultaneously mayincrease device complexity, degrade the network perfor-mance, and cause connectivity problems. The key chal-lenge for mobile clouds lies in transforming physicalaccess 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-cific virtual partition with autonomic reconfiguration andlossless connectivity. The virtualization of mobile protocolstacks could abstract mobile resources to accommodatetheir different requirements. We argue that a close interac-tion with the cloud may help achieve the multidimensionalmobility requirements [105] and relieve the network infra-structure from complex network tasks (e.g., configuration,traffic analysis) to the cloud [106].

7.3. SDN for WPAN

Since SDN promises to reduce the complexity of theconfiguration and management of networks, its functional-ity can also be applied to many wireless infrastructure net-works such as the Low-Rate Wireless Personal AreaNetworks (LR-WPANs). Extending SDN to LR-WPAN wasconsidered impractical because these networks are highlyconstrained. LR-WPAN requires numerous low-cost nodescommunicating over multiple hops to cover a large geo-graphical area. These nodes require duty cycles to providelow energy consumption to operate for multi year lifetimeson batteries with modest lifetimes. They also require smallsoftware footprint due their limited amount of memorystorage and CPU processing speeds.

Additionally, to enable SDN for LR-WPANs, several chal-lenges must be resolved to provide cross-layer optimiza-tion [107] as well as data aggregation. We argue thatfuture SDN controllers should provide an appropriate mod-ule to define the rules that consider specific matchingfields for LR-WPAN environment [108]. These rules mayroute packets based on their specific values includedwithin the payload they carry. For example, packets mayinclude a specific value of temperature sensors that exceeda given threshold. SDN controllers will need to configuremultipath routing algorithms to route LR-WPAN packetsbased on multilevel thresholds. Moreover, controllers mustaddress several key problems related to node mobility,topology discovery, self-configuration as well as self-orga-nization [109]. They should also deal with link unreliabil-ity, and robustness to the failure of generic nodes and thecontrol node [110].

7.4. SDN for cellular networks

The growing demand and the diverse patterns of mobiletraffic 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 different technolo-gies. However, supporting an increasing number of sub-scribers with frequent changes in user location incursserious issues [111]. Cellular network infrastructures mustredirect user’s data to load balancing servers to accommo-date changing network conditions and handle traffic inreal-time with specific QoS priority [8]. Presently, cellularsystems have a single direct link between the base stationand the terminal. However, multihop networks requiremaintaining multilink between multiple transmitter andreceiver to form multipath communication – the so calledmultihop cooperative network. Compared to existing tech-nology, which include mechanisms for retransmission andmultiple acknowledgments, multihop cooperative net-works can overcome these limitations by providing highdensity access networks. However, they often sufferthroughput penalties since they operate in a half duplexmode and therefore introduce insufficiency of spectrumusage.

To increase the capacity of cellular systems, SDN canprovide solutions to overcome the limitations of multihopwireless networks. Cellular SDN networks (or briefly, CellS-DN) [112] could maintain a Subscriber Information Base(SIB) to translate a subscriber’s attributes into the switchrules to set up and reconfigure services flexibly. To thisend, finer grained control of traffic in CellSDN must beadapted to cellular infrastructures to handle notificationsfrom the users’ terminals. The authors in [113] introducea Deep Packet Inspection (DPI) engine to enable finergrained classification at the application layer. Section 4described the use of DPI in monitoring tools, whereas hereit is used for routing flows across multichannel cellularnetworks. Application level control could then provideflexible and fine-grained control of the users data and ana-lyze packet contents to identify malicious traffic. Despitethese possibilities, CellSDN requires specific SDN protocolsto orchestrate the remote virtualized resources [114].Moreover, these protocols must enable network slicing,traffic engineering, minimizing delays and reduction inpacket loss [115].

In cellular communications, an architecture based onSDN techniques may give operators greater freedom tobalance operational parameters, such as network resil-ience, service performance and QoE. CellSDN controllersmay implement Radio Resource Management (RRM) pro-tocol [116] as northbound interfaces to simplify the QoSprovisioning. Similarly, CellSDN routers could supporttechniques like header compression and decompressionto reduce the overhead with small packet payloads onlow bandwidth links. Another important challenge inCellSDN is designing the architecture of the network. Tra-ditionally, CellSDN was designed with centralized controland data structures in mind to improve its performance.Centralized SDN model in CellSDN results in a single pointof failure. Thus, when the cellular infrastructure fails, theentire network will be unavailable. Hence, a rethinking ofarchitecting CellSDN using a distributed SDN model isneeded.



1474



24 October 2014

Q1

Distributed CellSDN could provide high-performance,cost-effective and distributed mobility management[117] in CellSDN. We believe that a distributed SDNmodel could also provide multiple parallel virtualizedtransmission channels to support the increasing numberof mobile terminals requesting the network resources[114]. As for fixed network virtualization, there is a needto reconsider the issue of isolating traffic into multiplewireless slices, where each slice could support a specifictraffic pattern. Such an approach may help to create vir-tual base stations and orchestrate the available resourcesamong different mobile devices, thereby saving powerand memory usage.

8. Challenges and opportunities for security in SDN

Security in SDN networks poses significant 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, mobile wire-less networks are more vulnerable than fixed wired net-works since broadcast wireless channels easily allowmessage eavesdropping and injection (i.e., vulnerabilityof channels). Moreover, mobile ad-hoc networks incurmore complex security challenges due to their lack ofinfrastructure (e.g., security servers), which renders classi-cal security solutions infeasible. Traditional securityapproaches require downtime to orchestrate topologychanges while the network is reconfigured, new securityconfiguration is inserted, and multiple security servicesare turned on and debugged.

8.1. Security challenges in SDN

Security is minimally specified in SDN; thus the Open-Flow specification does not describe the certificate formatto ensure data integrity. SDN security will require moresophisticated encryption and authentication mechanismsto prevent hackers and to recover packets from failure.For example, multiple controllers may mutually authenti-cate each other by exchanging certificates signed by thirdparty private keys. The difference between these keys,however, raises unexpected security vulnerabilities in theentire network. Thus, the controllers may be unable tointeroperate with each other since they have differentkeys. The OpenFlow specification 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 specification makesno mention about how a secure connection can be estab-lished nor how the certificate can be checked betweenthe controllers and the switches. Security issues also stemfrom the diversity in network configurations. The securitymechanisms defined by the specification are ill-suited to


protect 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 primarychallenging issue: managing the trade-offs between thenetwork security and performance.

8.2. Opportunities for addressing security concerns in SDNs

A promising approach to address the different securityproblems in SDN involves developing security policies witha unified syntax for the OpenFlow protocol. These policiesshould enable authentication, authorization, access con-trol, and secure transport between applications and SDNcontrollers, or even between multiple controllers and aset of switches. These policies can be defined via the Secu-rity Assertion Markup Language (SAML) to exchange public/private keys as part of the OpenFlow policies, e.g., withinconfidential OpenFlow messages that may be transportedusing the Datagram Transport Layer Security (DTLS)protocol.

Supporting intrusion detection is a crucial part of asecure SDN framework. A promising approach is to providean Intrusion Prevention System (IPS) based on the opensource SNORT project [119]. In particular, OpenFlow secu-rity algorithms should provide role-based authenticationto check for contradictions in flow rules when applicationsattempt to insert disallowed flow rules. It may be possibleto add customized security services into the network,either on a per-flow basis or per-group of flow [120].Another approach to resolving the mobile SDN securitychallenges could consider separating these functions oroutsource them to a third party server, as described inthe OpenWiFi project [121].

Yet another promising approach involves inserting dif-ferent security policies in the OpenFlow protocol using L4to L7 services, such as URL filtering between an endpoint,rejecting flows toward a specific destination, redirectingHTTP and HTTPS traffic using a proxy, firewall, etc. Extend-ing the OpenFlow matching rules to incorporate new secu-rity rules using different fields, such as wild-cards,physical/virtual ports and IP addresses is another possibil-ity. However, exposing IP addresses to network attacksmay hand the adversaries significant advantage to remo-tely scan networks and identify their targets accuratelyand quickly. The authors in [122] introduced a techniquecalled OpenFlow Random Host Mutation (OF-RHM) to hidereal IP addresses from external attacks. They assign virtualIP addresses to hosts so that they can be reached only byauthorized entities.

9. Conclusions

Most researchers argue that the current Internet archi-tecture is inadequate and has reached a tipping pointwhere most of the time and effort is spent addressingexisting flaws rather than developing new ideas. Toaddress the challenge of ossification of the Internet,researchers have started to focus on redesigning the over-all architecture by breaking the tight integration of the for-



1629 Q3

1643164416451646



24 October 2014

Q1

warding and control plane implementations. As a result,major research projects focus on the SDN architecture toconstruct and present a logically centralized map of thenetwork. The next-generation of SDN networks will benefitnot only from the simplicity of the implementation, butalso from the fact that maintaining and updating applica-tions will be easier as well.

In this paper, we have surveyed a wide range of recentand state-of-the-art projects in SDN. Based on the survey,we classified key challenges and opportunities along anumber of different areas including architectural models,programmability, convergence, wireless and mobility,cloud platforms, and security. We showed that the net-working community is heavily involved in SDN research,however, most of the investigations continue to focus ontopics such as control plane/data plane, distributed vs cen-tralized control plane, scalability of solutions, Hybrid solu-tions, call graph, networking models etc.

We argue that while these research efforts are impor-tant, they need to occur in the context of overall networkprogrammability and scalability goals. Although Open-Flow, which is a prominent SDN implementation, promisesa flexible, open, and dynamic flow transmission mecha-nism, it also poses a set of challenges in terms of networkvirtualization, mobility management, operation, which willrequire coordinated attention from the research commu-nity for its success and wide acceptance. Our goal was topresent these challenges and present current standardiza-tion efforts.

By no means have we presented an exhaustive list ofopportunities. We believe additional challenges and oppor-tunities for research exists along a broad spectrum rangingfrom SDN solutions used in converged packet and circuitswitched networks to formal modeling and model check-ing to improve the trustworthiness of the SDN-basedsolutions.

172117221723

References

[1] A. Metzger, C.C. Marquezan, Future internet apps: the next wave ofadaptive service-oriented systems, in: ServiceWave, 2011, pp. 230–241.

[2] C.C. Marquezan, A. Metzger, K. Pohl, V. Engen, M. Boniface, S.Phillips, Z. Zlatev, Adaptive Web Services for Modular and ReusableSoftware Development: Tactics and Solution, IGI, 2012, Ch.Adaptive Future Internet Applications: Opportunities andChallenges for Adaptive Web Services Technology.

[3] N. McKeown, Software-defined networking, INFOCOM keynote talk,April.

[4] H. Kim, N. Feamster, Improving network management withsoftware defined networking, Communications Magazine, vol. 51(2), IEEE, 2013, pp. 114–119.

[5] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,J. Rexford, Openflow: enabling innovation in campus networks,ACM SIGCOMM Comput. Commun. Rev. (2008) 69–74.

[6] ONF, The openflow 1.3.1 specification, Tech. rep.[7] C. Lam, H. Liu, B. Koley, X. Zhao, V. Kamalov, V. Gill, Fiber optic

communication technologies: what’s needed for datacenternetwork operations, IEEE Commun. Mag.

[8] L. Suresh, J. Schulz-Zander, R. Merz, A. Feldmann, T. Vazao, Towardsprogrammable enterprise wlans with odin, HotSDN 12 (2012) 115–120.

[9] M. Bansal, J. Mehlman, S. Katti, P. Levis, Openradio: a programmablewireless dataplane, HotSDN 12 (2012) 109–114.


[10] K.-K. Yap, M. Kobayashi, R. Sherwood, T.-Y. Huang, M. Chan, N.Handigol, N. McKeown, Openroads: empowering research inmobile networks, SIGCOMM Comput. Commun. Rev. 40 (1) (2010)125–126.

[11] J. Vasseur, J. Leroux, S. Yasukawa, S. Previdi, P. Psenak, P. Mabbey,Routing Extensions for Discovery of Multiprotocol (MPLS) LabelSwitch Router (LSR) Traffic Engineering (TE) Mesh Membership,2007.

[12] J. Turner, D. Taylor, Diversifying the internet, in: GlobalTelecommunications Conference, 2005, GLOBECOM ’05, vol. 2,IEEE, 2005.

[13] A. Feldmann, Internet clean-slate design: what and why?,SIGCOMM Comput Commun. Rev. 37 (3) (2007) 59–64.

[14] S. Paul, J. Pan, R. Jain, Architectures for the future networks and thenext generation internet: a survey, Comput. Commun. 34 (1) (2011)2–42.

[15] M. Berman, J.S. Chase, L. Landweber, A. Nakao, M. Ott, D.Raychaudhuri, R. Ricci, I. Seskar, Geni: a federated testbed forinnovative network experiments, Comput. Netw. 61 (0) (2014)5–23. <http://www.geni.net/>.

[16] http://www.ict-fire.eu/home.html.[17] P. Frosi, L.J. Camargos, R. Pasquini, M.S. Soares, L.F. Faina, D.M.F.O.

Silva, P.R.S.L. Coelho, V.B. Bernal, S.T. Kofuji., Experimenting domaintitle service to meet mobility and multicast aggregation by usingopenflow, September 2011.

[18] M. Sun, L. Bergesio, H. Woesner, T. Rothe, A. Kpsel, D. Colle, B.Puype, D. Simeonidou, R. Nejabati, M. Channegowda, M. Kind, T.Dietz, A. Autenrieth, V. Kotronis, E. Salvadori, S. Salsano, M. Krner, S.Sharma, Design and implementation of the OFELIA FP7 facility: theEuropean openflow testbed, Comput. Netw. 61 (0) (2014) 132–150.<http://www.fp7-ofelia.eu/>.

[19] M. Kind, F. Westphal, A. Gladisch, S. Topp, Splitarchitecture:applying the software defined networking concept to carriernetworks, in: World Telecommunications Congress (WTC), 2012,pp. 1–6. <http://www.fp7-sparc.eu/>.

[20] H. Harai, Akari architecture design for new generation network, in:Summer Topical Meeting, 2009 (LEOSST ’09), IEEE/LEOS, 2009, pp.155–156.

[21] Y. Kanaumi, S. Saito, E. Kawai, S. Ishii, K. Kobayashi, S. Shimojo, Rise:a wide-area hybrid openflow network testbed, IEICE Trans. 96-B (1)(2013) 108–118.

[22] O.N. Foundation, Onf overview, 2013. <https://www.opennetworking.org/about/onf-overview>.

[23] L. Foundation, Opendaylight: an open source community andmeritocracy for software-defined networking, A Linux FoundationCollaborative Project, April 2013. <http://www.opendaylight.org/resources/publications>.

[24] E. Haleplidis, S. Denazis, K. Pentikousis, J.H. Salim, O. Koufopavlou,Sdn layers and architecture terminology, Tech. rep. 01, 2013.

[25] A. Doria, J.H. Salim, R. Haas, H. Khosravi, W. Wang, L. Dong, R. Gopal,J. Halpern, Forwarding and control element separation (forces)protocol specification, 2010.

[26] L. Yang, R. Dantu, T. Anderson, R. Gopal, Forwarding and controlelement separation (forces) framework, 2004.

[27] L. Dong, A. Doria, R. Gopal, R. HAAS, J.H. Salim, H. Khosravi, W.Wang, Forces protocol specification, Tech. rep. draft-ietf-forces-protocol-17, 2008.

[28] I. Kovacevic, Forces protocol as a solution for interaction of controland forwarding planes in distributed routers, in: 17thTelecommunications Forum TELFOR, 2009, pp. 529–532.

[29] R. Haas, Forwarding and control element separation (forces) mib,2010.

[30] A. Crouch, H. Khosravi, A. Doria, X. Wang, K. Ogawa, Forwarding andcontrol element separation (forces) applicability statement, 2010.

[31] E. Haleplidis, O. Koufopavlou, S. Denazis, Forwarding and controlelement separation (forces) implementation experience, 2011.

[32] J. Halpern, J.H. Salim, Forces forwarding element model, Tech. rep.draft-ietf-forces-model-15, 2008.

[33] R. HAAS, Forces mib, Tech. rep. draft-ietf-forces-mib-10, 2008.[34] E. Haleplidis, O. Cherkaoui, S. Hares, W. Wang, Forwarding and

control element separation (forces) openflow model library, Tech.rep. draft-haleplidis-forces-openflow-lib-01, 2012.

[35] D. Liu, B. Khasnabish, H. Deng, Architecture discussion of i2rs, Tech.rep. 02, 2013.

[36] IUT FG NGN, The softrouter concept and the proposal for the studyof separation of forwarding and routing in the next generationnetwork, 2004.


http://www.geni.net/

http://www.ict-fire.eu/home.html

http://www.fp7-ofelia.eu/

http://www.fp7-sparc.eu/

http://https://www.opennetworking.org/about/onf-overview

http://https://www.opennetworking.org/about/onf-overview

http://www.opendaylight.org/resources/publications

http://www.opendaylight.org/resources/publications


1724172517261727172817291730173117321733173417351736173717381739174017411742174317441745174617471748174917501751175217531754175517561757175817591760176117621763176417651766176717681769177017711772177317741775177617771778177917801781178217831784178517861787178817891790179117921793179417951796179717981799180018011802

1803180418051806180718081809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851185218531854185518561857185818591860186118621863186418651866186718681869187018711872187318741875187618771878187918801881



24 October 2014

Q1

[37] Object Management Group, SDN Application Ecosystem RFI,Software Defined Networking (SDN) Working Group Mars,2013.

[38] Object Management Group, Data-Distribution Service for Real-TimeSystems - Version 1.2, January 2007. <http://portals.omg.org/dds/>.

[39] W. Kim, P. Sharma, J. Lee, S. Banerjee, J. Tourrilhes, S.-J. Lee, P.Yalagandula, Automated and scalable qos control for networkconvergence, in: Proceedings of the 2010 Internet NetworkManagement Conference on Research on Enterprise Networking,INM/WREN’10, 2010.

[40] Z. Cai, A.L. Cox, T.S.E. Ng, Maestro: a system for scalable openflowcontrol, Tech. rep., 2010.

[41] A. Voellmy, H. Kim, N. Feamster, Procera: a language for high-levelreactive network control, HotSDN 12 (2012) 43–48.

[42] T. Amin, G. Yashar, Hyperflow: a distributed control plane foropenflow, 2010.

[43] K. Teemu et al., Onix: a distributed control platform for large-scaleproduction networks, OSDI’10, 2010, pp. 1–6.

[44] A.S.-W. Tam, K. Xi, H.J. Chao, Use of devolved controllers in datacenter networks, CoRR.

[45] H.Y. Soheil, G. Yashar, Kandoo: a framework for efficient andscalable offloading of control applications, 2012, pp. 19–24.

[46] M.O.S. Volkan Yazici, A.O. Ercan, Controlling a software-definednetwork via distributed controllers, in: 2012 NEM SummitProceedings.

[47] Z. Cao, Z. Li, Analysis of sdn controller cluster in large-scaleproduction networks, Tech. rep. 00, 2013.

[48] B. Heller, R. Sherwood, N. McKeown, The controller placementproblem, in: Proceedings of the First Workshop on Hot Topics inSoftware Defined Networks, HotSDN ’12, 2012.

[49] T. Nadeau, P. Pan, Framework for software defined networks,Internet-Draft draft-nadeau-sdn-framework-01, Internet-Draft,October 2011.

[50] D.G. Underhill, An extensible network visualization and controlframework, Thesis, Stanford University.

[51] Scalable adaptive graphics environment. <http://www.openflow.org/wp/gui/>.

[52] M.C. Andrea Simeoni, Extension of the OpenFlow framework tofoster the Software Defined Network paradigm in the FutureInternet, 2011.

[53] S. Shin, J. Kim, Toward service-aware flow visualization overopenflow-based programmable networks 8–13, 2011.

[54] S. Natarajan, X. Huang, An interactive visualization frameworkfor next generation networks, in: Proceedings of the ACMCoNEXT Student Workshop, CoNEXT ’10 Student Workshop,2010, pp. 1–14.

[55] D. Mattos, N. Fernandes, V. da Costa, L. Cardoso, M. Campista,L.H.M.K. Costa, O. Duarte, Omni: Openflow managementinfrastructure, in: Network of the Future (NOF), 2011International Conference on the, 2011, pp. 52–56. <http://www.gta.ufrj.br/omni/>.

[56] FI-WARE Consortium, Future internet core platform, Tech. rep.D2.2, Europeen 7th FP, November 2011. <http://www.fi-ware.eu/>.

[57] G. Huang, C.-N. Chuah, S. Raza, S. Seetharaman, Dynamicmeasurement-aware routing in practice, IEEE Netw. 25 (3) (2011)29–34.

[58] R. Antonello, S. Fernandes, C. Kamienski, D. Sadok, J. Kelner, I.Gódor, G. Szabó, T. Westholm, Deep packet inspection tools andtechniques in commodity platforms: challenges and trends, J. Netw.Comput. Appl. 35 (6) (2012) 1863–1878.

[59] G. Malkin, RIP Version 2 – Carrying Additional Information, RFC1723 (Standard), 1994.

[60] Y. Rekhter, T. Li, S. Hares, A Border Gateway Protocol 4 (BGP-4), RFC4271 (Draft Standard), 2006.

[61] N. Feamster, H. Balakrishnan, J. Rexford, A. Shaikh, J. van derMerwe, The case for separating routing from routers, in:Proceedings of the ACM SIGCOMM Workshop on FutureDirections in Network Architecture, FDNA ’04, 2004, pp. 5–12.

[62] M. Schlansker, Y. Turner, J. Tourrilhes, A. Karp, Ensemble routing fordatacenter networks, in: Proceedings of the 6th ACM/IEEESymposium on Architectures for Networking andCommunications Systems, ANCS ’10, 2010.

[63] A. Bianco, R. Birke, L. Giraudo, M. Palacin, Openflow switching: dataplane performance, in: 2010 IEEE International Conference onCommunications (ICC), 2010.

[64] Z. Cai, F. Dinu, J. Zheng, A.L. Cox, T.S.E. Ng, Contract: incorporatingcoordination into the ip network control plane, in: Proceedings ofthe 2010 IEEE 30th International Conference on DistributedComputing Systems, ICDCS ’10, 2010, pp. 189–198.


[65] F. Nmeth, A. Stipkovits, B. Sonkoly, A. Gulyás, Towards smartflow:case studies on enhanced programmable forwarding in openflowswitches, SIGCOMM Comput. Commun. Rev. 42 (4) (2012) 85–86.

[66] F.O. Silva, M.A. Gonalves, J.H. de S. Pereira, L.J. Camargos, R.Pasquini, P.F. Rosa, S.T. Kofuji, Implementing the domain titleservice atop openflow, May 2012.

[67] Y. Nakagawa, K. Hyoudou, T. Shimizu, A management method of ipmulticast in overlay networks using openflow, in: Proceedings ofthe First Workshop on Hot Topics in Software Defined Networks,HotSDN ’12, 2012, pp. 91–96.

[68] S. Civanlar, M. Parlakisik, A.M. Tekalp, B. Gorkemli, B. Kaytaz, E.Onem, A qos-enabled openflow environment for scalable videostreaming, in: IEEE Globecom Workshops.

[69] H.E. Egilmez, B. Gorkemli, A.M. Tekalp, S. Civanlar, Scalable videostreaming over openflow networks: an optimization framework forqos routing, in: ICIP, 2011, pp. 2241–2244.

[70] H.E. Egilmez, S.T. Dane, B. Gorkemli, A.M. Tekalp, Openqos:openflow controller design and test network for multimediadelivery with quality of service, NEM Summit.

[71] A.T.H.E. Egilmez, S. Civanlar, A distributed qos routing architecturefor scalable video streaming over multi-domain openflownetworks, in: Proc. IEEE International Conference on ImageProcessing (ICIP 2012).

[72] H. Egilmez, Adaptive video streaming over openflow networks withquality of service, Ph.D. thesis, Koç University, 2012.

[73] R. Penno, T. Reddy, M. Boucadair, D. Wing, S. Vinapamula,Application enabled sdn (a-sdn), Tech. rep. 01, 2013.

[74] E. Kissel, G. Fernandes, M. Jaffee, M. Swany, M. Zhang, Drivingsoftware defined networks with xsp, SDN’12, 2012.

[75] J. Soeurt, I. Hoogendoorn, Shortest path forwarding using openflow,Tech. rep., February 2012.

[76] C. Kolias, Openflow & sdnfornetworkproviders: smart devices needsmartnetworks, November 2011.

[77] H. Yin, H. Xie, T. Tsou, D. Lopez, P. Aranda, R. Sidi, Sdni: a messageexchange protocol for software defined networks (sdns) acrossmultiple domains, Tech. rep. draft-yin-sdn-sdni-00.txt, 2012.

[78] M. Boucadair, C. Jacquenet, Requirements for Automated(Configuration) Management, Internet-Draft draft-boucadairnetwork-automation-requirements-01, IETF Secretariat,June 2013.

[79] S. Shah, K. Patel, S. Bajaj, L. Tomotaki, M. Boucadair, Inter-domainSLA Exchange, Tech. rep. draft-ietf-idrsla-exchange-01, June 2013.

[80] J.R.W. Liu, J. Wang, A unified framework for software-definedinformation-centric network, Tech. rep. 00, 2013.

[81] A. Detti, N. Blefari Melazzi, S. Salsano, M. Pomposini, Conet: acontent centric inter-networking architecture, in: Proceedings ofthe ACM SIGCOMM Workshop on Information-Centric Networking,ICN ’11, 2011, pp. 50–55.

[82] N. Blefari-Melazzi, A. Detti, G. Morabito, S. Salsano, L. Veltri,Information centric networking over {SDN} and openflow:architectural aspects and experiments on the {OFELIA} testbed,Computer Networks.

[83] FP7-ICT-SAIL, SAILScalable and Adaptable Internet Solutions,Techreport, d-5.2 (D-D.1) Cloud Network ArchitectureDescription, July 2011.

[84] B.J. Ko, V. Pappas, R. Raghavendra, Y. Song, R.B. Dilmaghani, K.-w.Lee, D. Verma, An information-centric architecture for data centernetworks, 2012, pp. 79–84.

[85] P. Pan, T. Nadeau, Software-defined network (sdn) problemstatement and use cases for data center applications, Tech. rep.00, 2013.

[86] D. Drutskoy, E. Keller, J. Rexford, Scalable network virtualization insoftware-defined networks, 2012.

[87] C. Rotsos, R. Mortier, A. Madhavapeddy, B. Singh, A.W. Moore, Cost,performance & flexibility in openflow: pick three, in: ICC, IEEE,2012, pp. 6601–6605.

[88] R. Raghavendra, J. Lobo, K.-W. Lee, Dynamic graph query primitivesfor sdn-based cloudnetwork management, 2012, pp. 97–102.

[89] P. Pisa, N. Fernandes, H. Carvalho, M. Moreira, M. Campista, L. Costa,O. Duarte, Openflow and xen-based virtual network migration, in:Communications: Wireless in Developing Countries and Networksof the Future, vol. 327, 2010, pp. 170–181.

[90] S. Ghorbani, M. Caesar, Walk the line: consistent network updateswith bandwidth guarantees, in: Proceedings of the First Workshopon Hot Topics in Software Defined Networks, HotSDN ’12, 2012.

[91] T. Benson, A. Akella, A. Shaikh, S. Sahu, Cloudnaas: a cloudnetworking platform for enterprise applications, 2011.

[92] E. Keller, S. Ghorbani, M. Caesar, J. Rexford, Live migration of anentire network (and its hosts), October 2012.


http://portals.omg.org/dds/

http://www.openflow.org/wp/gui/

http://www.openflow.org/wp/gui/

http://www.gta.ufrj.br/omni/

http://www.gta.ufrj.br/omni/

http://www.fi-ware.eu/


188218831884188518861887188818891890189118921893189418951896189718981899190019011902190319041905190619071908190919101911191219131914191519161917191819191920192119221923192419251926192719281929193019311932193319341935193619371938193919401941194219431944194519461947194819491950195119521953195419551956

195719581959196019611962196319641965

1966

19681968

196919701971197219731974197519761977197819791980198119821983198419851986198719881989

19911991

19921993Q41994199519961997199819992000200120022003200420052006200720082009201020112012

20142014

201520162017201820192020202120222023202420252026202720282029



24 October 2014

Q1

[93] V.S. Zaborovsky, A. Lukashin, S. Kupreenko, V. Mulukha, Dynamicaccess control in cloud services, in: SMC, 2011, pp. 1400–1404.

[94] Pantou, Open wireless freedom. <https://openwrt.org/>.[95] OpenFlowHub, Indigo – open source openflow switches. <http://

www.openflowhub.org/display/Indigo>.[96] D. Liu, H. Deng, Mobility support in software defined networking,

Tech. rep. 00, 2013.[97] T. Hau, D. Burghardt, W. Brenner, Multihoming, content delivery

networks, and the market for internet connectivity, Telecommun.Policy 35 (2011) 532–542.

[98] F. den Hartog, P. Nooren, A. Delphinanto, E. Fledderus, Onmanaged services lanes and their use in home networks, in:Proceedings of the 2013 ACM Conference on Pervasive andUbiquitous Computing Adjunct Publication, UbiComp ’13Adjunct, 2013, pp. 769–776.

[99] Y. Zhang, J. Luo, H. H fnfu, Wireless mesh networking: architectures,in: Protocols and Standards, Wireless Networks and MobileCommunications, Taylor & Francis, 2006. <http://books.google.fr/books?id=7t4szWRwnFkC>.

[100] Y. Peng, Y. Yu, L. Guo, D. Jiang, Q. Gai, An efficient joint channelassignment and qos routing protocol for {IEEE} 802.11 multi-radiomulti-channel wireless mesh networks, J. Netw. Comput. Appl. 36(2) (2013) 843–857.

[101] I. Ahmed, A. Mohammed, H. Alnuweiri, On the fairness of resourceallocation in wireless mesh networks: a survey, Wirel. Netw. 19 (6)(2013) 1451–1468.

[102] P. Dely, Towards an architecture for openflow and wireless meshnetworks, Ofelia Summer School.

[103] I. COMCAS (Ed.), Wireless Software Defined Networks: Challengesand Oppportunities, 2013.

[104] N. Bayer, P. Dely, A. Kassler, Openflow for wireless mesh networks,IEEE International Workshop on Wireless Mesh and Ad HocNetworks (WiMAN 2011).

[105] K.-H. Kim, S.-J. Lee, P. Congdon, On cloud-centric networkarchitecture for multi-dimensional mobility, 2012.

[106] R. Bifulco, M. Brunner, R. Canonico, P. Hasselmeyer, F. Mir,Scalability of a mobile cloud management system, 2012.

[107] L.D. Mendes, J.J. Rodrigues, A survey on cross-layer solutions forwireless sensor networks, J. Netw. Comput. Appl. 34 (2) (2011)523–534.

[108] T. Luo, H.-P. Tan, T.Q.S. Quek, Sensor openflow: enabling software-defined wireless sensor networks, IEEE Commun. Lett. 16 (11)(2012) 1896–1899.

[109] M. Peng, D. Liang, Y. Wei, J. Li, H.-H. Chen, Self-configuration andself-optimization in lte-advanced heterogeneous networks,Commun. Mag., IEEE 51 (5).

[110] S. Costanzo, L. Galluccio, G. Morabito, S. Palazzo, Software definedwireless networks: unbridling sdns, in: Proceedings of EuropeanWorkshop on Software Defined Networking.

[111] M. Mendonca, K. Obraczka, T. Turletti, The case for software-defined networking in heterogeneous networked environments, in:ACM-CoNEXT 2012, 2012, pp. 59–60.

[112] L.L. Erran, M.Z. Morley, J. Rexford, Cellsdn: software-definedcellular networks, Tech. rep., 2012.

[113] S. Kumar, J. Turner, J. Williams, Advanced algorithms for fast andscalable deep packet inspection, in: Proceedings of the 2006 ACM/IEEE Symposium on Architecture for Networking andCommunications Systems, ANCS ’06, 2006, pp. 81–92.

[114] L.E. Li, Z.M. Mao, J. Rexford, Toward software-defined cellularnetwork, in: Proceedings of European Workshop on SoftwareDefined Networking.

[115] K.-K. Yap, M. Kobayashi, D. Underhill, S. Seetharaman, P. Kazemian,N. McKeown, The stanford openroads deployment, WINTECH ’09,2009, pp. 59–66.

[116] J. Gozalvez, M.C. Lucas-Estañ, J. Sanchez-Soriano, Joint radioresource management for heterogeneous wireless systems, Wirel.Netw. 18 (4) (2012) 443–455.

[117] H. Chan, D. Liu, P. Seite, H. Yokota, J. Korhonen, Requirements fordistributed mobility management, Tech. rep. draft-ietf-dmm-requirements-09.txt, 2013.

[118] M. Wasserman, S. Hartman, D. Zhang, Security analysis of the opennetworking foundation (onf) openflow switch specification,Internet-Draft draft-mrw-sdnsec-openflow-analysis-00,informational, October 2012.

[119] S. Project. <http://www.snort.org/>.


[120] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, G. Gu, AFramework for Enabling Security Controls in OpenFlow Networks,ACM, 2012.

[121] K.-K. Yap, Y. Yiakoumis, M. Kobayashi, S. Katti, G. Parulkar, N.McKeown, Separating authentication, access and accounting: acase study with openwifi, Tech. rep., 2011.

[122] J.H. Jafarian, E. Al-Shaer, Q. Duan, Openflow random host mutation:transparent moving target defense using software definednetworking, HotSDN ’12, 2012, pp. 127–132.

Akram Hakiri is an Associate Professor ofComputer Science at the University of Haute-Alsace, and Junior Research Scientist at MIPS-Labs and Visitor Research Scientist at theInstitute for Software Integrated Systems(ISIS) at Vanderbilt University, Nashville, TN,USA. His current research focuses on devel-oping novel solutions to emerging challengesin wireless sensor networks, Cloud comput-ing, OpenFlow-based SDN Networks, multi-network communication architecture,dynamic QoS provisioning for distributed

computing over heterogeneous networks and multi-technologies com-munication systems. He is a TPC member of different journals and con-ferences since 2010. He received his M.S. thesis from Paul Sabatier
University in Toulouse, France, and he worked in wireless sensor net-works for Spatial and Aeronautic Systems. He is engineer of ComputerScience and Automatics from the National Institute of Applied science andTechnology (INSAT) in Tunisia. He was a member of technical staff atLAAS-CNRS Laboratories.
Aniruddha Gokhale is an Associate Professorin the Department of Electrical Engineeringand Computer Science, and Senior ResearchScientist at the Institute for Software Inte-grated Systems (ISIS) both at Vanderbilt Uni-versity, Nashville, TN, USA. He has over 150technical articles to his credit focusing ontopics pertaining to model-driven engineering(MDE), middleware solutions involving designpatterns for quality of service (QoS) assurance,and correct-by-construction design anddevelopment of distributed real-time and

embedded systems. His current research focuses on developing novelsolutions to emerging challenges in cloud computing and cyber physicalsystems. He obtained his B.E. (Computer Engineering) from University of
Pune, India, 1989; M.S. (Computer Science) from Arizona State University,1992; and D.Sc. (Computer Science) from Washington University in St.Louis, 1998. Prior to joining Vanderbilt, he was a member of technicalstaff at Lucent Bell Laboratories, NJ. He is a Senior member of both IEEEand ACM.
Pascal Berthou is an Associate Professor ofComputer Science in the University of Tou-louse, France and Senior Research Scientist atLAAS-CNRS French research Labs, Toulouse-France. He has over 120 technical articles tohis credit focusing on topics pertaining tonetwork QoS-support for distributed interac-tive simulation, wireless sensor networks,multi-network communication architecture,multimedia applications over QoS-basedbroadband satellite systems, and networkEmulation. Before, He received his M.S. thesis

from the Institute of Polytechnics of Toulouse, where he worked on dis-tributed and parallel network computing.


http://https://openwrt.org/

http://www.openflowhub.org/display/Indigo

http://www.openflowhub.org/display/Indigo

http://books.google.fr/books?id=7t4szWRwnFkC

http://books.google.fr/books?id=7t4szWRwnFkC

http://www.snort.org/


20312031

2032203320342035203620372038203920402041204220432044204520462047204820492050205120522053

20552055

205620572058205920602061206220632064206520662067206820692070



24 October 2014

Q1

Douglas C. Schmidt is a Professor of Com-puter Science, Associate Chair of the Com-puter Science and Engineering program, anda Senior Researcher at the Institute at Soft-ware Integrated Systems, all at VanderbiltUniversity. He has published 10 books andmore than 500 technical papers covering awide range of software-related topics,including patterns, optimization techniques,and empirical analyses of object-orientedframeworks and domain-specific modelingenvironments that facilitate the develop-

ment of DRE middleware and mission-critical applications running overdata networks and embedded system interconnects. In addition to hisacademic research, He has led the development of ACE, TAO, CIAO, and

2071207220732074207520762077

CoSMIC for the past two decades. These technologies are open-sourceDRE middleware frameworks and model-driven tools used successfullyby thousands of companies and agencies worldwide in many domains,including national defense and security, datacom/telecom, financialservices, medical engineering, and massively multiplayer onlinegaming.


Thierry Gayraud is Full Professor of ComputerScience at the University of Science, Toulouse,France and Senior Research Scientist at LAAS-CNRS (SARA Team). He has published morethan 200 technical papers covering a widerange of network-related topics, includingwireless sensor networks, cyber-physicalsystems, distributed interactive simulation,multi-technologies networks, and QoS sup-port over heterogeneous networks and satel-lite access networks. With a background ofmore than 10 years in satellite networking,

his current research focuses on developing novel solutions to emergingchallenges in session protocols like SIP and QoS mapping mechanisms,mobility support architectures with QoS support, sensor networks and

2078

related applications, green networking and longer lifetime networkdevices. He was the scientific contact person in LAAS in EU IST projectSATIP6 and IST SatSix project, in French projects as PlatSim on distributedsimulations over LAN and WAN. He is a reviewer for various journals andconferences, TPC member of the main IEEE Comm. Soc. conferences likeGLOBECOM, ICC and WCNC conferences since 2006, and track chair of Ad-Hoc and Sensor Networks at IFIP Wireless Days conference since 2012.



software-defined networking: challenges and research ...wiki.occc.ir/images/sdn7.pdf · 2.1. sdn...

Documents