Disclaimer: This dissertation has been written by a student and is not an example of our professional work, which you can see examples of here.

Any opinions, findings, conclusions, or recommendations expressed in this dissertation are those of the authors and do not necessarily reflect the views of UKDiss.com.

Software-Defined Networking Control Challenges and Countermeasures: A Survey

Info: 9759 words (39 pages) Dissertation
Published: 10th Dec 2019

Reference this

Tags: Computer Science

Software-Defined Networking Control Challenges and Countermeasures: A survey



Security if a constant moving target, it shouldn’t come as a

surprise that cybersecurity is a different beast than it was 10,

or even 5 years ago. While traditional cyber threats such as

adware and spam emails are certainly still alive and kicking,

the threat surface has grown enormously with the advent of

Internet of Things (IoT) and cyber physical systems [20],

mobility, bring your own device (BYOD), and the cloud. It’s

a basic equation the more interconnected we get, the more

devices, the more digital traffic there is, control declines,

the more crevices there are for cyber threats to exploit

[23]. IoT is an information network of physical objects

(sensors, machines, cars, buildings, and other items) that

allows interaction and cooperation of these objects to reach

common goals over a network [14]. Applications include

among others smart cities, transportation, healthcare, smart

homes, smart grid and industrial environments [18].

Fig. 1 depicts the comparison of high level transformation

of traditional networking architecture and SDN architecture.

SDN is regarded as the hardware independent next gen-

eration networking paradigm in which networking device

from any vendors could be controlled through SDN. SDN

has decoupled data plane and control plane. The control

mechanism provided by SDN can lower the complexity

of IoT Computing architectures and implementations by

bringing novel approach to the networking and utilizing the

available resources in a more efficient manner. For instance,

a system that incorporates edge servers into the traditional

cloud data center, the traffic originated at the edge can be

dynamically routed to the tier and server that may provide

the highest quality service to the user by using the available

SDN mechanisms [21].

SDNs logically centralized control and programmable

interfaces are being used as a new way to look out for the res-

olution to many fault management issues which exist today,

for example, a global network view adds many possibilities

to the process of fault localization [24], [25], [27].

SDN architecture is composed of three layers: infras-

tructure layer/Data layer, which is exclusively responsible

for data forwarding and statistics storage, control layer,

which maintains the network view and provides core network

functions, and application layer, which uses abstractions

provided by control layer to implement network business ap-

plications(e.g. firewall, load balancer), enforcing networking

policies and requirements [22].

Fig. 1.

Comparison of traditional network architecture and Software-

Defined Networking

SDNs layered architecture presents new points for security

attacks, and even augments some issues already present in

legacy networks. SDN layers have independent and interde-

pendent security threat vectors. For instance, an intrusion

or Denial-of-service (DoS) attack on the controller may

compromise the entire network services affecting data plane.

In summary, as SDN brings new ways to tackle classic

network security issues it also brings new threat vectors that

need to be addressed.

Some of the attacks include; spoofing attacks, intrusion

attacks, anamoly attacks, DoS and DDoS attacks.They affect

data layer, control layer, data control interface, application

layer, application control interface, which results into rule

modification, leakage of data, malicious applications, unau-

thorized entry, entry of bugs, application failures, modifica-

tion of data, denial of service, flooding the controller and

flooding flow entries [28].

1.1 Survey organization

In this survey paper is organized as follows. Section II

provides background on SDN. Section III Security issues

in SDN. In Section IV provides a detailed study on SDN

security aspects pertaining to control plane.

The aim of this survey paper is to provide the recent works

towards the security aspects of SDN with a more focus on

various security threats that are resolved by SDN and new

threats that arise as a result of SDN implementation. Further,

present various security threats that are resolved by SDN andnew threats that arise as a result of SDN implementation.


In this section we provide a detailed view of SDN archi-

tecture and how it relates to security issues in SDN.

A. Software-Defined Network Architecture

In traditional networks, control plane and data plane

are tightly coupled in network devices. Conversely, SDN

keeps only data forwarding functionality in network devices,

whereas it delegates control plane functionality to a physi-

cally separate layer, composed of one or more network enti-

ties called controllers, which provide the interface between

the high-level network applications and the network devices

[12]. The basic structure of SDN is represented in Fig. 2. It

consists of three different planes: Application plane, Control

plane and Infrastructure Plane.

1) Infrastructure/Data Plane: Also known as data plane

comprises of network devices such as router, switch and

access point. Both virtual switches such as Open vSwitch,

Indigo, Pica8, Nettle, OpenFlow and physical switches co-

exist in this layer [1], [2], [3]. The main function of the data

plane is forwarding the packets according to the assigned


2) Control Plane: Control layer consists of a controller

which controls the overall SDN functions. This layer acts

as a mediator for infrastructure layer and application layer.

The controller is responsible for managing the entire traffic

flow and solely takes decisions on routing, flow forwarding

and packet dropping through programming [5], [6], [4]. The

controllers in the distributed environment communicate with

each other through east-bound and west-bound interfaces.

The control layer and the infrastructure layer communicate

with each other through south-bound API such as OpenFlow,

NetConf, etc. [2].

3) Application Plane: The Application layer is the fore-

most layer in the SDN as shown in Fig. 2. It is responsible for

handling software related business and security applications.

Network virtualization, Intrusion Detection Systems (IDS),

Intrusion Prevention Systems (IPS), firewall implementation

and mobility management are some examples of applications

handled by this layer. This layer communicates with the con-

trol layer using Application Control Plane Interface (A-CPI)

also called as northbound application interface [8] as shown

in Fig.2.

B. SDN Features

