INTL JOURNAL OF ELECTRONICS AND TELECOMMUNICATIONS, 2014, VOL. 60, NO. 4, PP.

299–307
Manuscript received September 3, 2014; revised December 2014. DOI: 10.2478/eletel-2014-0039

SDN Controller Mechanisms for Flexible

and Customized Networking
Jacek Wytr˛ebowicz, Thorsten Ries, Khoa Truong Dinh, and Sławomir Kukliński

Abstract—Software-Defined Networking (SDN) is seen as the SDN switches available today (e.g. from BigSwitch, Hewlett-
most promising networking technology today. The spread of Packard, Brocade, IBM, NEC, Pronto, Juniper, Pica8) support
a new technology depends on the acceptance of the engineers OpenFlow in addition to traditional operation and protocols.
implementing the networks. Typically, when engineers start the
conceptualization of new network devices that work with a new The controllers (e.g. NOX, POX, Beacon) are based on generic
paradigm, and that should provide expected business values, high performance server platforms and typically are offered
they must identify and utilize technical enablers for the defined as Open Source software. The principles of their creation and
business use cases. This paper tries to summarize essential SDN evolution were: to have a framework for network application
applications and defines the technical enablers for advanced development, and to provide an experimentation environment
and efficient SDN networking. To this end, we identify the core
technical mechanisms, expecting to provide a useful analysis for that will be verified by community working with the open
the design of new SDN networks. source.
There are other technologies proposed or considered as ap-
Keywords—Software Defined Networking, Network Controller,
SDN Management plicable to SDN: ForCES [2], Path Computation Element [3],
BGP-TE [4], Application Layer Traffic Optimization (ALTO)
[5]. These technologies are rather complementary but in some
I. I NTRODUCTION cases they are also mutually exclusive. For example, the
goal of the Software Driven Network Protocol (SDNP) IETF
INCE its appearance, the SDN paradigm has taken a lot of
S interest by the community of network researchers and de-
signers. The main idea of SDN is to decouple the control plane
working group is to enable existing control planes to become
more adaptable to application requirements. This leads to rapid
and reliable configuration changes between applications and
from the data plane and to centralize control and management network control planes. In the IETF draft, "Software Driven
functions of a network. As a result the control plane can be Networks: Use Cases and Framework" [6], the authors claim
implemented purely in software, and the data plane can be that SDNP is also useful to OpenFlow type networks, since
realized through relatively simple and inexpensive hardware. SDNP provides the interface between applications and control
Such a network architecture promises better flexibility in planes implemented in OpenFlow controllers. Another IETF
network services provisioning, better accessibility to low-level draft "Use Cases for ALTO with Software Defined Networks"
network functions towards new innovative networks. One of [7] proposes two (vertical and horizontal) architectures for
the main drivers for SDN deployments is the significant spread integration with SDN infrastructure. The Vertical Architecture
of cloud computing and the resulting need for cooperation assumes placement of ALTO server over SDN server, the
between new applications and network control functions. Horizontal Architecture assumes integration of those servers,
At present the most popular SDN approach is based on in order to simplify their interactions. The Vertical Architec-
OpenFlow [1]. It is defined and promoted by the Open ture allows better division, management, flexibility, privacy
Networking Foundation (ONF), in which major manufacturers control and long-term evolution of the network. ALTO is the
and Internet related companies are involved. application layer traffic optimization, which is defined by IETF
ONF specifies the internals of the OpenFlow switch as well ALTO Working Group. The IETF drafts mentioned above
as the interactions between the network controller and the are working documents, which present ideas, not matured
switches. The switches operate on data flows, not on individual solutions. We cite them to point these ideas and related use
IP packets. The SDN control software works on a central cases for SDN. A comprehensive review on SDN definition,
server and defines predefined matching rules for the OpenFlow and the proposed technologies for SDN, is given in [8].
switches in a dynamic way. This approach allows direct access Variances in understanding the SDN concept result from
and manipulation of the forwarding plane on both physical different approaches to the complexity of forwarding network
and virtual (hypervisor-based) switches. Most commercial elements. One approach is to build a layer over existing, and
typically complex network devices in order to offer centralized
This work has been conducted as part of the Cognitive Software Defined control of network services or to enable interactions between
Networks (CoSDN) project, funded by FNR Luxembourg and NCBiR Poland.
J. Wytr˛ebowicz, Khoa Truong Dinh, and S. Kukliński are with Insti- the applications and the network, e.g. using the Interface to
tute of Computer Science, Warsaw University of Technology, Plac Po- the Routing System Framework (I2RS) [9]. One position is
litechniki 1, 00-661 Warsaw, Poland (e-mails: J.Wytrebowicz@ii.pw.edu.pl; that SDN should be built over traditional switches [10] and
t.dinhkhoa@gmail.com; kuklinski@tele.pw.edu.pl).
Thorsten Ries is with Post Technologies, 2, rue Emile Bian, L-2999 the authors outline how SDN networks can use I2RS. An
Luxembourg, Luxembourg (e-mail: thorsten.ries@post.lu). opposite approach is to use simple network switches, which are
300 J. WYTREBOWICZ,
˛ T. RIES, KHOA TRUONG DINH, S. KUKLIŃSKI

capable of effectively forwarding incoming packets or flows, While building big multi-tenant data centers, SDN facili-
and to control them through cooperation with a central server, tates network orchestration with respect to workload changes,
which contains all network control logic. Other approaches allowing a higher level of personalization services, traffic
vary between these two extremes, e.g. by adding fast reroute steering and service insertion. Inside these data centers, the
control logic to the new simple switches, or handling "short- load should be balanced for both the servers and their com-
lived" flows in switches to mitigate flow setup delay and munication paths. The administrator should be able to quickly
controller overhead. In the book [11], the authors explore the locate a network failure and to protect other traffic in such
emerging concepts and protocols for SDN. They show their situations. Furthermore, for the ease of network management,
variety and assess them from a pragmatic perspective, opting data centers typically contain virtual switches and firewalls.
for building SDN over traditional switches. Therefore, it may be desirable to have virtual patch panels for
Recently just proposed technology, named Protocol Obliv- manipulation of virtual links, which can be managed remotely
ious Forwarding (POF) [12], is similar to OpenFlow. POF in a centralized manner, without the need of manual cross-
offers more flexibility for switch programming than OpenFlow, swiching of physical links.
and in the future can compete with it in SDN deployments. Creating an infrastructure for cloud computing, adminis-
OpenFlow and POF specify the internals of the switch and trators have to create and to connect virtual servers through
its interface to the network controller. Other above-mentioned secured access, requiring both physical and virtual firewalls.
technologies define interfaces for network applications and Like in data centers, contents of huge data repositories need
interactions between networks. None of these technologies to be balanced and moved between remote localizations.
deals with control mechanisms of the network, which are Combining SDN and virtualization, it is possible to provide
supposed to work on the central network controller. network infrastructure as a service, which can be beneficial for
A detailed presentation and analysis of the SDN technolo- research, experimentation or test purposes and consequently
gies mentioned above could be a subject of a stand-alone to provide full network virtualization that allows customers to
paper, but they are out of the scope of this article. In this work, connect their own Network Operating System to the logical
we try to highlight essential network control mechanisms, switches that are running on top of the physical infrastructure.
perceiving them as enablers of new SDN functionalities. In fact, SDN enables different network abstraction levels to
Before we outline the known SDN use cases, and we highlight the customers. The IETF draft "Software Defined Networks
relating functionalities. Use Case for Virtual Connection and Network on Demand"
[13] points to another important idea: to build application
II. SDN U SE C ASES services over heterogeneous infrastructures of physical and
SDN comes with the promise of enabling new network ser- virtual networks. The SDN approach supports the provision
vices only through the way in which the network is operated. of the two services (i.e. Virtual Connectivity and Network on
From the technical point of view two main properties should Demand) in an automated way without delays related to human
be emphasized: firstly, the already mentioned flow forwarding interactions with network devices.
ability, which can be managed for each individual flow; and Providing access to data center services is desirable to
secondly the centralized approach to network control, which connect with a source of requested content or requested
means that in a single place all information about all network service, regardless of its IP address. An SDN controller (SC)
nodes, links, and traffic is available. Consequently the basic can easily redirect incoming content/service requests on the
networking operations can and should be optimized in a cen- fly. Also the controller can provide rendezvous services [14],
tralized manner, what is difficult to achieve in today networks, which benefit from central information about their location to
because of multiple limitations with distributed control. Most effectively deliver services such as Content Delivery Networks
importantly, SDN enables the creation of highly customized (CDN), p2p systems, and data center applications. In this
networks, which are tailored to meet specific needs. context, the "Content Distribution Network Interconnection
Network providers and devices vendors expecting to benefit (CDNI) Problem" is introduced in RFC 6707 [15]. CDNI
from SDN published many SDN use cases. The proposed ideas defines, among others, the Request Routing Interface between
are mostly about creating business profits when applying SDN Upstream CDN and Downstream SDN. An integration of
to their networks, rather than about technical issues. These OpenFlow into CDNI is discussed in [16].
ideas are typically discussed in the context of the type of SDN Due to the centralized control of network resources, access
owner, i.e.: an enterprise, a content provider, a cloud services can be offered with individual QoS parameters. SDN has
provider and a network provider. It happens that the same the ability to guarantee end-to-end bandwidth requirements
technical idea is presented as several use cases, but differs in between different data centers [17]. The same counts for an
the ownership of the network and its business perspective. enterprise deploying a private WAN by using SDN. When pro-
Common SDN use cases point to where this new network visioning intra-data center interconnectivity, SDN can provide
concept can be beneficial. Analyzing these, we can distinguish dynamic traffic steering with QoS guarantees.
five domains of evident benefits: internal networks for big Another common need is calendaring of huge data transfers
data centers, transmission between big data centers, access between data centers, like remote backups, multimedia content
provisioning for data centers, network administration, and distributions or virtual hosts displacement (from one to other
network security enforcement. data center). Consequently, demand placement, bandwidth cal-
SDN CONTROLLER MECHANISMS FOR FLEXIBLE AND CUSTOMIZED NETWORKING 301

endaring, and bandwidth probing are also expected functions TABLE I