C. SDN Applications


A. Fault Management

1) Fault tolerant programming platforms: Most dis-

tributed control plane architectures share their state

among replicas. This approach, at most, allows ap-

plications to configure consistency level desired. A

more flexible programming platform could give control

to network applications define different fault toler-

ance policies for different events and types of traffic.

Additionally, the programming platform may support

Fig. 2.

Software defined networking architecture

the definition of high-level fault tolerance objectives.

For instance, latest versions of ONOS [35] allow pro-

grammers to create intents, which represent high-level

control desires (e.g., connectivity between two hosts)

that are translated and constantly enforced through

low-level rules.

2) Geo-distributed recovery: Local fault tolerance may

be achieved in a domain through the partitioning

of management among independently managed clus-

ters, where controllers serve as backups to others in

case of failure. How- ever, a failure that affects the

whole domain (e.g. a disaster event) would require

geo-distributed state redundancy in order to recover

functionality. Authentication, latency, and inter-domain

management are some of the issues that must be

addressed in order to achieve efficient geo-distributed

recovery. SDN facilitates coordination between differ-

ent domains with different policies and access policies.

Some efforts proposed inter-domain failure manage-

ment mechanisms [36], [37], however, experiments

showed performance issues, demonstrating that there

is much to be improved. Gramoli et al. [38] showed

that the performance can be improved by extending

SDN with inter-domain communication primitives, in-

dicating that southbound protocol support may help to

achieve higher efficiency.

B. Scalability

1) Controller(s) failure: In a traditional network, when

one or more network nodes fail, flows are routed

through alternative paths/nodes to maintain the traffic

continuity. However, in an SDN architecture, failure

of the controller(s) may result in a chaos for the

specific part(s) of the network controlled by the failed

controller(s) due to two main critical reasons: (i)

The controllers are responsible for all configurations,

operations, and validations of the network topologies,

resources etc. and (ii) data plane devices lack an

ability for an online detour of flows. This problem

may become worse in the single controller design case.

In addition, distributing the load of a failed controllerto other controllers brings extra load on them, which

reduces performances thereby their scalability. This

distribution may even result in a cascading failures of

controllers because it can exceed the capacity of them.

One way to address this problem is to enhance the

network with backup/standby controllers [9], [41]. In

case of the main controller failure, these backup con-

troller(s) may take the responsibility of the network

operations over from the main controller. In this case,

controllers need to be synchronized to be in a consis-

tent status regarding network states.

In [10] , the authors present a disaster-aware control

plane design to reduce controller-related interruptions.

They model the problem of designing a disaster-

resilient control plane problem regarding the number

of controllers, their placement, and the control plane

topology. Pashkov et al. [16] propose a fault-tolerant

control plane design, High-Available Controller (HAC)

architecture, to address the fast recovery of the con-

trol plane by adding an additional cluster middleware

between the controller core and controller network

services and applications.

2) State/policy distribution/consistency: Another impor-

tant prob- lem regarding scalability is the network

state distribution and consistency between controllers

of a control plane. This problem mainly happens in

the distributed and/or hierarchical architectures due to

distribution of network states among controller repli-

cas. In addition, this distribution needs to be fast and

reliable to provide the consistency between controller

instances [30] . Moreover, policy consistency [7] in a

distributed control plane is required because network-

wide policies do not come from a single component

of a network, but rather, they are formed by different

functional modules such as routing, monitoring, and

access control as well as multiple human operators

controlling different parts of the network. These con-

flicts may result in serious inconsistencies such as

violation to another policy and wrong forwarding of

the packet etc. on the data plane. Therefore, more

efficient algorithms and mechanisms are needed to

maintain state/policy consistency among the distributed


Distributing network state among local controllers in

the same domain does not necessarily deal with se-

curity issues. However, the Internet consists of many

networks managed by different authorities. Therefore,

the logically centralized control model of SDN must be

extended to account for inter-domain traffic. This ex-

tension requires peering, thereby state sharing, among

different administrative domains to have a relative

global network view in order to determine the next

hop. However, this distribution has to be secure, pri-

vate, and consistent. In addition, some other critical

questions regarding this sharing are how and what to

exchange with other domains. Yin et al. [99] state that

the types of messages exchanged among controllers

may be various such as reachability information, flow

setup/tear down/update requests, network parameters

(bandwidth, delay, loss etc.), service-level agreements

(SLAs), virtual network information and so on. In

[11], [17], [39], the authors propose a West-East (WE)

Bridge mechanism to enable different SDN adminis-

trative domains to securely peer and cooperate with

each other.

3) Flow rule setup latency: This problem refers to the

delay in new flow rule setup process in the context

of control plane scalability [15]. As explained earlier,

proactive mode and reactive mode are two prominent

modes to setup a new flow rule. The proactive mode

does not impose any latency in the flow rule setup from

the controllers point of view. In the reactive mode,

the controller response time (i.e. delay) is crucial.

Controllers having longer flow rule setup latencies

may not meet requirements of certain applications

such as fast fail-over and reactive routing of latency-

sensitive flows. Therefore, such control planes cannot

be scalable enough to satisfy the network needs. How-

ever, this delay can be relatively reduced by imposing

more controller and switch resources such as CPU,

memory etc. and devolving some control functions to

the switches.

In [42], the authors conduct various setup experi-

ments to test the latency of various controllers by

changing the number of switches, number of threads,

and controller workload. They conclude that adding

more threads beyond the number of switches does

not improve latency, and serving more switches than

available CPUs increases controller response time.

Some studies [13], [26] mitigate the flow rule setup

latency by leveraging the idea of Control Function