of SDNs. S UMMARY OF SDN USE CASES DOMAIN AND RELATED NEEDS
Network administration is still a complex, resource intensive
and error prone work. Hence, network operators are looking Domains of SDN use Key needs from the SDN controller
cases
for more reliable solutions at reduced administration cost, Internal networks for Traffic steering and service insertion, e.g. via
while users interests are contrary: they expect fast reconfigura- data centers virtual switches & Load balancing
tion of network resources on their demand/needs. For example, Transmission between Load balancing & Bandwidth probing and
data centers calendaring
a high mobility of users and frequent changes of computation Access provisioning Virtual connections and networks on demand
services are observed in campus networks. & Support for content delivery and distribution
SDN promises simpler administration with more automatic & Dynamic QoS reservations
Network administration Traffic distribution according to network owner
functionalities. First of all, the controller provides this abil- policies & Energy saving
ity to automatically redirect and distribute traffic, based on Security Global view of network activities & Support
for attack prevention schemes
network owner policies. Next based on extensive network
statistics, SDN enables efficient energy functions. For instance,
exploiting information of port and switch use, a university
could dynamically turn down segments of the network across centralized control and management of simplified switches.
the campus during the night or in the period when students The OpenFlow technology, which supports well these con-
leave for vacation or faculty for holidays. Moreover the cepts, is a good base for SDN projects and deployments. An
centralized control enables more efficient flow distribution, OpenFlow cloud of switches with its controller belongs to
leading to higher customer satisfaction and better utilization a network owner. The owner can have many such networks,
of network resources. which are cross connected to form a bigger infrastructure. On
Traditional network security concepts typically lack the the top of the OpenFlow controllers, other technologies like
global view of network activities. This view is very beneficial ALTO could be developed.
for effective attack or misbehavior detection and the imple- Even though the SDN principle is to centralize control
mentation of proper counter measurements. SDN can fill this and management functionality, the switches should embed a
gap and enable a comprehensive security environment with simple control element to process operations that cannot be
individual, fine-grained policy definition and security mea- performed remotely or that should be processed locally to
sures, the implementation of effective countermeasures plus achieve reasonable response times. The switch should have
pro-active fault and attack prevention schemes. For instance, a local intelligence that support auto-configuration or may
firewall and intrusion detection systems (IDS) can be easily offer Plug&Play functionality. The local intelligence should
placed at strategic positions within the network, i.e. on ingress process neighbor discovery and keep-alive/failure detection
switches, even their location being dynamically adapted in autonomously (without stimulations of a network controller).
case of security incidents or network re-configurations. The Moreover, if there are signal amplifiers or retransmitters on
detailed statistics of the whole network support also forensics connection lines, a simple Hello protocol may be required
and attack mitigation actions. for this purpose. Such a protocol is also needed, if wireless
However, it has to be noted that SDN itself creates ad- links are in use. To achieve carrier-grade fast (sub 50 ms)
ditional attack vectors, which are non-existent in traditional recovery, this mechanism needs to be implemented locally on
networks. For instance, the data exchange between switches the switch too. There are also other functionalities that would
and the centralized controller could potentially cause a denial benefit from local intelligence, e.g. data aggregation for remote
of service attack simply by a huge number of distinct and monitoring or data analysis for distributed intrusion detection.
previously unknown flows. It needs to be noted that all possible local extensions need to be
Table I summarizes the key requirements to enable the implemented with low complexity. Whereas, high complexity
described use cases. Expected advantages of SDN, that are tasks should be performed on the central controller, they
pointed in the analyzed use cases, are: are: network topology tracking and mapping, routing, traffic
• faster provisioning of network access and services, engineering and computing forwarding tables for the switches,
• possibility of cooperation between cloud applications and calculating parameters for achievable QoS, admission control,
network control applications, administration and management of the network, or inter-
• improved security, operation with legacy protocols and applications (Business
• lower investment and operational costs for network own- Support Systems and Operation Support Systems).
ers, To this end, the SC has to maintain information about the
• better load balancing,
controlled network, to offer services for external applications,
• possibility of automatic energy savings control.
and to perform a set of tasks in order to operate the network
efficiently. Therefore, SC databases store information gath-
III. SDN FROM AN I MPLEMENTATION P ERSPECTIVE ered from network devices and information assembled from
The analysis of SDN use cases and applications leads to the external management requests. We distinguish between four
conclusion that the benefits from SDN are based on inexpen- principal databases and present their current implementation
sive flow switching that is combined together with flexible, status in current distributions of popular open-source SCs in
302 J. WYTREBOWICZ,
˛ T. RIES, KHOA TRUONG DINH, S. KUKLIŃSKI

TABLE II Though some of the mentioned services and tasks are

P RINCIPAL DATABASES AND THEIR PRESENCE IN SELECTED SC S offered and performed in traditional IP networks too, the
SDN paradigm has the potential to enable better functionality
Principal DB NOX POX Beacon F & Ha Trema and effectiveness. From the technical point of view we can
Topology X X X X X distinguish the mechanisms that are crucial to enable SC
Usage History - - X X X services, and tasks which are essential to vivify the SDN use
ACLs X X - X -
Usage Plan - X X X - cases presented above. We discuss these mechanisms in the
a subsequent chapter.
Floodlight and Hydrogen

IV. C ORE SDN C ONTROLLER M ECHANISMS

TABLE III In the previous section we described use cases, which
SC PRINCIPAL TASKS AND THEIR SUPPORT IN SELECTED SC S
are indispensable to today’s network operations. Based on
these, we derive the core SC mechanisms, which form the
Proposed SC tasks Hydrogen Trema Othersa base for autonomous network operations. These can be used
Network discovery X X X
by dedicated network applications to offer further advanced
Statistics collection X X X
Path evaluation for flows X - - functionalities for the network owner, for providers of network
Access control X - X services and for users. Technically it is possible to deploy
QoS path attribution X - - network applications (or their elements) directly on the SC.
Fault detection & Rerouting X - X However, for security and reliability reasons, the network
Energy savings control - - - owner will limit such deployment, allowing only for appli-
Network sanity checking X - -
a
cations supporting network management and provisioning of
NOX, POX, Beacon, Floodlight network services.
Even though the expected SDN advantages are commonly
repeated, and SDN use cases are known, there is still a lack
Table II. For the comparison, we selected: NOX [18], POX of understanding of the core operations of a SC: which mech-
[19], Beacon [20], Floodlight [21], Trema [22] controllers and anisms should be implemented in the SC? Which mechanisms
the Hydrogen platform proposed by the Opendaylight project should be implemented on application level of the controller or
[23]. even outside the controller, i.e. on the switches or on special-
The Topology database contains a description of all network ized application controllers? For our review, we take only SDN
links, both active and inactive, and characteristics of all related functionality into consideration, which are independent
external and internal interfaces. The Usage History database from the implementation platform, i.e. the controller software.
collects data of link and queue usage of every switch port. The All issues related to such a platform, like software updates,
ACL database contains access control lists for every ingress internal data representation and communication security, are
network interface. Finally, the Usage Plan registers the planned intentionally omitted.
link usage based on queue priorities. Routing is neither single nor simple task, and it needs a
In addition to maintaining the mentioned databases, SC has comment here. Routing means collecting and processing data,
to calculate and store network control data, i.e.: unicast routing to find a path to a given destination (unicast) or to a given
data, multicast routing data, QoS parameters for every link and source (multicast). In the case of routing via internal links of
every offered path. In small networks, the set of offered paths an SDN cloud, the SC can relatively easy do this job, as it
may be equal to the set of all possible paths, while in large has always all required information and even one thread or
networks, the offered paths may be selected from the set of all process can do the calculations. Hence, internal routing can
possible paths in a way of satisfying optimal routing needs. be considered as SC duty. However, in the case of routing
Further services like: availability checking for a flow of via border interfaces of an SDN cloud, the job is much more
demanded QoS parameters, reporting on flows’ activities, flow complex. Therefore, support of existing routing protocols, like
calendaring with QoS parameters, and provisioning of virtual OSPF, IS-IS or BGP, is required on every border interface. A
network elements are expected to be provided by the SC. network application can then be hosted on a separate server to
Therefore, the SC has to perform at least the tasks listed provide external routing for an SDN cloud. Such an approach
in Table III to effectively control dependent switches. As has been successfully deployed by Google in their B4 SDN
the table shows, most SCs show a similar set of supported network, which is a private WAN connecting data centers
tasks. However it should be noticed, that there are functional across the planet [24].
differences between their implementations on different SCs. The subsequent description is an attempt to define essential
The network operator needs to define configuration poli- core controller functionalities and their placement/relations to
cies for every SC task and for every service offered by each other:
the controller. Such policies define constrains, warnings and 1) Access Control for Flows (AC4F),
alarms related to the business prerequisites of the owner. 2) Multipath Unicast and Anycast Routing for QoS and
New applications supporting management of such policies (i.e. Load Balancing Control (MPR),
administration of SDN networks) are needed. 3) Multicast Routing for QoS Control (MCR),
SDN CONTROLLER MECHANISMS FOR FLEXIBLE AND CUSTOMIZED NETWORKING 303

External Applications
Authen tication,
Ban dwidth pro bing, Virtual network
Content delivery Authori zation and Exte rnal routing
reservations provisionin g
Accounting

Northbound
Interface

ESC T4C AC4F

Network access
East-west
Planned ACLs
Link Usage Link Usage history Interface
History to other
Flow to path binding
controllers
PS4Q C2C

Core SDN MPR MCR

Controller
Unicast Routing Network Topology Multicast routing

Southbound
Interface
Interface Managemet Topology Forwarding Table Multicast New Flows
[on|off] Discovery Control Management

Switches

Fig. 1. Interactions between SC mechanisms and the controlled network