Devolvement. This idea relies on the delegation of

some of the control functions to the data plane so as to

alleviate the load on the controller(s), thereby reducing

controller-switch communication frequency.

4) Controller placement: In addition the number of con-

trollers, placement of the controller(s) [19] has impacts

on performance of the network as well. Suboptimal

controller placement affects many other problems such

as flow rule setup latency due to controller-switch

communication delay, controller-controller communi-

cation delay, control plane overhead, fault tolerance,

resiliency and so on. Although there are some studies

addressing this problem in the literature [43], we be-

lieve it is still an ongoing issue and needs further atten-

tion of researchers. Hu et al. [43] propose algorithms

to automate the controller placement decisions given a

physical network and the number of controllers. The

main objective of these algorithms is to maximize

resiliency of SDN to failures. In [45], [49] , the authors

address the controller placement problem to maximize

the reliability of control networks.

Rath et al. [46] present a non-zero-sum game-based

distributed technique to discuss optimal controllerplacement in SDN. Hock et al. [44] introduce the

Pareto-based Optimal COntroller-placement (POCO)

framework, which brings network operators a range

of options to select the controller placement based on

their particular needs regarding the metrics like latency,

load balancing etc. In [47] , the authors focus on the

controller placement problem for WAN. They use the

Spectral Clustering placement algorithm to partition

a large network into several small SDN domains.

Jimenez et al. [48] utilize the algorithm called k-

Critical to discover the minimum number of controllers

and their locations to create a robust control topology

that deals with failures and balances the load among

the selected controllers.

Furthermore, control plane overhead is affected by

the placement of controllers due to traffic between

switches and controllers ( packet in and flow mod

messages) and among controllers (e.g. state sharing).

Obadia et al. [40] challenge the problem of mini-

mizing control overhead by optimizing the number of

controllers and their placement. This approach differs

from others because they target minimization of control

overhead instead of minimization of switch-controller


C. Network update

Network is dynamic and requires update in the operation.

However, many confusions and problems can be caused

by careless schedule in the update process. Although the

problem has been investigated for many years in traditional

networks where the control plane is distributed, software

defined networking (SDN) brings new opportunities and

solutions to this problem by the separation of control and

data plane, as well as the centralized control [50].


Update forwarding policy

Change access list of a


VM migration in Data


Adjust traffic engineering



Forwarding loop, forwarding black hole,

link congestion, network policy viola-


Network policy violation

Forwarding black hole, link congestion

Link congestion




1) Forwarding black hole: The forwarding black hole

confusion refers to the case that a packet entering an

SDN switch cannot match any rule in the forwarding

table during the network updating process.

2) Forwarding loop: The forwarding loop confusion

refers to the case that a packet suffers from forwarding

loops and cannot be delivered to its destination during

network update.

3) Link congestion: The link congestion refers to the

situation that link is congested by flows during the

network update process.

4) Network policy violation: Middleboxes (e.g., Firewall,

NAT, and Proxy) are widely deployed in modern

networks [18]. Packets have to follow network policies

which enforce packets going through a list of mid-

dleboxes. During the network policy update, packets

may violate the policies. Such confusion is known as

network policy violation.

D. Security

Security is a constant moving target, therefore securing the

controller is one of the most critical security measure to be

employed in an SDN network. Some of the security threats


1) An intrusion attack is an unauthorized activity on

a network where attacks absorb network resources

intended for other uses. Due to the reconfigurablity

and programmability of SDN, the SDN can be imple-

mented as Intrusion Detection System (IDS) and Intru-

sion Prevention System (IPS) to monitor the network

activities continuously to detect intrusion attacks. Most

common intrusion attack vectors that can be defended

by using adaptability and programmability of SDN are

a) Asymmetric Routing Attack: The attacker use

more than one route to the targeted network

device to bypass certain network segments and

intrusion sensors. If networks is not set up for

asymmetric routing, they are vulnerable to this


b) Buffer Overflow Attacks: This attack overwrites

specific sections of device memory of a target

network or replaces normal data in certain mem-

ory locations with a malware to attack the net-

work with an aim of initiating denial-of-service.

c) Protocol-Specific Attacks: The network protocols

– such as TCP, UDP, ARP, IP, ICMP etc., may

inadvertently leave a backdoor for network intru-

sions through spoof- ing or so with an aim of

compromising or even crash- ing the targeted de-

vices on a network. For instance, while mapping

IP network addresses to the hardware addresses,

ARP protocol does not perform authentication on

messages, allowing attackers to execute man-in-

the- middle attacks.

d) Traffic Flooding Attacks: Attacker can generate

traf- fic loads too heavy for the network to

overwhelm the overall network resources. These

attacks can be easily controlled using SDN.

e) Trojan based Attack: This attack instigates DoS

attacks, erase stored data or open back doors to

permit system control by outside attackers.

2) Anomaly Attack is caused by unknown user by violat-

ing policies and compromising the entire system. For

instance traffic anomaly, a deviation from the normal

traffic pattern. An intrusion detection system (IDS)

may look for unusual traffic activities, such as a flood

of UDP packets or a new service appearing on the2) Threat vector 2 represents the attacks at SDN switches

in data plane which may occur from the in-flow and

out-flow of traffic.

3) Threat vector 3 represents the attacks that may occur

during the communication of data plane devices with

control plane device (controller).

4) Threat vector 4 represents the attacks on administrators

station which is linked with the controller e.g software

virus attack.

5) Threat vector 5 represents the attacks at the controller.

6) Threat vector 6 represents the attacks that occur be-

tween controller and application layer devices (includ-

ing admin systems).