4) Path Selection for End-to-End QoS Flows (PS4Q), path for every non-rejected new flow. AC4F directly operates
5) Transactions for Flow calendaring (T4C), on two SC databases. It uses and can update the access control
6) Energy Savings Control (ESC), lists (ACLs) for every ingress network interface. It writes to
7) Cooperation with other SDN controllers (C2C). the history of link usage and queue usage of every switch port.
For each mechanism we provide its aim and related func- In traditional IP networks, switches have access control lists,
tions. To this end, we have analyzed the above-mentioned and routers have packet filters. The central AC4F mechanism
controller platforms: NOX, POX, Beacon, Floodlight, Trema can provide better functionality due to on-line cooperation
and Hydrogen, and we present their implementation status in with AAA servers, firewalls, IDSs, WAN optimizers, which
the individual mechanism’s descriptions. Fig. 1 depicts inter- can work as local or remote applications. AC4F can deliver
actions between SC mechanisms and the controlled network; aggregated and statistical data about flows in the network. It
it points also usage of the main databases of the controller. can also process admission rules related to events observed
on remote points of the network (e.g. load incoming on all
A. Access Control for Flows border interfaces and originated from, or designated to, a
Especially in critical infrastructures, there is a need of given network can have a defined limit). AC4F can support
dynamically controlling access rights of appearing flows and also automatic (i.e. fast) provisioning of network services,
to direct them according to policies but also according to according to predefined management rules.
observed features and flow behavior. Access Control for Flows AC4F provides essential services for the SDN use cases that
mechanism (AC4F) cooperates with SDN switches, AAA are related to access provisioning.
servers, firewalls, and with the network administrator via con- The use cases should be implemented as control applica-
figuration files. AC4F is able to evaluate access requests and tions. However, AC4F has to support the binding between new
to recognize users of regular flows, thus to apply predefined flows and their preprogrammed (on demand) virtual connec-
rules for them, e.g. to direct a flow via a path of requested tions and networks. Similarly, AC4F has to support services for
bandwidth or via pre-selected middleboxes (like firewalls, content delivery and distribution, by recognizing and binding
intrusion detection systems, WAN optimizers). AC4F queries appearing connection request with preprogrammed destination
the path selection mechanism (PS4Q, see below), to find a addresses.
304 J. WYTREBOWICZ,
˛ T. RIES, KHOA TRUONG DINH, S. KUKLIŃSKI

As a basic mechanism, admission control is already pro- address is substituted appropriately. Trema doesn’t provide
vided in most of the existing controllers. The Floodlight full load balancing functionality. Provided load balancing can
controller has a firewall module, which is used to apply ACL be used only in the simulation tests, and cannot work in
rules to allow/deny traffic based on a specified match. In the real network environment. Hydrogen platform has the
the NOX and POX controllers, the access control mechanism Affinity Metadata Service (still under development) to support
is also provided to check whether a new host/user or flow load balancing. This service operates on variables: Affinity
is added to the network. However, we could not find this Identifier, Group, Link, and Attribute. The Affinity Attribute
mechanism in Beacon and Trema controllers, which has only describes the network properties that are assigned to Affinity
the ability to set priorities for new flows by setting VLAN Link to meet workload performance. The service has capability
tag, and to define different paths for the flows. Hydrogen to isolate traffic to be forwarded using separated physical links
controller provides user authorization mechanism, and gives or paths not shared by other traffic. We haven’t seen this
access for user flows. Moreover, BGP protocol has also mechanism implemented in other controllers.
been implemented in this controller to provide an enhanced
mechanism for access control. C. Multicast Routing for QoS Control
Especially multimedia content distribution requires mul-
B. Multipath Unicast and Anycast Routing for QoS and Load
ticast data transmission based on given QoS requirements.
Balancing Control
Hence, the aim of the Multicast Routing for QoS Control
Multipath Unicast and Anycast Routing for QoS and Load (MCR) mechanism is to build and update the routing database
Balancing Control (MPR) is supposed to build and update a for multicast streams. The database is updated for every
routing database for unicast and anycast flows. The multipath multicast stream and for every change in the set of the
approach gives failover paths and supports load balancing. For stream receivers. Based on this information, MCR calculates
every pair of border interfaces, possible paths are analyzed and the distribution paths individually per stream trying to satisfy
relevant paths are selected to satisfy QoS and load policies. policy-defined QoS parameters. The multicast routing policies
MPR is activated by every topology change in the network, are supposed to be altered by the network administrator and
i.e. activation or deactivation of an interface or a switch (due by authorized network applications.
to a failure or to an energy saving action). Moreover, it checks For SDN-internal multicast streams, MCR can do routing
periodically the network load, and if need be, it recalculates calculations itself. To transport the streams via borders of the
paths’ parameters that are stored in the routing database. network, information distributed by legacy multicast routing
MPR maintains the network topology database, thus it protocols is required. Therefore, a cooperation with related
performs network topology discovery. Depending on the im- control applications, that maintain the legacy multicast routing
plementation, topology discovery can be considered as a protocols on boarding interfaces of the network, is required.
separate SC submodule. In that case, such submodule should Because of the need to distribute information on sources
fire the processing of MPR every time a topology change is reachability, as well as on possible transits for external sources,
discovered. MCR has to offer the required information to the applications.
MPR calculates paths and estimates their QoS parameters. Most OpenFlow switches already support multicast mecha-
Given by the global topology view, the controller has the nisms by pushing packets/flows out of multiple ports. However
ability to determine the best path for incoming flows. The the analyzed SDN controllers do not have the capability to
controller is able to consider relative priorities of all paths and define individual paths for a multicast stream satisfying QoS
allocate network resources efficiently. This mechanism ensures requirements. The only exception is Hydrogen, which allows
that switches don’t compete for the best path after a link binding QoS parameters to multicast streams using Affinity
failure. In traditional IP networks, routers build appropriate Attributes.
data structures using routing protocols, and layer 2 switches
operate Spanning Tree Protocols. The multipath processing is
limited. Most deployments do not allow for load balancing, D. Path Selection for End-to-End QoS Flows
and secondary paths are calculated after a failure. Based on given policies, the aim of the path selection
While MPR can do routing calculations itself for internal mechanism (PS4Q) is to satisfy a requested set of QoS
flows, flows terminating outside the network require informa- parameters and to select end-to-end paths. The selection is
tion distributed by legacy routing protocols. For that reason, performed using the data calculated by either the multipath
cooperation with related control applications (which maintain routing mechanism or the multicast routing mechanism. PS4Q
the legacy routing protocols on boarding interfaces of the net- is demand triggered by the following mechanisms: Access
work) is required. Moreover, the applications have to distribute Control for New Flows (AC4F), Transactions for Flow cal-
information on destinations reachability, for which they require endaring (T4C), and Energy Savings Control (ESC).
MPR to provide relevant information. Moreover it supports dynamic flow rerouting in case of link
All analyzed controllers perform topology discovery. Flood- failures or in case of network application request. PS4Q keeps
light and POX have a simple load balancer for TCP and UDP track of the bindings between flows and paths and cooperates
flows. Incoming flows for a given service can be randomly with AC4F, T4C, and with SDN switches. It updates their
redirected to one of the known servers – the destination IP forwarding tables and also processes failure alerts from them.
SDN CONTROLLER MECHANISMS FOR FLEXIBLE AND CUSTOMIZED NETWORKING 305