7) Threat vector 7 represents the attacks targeting com-

munications between data layer and control layer.

8) Threat vector 8 represents the attacks on various ap-

plications running on the network.

9) Threat vector 9 represents the attacks targeting commu-

nications between control layer and application layer.

Fig. 3.

Attack Definition Application


Attacks An unauthorized activity

on a network where at-

tacks absorb network re-

sources intended for other

uses Cloud


smart grids,



data centers











things, data


SDN security threat vector map


3) Distributed Denial-of-Service (DDoS) Attack: DDoS

attacks deny legitimate users to get access to network

services. These attacks can cause a significant damage

by compromising the entire network [33]. Conven-

tional networks have some methods to detect DDoS

attacks and protect the networks but do not offer very

reliable and flexible defense solutions [34].



A. Security

SDN architecture by itself provides some level of security

protection over the network, in other words SDN serves as

a security solution. In this section we present SDN solution

for the different security attacks, before we do that here are

SDN attack vectors.

a. SDN Attack Vectors

Even though many SDN systems are relatively new and

SDN is still in the realm of the early adopters, we can be sure,

that as the technology matures and is more widely deployed,

it will become a target for attackers. It is anticipated that sev-

eral attack vectors will face SDN systems. The more common

SDN security concerns include attacks at the various SDN

architecture layers [29]. Lets look at the anticipated attacks

that could occur at each of these layers following Fig.3.

1) Threat vector 1 represents the fake traffic flows that

occur during intercommunication of SDN devices in

data plane. The attack may occur using the spoofed

identity of legitimate flows or fake identity of the


Anomaly Caused by unknown user


by violating policies and

compromising the entire



Attacker denys legitimate


users to get access to net-

work services





Snort SDN,












privacy away








b. SDN as a security solution

Table 2 displays a summary of the different attacks, thier

definitions, application affected and the proposed defense

technique. The following are various security threats that can

be resolved using SDN [28];

1) SDN as Intrusion Detection System (IDS) and Intrusion

Prevention System (IPS): An intrusion attack is an unautho-

rized activity on a network where attacks absorb network

resources intended for other uses. Due to the reconfigurablity

and programmability of SDN, the SDN can be implemented

as IDS and IPS to monitor the network activities contin-

uously to detect intrusion attacks. Most common intrusion

attack vectors that can be defended by using adaptability

and programmability of SDN are1) Asymmetric Routing Attack: The attacker use more

than one route to the targeted network device to bypass

certain network segments and intrusion sensors. If

networks is not set up for asymmetric routing, they

are vulnerable to this attack.

2) Buffer Overflow Attacks: This attack overwrites spe-

cific sections of device memory of a target network

or replaces normal data in certain memory locations

with a malware to attack the network with an aim of

initiating denial-of-service.

3) Protocol-Specific Attacks: The network protocols –

such as TCP, UDP, ARP, IP, ICMP etc., may inadver-

tently leave a backdoor for network intrusions through

spoof- ing or so with an aim of compromising or

even crash- ing the targeted devices on a network.

For instance, while mapping IP network addresses

to the hardware addresses, ARP protocol does not

perform authentication on messages, allowing attackers

to execute man-in-the-middle attacks.

4) Traffic Flooding Attacks: Attacker can generate traffic

loads too heavy for the network to overwhelm the

overall network resources. These attacks can be easily

controlled using SDN.

5) Trojan based Attack: This attack instigates DoS at-

tacks, erase stored data or open back doors to permit

system control by outside attackers.

2) SDN for Anomaly Detection: Anomaly detection (or

out-lier detection) in a network is the identification of events

or observations which do not conform to an expected pattern.

These days attacks are becoming more sophisticated which

makes it hard to trace the actual origin of the attack [28].

SDN technology gives us a privilege to configure the devices

to serve our need. For instance, home router that is config-

ured using SDN works effectively to detect the malware and

spyware attacking the system [32].

3) SDN for Distributed Denial-of-Service (DDoS) Attack

Detection and Prevention: DDoS attacks deny legitimate

users to get access to network services. These attacks can

cause a significant damage by compromising the entire

network [33]. Conventional networks have some methods to

detect DDoS attacks and protect the networks but do not offer

very reliable and flexible defense solutions [34]. Due to the

programmable features and reconfigurable nature of SDN,

flexible and robust approaches can be designed, deployed

and evaluated to detect and prevent DDoS attacks.

B. Network Update

1) Solution to forwarding black hole

The forwarding black hole results from the reason

that there is no forwarding rule matching the packet.

Mahajan and Wattenhofer propose a solution to this

confusion as add before remove in Ref. [19]. The

scheme suggests that switches should update new

rules first before removing old rules. Then Reitblatt

et al. [20] implement a more generous version of add

before remove on the whole network to solve the

forwarding black hole confusion. As demonstrated in

Fig. 4.

Forwarding black holes solution

Fig. 4, each packet is stamped with a version number k

and forwarded through the network. When the update

process starts, new rules with version number k + 1 are

distributed to switches, while the switches still keep

old rules with version number k. After confirming that

all switches have received the new rules, controller

informs switches of stamping new packets injecting

into the network with new version number k + 1.

Then all switches wait for a time during which all

packets with version number k should have left the

network. After that, switches could remove old rules

with version k. Because switches keep both old and

new rules in forwarding tables during update process,

there will be no forwarding black holes.

2) Solution to forwarding loop

In order to solve forwarding loop confusion, we need

to avoid the existence of the loop during the update

process. We have mentioned that per-packet consis-

tency by Reitblatts solution [20] is a strong consistent

property in last subsection. Indeed, such per-packet

consistency not only keeps the forwarding black hole

free but also holds forwarding loop free.

However, Mahajan and Wattenhofer point out that

Reitblatts solution is too strong for forwarding loop

free property [19]. They show that a careful mix of

the old rule and new rule could hold forwarding-loop

free property. With the help of the example in Fig.

5, we illustrate Mahajan and Wattenhofers solution

to forwarding loop confusion. Fig. 5(a) shows the

forwarding path to node Z before network updating

and Fig. 5(d) shows the forwarding path to node Z

after network updating. All subfigures (a)(d) in Fig.

5 in sequence indicate the update schedule according

to Mahajan and Wattenhofers solution. The update

sequence is W-Y-X. This update schedule is based on

a dependency tree. The dependency tree is constructed

based on the forwarding path to node Z after update

shown in Fig. 5(d) according to principles: destination

node Z is the root of the dependency tree; node W

is the child of node Z and node X and node Y are

children of node W, resulting from node Z is the next

hop for node W and node W is the next hop for node

X and Y, as shown in Fig. 5(d). After building up the

dependency tree, the updating rule will be scheduled

as updating the root first, and then update children of

each node in sequence following the seemingly breadthFig. 5.

Forwarding loop solution

first search (BFS) rule.

3) Solution to link congestion

The link congestion confusion is caused by the over-

loading of link during the update process. Microsoft

demonstrates their inter-data center network solution

to link congestion SWAN [13] in 2013. The main

purpose of SWAN is to highly utilize the network

capacity even the traffic volume varies significantly by

time. SWAN leaves scratch capacity on links. Scratch

capacity will not be used until updating, and it proves

that when setting scratch capacity as s, update could

be finished in 1/s 1 steps without congestion. Idea of

this mechanism is similar to that of ICU [21]. They

both trade updating time with scarce resource which

in SWAN is link capacity and in ICU [21] is TCAM.

zUpdate [22] by Liu et al. aims to eliminate congestion

in data center updating progress. They point out that

in data centers switches utilize equal cost multipath

routing (ECMP) to split traffic evenly among all next

hops to make fully use of the redundant paths [22].

If one link fails, traffic on this link is evenly split

to the remaining links which may cause congestion.

zUpdate breaks the fairness among multiple paths

and split effected traffic on each path carefully when

failure happens. Like [20], optimization programming

model in zUpdate only requires operator to provide

final configuration without paying attention to update


4) Solution to network policy violation

The origin of network policy violation is that a

packet cannot be matched with its original address.

Fayazbakhsh et al. point out that the key to solving

network policy violation con fusion is OriginBinding

[23]. They design a FlowTags mechanism for Orig-

inBinding as shown in Fig. 7. The NAT adds tags to

packets and sends the mapping between original IP and

tag to controller. Switches forward packets according

to tags in packet header. The FW consumes tags. Also,

They compare tags with the mapping received from

the controller and find out the original IP of packets,

so that no matter how many times a packet have

been edited, middleboxes and switches could always

map it with its original IP. For middlebox update

process, a middlebox can change its configuration rules

without worrying about the impact to downstream

middleboxes. In such a manner, network policy always

holds for every packet.

Fayazbakhshs solution helps switches to OriginBind a

packet with its original IP address, but there is still a

problem that may violet security polity. In a case which

is similar to Fig. 7, Host1 is multihoming to SW3.

Therefore, flows from Host1 may visit Internet through

SW3. How can we let flows from Host1 go back to

SW2 and blocked by the FW? Solution to the problem

is called waypoint enforcement provided by Ludwig et

al. [24]. In this case, SW2 is the waypoint that every

flow from Host1 must go through. Ludwigs solution

could guarantee that during update or any cases, flows

will always travel through the selected way point and

therefore security policy is hold.

C. Fault Management

Control plane architectures deal simultaneously with many

issues related to control plane failures.

1) Control plane state redundancy:

Fault-tolerant controller architectures can be catego-

rized with respect to two aspects: control distribution

and state redundancy. Control distribution can be, Cen-

tralized, where a primary controller is responsible for

domain management, while backup controllers keep

their state consistent with the primary, so they can

take over network control in case of primary failure;

or Distributed, where multiple controllers take control

of a network simultaneously, while coordinating with

each other to exchange network information necessary

to process their requests.

Control state redundancy can be achieved through

three approaches: State replication encapsulates net-

work view and/or applications state directly and sends

them to replicas, which must update their states; Event

propagation sends all, or selected, events in the same

order to each replica, so that they can achieve the

same state after event processing; Traffic duplication

replicates all traffic, at switch-level, into replica con-

trollers. Event and traffic replication approaches must

consider ordering, because message reordering may

lead controllers to inconsistent states.

2) Controller failover:

After controller failure, the backup controllers that will

take control of its orphan devices must be chosen

carefully. For example, if the orphan devices are as-

signed to a controller that is only accessed through

a congested link, the request processing latency may

increase. Some fault-tolerant control frameworks focus

on efficient controller failover approaches.Chan et al. [149] propose a fast controller failover

for multidomain SDN (FCF-M). In this distributed

approach, each domain is managed by a controller

which is replicated to a local backup using strong

consistency. Controller failure is detected using a

circular heartbeat mechanism, where each controller

checks whether its predecessor is still alive sending

probe packets. Controller failover is performed lo-

cally, if the backup controller is available, or using

controllers from other domains if necessary. Devices

are assigned to controllers by minimizing controller

distance and verifying whether its residual capacity is

enough to accommodate orphan switches. Otherwise,

orphan switches are distributed among other domain


3) Controller-switch reliable communication:

Since controller state is updated through network