Processing data for switch forwarding tables is the indis- ESC needs the ability to switch on/off interfaces or devices
pensable function for every IP router and Ethernet switch. through direct communication with the network switches.
The centralized PS4Q mechanism simplifies the cooperation Though the OpenFlow protocol provides the ability manage
with other mechanisms (T4C, ESC), and cooperation with ports administratively (i.e., activate/deactivate), there are no
management applications. The clue for enabling the SDN use means to control the power of physical interfaces. The way of
cases, as discussed earlier, is the interface for network control doing this based on an energy saving policy is not available
and management applications. The applications can support: in the above-mentioned controllers. Such a realization would
traffic steering and service insertion in big multi-tenant data require extensions to the existing protocols in order to monitor
centers, virtual patch panels for virtual switches and firewalls, and control energy consumption.
Content Delivery Network services, load balance for both the Certainly, energy-saving does not stop at this point: topol-
servers and their communication paths, and so on. ogy and routing optimisation have an impact on energy con-
As we mentioned above, the Beacon controller has the sumption as well. For instance, parts of a redundant topology
ability to set priorities to incoming flows. The POX controller could be turned of, as long as it is not required and SDN
can additionally add a VLAN tag to the packet header to set may provide the required capabilities for such an intelligent
the priority, thus enabling QoS for end-to-end paths. The PS4Q traffic engineering. In [25], Heller et al. argue that even
mechanism is not implemented in NOX, Trema, and Floodlight critical network components may be turned of or put in stand-
controllers. by if they are idle while still maintaining robustness and
The Affinity Metadata Service (Hydrogen controller) gives performance of the network.
the ability to select/isolate a path for a flow with QoS Today’s deployments widely use custom-made software
parameters. Moreover, the Defense4All Service proposed for to provide remote power control on network devices and
Hydrogen is also able to redirect the traffic, what can be interfaces. Therefore typically SNMP (Simple Network Man-
applied in case of anomaly detection or attack. This service agement Protocol) or out of band communication channels
is responsible for configuring the network, in order to prevent (e.g. via telephone modems to power supplies) is utilized.
system against suspicious traffic, and is also responsible for As the available hardware and software for remote power
restoring the network to original configuration. control can vary, communication with them would be better
managed by a control application and not directly by an SC
E. Transactions for Flow Calendaring module. ESC having full access to the controller data bases
The aim of flow calendaring (T4C) is to enable planning can efficiently compute desired power controls and switching
of big data transfers and to enable throughput reservation for communication paths in advance.
these. The supposed throughput availability can be checked
for the required time period. Calendaring adjustments should
be performed by the network administrator and authorized G. Cooperation with Other SC
network applications only. In traditional IP networks, admin- Until now, SDN has been mainly deployed as single network
istrators process such services manually. domains, managed by one controller per network. Though
T4C has to process information from two SC databases: the there are failover implementations based on multiple con-
ACLs for every ingress network interface, and the network trollers, it is basically only the master controller managing
topology and characteristics of all external and internal inter- one single domain. Such an approach may be acceptable for
faces. T4C can also consider data from the link usage history small private networks, but big commercial networks, require
database, and signalize possible future conflicts of links usage. higher scalability and reliability. Therefore multi-controller-
Next it alters the planned link usage database. multi-domain architectures are the logical consequence. A
There is no bandwidth reservation mechanism in the ana- well-engineered multi-controller deployment has also a strong
lyzed controller distributions. impact on the security of the network. The SDN controller
in a single-controller network is not only a single point of
F. Energy Savings Control failure but also the most interesting target for attackers. A
Not only in wireless ad-hoc or sensor networks, efficient faulty or malicious controller can easily compromise the entire
energy saving plays an important role for a reliable and durable network. Therefore, a multi-controller architecture, even only
operation. Saving energy is basically an important aspect for single domain networks, is essential to provide a higher
for all network deployments, in order to reduce operational level of security of the SDN network.
costs. Typically in wired networks, the network administrator The multi-controller requirements for reliability and for
defines energy savings policies and executes them by changing scalability show many differences. In fact, high reliability can
configuration of network devices. The energy savings control be achieved by well-known solutions that are applied for fault-
mechanism (ESC) may help the administrator by controlling tolerant computer system in data centers, i.e. redundant hard-
execution of a defined policy in an automatic way. ware, software, and mechanisms solving consensus in a net-
ESC needs to be embedded seamlessly into the general work of unreliable processors, e.g. Raft [26]. These solutions
picture. By cooperating with the PS4Q mechanism, it changes can be applied for SDN controllers and servers hosting control
paths for on-going flows by sending requests to PS4Q, preserv- applications. However, it is desired that redundant processes
ing calendared flows that were scheduled by T4C. Furthermore set out stable states for mirroring and synchronization.
306 J. WYTREBOWICZ,
˛ T. RIES, KHOA TRUONG DINH, S. KUKLIŃSKI