events, if an event is lost it may cause incorrect

behavior. For example, when there is a failure in a

primary controller, a backup replica takes over the

network control. Until this operation is complete, new

requests from switches can not be processed and will

be lost, leading the backup controller to an inconsistent

state. Thus controller-switch communication must be

reliable in order to guarantee network correctness.

Ravana [48] provide a message delivery guarantee

mechanism. During controller and switch communica-

tion, both exchange acknowledgement messages, while

the switch keeps the event in a temporary buffer in

case of controller failure in order to guarantee that

the events will be eventually delivered. The Open-

Flow protocol was also modified in order to support

the exchange of acknowledgment messages between

controller and switch, and buffer operations through

the following messages: EVENT ACK, an event arrival

notification; CMD ACK, a command arrival notification;

EBuf CLEAR and CBuf CLEAR are used to clear

event buffer and command buffer, respectively.

4) Controller placement and assignment:

A controller placement strategy needs to address two

network design choices: How many controllers are

needed and where they should be placed. Research

has demonstrated that the location of a controller can

affect network performance, from latency [50], [155]

to control and data network resiliency [156]. A fault

tolerant controller placement may prioritize different

network aspects, such as failure isolation (e.g. failures

of each partition do not affect others) [156], [157], or

control path resiliency [158]. Most of the approaches

model controller placement using graph representation

[159] or integer linear programming [153]. In general,

resilient controller placement efforts differ with respect

to the fault tolerance aspect they prioritize, metrics that

they consider and methods they use to optimize these


Device assignment is a related problem, where the

switches are assigned to the controllers but the con-

troller location is already defined [160], [161].

Zhang et al. [156] tackle the controller placement mod-

eling as a graph partitioning problem. The proposed

method aims to reduce total failure likelihood min-

imizing inter-partition connectivity, using a modified

version of min-cut, where the network is partitioned

with minimum cuts across boundaries, while balancing

number of devices and links per partition. For each

partition, a controller is assigned to the location which

has the shortest paths to all devices in the same


5) Control Traffic

In this subsection we discuss efforts that focus on

improving control plane fault tolerance by quickly

detecting and responding to control channel failures.

a) Fault detection: Kotani et al. [69] propose a

control channel failure detection method. Each

switch sends probe messages to all controllers,

and as soon as the first one responds, it sets

its channel state to active, otherwise, it is set to

inactive. In order to avoid unnecessary commu-

nication overhead, a switch sends echo request

to control channels only after it sends a network

event to the controller. The controller checks

each switch individually sending an echo request

and, upon reply notification, it updates other

controllers with the information that the switch

is alive.

Lee et al. [11] also propose a failure detection

mechanism. Monitoring circle paths, composed

by a subset of network links, are responsible for

the detection of link failures. Initially, the con-

troller forwards a packet to the circle and waits

for a timeout period. If the controller receives a

response within this period, links of this circle are

considered as healthy, otherwise it starts a failure

location mechanism that sends a packet along the

suspected failed path, where each switch must

send a copy directly to the controller. The node

that does not send the packet is considered faulty.

In in-band control an extra round is performed to

check whether the failure affects control traffic. A

probe is sent along the in-band control tree, and if

one or more controllers fail to reply, the location

is determined by sending a probe packet to each

respective control tree node, and then, the root of

the subtree or leaf that fails to reply is finalized

as the failure location.

b) Fault recovery: Network control can be of two

types, out-of-band, control is performed directly

over dedicated communication channels, and in-

band, the same network is used for data and con-

trol traffic. Usually, in in-band control, switches

need to traverse intermediate devices to reach

con- troller. Consequently, if one intermediate

node fails, control traffic is lost.Petry et al. [177] investigates how cellular data

network can improve control plane resiliency pro-

viding out-of-band control. They added cellular

link between forwarding planes and the controller

that could be used in case of primary link failure.

It was demonstrated that cellular network band-

width was equivalent to ethernet network, while

the delay increased. Authors argue that further

investigation and optimization might be neces-

sary to guarantee that data cellular networks are

robust enough to handle data and control plane

failures. Sharma et al. [178] provide restoration

and protection mechanisms to control traffic in

in-band networks. In control path restoration, the

new path must be restored first on switches closer

to the controller to guarantee that its descending

switches will be able to receive restoration rules.

The controller sends barrier requests, which force

switches to process pending messages in order to

guarantee the restoration of ordering. In control

path protection, disjoint paths are pre-installed on

switches in order to mitigate failures.




[1] F. Hu, Q. Hao, and K. Bao, A survey on software-defined network and

OpenFlow: From concept to implementation, IEEE Commun. Surveys

Tuts., vol. 16, no. 4, pp. 21812206, 4th Quart., 2014.

[2] [7] D. Kreutz et al., Software-defined networking: A comprehensive

survey, Proc. IEEE, vol. 103, no. 1, pp. 1476, Jan. 2015.

[3] W. Stallings, Software-defined networks and OpenFlow, Internet Pro-

tocol J., vol. 16, no. 1, pp. 16, 2013.

[4] Floodlight. Accessed on October 16, 2017 [Online]. Available:


[5] K. Dhamecha and B. Trivedi, SDN issuesA survey, Int. J. Comput.

Appl., vol. 73, no. 18, pp. 3035, 2013.

[6] N. Gude et al., NOX: Towards an operating system for networks, ACM

SIGCOMM Comput. Commun. Rev., vol. 38, no. 3, pp. 105110, 2008.

[7] M. Canini, P. Kuznetsov, D. Levin, S. Schmid, Software transactional

networking: concurrent and consistent policy composition, in: Pro-

ceedings of the Second ACM SIGCOMM Workshop on Hot Topics in

Software Defined Networking, in: HotSDN 13, ACM, New York, NY,

USA, 2013, pp. 16, doi: 10.1145/ 2491185.2491200 .

[8] A. Voellmy, H. Kim, and N. Feamster, Procera: A language for high-

level reactive network control, in Proc. 1st Workshop Hot Topics Softw.

Defined Netw., Helsinki, Finland, 2012, pp. 4348.

[9] F. Botelho, A. Bessani, F. Ramos, P. Ferreira, On the design of

practical fault-tolerant sdn controllers, in: Software Defined Networks

(EWSDN), 2014 Third European Workshop on, 2014, pp. 7378, doi:

10.1109/EWSDN.2014.25 .

[10] S. Sedef Savas, M. Tornatore, M. Farhan Habib, P. Chowdhury,

B. Mukherjee, Disaster-resilient control plane design and mapping in

software-defined networks, ArXiv e-prints (2015).

[11] P. Lin, J. Bi, Z. Chen, Y. Wang, H. Hu, A. Xu, We-bridge: west-east

bridge for sdn inter-domain network peering, in: Computer Communi-

cations Workshops (INFOCOM WKSHPS), 2014 IEEE Conference on,

2014, pp. 111112, doi: 10.1109/INFCOMW.2014.6 84 9180 .

[12] Paulo F., Edjard M, ”A Survey on Fault Management in Software-


RIALS, 2017

[13] M. Yu , J. Rexford , M.J. Freedman , J. Wang , Scalable flow-based

networking with difane, SIGCOMM Comput. Commun. Rev. 41 (4)

(2010) .

[14] Atzori L, Iera A, Morabito G The internet of things: a survey. Comput

Netw 54(15):27872805, 2010

[15] K. He, J. Khalid, S. Das, A. Gember-Jacobson, C. Prakash, A.

Akella, L.E. Li, M. Thottan, Latency in software defined networks:

Measurements and mitigation techniques, in: Proceedings of the 2015

ACM SIGMETRICS International Conference on Measurement and

Modeling of Computer Systems, in: SIGMET-RICS 15, ACM, New

York, NY, USA, 2015, pp. 435436, doi: 10.1145/2745844. 2745880


[16] V. Pashkov, A. Shalimov, R. Smeliansky, Controller failover for sdn

enterprise networks, in: Science and Technology Conference (Modern

Networking Technologies) (MoNeTeC), 2014 International, 2014, pp.

16, doi: 10.1109/MoNeTeC. 2014.6995594 .

[17] P. Lin, J. Bi, Y. Wang, Webridge: west-east bridge for distributed

heterogeneous sdn noses peering, Secur. Commun. Netw. 8 (10) (2015)

19261942, doi: 10.1002/sec.1030 .

[18] Whitmore A, Agarwal A, Da Xu L The internet of thingsa survey

of topics and trends. Inf Syst Front 17(2):261274. doi:10.1007/s10796-

014-9489-2, 2015

[19] B. Heller , R. Sherwood , N. McKeown , The controller placement

problem, in: Proceedings of the first workshop on Hot topics in software

defined networks, in: HotSDN 12, 2012, pp. 712 .

[20] D. B. Rawat, J. J. Rodrigues, and I. Stojmenovi, Cyber-Physical

Systems: From Theory to Practice. Boca Raton, FL, USA: CRC Press,


[21] A. C. Baktir, A. Ozgovde, and C. Ersoy, How Can Edge Computing

Benefit from Software-Defined Networking: A Survey, Use Cases &

Future Directions, Article in IEEE Communications Surveys & Tutorials

June 2017

[22] P. Fonseca and E. Mota, A Survey on Fault Management in Software-


ALS 2017

[23] Security
















[24] S. S. Lee, K.-Y. Li, K. Y. Chan, G.-H. Lai, and Y. C. Chung, Software-

based fast failure recovery for resilient openflow networks, in Reliable

Networks Design and Modeling (RNDM), 2015 7th International Work-

shop on, (Munich,Germany), pp. 194200, IEEE, Oct. 2015.

[25] S. S. Lee, K.-Y. Li, K.-Y. Chan, G.-H. Lai, and Y.-C. Chung, Path

layout planning and software based fast failure detection in survivable

OpenFlow networks, in Design of Reliable Communication Networks

(DRCN), 2014 10th International Conference on the, pp. 18, IEEE,


[26] A.R. Curtis, J.C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma, S.

Banerjee, Devoflow: scaling flow management for high-performance

networks, SIGCOMM Comput. Commun. Rev. 41 (4) (2011) 254265,

doi: 10.1145/2043164.2018466.

[27] U. C. Kozat, G. Liang, and K. Kkten, On diagnosis of forwarding

plane via static forwarding rules in Software Defined Networks, in IEEE

Conference on Computer Communications, INFOCOM 14, (Toronto,

Canada), pp. 17161724, April 2014.

[28] D. B. Rawat, and S. R. Reddy, Software Defined Networking Architec-

ture, Security and Energy Efficiency: A Survey, IEEE COMMUNICA-



[29] SDN
















[30] D. Levin, A. Wundsam, B. Heller, N. Handigol, A. Feldmann, Log-

ically centralized?: State distribution trade-offs in software defined

networks, in: Proceedings of the First Workshop on Hot Topics in

Software Defined Networks, in: HotSDN 12, ACM, New York, NY, USA,

2012, pp. 16, doi: 10.1145/2342441. 2342443 .

[31] H. Yin , H. Xie , T. Tsou , D.R. Lopez , P.A. Aranda , R. Sidi ,