In the case of providing scalability, the processes should We have analyzed common needs and looked on their require-
also set out stable states for full or partial synchronization ments from a technical implementation point of view, trying
of their data structures and states. Even thought the aim of to define the core mechanisms of an SDN controller and to
synchronization is different, the way of providing it can be define the functional structure of the controller.
the same. For that reason we propose a generic mechanism The proposed set of controller functionalities is essential for
for cooperation with other SCs. both basic and advanced network operations for flexible and
For the above-mentioned reasons, SC should contain a customized networking. Depending on individual needs, these
mechanism for cooperation with other controllers, so called mechanisms could be designed to be included on demand in
Controller-to-Controller (C2C) communication. Two kinds of the network operation system. For that reason, the SC platform
cooperation ought to be considered: between adjacent network should support loadable modules with standardized APIs. We
controllers, and between controllers that provide redundancy believe that the described mechanisms further enlarge the great
for a given domain. potential of Software Defined Networking and that they should
In single-domain networks, elastic distributed controller be included into all SCs.
architectures can be used to dynamically adapt to traffic
conditions by distributing the load across several controllers R EFERENCES
[27]. However, as mentioned above, large-scale multi-domain [1] OpenFlow Switch Specification, https://www.opennetworking.org/
networks demand advanced intra-domain network manage- images/stories/downloads/sdn-resources/onf-specifications/openflow/
openflow-spec-v1.4.0.pdf, Open Network Foundation, October 2013,
ment. In the case of SDN, this means that the controllers Version 1.4.0 (Wire Protocol 0x05).
need to communicate with each other to improve the overall [2] A. Doria, J. H. Salim, R. Haas, H. Khosravi, W. Wang, L.
network security and to allow end-to-end management [28]. Dong, R. Gopal, and J. Halpern, “Forwarding and Control Element
Separation (ForCES) Protocol Specification,” Internet Requests for
In fact, all proposed mechanisms would benefit from C2C Comments, RFC Editor, RFC 5810, March 2010. [Online]. Available:
communication and cooperation e.g. by extending path se- http://www.rfc-editor.org/rfc/rfc5810.txt
lection mechanisms over multiple network domains. As these [3] A. Farrel, J. P. Vasseur, and J. Ash, “A Path Computation Element
(PCE)-Based Architecture,” Internet Requests for Comments, RFC
operations require a high degree of information exchange, such Editor, RFC 4655, March 2010. [Online]. Available: http://www.rfc-
that the existing SC capabilities need to be extended in a way editor.org/rfc/rfc4655.txt
that internal databases should be ready (entirely or partially) [4] H. Gredler and J. Medved, “Advertising Traffic Engineering Information
in BGP,” Working Draft, IETF Secretariat, Internet-Draft draft-gredler-
for synchronization between controllers and enable storing and bgp-te-01.txt, July 2011.
processing data even for switches from other domains. Here, [5] J. Seedorf and E. Burger, “Application-Layer Traffic Optimization
known solutions for synchronization of distributed databases (ALTO) Problem Statement,” Internet Requests for Comments, RFC
Editor, RFC 5693, October 2009. [Online]. Available: http://www.rfc-
can be applied. For these operations, dedicated policies need editor.org/rfc/rfc5693.txt
to be in place or may be negotiated as part of the cooperation. [6] D. Stiliadis, F. Balus, W. Henderickx, N. Bitar, and M. Pisica,
This is still the matter of future research. “Software Driven Networks: Use Cases and Framework,” Working
Draft, IETF Secretariat, Internet-Draft draft-stiliadis-sdnp-framework-
To our knowledge, there is no mechanism for cooperation use-cases-01.txt, October 2011.
with SCs in the distributions of the analyzed SDN controllers. [7] H. Xie, T. Tsou, D. Lopez, and H. Yin, “Use Cases for ALTO with
Software Defined Networks,” Working Draft, IETF Secretariat, Internet-
Draft draft-xie-alto-sdn-extension-use-cases-01.txt, June 2012.
V. C ONCLUSIONS [8] S. Sezer et al., “Are we ready for SDN? Implementation challenges for
Software-Defined Networks,” Commun. Mag., vol. 51, no. 7, pp. 36–43,
July 2013.
Most published SDN use cases highlight the multifaceted [9] A. Atlas, T. Nadeau, and D. Ward, “Interface to the Routing System
areas of applications that exist for these kind of networks. Framework,” Working Draft, IETF Secretariat, Internet-Draft draft-ward-
Many vendors already provide SDN switches and network i2rs-framework-00.txt, February 2013.
[10] S. Hares and M. Chen, “Use Cases for Virtual Connections on Demand
controllers and there are ambitious efforts to bring the required (VCoD) and Virtual Network on Demand (VNoD) using Interface to
technologies as RFC to IETF. However, SDN is still in the Routing System,” Working Draft, IETF Secretariat, Internet-Draft draft-
early stage of its evolution, and at present a lot of concurrent hares-use-case-vn-vc-01.txt, February 2014.
[11] T. D. Nadeau and K. Gray, SDN: Software Defined Networks. O’Reilly
works are carried out to reach the maturity of existing SDN Media, Inc., 2013.
technologies. [12] H. Song, “Protocol oblivious forwarding: Unleash the power of SDN
Indeed, Software Defined Networking shows huge potential through a future proof forwarding plan,” in Proc. 2nd ACM SIGCOMM
workshop HotSDN, 2013, pp. 127–132.
in development of innovative network services and applica- [13] M. Chen, M. McBride, and L. Ou, “Software Defined Networks
tions. Flow forwarding together with the central control of Use Case for Virtual Connection and Network on Demand,” Working
a cloud of simplified switches, promises lower CAPEX and Draft, IETF Secretariat, Internet-Draft draft-mm-sdn-vc-vn-on-demand-
use-case-02.txt, January 2013.
OPEX for network owners. For that reason we can expect [14] K. Gurbani, M. Scharf, T. V. Lakshman, and V. Hilt, “Abstracting
many developments on SDN controllers to support the growing network state in Software Defined Networks (SDN) for rendezvous
number of SDN deployments. Yet, several distinct controllers services,” in IEEE Int. Conf. Communications, 2012, pp. 6627–6632.
[15] B. Niven-Jenkins, F. L. Faucheur, and N. Bitar, “Content distribution
have been developed, most of them with different features, network interconnection (cdni) problem statement,” Internet Requests
aligned to different needs. We hope that our work will help in for Comments, RFC Editor, RFC 6707, September 2012. [Online].
the definition of a common base of SDN controllers. Available: http://www.rfc-editor.org/rfc/rfc6707.txt
[16] M.-K. Shin, S. Lee, D. Chang, and T. Kwon, “CDNI Request Routing
The paper summarizes the possible applications of SDN, with SDN,” Working Draft, IETF Secretariat, Internet-Draft draft-shin-
and exploits the advantages of this new network paradigm. cdni-request-routing-sdn-01.txt, February 2013.
SDN CONTROLLER MECHANISMS FOR FLEXIBLE AND CUSTOMIZED NETWORKING 307

[17] G. Bernstein and Y. Lee, “Use cases for High bandwidth Query and [24] Sushant Jain et al., “B4- Experience with a Globally-Deployed Software
Control of Core Networks,” Working Draft, IETF Secretariat, Internet- Defined WAN,” in Proc. ACM SIGCOMM conference, 2013, pp. 3–14.
Draft draft-bernstein-alto-large-bandwidth-cases-02.txt, July 2012. [25] Brandon Heller et al., “ElasticTree: Saving Energy in Data Center
[18] “Nox project documentation,” http://www.noxrepo.org/_/nox-doxygen/ Networks,” in Proceedings of the 7th USENIX Conference on Networked
index.html, last accessed: February 19, 2014. Systems Design and Implementation, ser. NSDI’10. Berkeley, CA,
[19] “Pox project documentation,” https://openflow.stanford.edu/display/ USA: USENIX Association, 2010, pp. 17–17. [Online]. Available:
ONL/POX+Wiki, last accessed: February 19, 2014. http://dl.acm.org/citation.cfm?id=1855711.1855728
[20] “Beacon project documentation,” https://openflow.stanford.edu/static/ [26] D. Ongaro and J. Ousterhout, “In search of an understandable consensus
beacon/releases/1.0.4/apidocs/, last accessed: February 19, 2014. algorithm,” in Proc. USENIX Annual Technical Conference, 2014, pp.
[21] “Floodlight project documentation,” http://docs.projectfloodlight.org/ 305–320.
display/floodlightcontroller/Floodlight+Documentation, last accessed: [27] A. Dixit, F. Hao, S. Mukherjee, T.V. Lakshman, and R. Kompella,
February 19, 2014. “Towards an elastic distributed SDN controller,” in Proc. 2nd ACM
[22] “Trema project documentation,” http://trema.github.io/trema/, last ac- SIGCOMM workshop HotSDN, 2013, pp. 7–12.
cessed: February 19, 2014. [28] K. Phemius, M. Bouet, and J. Leguay, “Disco: Distributed multi-domain
[23] “Opendaylight project documentation,” http://www.opendaylight.org/ sdn controllers,” The Computing Research Repository (CORR), August
news/2013/09/converge-network-digest-opendaylight-hydrogen-open- 2013. [Online]. Available: http://arxiv.org/abs/1308.6138
source-sdn, last accessed: February 19, 2014.