SDNi: A Message Exchange Protocol for Software Defined Networks

(SDNS) across Multiple Domains, Internet-Draft, Internet Engineering

Task Force, 2012.

[32] S. A. Mehdi, J. Khalid, and S. A. Khayam, Revisiting traffic anomaly

detection using software defined networking, in Recent Advances in

Intrusion Detection. Heidelberg, Germany: Springer, 2011, pp. 161180.

[33] Q. Yan and F. R. Yu, Distributed denial of service attacks in software-

defined networking with cloud computing, IEEE Commun. Mag., vol.

53, no. 4, pp. 5259, Apr. 2015.[34] M. Abliz, Internet denial of service attacks and defense mechanisms,

Dept. Comput. Sci., Univ. Pittsburgh, Pittsburgh, PA, USA, Tech. Rep.

TR-11-178, 2011.

[35] P. Berde, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi, T. Koide,

B. Lantz, W. Snow, G. Parulkar, B. OConnor, and P. Radoslavov,

ONOS: Towards an Open, Distributed SDN OS, Proceedings of the

third workshop on Hot topics in software defined networking, pp. 16,

Aug. 2014.

[36] M. Gerola, M. Santuari, E. Salvadori, S. Salsano, P. L. Ventre, M.

Campanella, F. Lombardo, and G. Siracusano, ICONA: Inter Cluster

ONOS Network Application, in Network Softwarization (NetSoft), 2015

1st IEEE Conference on, pp. 12, IEEE, 2015.

[37] K. Kuroki, N. Matsumoto, and M. Hayashi, Scalable OpenFlow

controller redundancy tackling local and global recoveries, in The Fifth

International Conference on Advances in Future Internet, pp. 6166,

Citeseer, 2013.

[38] V. Gramoli, G. Jourjon, and O. Mehani, Disaster-tolerant storage with

SDN, in International Conference on Networked Systems, pp. 293 307,

Springer, 2015.

[39] P. Lin, J. Bi, S. Wolff, Y. Wang, A. Xu, Z. Chen, H. Hu, Y. Lin, A

west-east bridge based sdn inter-domain testbed, Commun. Mag., IEEE

53 (2) (2015) 190197, doi: 10.1109/MCOM.2015.7045408.

[40] M. Obadia, M. Bouet, J.L. Rougier, L. Iannone, A Greedy Ap-

proach for Minimizing SDN Control Overhead, in: Network Soft-

warization (NetSoft), 2015 1st IEEE Conference on, 2015, pp. 15, doi:

10.1109/NETSOFT.2015.7116135 .

[41] P. Fonseca, R. Bennesby, E. Mota, A. Passito, A replication component

for resilient openflow-based networking, in: Network Operations and

Management Symposium (NOMS), 2012 IEEE, 2012, pp. 933939, doi:

10.1109/NOMS.2012. 6212011.

[42] J.C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma, A.R. Curtis, S.

Banerjee, Devoflow: Cost-effective flow management for high perfor-

mance enterprise networks, in: Proceedings of the 9th ACM SIGCOMM

Workshop on Hot Topics in Networks, in: Hotnets-IX, ACM, New York,

NY, USA, 2010, pp. 1:11:6, doi: 10.1145/1868447.1868448 .

[43] Y. nan HU, W. dong WANG, X. yang GONG, X. rong QUE, S. duan

CHENG, On the placement of controllers in software-defined networks,

J. China Univ. Posts Telecommun. 19, Supplement 2 (2012) 92171.

http://dx.doi.org/10. 1016/S1005- 8885(11)60438- X .

[44] D. Hock, M. Hartmann, S. Gebert, M. Jarschel, T. Zinner, P. Tran-

Gia, Pareto-optimal resilient controller placement in sdn-based core

networks, in: Tele-traffic Congress (ITC), 2013 25th International,

2013, pp. 19, doi: 10.1109/ITC. 2013.6662939 .

[45] Y. Hu, W. Wang, X. Gong, X. Que, S. Cheng, On reliability-optimized

controller placement for software-defined networks, Commun., China

11 (2) (2014) 38 54, doi: 10.1109/CC.2014.6821736 .

[46] H. Rath, V. Revoori, S. Nadaf, A. Simha, Optimal controller placement

in soft- ware defined networks (sdn) using a non-zero-sum game,

in: World of Wireless, Mobile and Multimedia Networks (WoWMoM),

2014 IEEE 15th International Symposium on a, 2014, pp. 16, doi:

10.1109/WoWMoM.2014.6918987 .

[47] P. Xiao, W. Qu, H. Qi, Z. Li, Y. Xu, The sdn controller placement prob-

lem for wan, in: Communications in China (ICCC), 2014 IEEE/CIC

International Conference on, 2014, pp. 220224, doi: 10.1109/IC-

CChina.2014.7008275 .

[48] Y. Jimenez, C. Cervello-Pastor, A. Garcia, On the controller placement

for designing a distributed sdn control layer, in: Networking Conference,

2014 IFIP, 2014, pp. 19, doi: 10.1109/IFIPNetworking.2014.6857117 .

[49] Y. Hu , W. Wendong , X. Gong , X. Que , C. Shiduan , Reliability-

aware controller placement for software-defined networks, in: Inte-

grated Network Management (IM 2013), 2013 IFIP/IEEE International

Symposium on, 2013, pp. 672675.

[50] D. LI, S. WANG, K. ZHU, S. XIA, survey of network update in SDN,

Comput. Sci., 2017, 11(1): 412

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this dissertation and no longer wish to have your work published on the UKDiss.com website then please: