A Software Engineering Perspective On SDN PDF

IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 18, NO.
2, SECOND QUARTER 2016
1255
A Software Engineering Perspective on SDN

Programmability
Felipe A. Lopes, Marcelo Santos, Robson Fidalgo, and Stenio Fernandes, Senior Member, IEEE
AbstractSoftware-defined networking (SDN) has received a

great deal of attention from both academia and industry in recent
years. Studies on SDN have brought a number of interesting technical discussions on network architecture design, along with scientific contributions. Researchers, network operators, and vendors
are trying to establish new standards and provide guidelines for
proper implementation and deployment of such novel approach.
It is clear that many of these research efforts have been made in
the southbound of the SDN architecture, while the northbound
interface still needs improvements. By focusing in the SDN northbound, this paper surveys the body of knowledge and discusses the
challenges for developing SDN software. We investigate the existing solutions and identify trends and challenges on programming
for SDN environments. We also discuss future developments on
techniques, specifications, and methodologies for programmable
networks, with the orthogonal view from the software engineering
discipline.
Index TermsSDN programming languages, software defined
networking, software engineering.
I. I NTRODUCTION
HE INTERNET architecture has become complex and

hard to manage. Due to its large development and level of
maturity, implementing strategies with a high degree of innovation is risky because the success of the Internet depends
on the accurate operation of all of its subnets. The Internet
became static and difficult to change its structure, a phenomenon known as Internet Ossification [1]. The need for
making networks more dynamic, robust, and able to be experimented with new ideas and protocols in realistic scenarios
brought a new paradigm called Software-Defined Networking
(SDN). SDN enables a new network architecture that makes
possible for computer networks to be programmable [2]. In its
essence, SDN decouples the control plane from the forwarding
plane. It enables researchers and software developers to create
and deploy network applications, by abstracting the underlying
infrastructure and even complex protocols present in traditional
and legacy networks.
A number of organizations and research groups have
embraced such new paradigm and brought standardized protocols and recommended practices into play. For instance,
Manuscript received December 23, 2014; revised September 7, 2015 and

July 15, 2015; accepted October 14, 2015. Date of publication November
18, 2015; date of current version May 20, 2016. This work is supported by
FACEPE (Grant no. IBPG-1200-1.03/14 for Felipe Lopes; and IBPG-13211.03/11 for Marcelo Santos) and CNPq (grants 206410/2014-0, 304422/2013-4,
482831/2012-0) for Stenio Fernandes.
The authors are with the Center of Informatics (CIn), Federal University
of Pernambuco (UFPE), Recife, Brazil (e-mail: fal3@cin.ufpe.br; mabs@cin.
ufpe.br; rdnf@cin.ufpe.br; sflf@cin.ufpe.br).
Digital Object Identifier 10.1109/COMST.2015.2501026
the Open Network Foundation (ONF), Internet Research Task

Force (IRTF), and the Open Networking Research Center
(ONRC) are putting efforts on organizing further developments
on well-defined interfaces. In general, those research groups
and organizations are trying to standardize and address the
challenges involving SDN. Current scenarios are based on the
deployment of OpenFlow [2], as well as other approaches, such
as NetOpen [3], OpFlex [4], POF [5], and ForCES [6].
Programmable networks has been the subject of active
research in the past (e.g., Open Signaling [7], Active
Networking [8], and Ethane [9]). However, they failed to
be fully adopted by the industry due to many reasons, such
as focusing on the data plane programmability as well as
enabling programmability for specific network devices vendors.
Although some of the SDN concepts are not new, it integrates
the concepts of programmability in the network architecture
in order to offer better network management strategies. In
this scenario, OpenFlow [2] has been considered the de facto
and widely accepted solution to implement SDN. It is worth
emphasizing that OpenFlow and SDN terms cannot be used
interchangeably. OpenFlow is a protocol that defines an open
standard interface for SDN, and uses a programmable controller to communicate with the forwarding plane, manage
the network, and possibly receive instructions from a network
application. Such an interface has a low-level implementation, which offers basic features to developers. The complexity
involved in developing advanced SDN software applications
needs to be addressed by other means (e.g., via new programming languages), in order to increase its level of abstraction.
In this scenario, full development and deployment of such
applications in staging and production environments remains
a challenge for network operators [10].
Although some previous studies [11][14] have surveyed the
state-of-the-art on SDN programmability, we take a different
perspective on the topic by describing the techniques, methodologies, and challenges to develop and deploy SDN software
applications. We provide a unique view from the perspective
of the Software Engineering discipline in which we present the
evolution, current maturity, and point out prospective research
directions and challenges to develop applications for SDN. We
also cover in detail the current research efforts to increase the
level of abstraction in developing SDN software applications
and their effective deployment in real scenarios.
The paper is organized as follows: Section 2 briefly presents
SDN concepts. Section 3 provides the Software Engineering
view on programming languages. Section 4 gives an overview
of SDN languages. Lessons learned and analysis of use cases
for each SDN language are presented in Sections 5 and 6,
1553-877X 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
1256
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 18, NO. 2, SECOND QUARTER 2016
respectively. Section 7 presents research challenges and future

directions for SDN programmability. Finally, Section 8 concludes the paper.
II. S OFTWARE D EFINED N ETWORKING
The separation of the control plane from the forwarding
plane is one of the pillars of the SDN paradigm. Its decoupled
architecture enables network programmability. Historically, the
research community made several attempts to provide network
programmability, where Active Networking (AN) and Open
Signaling (Opensig) are considered the seminal approaches
[13]. In this context, two questions may arise: (i) why previous approaches did not succeed? and (ii) what are the main
differences between SDN and those previous approaches? We
argue that SDN came to fill up an important gap left. AN
[8] focused on users configuring the network router, thus
the programmability was designed to occur directly at the
data plane. Such principle resulted in network operator concerns (e.g., inconsistent applications and security). Opensig [7]
also focused in providing network programmability by separating network control from information transport, but with
tight dependence on static programming interfaces. SDN then
advances the state-of-the-art and focuses on overcoming the
dependency on vendor-specific interfaces. It enables networks
to quickly evolve, by reducing complexity to deploy new protocols, including experimental ones. Besides the separation
between data and control planes, the operation of an SDN differs from traditional networks. In traditional networks, each
switch has its local software to perform packet forwarding
logic. In SDN, this logic is centralized and externally defined
on the control plane via a controller as a software (running in
a commodity hardware), which has a global network view and
can be programmed to meet developers, operators, or network
providers requirements.
A. SDN Architecture
When the control logic is decoupled from the forwarding devices, all the network intelligence (e.g., decisions about
routing, permissions) is moved to the controller. The SDN
controller becomes the network component responsible for network management, as Fig. 1 depicts. Management then occurs
through a flow table present in the network switches, which
receive and register network rules defined by the controller (cf.
section II. C). In other words, the SDN controller adds flow
table entries in the switches for proper packet or flow handling.
The controller has all the necessary network information (e.g.,
where the hosts are connected, topology, and the like) that it
uses to deal with possible conflicts involving policies or to avoid
misbehavior of network elements.
As Fig. 1 depicts, the controller has two main interfaces,
namely i) the northbound interface, for higher-level elements
to support the development of network applications and services, or to program the SDN controller through a well-defined
API and ii) the southbound interface, for the communication between controllers (low-level protocols) and the network
switches at the forwarding plane.
Fig. 1. Northbound and Southbound interfaces in an SDN architecture.
B. The Northbound and Southbound Interfaces in SDN

Architectures
One can argue that the Southbound Interface (SI) has converged to the OpenFlow protocol standard [13], [11], although
there is some room for discussions and improvements [6], [4],
such as the ones regarding efficiency of the data-plane and integration to the control-plane. A southbound interface enables
SDN switches to communicate with the controllers [15], so that
switches can handle the incoming packets.
On the other hand, the Northbound Interface (NI) encompasses the relationships between controllers, network applications or services, and user applications. This layer has the
responsibility of abstracting underlying network functions, in
a way that network operators or developers can implement
or change applications without worrying about the low-level
aspects. According to Kreutz et al. [11], the NI abstracts the
low-level functions defined by the SI to program forwarding
devices. However, the NI has still no widely accepted standard. Fortunately, there are already some initiatives towards this
direction. For instance, ONF has created a working group that
aims at designing prototypes, codifying some patterns, and producing artifacts that may validate the creation of a standard for
the NI [15], [16].
A common view involving the northbound and southbound
layers is depicted at Fig. 1. This perspective demonstrates
the separation of responsibilities for each level in the SDN
architecture. Thus, with a standard for northbound, different
applications may be developed and executed in SDN controllers from any vendor, through the utilization of well-defined
Application Programming Interfaces (API).
C. Controllers in the SDN Architecture
The SDN controllers are strategic control elements that communicate with the underlying switches (via SI) and with applications on the top (via NI). An SDN controller sends messages
to switches disseminating specific or general packet handling
LOPES et al.: SOFTWARE ENGINEERING PERSPECTIVE
1257
are verified and compared to related fields in the flow table

entries. If an entry corresponds to this packet header, the switch
will perform the set of instructions or actions related with
the flow entry (e.g., forward the packet to C2 in Fig. 2). In
case that no related entry is found, the switch will act based
on instructions defined at tablemiss flow entry. It is worth
emphasizing that every flow table contains a table miss entry to
address such a case. The given switch may forward the packet
to the controller via an OpenFlow SSL/TLS channel, drop the
packet, or continue to match the packet header fields with others
flow tables (if any).
Currently, OpenFlow is the widely adopted protocol to perform the communication between controllers and switches [2].
E. SDN Use Cases
Fig. 2. The necessary steps to the Client 1 communicate with the Client 2 when
the switch does not have rules that can manage this communication.
rules, which are generally defined by a developer or administrator through the controllers northbound API [17], [18].
The hypothetical scenario depicted in Fig. 2 helps to understand the controllers responsibility and how it inserts a new
rule into a switch. In this Figure, client 1 (computer C1) wishes
to establish a communication with client 2 (computer C2).
Thus, C1 sends a packet with destination to C2 (step 1). The
packet arrives at switch (S), which at the time has no forwarding
rule for this packet (i.e., it does not have a matching rule in its
flow table) (step 2). After the arrival, switch S generates a new
flow request to the controller (step 3). If switch S has memory
space available to buffer these packets, it sends a buffer ID that
will be used by the controller to define the forwarding rule [16].
Otherwise, switch S sends the full packet to the controller. The
controller responds with a new packet that inserts a new rule at
switch S (step 4), enabling switch S to forward the first packet
to C2 (step 5). Then, switch S will now be able to send all packets from C1 to C2 with no need for additional communication
with the controller. It is noteworthy that currently all communication switch-controller-switch is likely to be performed by the
OpenFlow protocol.
The possible responses from the SDN controller to switches
are defined by algorithms as applications, software modules, or
policies. These ones may run in the SDN controller or interact
with it through external applications or services in the application layer. An important aspect of the SDN architecture, given
any administrative domain, is its capacity to have more than one
controller handling several switches. This is a desired feature
when network reliability and availability comes into play [17]
[18]. Conversely, based on the OpenFlow specification [16], a
switch is capable of connecting to multiple controllers.
D. The OpenFlow Protocol

The OpenFlow protocol defines how the exchange of information between control-plane and data-plane must occur [16].
When an OpenFlow switch receives a packet, its header fields
The benefits of SDN would not be clear if this paradigm

could not be applied in use cases. Based on [12] and [19],
we understand that most use cases of SDN may be categorized in the following main classes, namely: Routing,
Cloud Orchestration, Load Balancing, Network Monitoring and
Measurement, Network Management, Network Applications,
and Security and Dependability.
Routing: The current decentralized routing schemes
deployed on network devices from specific vendors makes
difficult to adapt routes to different scenarios (e.g., virtual
machines in a cloud computing environment). The interface
between data and control planes offers several possibilities
in adapting routing protocols. Thus, SDN enables the implementation of routing services for many contexts (e.g., route
selection, traffic optimization, secure routing, and the like).
Cloud Orchestration: A unified orchestration of IT and networking resources (e.g., forwarding devices) is considered one
of the most important use cases for an SDN-based network
[20]. The cloud orchestration involves managing interconnections and interactions between datacenters and transport
networks. With SDN, this use case can result in a virtualized
environment offering, for instance, customized bandwidth for
network nodes, and specific policies for transferring large bulk
data. In this scenario, SDN controller can communicate with
cloud orchestrators (e.g., Open-Nebula [21]). Thus, for example, when a new virtual machine starts, the cloud orchestrator
can request to controller the network configurations for such
machine. Moreover, the controller can notify the cloud orchestrator about an overloaded route. In such scenario, the controller
can define an alternative path, if available, or cloud orchestrator
may move the cloud resources to another location based on network status. For further details, we refer the reader to [22], [11].
Load Balancing: Load balancers distribute the incoming
server workloads across an array of multiple replicated servers,
rerouting traffic to such servers in order to decongest the use
of computational resources. Current load balancers are mostly
deployed as specific hardware components. SDN enables load
balancers to be part of the controller logic. One example
of load balancing with SDN is the following: if a network
node is overloaded, the load balancer can notify the controller,
which forwards the workload to a different replicated node.
Another way is the controller actively check for congested
1258
links, offering alternative routes. According to [12], dedicated

balancer devices can be replaced by SDN controllers and load
balancers as software components running on it to prevent
traffic flow through overloaded paths.
Network Monitoring and Measurement: SDN offers for network operators the capabilities to monitor and measure the traffic flows, without the need for an additional device [12], [23],
[24]. As the controller has a global view of the network, the
implementation of monitoring mechanisms is straightforward.
Network Management: Currently, network management
becomes more complex as the number of devices that need to be
configured and monitored increases. The logically centralized
control plane enables operators to define policies from a single logical point in the network. This could drastically reduce
the complexity in adapting the network to new management
requirements [25].
Application-Based Network: Quality of Service (QoS) and
Quality of Experience (QoE) are key concepts in the next generation networks. With SDN, applications and controllers could
exchange some valuable information about the state of the networks. The controller could then manage traffic flow to meet
the networks and applications requirements [26], [27].
Security and Dependability: Proper authorization to access
data or resources in a network is generally managed by the
network operator and can be seen as a use case in security.
Authenticating user devices or applications to use network
resources is an inherent feature in SDN. Kim and Feamster
[24] replace a web portal, VLAN domains (for authenticated
and unauthenticated users), and a VLAN management server,
by using a machine state and algorithms as policies for managing user device authentication. On the other hand, to ensure
that network resources will work in a number of scenarios, or
in the event of a network failure it will continue to deliver
its services, SDN has potential to be deployed as dependable
environments. It is clear that SDN and network virtualization technologies introduce several dependability challenges
due to the addition of software layers to handle network flows
[25][30]. There exists recent concerns on the SDN Controller
placement problem considering dependability attributes (e.g.,
availability and reliability) [28], [29]. High availability and the
ability to quickly recover from failures are essential for the SDN
adoption in a large scale [30][32].
The correctness of an SDN application or environment is
related to network behavior, which must be in accordance to
the requirements defined by the network operator. To achieve
this, a certain application running in the controller needs to verify and validate all the rules that may be applied to the network.
Such verifying and validating might be provided as feature by
an SDN programming language. For instance, if the network
operator wants to restrict certain IP addresses range, the controller needs an application that identifies if there is any other
rule that will be affected by such restriction. Furthermore, the
application (or its underlying controller) needs to decide if such
operator has privileges to deploy the rule. Some approaches try
to offer that type of correctness, as in [33][35]
In summary, the abstractions offered and enabled by SDN
make it possible to deploy any use case described above,
most of them based on software components in the controller.
Fig. 3. Frenetic declaration to filter packets.
However, such implementation involves a variety of techniques

and challenges. As SDN is a networking architecture paradigm
change that defines the network through a set of software
layers, its software development needs formal programming
languages, specifications, and software engineering techniques
to overcome the challenges common in the software industry. In addition, as SDN architecture enables network programmability, issues regarding scalability [36], performance
[37], reliability [38], and security [32] need to be properly
addressed.
III. P ROGRAMMING PARADIGMS , L ANGUAGES

S PECIFICATION , AND S OFTWARE E NGINEERING IN SDN
In order to introduce new features in the network through
well-defined Software Engineering methods and to achieve the
fully potential of SDN, industrial and research communities are
trying to standardize programming languages for SDN [39],
[10]. This section presents the contributions that relate programming paradigms with network programmability, and also
highlights the general characteristics of existing languages for
SDN programming.
A. Programming Paradigms in SDN

The main paradigm for programming languages in SDN
applications development is the declarative, used in most
research papers in the literature [40], [10], [41]. Declarative
programming languages have been characterized by its
extremely formal nature, often based on logic, but without arithmetic [42]. This paradigm allows a developer to define what
action needs to be done in the network, but not how this action
will do it. Please note that this definition applies to all declarative programming languages. To make it possible, a language
interpreter is used to translate the what into how. An example involving this approach in an SDN scenario is shown below,
using the Frenetic notation [10]:
The example presented in Fig. 3 demonstrates a high-level
declaration to filter packets in a given flow, which does not
require the programmers knowledge to implement how the
Select(packets) clause will receive and direct the packets to
some program or service that is requesting it.
Another widely used paradigm present in SDN programming
languages is the Functional Reactive Programming (FRP). FRP
is a well-suited solution for the development of event-driven
applications, such as SDN applications, enabling programs
to capture the time flow property pertinent to SDN systems
[43]. The reactive characteristic of FRP is direct related to the
SDN environment, where switches and controllers continuously
exchange information upon packet arrival and apply rules to the
corresponding flow. Reactive programming also makes it easier
1259
an OpenFlow-based mode and showed that it has a precise

mathematical concept that enables formal reasoning.
C. Software Engineering in Network Programmability
Fig. 4. FRP characteristic of Frenetic.
to express applications parts as behaviors that react to external

events [44]. When an SDN language follows the FRP paradigm,
it automatically administers the time flow and the dependencies
between data and computation. The main idea behind FRP is
to define everything in terms of signals. A signal is an element
in which its values change in the course of time [45] (e.g., if a
variable switch is equal to false, its value might changes to true
due to emission of a signal). Fig. 4 depicts a code example in
the context of FRP. This piece of code shows a packet counts
monitoring example [10]:
This type of monitoring can observe the network, selecting the packet counts filtered by IP address at some interval.
Therefore, when the flow time reaches the defined interval, a
new query is realized via signal from the application.
B. SDN Languages Specification

The formal specification of a programming language is written in a form ready for machine execution or written using a
formal mathematical notation, as defined in [46]. On the other
hand, an informal specification can be expressed through a
model such as UML or in natural language [47].
Shin et al. [39] presented a formal context to specify SDN
programming languages. In summary, they used an SDN framework specification for SDN languages in order to allow SDN
applications development and to define the initial requirements
for SDN programming (e.g., flow table, packets, rules/policies,
and the like). They discussed a formal specification framework that enables verification methods (i.e., model checking
and theorem proving), which brings correctness for the development of SDN applications. Thus, if an SDN programming
language is created based on such a framework, it can verify
the correctness of some method or feature that makes part of
a certain SDN application. We argue that, from the point of
view of the Software Engineering discipline, such statement
can be accepted by the SDN research and development community [48]. This verifiable formal network can provide a logical
framework to unify the design, specification, verification, and
implementation of SDN applications. It adds an SDN language
compiler on top of SDN run-time systems that could then verify policy rules and well-formed declarations to specify an SDN
application.
Another research study involving mathematical foundations
for SDNs that enables and makes easier to reason about the formal network was proposed by Guha et al. [49]. The authors
present a mathematical foundation for SDN that can be used
to build and verify high-level SDN tools. They argued that
a programmer who uses such tools might be able to obtain
correctness through a low-level SDN model. They presented
Software can be created using a Domain-Specific Language

(DSL) and/or a General-Purpose Language (GPL) [50], [51].
The former is tailored to a specific application domain, whereas
the latter is applicable across domains. That is, a DSL tends to
offer more abstract and easy-to-use constructions than a GPL.
DSLs have been used to create many SDN languages (e.g.,
Frenetic [10], Procera [52]). The advantage of SDN languages
based in DSL is to abstract its complexity to developers, generally through the use of many features and methods created to
a particular domain. Figs. 3 and 4 show examples of two DSLs
for SDN. In turn, the well-known C and C++ programming
languages are two examples of GPL for creating networking
applications. In this context, this section presents how Software
Engineering techniques can be used to improve productivity
and quality of software programming for SDN. More specifically, this sections discusses how Model Driven Engineering
(MDE) [53] can be used to hide implementation details [53],
speeding up the software development process [54] by reducing
its complexity.
A DSL can be textual or visual (also called DomainSpecific Modeling Languages DSML [55]) and, in both
cases, the engineering used to build a DSL/DSML must define
an abstract syntax (i.e., grammar), a concrete syntax (i.e.,
representation), mappings between abstract and concrete syntax, and a description of the semantics [55]. Considering that
modeling/diagrammatic languages tend to provide higher-level
abstractions than textual ones, DSMLs tend to be easier than
DSLs, especially because the visual notation of a DSML aims
at abstracting the textual representation of a DSL, thus hiding implementation details. Moreover, DSMLs are supported
by (Computer-Aided Software Engineering) CASE tools that
can i) detect errors in advance - or even prevent them from happening -, ii) guide towards preferable design patterns, iii) check
completeness by informing about missing elements, iv) reduce
modeling work by applying conventions and default values,
v) support full code generation, and vi) keep specifications
consistent [56].
In the DSML scope, MDE is defined as a software development paradigm that uses models as the key artifacts in all
phases of development. Therefore, in MDE, models are more
than documentation items; they are executable objects [53]. In
other words, once the models are created, target code can be
generated and then compiled or interpreted for execution. It is
noteworthy that the concept of executable models is possible
because both the modeling language and code generator are
designed for a specific application domain and are under full
control of their users. Considering the MDE scope, other important concepts are Model Driven Architecture (MDA) [57] and
Model Driven Development (MDD) [58]. MDA is the Object
Management Groups (OMG) vision of MDE and thus relies
on the use of its Unified Modeling Language (UML) and other
OMGs standards, while MDD is an MDE view following a
1260
compatibility of policies in different scenarios. Therefore, the

specification of a DSML for SDN might provide easier network
management, due to its capability to enable higher-level graphical implementation of network behavior and applications.
Furthermore, a DSML specification evaluates several concepts
and relationships on the SDN domain, thus providing a robust
platform in which network operators or developers may rely on.
IV. S TATE - OF - THE -A RT IN P ROGRAMMING L ANGUAGES
FOR SDN
Fig. 5. Key concepts and technologies related to Modelling Languages.
more general approach. That is, in MDD, a DSML is able to

use the OMGs standards for interoperability reasons, but it
does not need to follow the UML abstract or concrete syntaxes,
which is useful when the graphical elements or the constructions rules of UML are not suitable for a particular domain.
The specification of a DSML in MDE (considering both
MDA and MDD) is based on the metamodel concept [55],
which provides an abstract syntax to distinguish between valid
and invalid models. That is, a metamodel (or abstract syntax)
of a DSML describes the concepts, the relationships between
them, and the structuring rules that constrain the combination
of these concepts according to the domain rules of a modeling
language. Furthermore, the semantics of a DSML can also be
defined using a metamodel and/or deriving it from the runtime
behavior of a DSL. Thus, a metamodel presents a precise specification of modeling concepts and the well-formedness rules
needed for creating syntactically correct models. Consequently,
a metamodel is as useful for a modeling language as a grammar
is for a programming language. In this context, it is important to highlight that a metamodel for a DSML offers the basic
definitions (i.e., metadata) to develop CASE tools, which can
be done using free (e.g., Eclipse Modeling Project [59]) or
proprietary (e.g., Microsoft Modeling SDK for Visual Studio
[60]) technologies. The relationship among the key concepts
and technologies discussed in this section is presented in Fig. 5.
In Fig. 5 we can see that a CASE tool is supported by a
DSML, which is defined from the meaning (semantics) of its
valid constructions, and the mapping between its visual notation
(concrete syntax) and metamodel/grammar (abstract syntax).
Moreover, a DSML based on the MDE paradigm can be specified according to OMGs standards (MDA) or following a
more general approach (MDD), which can also include OMGs
standards.
Bearing in mind concepts and technologies presented in this
section, we have good arguments to advocate that DSML is
of paramount importance as a research topic to create SDN
applications with a high-level of abstraction. For instance,
a DSML for SDN can model all the policies that compose
the network behavior desired by an operator or an organization. Furthermore, a DSML-based policy model could generate code for any SDN language or controller, increasing the
Since the first OpenFlow specification was released in 2008,

several approaches emerged trying to raise the abstraction level
for programming in SDN. In SDN architecture, the northbound
interface enables and even requires a higher-level concept to
define the desired behavior of the network. Due to network
dynamics and complexity of an SDN application, the northbound interface has been composed of high-level programming
languages that hide the complexity involved in implementing
and handling of OpenFlow protocol.
Some SDN programming languages have emerged aiming
at allowing developers to create network applications to the
controllers northbound interface. Currently, there is no widely
adopted standard that defines how the interactions between
network applications and controller must occur.
The first SDN programming language released was FML
[61], using a declarative paradigm to express network policies. It was released just one year after the release of the
OpenFlow specification. Nettle [62] has concepts of DSL for
developing SDN applications, which includes the discussion
about proactive and reactive SDN applications development.
Nettle also uses the FRP paradigm in its design. Procera [52]
and NetCore [63] offer support to avoid conflicts among policies. The FRP, DSL, and declarative paradigms, used earlier
in Nettle [62] and FML [61], were also used in Procera [52]
and NetCore [63]. Frenetic [10] and Pyretic [64] are slightly
different languages as they have distinct characteristics involving how policy rules are interpreted. Frenetic allows parallel
modules whereas Pyretic adds sequential execution to parallel
support. They also use DSL, declarative, and FRP paradigms.
Flog [65] applies ideas of FML [61] and Frenetic [10], allowing
event-driven development, query network state, and information processing to the events generated by network dynamics.
FatTire [40] is one of the most comprehensive languages due to
its focus on fault-tolerance, by offering features to handle the
failures in an SDN application. Nlog [66] is another proposal
for computing the network forwarding state, based on DSL and
declarative paradigms, and resembles FML [61] semantically
when querying the network state. Flowlog [67] is a finite-state
language, which restricts some constructs in order to simplify
the reasoning about correctness and proactively install rules
onto switches.
Recently, Merlin [34] and Kinect [35] have recently arrived
in the SDN programming languages pool. They represent
another direction as compared to previous SDN languages,
regarding the independency from underlying structures (e.g.,
controllers and protocols). Our view for this new direction considers two factors: (i) the gaps left by the previous languages;
1261
Fig. 6. The SDN programming languages timeline.
and (ii) the maturity of SDN open avenues to the development

of new programming languages. For instance, Merlin [34] and
Kinect [35] focus on network functions in different network
components (e.g., forwarding devices, middleboxes, and endhosts), whereas the other languages just provide abstractions
for SDN controllers or forwarding plane.
Fig. 6 illustrates the timeline of releases of SDN programming languages.
In the following sub-sections, we present details on each
existing SDN programming languages.
A. FML Flow Management Language

The Flow-based Management Language (FML) is a declarative policy language for managing the configuration of enterprise networks, developed to replace the various different configuration mechanisms traditionally used to enforce policies
within the enterprise, including Access Control Lists (ACL),
Virtual LANs (VLAN), Network Address Translations (NAT),
policy-routing, and proprietary admission control systems.
FML balances the desires to express policies naturally
and enforce policies efficiently [61]. Its logic programming
paradigm instantiates policies when conditions are satisfied in
a set of data. The FML is considered a high-level declarative
management language that expresses network-wide policies
in different scenarios and management tasks. It operates in a
unidirectional network flow. Therefore, the policy decision is
applied to every packet in the same flow, so the policy needs to
handle every type of flow and be queried at least once per flow.
FML design was targeted as the policy language for NOX
[41], although the FML principles might be generalized to any
flow-based network architecture. It is a language to specify policies on flows, based on a declarative and logic programming
language, named DATALOG11 , but without recursion and with
structures of negation [61]. A FML policy is a set of statements,
where each declaration represents a simple conditional if-then
relationship. This set of statements defines that a particular
instruction should be applied to the flows.
FML assumes the possibility of distributed authorship within
a single policy domain, which can trigger policies conflicts [61].
To address this issue, FML includes two mechanisms for conflict resolution: (1) a mechanism under control of application
developers that resolves conflicts at the level of keywords, (2) a
FML cascade that is under the control policy writers and is built
into the language itself.
FML extends FSL (Flow-Based Security Language) [61],
which was also created to provide high-level concepts to network operators and was aimed at the NOX controller.
1 DATALOG is a declarative logic programming language [72].
Fig. 7. The northbound and policy layer where the SDN programming languages fit into the SDN architecture.
B. Nettle
Focused on the network control, Nettle [62] is a domainspecific language, embedded in Haskell2 . It allows programming of OpenFlow networks in a declarative mode and it is also
based on FRP principles [62].
As compared to the NOX controller, we observe that either
NOX [41] or Nettle [62] provide a framework to make easier the development of applications by hiding low-level details
from the user, supporting an event-based programming model,
and allowing a fine-grained control of switches behaviors. The
main difference is how Nettle offers a specific programming
language to develop SDN applications.
The noticeable difference in Nettle [62] (as compared to
NOX [41] and its FML [61]) is the more declarative approach to
event-based programming through manipulating series of messages rather than handling individual messages. Furthermore,
with the help of its declarative feature, Nettle offers a way easier
to developers to code time-sensitive and time-varying behaviors
in SDN applications.
C. Procera
Procera [52] is presented as a combination between a
controller architecture and high-level network control language. The language that composes Procera allows operators
to express policies that are dynamic and relative to external
events such as intrusion detection, Quality of Service (QoS),
or specific time events [52]. Its principles are based on FRP,
including a collection of domain-specific temporal operators.
It makes easier for the programmers to define the values of
time-varying sets and dictionaries relative to event histories.
Furthermore, Procera implements flow constraint functions,
enabling a lower-level network controller to constrain behavior.
Fig. 7 depicts the policy layer where Procera lies (as well as
other approaches present in this survey). This layer is the main
focus of the Procera approach [52], providing resources for
network administrators to define rules of an SDN environment.
The policy layer acts as a supervisor of the network, responding to signals from relevant events from the network, users, and
devices. Procera allows network operators to describe how an
OpenFlow controller should react to such events [52]. At this
point, we can define Procera as a policy language.
Procera [52] has four key features:
2 Haskell is a functional programming language for general purpose. Site:
http://www.haskell.org
1262
1) Core language based on FRP. Using this approach, users

can describe values that vary in time. Thus, depending on
events that occur over time, the values for policies can be
changed dynamically.
2) Event interpretations to manipulate event streams. A supported feature that makes possible for Procera operations
to filter, transform, and merge event streams.
3) Windowing and aggregation of signal functions. A set of
signal functions and abstract data types that enable network operators to define a convenient way to express
reactive policies.
4) Function values to define high-level policies. Procera is an
embedded domain-specific language (EDSL) in Haskell,
and some functions from Haskell are combined to define
high-level policies in Procera, using the DSL paradigm.
D. Frenetic
Frenetic is a high-level language for programming distributed collections of network switches [10]. Through a declarative query language, operators can classify and aggregate network traffic and use a functional reactive combinatory library
to describe high-level packet-forward policies.
Frenetic architecture design has two levels of abstraction,
namely i) a set of source-level operators for constructing and
manipulating streams of network traffic, and ii) a run-time
system that handles all of the details of deploying or removing low-level rules on switches. The source-level operators are
defined as a declarative database query language and also as
an FRP paradigm. The Frenetic project aims at increasing the
level of abstraction for programming to SDN [68]. Frenetic [10]
proposes three main components called by a control loop for a
running SDN instance, as follows:
i) Query network state;
ii) Express policies;
iii) Reconfigure the network.
Those components enable programmers to focus on highlevel network management goals, thus hiding low-level details
relative to rules and network events.
E. Flog
Combining the main ideas of FML [61] and Frenetic [10],
Flog [65] uses logic programming as its paradigm that results
in a declarative reading, as FML. The relation with Frenetic
involves the idea that SDN applications have three main components to be developed, as discussed earlier (c.f. section IV. D).
Flog is similar to Flowlog [67], it has different features to
check model of policies, verify the code dynamically, and monitor the state of forwarding devices. Flogs declarative style
allows a programmer to develop very efficient codes [65].
F. FatTire
FatTires authors argue that SDN programmers should have
high-level constructs that allow them to specify distinct policy concerns, such as forwarding, performance, security, and
fault-tolerance [40]. In addition, SDN programmers should be
able to reason about the interactions between those constructs

when they are combined into a single program. FatTire [40] is
a high-level programming language that provides constructs for
writing programs in terms of paths through the network, explicit
fault-tolerance requirements and has the following features:
1) Expressive: programming constructs that makes it easier
to write forwarding and fault-tolerance policies.
2) Efficient: a proof-of-concept implementation based on
translation to the fast-failover mechanism provided in
recent versions of OpenFlow.
3) Correct: a methodology for reasoning about the behavior
of the system during periods of failure recovery, which
enables verification of network-wide invariants.
FatTire [40] is also composed by a compiler which generates
rule tables and group tables that provide the specified faulttolerance while guaranteeing that traffic flows along the paths
defined by the program.
G. Pyretic
Pyretic was created to provide abstractions involving the
building of SDN applications with independent modules that
jointly manage network traffic [64]. Pyretic is an imperative, domain-specific language embedded in Python. It is also
defined as a language and system that enables programmers to
specify network policies at a high level of abstraction.
One of the arguments for the development of Pyretic involve
some existing controller platforms (i.e., NOX [41], Onix [69],
and POX [70]) that force programmers to reason manually
on low-level dependencies in different parts of the code. In
terms of applications that perform multiple tasks, deployment
of packet-processing rules needs to ensure that one task does
not interfere with the operation of the others.
Pyretic argues for modularity as the key to managing complexity in SDN. Therefore, the modular abstractions involve i)
composition operators and a library of policies for forwarding
and querying the traffic, ii) an abstract topology that implicitly constrains what each module can see and do, and iii) an
abstract packet model that allows programmers to extend packets with virtual fields, which may be used to associate packets
with high-level meta-data.
When compared to Frenetic [10], Pyretic supports both operators, realizing both parallel and sequential composition, which
means executions of one module can be the input of a second
module.
H. NetCore
NetCore is defined as a high-level declarative language for
expressing packet-forwarding policies on SDNs [66]. NetCore
is expressive, compositional, and has formal semantics [63].
Netcore aims at enabling programmers to construct and reason
about rich policies in a natural way. SDN needs to deal with the
problems of evaluating arbitrary policies made in the controller
and increasing the latency involved in forwarding the packets
to the controller and then to switches. Therefore, NetCore is
presented as a way to address such challenges by analyzing programs and automatically dividing them into two pieces: one that
runs on the switches and another that runs on the controller.

Such division occurs dynamically and repeatedly. A strategy
called reactive specification uses this division. In this strategy
the controller partially evaluates the correspondent packet to
current network policy and dynamically generates new switchlevel rules that handle it. New rules are subsequently sent to the
switches, so similar packets arriving in the future are handled by
the switches, thus less traffic is diverted to the SDN controller.
NetCore is based on Frenetic [10]. The main difference
between these two languages is relative to the compiler and how
they deal with rich policies or manage the controller-switch
interactions. NetCore also adds a query language, which can
be used to analyze traffic history.
I. Nlog
Part of the Network Virtualization Platform (NVP), Nlog
[66] is a declarative language to compute forwarding state,
separating the logic specification from the controller that implements such logic. As in FML [61], Nlog has the design of
declarations based on DATALOGi queries; it does not support
recursive declarations or negations. Besides, it also has an integrated component to manage the declarations and the tuples of
data provided by the controller in runtime. This component is
written in C++ and is a sequential program. Therefore, each
declaration can use one tuple at a time.
J. Flowlog
Flowlog [67] resembles Structured Query Language (SQL)
in its design. It provides a unified abstraction for control-plane
and data-plane, and has limited expressivity in order to facilitate
the reasoning about correctness and rules proactively installed
into switches.
Flowlog has been used to discover bugs in SDN applications, while also producing efficient and minimal network rules.
These characteristics refer to i) its design, which follows a
logic programming paradigm, and ii) the support for program
verification, which is realized on Alloy [71]. This SDN programming language has different characteristics and features to
develop SDN applications, such as model checking, dynamic
verification on the code, and middleboxes with state monitoring.
Moreover, Flowlog extends Frenetics design with proactive
compilation for stateless NetCore policies.
K. Merlin
Merlin is declarative language created to address problems related to bandwidth and packet-processing functions.
According to [34], it has high-level components for i) classifying packets; ii) controlling forwarding packets; iii) specifying
packet-processing functions; and iv) defining bandwidth properties. Merlin goes beyond the features of existing languages
like Frenetic [10] and Pyretic [64]. The advantages of Merlin
are related to its constructs (e.g., statements, logical predicates,
and packet-processing functions), mainly due to the support of
regular expressions for defining forwarding paths.
1263
L. Kinetic
Kinetic is a DSL that provides abstractions for automating
changes in network policy in response to dynamic network
conditions [35]. In addition, it makes possible to verify if
such changes will satisfy network operators requirements and
how it should react to changing network conditions. Such
a verification makes Kinetic different from several previous
languages.
Regarding its architecture, Kinetic is embedded in Pyretic
[64] and uses its underlying structure to handle network events
(e.g., incoming packets). An application created with Kinetic
is similar to a Finite State Machine, it can change its state
according to an external event (e.g., incoming flows, updates,
and requests). On the other hand, the characteristics of Kinetic
are very close to that of Flowlog [67], as both focus on creating
correct applications. However, Kinetic has a more automated
verification and it was evaluated in realistic scenarios.
V. L ESSONS L EARNED FROM THE SDN P ROGRAMMING
L ANGUAGES
In order to analyze the particularities of current SDN programming languages, we have summarized the aspects of
each of them, highlighting the set of their important features,
namely scope, paradigm, main objectives, and current limitations. Some languages could not be investigated in details since
its code is not publicly available (e.g., Procera [52], NetCore
[63], FatTire [40]). But overall this issue did not affect the
analysis.
Table I presents such summary and has the following structure: the scope feature has the analysis of the main network
features that may be involved by the corresponding programming language. The paradigm feature lists the approaches
currently used to design SDN programming languages. The features objective and year describe the languages goal and the
year which the programming language was released, respectively. Feature limitations presents our view on the weaknesses
of each language, at the time of writing this paper.
Despite the slightly different objectives, all the programming
languages analyzed have in common the assertion about how
complex is to develop SDN applications without the proper
level of abstraction. Although there are some limitations, those
languages and their designs demonstrate a clear direction about
the future of SDN applications and the problems involving
events, policies, and conflicts in a SDN environment. It is worth
emphasizing that many of these languages are still work in
progress.
A. What SDN Programming Language to Use? When? How?
It would be unfair to point out only one SDN programming
language that is recommended for implementing SDN applications. The truth is that each language focuses on a certain
aspect of SDN paradigm and serves to create different types of
applications. However, according to our view - based on the corresponding papers and specification of each SDN programming
language - it is important to observe some key characteristics
for a proper a choice.
1264
TABLE I
S UMMARY OF SDN P ROGRAMMING L ANGUAGES AND I TS A SPECTS
First, the SDN programming languages analyzed in this

survey paper may be grouped by several aspects, such as
use cases, programming paradigms, controller operation mode,
etc. However, one crucial point is related to the controller
dependency on most of the SDN programming languages.
Such a dependency leads a network operator to select an SDN
controller before the SDN programming language that will be

used. Fortunately, some approaches are trying to eliminate such
an issue [73], [74].
Second, the SDN programming languages may be used
when there is a need for a higher level of abstraction, especially when a developer needs to specify policies of a complex
network in the controller. Most of these programming languages (e.g., Pyretic [64], FML [61]) provide abstractions
and features that make the specification and management of
policies, network features, and network behavior much easier when compared to defining OpenFlow rules by hand, for
instance.
Third, SDN programming languages have the SDN controller as the underlying element in the SDN architecture (cf.
Fig. 7). The programming languages discussed in this paper
show that each of them is intrinsically related to the controller and the compiler that translates high-level methods into
OpenFlow rules. Therefore, the common way to use such languages is writing the SDN applications in the corresponding
syntax. The related compiler performs translation and underlying controller applies the resulting rules into forwarding devices
and their flow tables.
Last but not least, not all SDN programming languages
have features for verifying and validating applications. Some
languages have limited focus to address problems of a specific category. These aspects should be taken into account
when choosing a language to create applications for an SDN
environment.
1265
TABLE II
P ROS AND C ONS OF P ROGRAMMING L ANGUAGES PARADIGMS FOR
C REATING SDN A PPLICATIONS
B. Why There Are Different Trends of the SDN Programming

Languages Design?
To answer that question, it is important to highlight that
since each SDN challenging scenarios can be addressed using
different abstractions, it is a matter of particular choice to
decide which abstraction is more suitable to address a particular domain problem. Moreover, the gap between programming
paradigms has been overcome by multi-paradigm programming languages. By using more than one paradigm, such
programming languages enable the developers to apply the right
techniques for their problems, without compromising to a single paradigm. Multi-paradigm approaches generally involve the
DSL paradigm (graphical or textual) in their design.
C. What is the Best Paradigm for an SDN Programming

Language? What Are Their Pros and Cons?
Although SDN programming languages use several
paradigms in their structures, some of these paradigms demonstrate a higher level of suitability for SDN. Such suitability
might have more than one perspective, e.g., expressiveness,
abstraction level, correctness, and the like (cf. Table II).
From our point of view, the popularity of FRP and DSL
paradigms in current SDN programming languages has two
main reasons, namely i) they enable high abstraction levels
for representing its elements and ii) involve several events and
rules, which its applications need to handle. Therefore, DSL
and FRP paradigms become together a plausible way for building SDN languages. Moreover, some DSLs [75] can provide
a constraint checker for verifying and validating applications.
On the other hand, approaches using imperative paradigm, for
instance, make hard for a developer the writing of SDN applications that result in correct and consistent network behavior.
In Table II, specifically, we point out a not exhaustive list of

pros and cons for each paradigm in the structure of an SDN
programming language.
VI. A NALYSIS OF U SE C ASES AND A PPLICATIONS
FOR SDN P ROGRAMMING L ANGUAGES
Prospective environments for SDN scenarios drive us to analyze a number of specific applications and use cases for SDN
programmability. All the languages analyzed in this survey have
use cases and evaluation scenarios in their respective publications. This section then presents an overview of the SDN
programming languages and their possible applications to be
developed.
Initially we describe and categorize the applications in the
use cases previously defined in this survey. Then, we map these
applications and use cases to the SDN programming languages
1266
TABLE III
M APPING OF SDN P ROGRAMMING L ANGUAGES TO SDN A PPLICATIONS AND T HEIR U SE C ASES
The feasibility of each of the above identified programming language as an application and use case enabler: FULLY
FEASIBLE ( ) the language has all features to deploy the application; PARTIALLY FEASIBLE () the language needs another tool or complement to implement the application; and NOT FEASIBLE () the language is
not recommended to implement the related application.
that may be used by developers to write them, as shown in

Table III. This mapping defines the lessons learned in this survey, providing directions on what language to use in developing
SDN applications.
Admission Control: An admission control application
enables the administrator to specify the authentication rules
for hosts and users that try to access the network. Admission
control applications can be implemented through an SDN
programming language to define what default connectivity is
allowed and which authentication mechanisms will be used.
Load Balancing: The load balancing use case might be seen
as a congestion-aware routing for networks [76]. With a load
balancing application, the controller prevents overload instructing the switches how to balance the incoming traffic among the
network paths.
Quality of Service (QoS): For QoS applications, developers may use how resources should be allocated to different
users and flow classes. This is done by setting some network
properties, such as latency and available bandwidth. These
applications to fit in the Applications-based Network use case.
This is because end-user software can communicate with the

SDN controller, which must be running a QoS application, to
request some network resource.
NAT Administration: The Network Address Translation
(NAT) Administration is generally used to enable multiple
machines within a private IP range to share a single public
IP address, mapping two pools of IP addresses. This translation requires an implementation which alters the IP and port
number of each packet in the private network. This is the basic
difference between NAT and others applications mentioned. In
NAT administration, each packet in the flow must be modified, therefore requiring the network switches to support this
functionality. In the SDN scenario, the NAT administration
application may be executed on the controller, which installs
rules into switches to perform the modification of headers of
certain packets corresponding to IP addresses and port numbers
that should have a specific quality [61].
Security Rules: A typical example of security rules is the
implementation of an IP addresses black list module that
prevents a malicious IP source addresses from sending traffic.
Fault Tolerance: An interesting use case involves network resilience scenarios. For instance, in the case of a link
failure, the network should be able to choose a backup path
dynamically.
Deep Packet Inspection: It is a network application which
examines packets payload looking for patterns, such as from
well-known applications and services, viruses, attacks, and the
like. In SDN, the controller executes some algorithm to perform
DPI. SDN languages as Frenetic [10] and NetCore [63] have
features to implement DPI applications.
Cloud Orchestrator: The Cloud Orchestration use case needs
a software orchestrator in order to manage the network and
the virtual machines. All SDN languages partially enable the
implementation of such a software, because they only provide
methods to implement a network application, which in this case
may create the network orchestrator. The orchestrator of virtual
machine needs to be developed with third parties programming
languages or obtained from vendors.
Policy Specification: The most basic feature of an SDN application and environment is the specification of policies. All the
analyzed SDN programming languages enable the implementation of policies in several ways, as well as applications to define
the network behavior through policies. However, they differ in
the way of writing and implementing these policies in practice.
Network Monitor: Foster et al. [16] argue that querying network state is one of the fundamental elements in programming
SDNs. A Network Monitor application in SDN can observe and
request several types of information (e.g., packet counter state
in a switch). All languages analyzed allow the implementation
of applications that monitor network states.
Correctness: The verification and validation of network
applications are desired features [34], [35]. SDN programming languages might offer constructs that help developers to
avoid network misbehavior (i.e., verification), and to build correct applications (i.e., validation), according to the specified
requirements.
VII. R ESEARCH C HALLENGES AND F UTURE D IRECTIONS

The SDN scenario brings many opportunities to network
operators, but also brings a number challenges to overcome.
These challenges involve, for instance, correctness in SDN
applications, proper handling of failures, avoid conflicting policy rules, automating software tests, and abstracting the complexity in development of SDN applications. We offer our view
on such research challenges as well as we also provide guidelines for advanced research and standardization developments
in this topic.
A. Open Research Issues

In this subsection we pose a number of questions regarding the Software Engineering discipline perspective (e.g., tools
and methodologies) on SDN programming. For each issue
raised, we also provide directions for future research and development work, thus setting embryonic guidelines for further
developments of advanced applications in SDN environments.
1267
TABLE IV
C OMPARING AN E XAMPLE OF I NTEGRITY I SSUES IN P ROGRAMMING
SDN A PPLICATIONS
The first table row is an algorithm based on Pyretic language which causes a
deadlock in the network. The second table row, in contrast, presents a metamodel which does not allow the relation between the controller with itself in
specifying SDN applications (i.e., the entity named Controller can relate, in this
example, with the ControllerSwitchLink entity, which in its turn is related only
with the SdnSwitch entity). On the other hand, the first table row exhibits that
relationship between a controller and itself has no constraints. This relationship
enables constructions like the one shown, which may generate a misbehaviour.
What approaches ensure the correctness for SDN application

development? Why is this important? The correctness attribute
is a characteristic of programming languages. It specifies the
constraints and list all possible program states, comparing these
states to check if they meet the constraints.
Correctness guarantees can avoid unwanted states in the execution of a certain application. Shin et al. [49] try to specify and
define constraints to SDN programming languages, although
there is no ultimate solution to this issue yet. The languages
presented so far have no ways to ensure integrity constraints
to the behavior of an SDN environment and its applications.
The utilization of metamodels defined in MDE can also guarantee the correctness for SDN applications and its development.
Table IV presents an algorithm that causes a deadlock in the
network (first table row), and a metamodel which prevents such
wrong implementation (second table row).
In [77], Qadir and Hasan surveyed some solutions to build
correct SDN applications by using formal methods. They
present a list of techniques for verifying SDN environments
and their applications, such as reachability analysis [24], loop
detection [78], and control plane verification [79], which are
still open issues that require a further investigation.
How to handle network failures? A recurrent discussion on
SDN research involves handling of failures. Failures can occur
in the availability of a controller or even in wrong policy rules
defined by an SDN application. The authors of FatTire argue
that programmers do not write programs using the primitive
1268
fast-failover OpenFlow mechanisms directly due to the increment of complexity in failure-handling control, which might
make code more complex.
In order to handle failures in SDN programming, the language needs to support an abstraction of the OpenFlow forwarding table called a group table. Group table consists of
group entries. The ability for a flow entry to point a group
enables OpenFlow to represent more methods of forwarding
[16]. It enables multiple conditional rules in OpenFlow. One of
the group table types is the fast failover (FF). The fast failover
determine that if a flow entry belongs to this group type, the first
action bucket (an ordered list of actions) will be performed.
FatTire [40] abstracts the construction of a fast failover group
table, generating the entries in such group table automatically.
This approach avoids the error-prone development made by
programmers when interacting with fast failover group table
directly [40].
From the Software Engineering perspective, the development
of fault-tolerant applications must be based on languages that
define dependable features or build rules created from formal
methods. For instance, a language that provides modular development may enable an SDN application to run as redundant
modules in replicated controllers, thus improving the recovering time of a network failure. However, synchronizing such
modules is not a trivial task [33].
How to avoid conflicting rules? This is a challenge investigated by some research studies (e.g., PANE [80], Pyretic
[64]). Avoiding conflicts means that a policy rule X does not
invalidate a policy rule Y, and vice-versa, simultaneously, so
that at least one policy rule should be correctly applied. In
[61], Hinrichs et al. proposed two conflict resolution mechanisms, which we consider a valuable path to effective SDN
programming, i.e. one has its features at the level of keywords,
identifying the conflicting policies. The other mechanism is
a schema that defines priority to each keyword (e.g. the keyword deny has precedence over the keyword allow). A similar
approach can be also found in [80]. One possible approach to
address conflicts in policies could be based on a DSML. In such
an approach, invalid policies that result in conflicts could not
be created due to the constraints contained in an underlying
metamodel.
How can one realize automated tests? In order to identify
inconsistences or unexpected states in an SDN application,
Canini et al. [81] and Vissichio et al. [82] propose approaches
to realize tests in SDN applications. End-host applications and
switches affect the program running on the controller. In [81]
Canini et al. address this challenge by generating flows with
several possible events occurring in parallel. It also enables the
programmer to verify generic correctness properties (e.g., forwarding loops or black holes) and code validation (i.e., global
system state determined by code fragments). On the other hand,
in [82] Vissichio et al. use Test-Driven Development (TDD) to
perform tests on SDN applications.
How to abstract the complexity in SDN development efficiently? The low level of abstraction used by OpenFlow and its
releases makes it hard to program applications and to define a
desired behavior into the network. The studies analyzed suggest
that a decomposition of the controller, through one relationship
with the OpenFlow protocol and adding a layer to specify

policies, reduces the complexity to develop and deploy SDN
applications, mainly due to the readiness to build applications
without the need to worry about maintaining consistency of
various rules present in an SDN environment. Therefore, such
an abstraction is more than only adding more layers for SDN
architecture or controllers; it also provides smart structures that
reduce the complexity in SDN applications development, and
not just encapsulating the methods from the underlying structures. Furthermore, this layering and efficient structures can be
used by some DSML, further increasing the level of abstraction,
enabling the concrete visualization of network behavior.
Be reactive or proactive? The proactive or reactive behavior
and structure of a certain SDN language will depend closely
on the controller and how packet handling occurs. It is worth
emphasizing that one could follow a hybrid approach, where
a combination of both strategies allows the flexibility from
reactive paradigm to particular sets of traffic control, while
proactively providing low latency routing for ordinary traffic.
Creating a framework or SDN language to support these two
main approaches seems to be the most correct way to achieve
completeness. As far as we are concerned to create an SDN language, the possibility of defining a DSML enables developers
to develop high-quality SDN applications. This is due to the
ability of DSML to raise the level of abstraction in software
programming, because its visual representations are easier to
understand than the syntax of textual programming languages.
How to improve the SDN programmability? Although this
question allows a number of answers, we aim at presenting and
discussing the four most important issues that need improvements: i) verifying and validating applications (e.g., consistent
updates, rules, and the like), which could be achieved by
using DSMLs or constraint checkers in compilers; ii) offering
high-level tools for developers, since there is no widespread
tool (e.g., Integrated Development Environment IDE, CASE
tool) for creating SDN applications; iii) providing programming languages independent from the underlying controllers
or southbound protocols, which fortunately there are some
efforts in this direction, such as P4; and iv) writing applications that meet network dependable requirements, which should
be achievable by programming languages and their features
(e.g., avoiding functions that reduces availability and offering
fault-tolerant components).
B. Future Directions in SDN Programmability
Though SDN enables the network programmability, there are
still many issues and topics to investigate. The multiple implementations of SDN controllers by different vendors result in
different ways to program the network. Moreover, current SDN
languages are dependent on controllers, meaning that there
might be incompatibility between SDN applications and different controllers. In this scenario, we suggest some directions to
develop SDN applications, from the perspective of the Software
Engineering discipline.
Standardize processes and development tools. It is extremely
complex to build correct SDN applications, which work in different contexts, and to meet requirements defined by network
analysts. There is no standard architecture, and SDN applications have been handcrafted written from SDN languages
proposals. Research efforts should establish processes and tools
(e.g., frameworks) for achieving a higher-level of abstraction in developing SDN applications. For instance, researches
could investigate solutions based on DSL and DSML to avoid
the development of unsafe applications. Composing such languages with well-formed algorithms and methods seems to be
a way to define a process or create a tool for developing SDN
applications.
Design Patterns for SDN applications. The software development process has problems that occur repeatedly in different
situations through code written by developers. In order to avoid
such repeated and known errors, design patterns [83] provides a
set of solutions from the Software Engineering perspective that
can be used in many different situations. Since SDN applications are also software, the definition of design patterns in the
scope of SDN can help developers in avoiding improper builds
while writing SDN applications.
Test-Driven Development for SDN. Currently, the tests of
SDN applications and environments can use a network simulator (e.g., Mininet [84]) and an SDN controller which manages the emulated network. However, performing tests in such
environment based on manual deployments is error-prone.
Unfortunately, to date, network operators have no alternatives
than manually verify the network behavior when running experimental applications. This scenario drives the investigation of
Test-Driven Development (TDD) applied to SDN applications
development. Vissichio et al. [82] published the first approach
to apply TDD to SDN.
Increase the level of abstraction in SDN applications development. The need for a network operator to understand programming languages (SDN specific or not) in defining the
network behavior through SDN applications is a drawback.
Even in the interaction of a network operator or developer with
an SDN controller through an API, there is a need for understand the programming methods and algorithms. SDN does not
limit its level of abstraction in interaction with controllers or in
developing SDN applications. The enabling of higher abstraction levels, in interacting with controllers or developing SDN
applications, seems to be a valuable approach for facilitating the
utilization of SDN paradigm and its components. We suggest
the use of DSML as an important direction in SDN applications development or in the interaction with SDN controllers.
As previously described (cf. section III. C), a DSML has a concrete syntax (e.g., graphical representation), an abstract syntax
(e.g., metamodel), and it enables code generation. Thus, when
well-specified, a DSML can help network operators in defining
the network behavior without the need to understand low-level
algorithms [85].
Match applications development for the control-plane with
algorithms in the data-plane. One of the limitations involving the most SDN languages presented in this paper is the
dependency between programming languages, controllers, and
protocols (e.g., OpenFlow). A timely research field that is being
explored deals with the alignment between programming of
control and data planes [73]. It means enabling the applications created for control plane (i.e., SDN controllers) to be
1269
deployed on data plane without the dependency of a specific

hardware (e.g., OpenFlow switch) or protocol. In [73] and
[5] the authors highlight the issues regarding the dependency
between SDN applications and the underlying elements (i.e.,
controllers and protocols) (cf. section VII. A). P4 [73] is a
programming language focused on programming the SDN forwarding plane independent from any protocol (e.g., OpenFlow).
Similarly, POF [5] also gives flexibility to the forwarding plane.
Its main argument is that legacy OpenFlow-enabled switches
cannot handle new headers added in each new version of
OpenFlow protocol, making devices obsolete. Besides, any
update in OpenFlow needs also to be changed in the controller.
VIII. C ONCLUSION
In this paper, we presented a comprehensive review of the
state-of-the-art on programmability for SDN environments,
with a particular perspective from the Software Engineering
discipline. The specifications and paradigms used to build the
SDN languages avoid the low-level characteristics of OpenFlow
[2], and also avoid the complexities related to SDN features
(e.g. policy conflicts, countless rules, and the like). These
paradigms have a decisive impact on the success of a certain
SDN language and how it will set ground to the development of
SDN applications that are effective and efficient.
Compared to other recent surveys in SDN field, such as
Nunes et al. [86], Hu et al. [87], and Xia et al. [88], we presented the state-of-the-art for SDN programming languages,
instead of focusing on programmable networks [86] or SDN
applications/use cases [87], [88]. We provide a unique view
in analyzing SDN and its applications based on well-known
as well as recent concepts from the Software Engineering
discipline.
After the analysis, we have identified that many current
approaches in programming SDN applications are based on the
paradigm of reactive programming and also on DSL. This is
due to the dynamic nature of the network that reacts to different types of external and internal events. We highlighted
that despite there are already various solutions to develop SDN
applications, all of them are dependent on a specific controller (and protocol), which may raise interoperability problems between SDN applications in different scenarios (e.g.,
multi-vendor controllers). Fortunately, recent approaches, such
as POF [5] and P4 [73], try to overcome such a dependency.
Some current challenges show that the programming of
SDN applications is still complex and not completely standardized; they might hinder the adoption of SDN as an effective
solution. We elucidated some important aspects based on the
Software Engineering discipline, which can bring improvements to the development of SDN applications. In particular,
the MDD/DSML concept is a possible research path to investigate, in order to achieve correctness, completeness, ease of use,
and productivity.
Although there are several abstractions at the application
level for SDN, there are still issues to be addressed, such
as interoperability, fault handling, and conflict resolution or
detection. Although SDN offers the opportunity of innovative and powerful networking scenarios, the development of
1270
correct applications with efficiency and efficacy is still a work

in progress. Thus, this survey concludes with concrete although
germinal guidelines for SDN programmability, by unraveling
its key current research issues that need to be focused in a near
future. We suggested some directions for future research work
in the field of SDN programmability. We hope that such suggestions motivate further discussion within the SDN research
and development community.
R EFERENCES
[1] J. S. Turner and D. E. Taylor, Diversifying the internet, in Proc. IEEE
Global Telecommun. Conf. (GLOBECOM 05), Dec. 2, 2005, pp. 760
765.
[2] N. McKeown et al., OpenFlow: Enabling innovation in campus networks, ACM SIGCOMM Comput. Commun. Rev., vol. 38, no. 2,
pp. 6974, Apr. 2008.
[3] N. Kim and J. Kim, Building NetOpen networking services over open
flow-based programmable networks, in Proc. Int. Conf. Inf. Netw.
(ICOIN11), Jan. 2011, pp. 525529.
[4] Cisco, OpFlex: An open source approach, 2014, http://www.cisco.
com/c/en/us/solutions/collateral/data-center-virtualization/applicationcentric-infrastructure/white-paper-c11-731304.html
[5] H. Song, Protocol-oblivious forwarding: Unleash the power of SDN
through a future-proof forwarding plane, in Proc. 2nd ACM SIGCOMM
Workshop Hot Topics Softw. Defined Netw. (HotSDN13), 2013,
pp. 127132.
[6] A. Doria et al., Forwarding and control element separation, RFC 5810
(Proposed Standard), Mar. 2010.
[7] A. T. Campbell, I. Katzela, K. Miki, and J. Vicente, Open signaling for
ATM, internet and mobile networks (OPENSIG98), ACM SIGCOMM
Comput. Commun. Rev., vol. 29, no. 1, pp. 97108, 1999.
[8] D. L. Tennenhouse, J. M. Smith, W. D. Sincoskie, D. J. Wetherall, and
G. J. Minden, A survey of active network research, IEEE Commun.
Mag., vol. 35, no. 1, pp. 8086, Jan. 1997.
[9] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and
S. Shenker, Ethane: Taking control of the enterprise, ACM SIGCOMM
Comput. Commun. Rev., vol. 37, no. 4, pp. 112, 2007.
[10] N. Foster et al., Frenetic: A network programming language, in
Proc. 16th ACM SIGPLAN Int. Conf. Funct. (ICFP), Sep. 2011,
pp. 279291.
[11] D. Kreutz, F. M. V. Ramos, P. Verissimo, C. E. Rothenberg,
S. Azodolmolky, and S. Uhlig, Software-defined networking: A comprehensive survey, Proc. IEEE, vol. 103, no. 1, pp. 1476, Jan. 2015.
[12] M. Jarschel, T. Zinner, T. Hossfeld, P. Tran-Gia, and W. Kellerer,
Interfaces, attributes, and use cases: A compass for SDN, IEEE
Commun. Mag., vol. 52, no. 6, pp. 210217, Jun. 2014.
[13] N. Feamster, J. Rexford, and E. Zegura, The road to SDN, QueueLarge-Scale Implement., vol. 11, no. 12, p. 20, 2013.
[14] A. Lara, A. Kolasani, and B. Ramamurthy, Network innovation using
OpenFlow: A survey, IEEE Commun. Surv. Tuts., vol. 16, no. 1, pp. 493
512, Feb. 2014.
[15] S. Raza and D. Lenrow, North Bound Interface Working
Group (NBI-WG) Charter. Open Networking Foundation, 2013,
https://www.opennetworking.org/images/stories/downloads/workinggroups/charter-nbi.pdf.
[16] Open Networking Foundation. (2013, Oct. 14) OpenFlow Switch
Specification 1.4.0 [Online]. Available: https://www.opennetworking.org/
images/stories/downloads/sdn-resources/onf-specifications/openflow/
openflow-spec-v1.4.0.pdf, accessed on Apr. 20, 2014.
[17] S. Fernandes, E. Tavares, M. Santos, V. Lira, and P. Maciel,
Dependability assessment of virtualized networks, in Proc. IEEE Int.
Conf. Commun. (ICC), Jun. 1015, 2012, pp. 27112716.
[18] F. Longo, S. Distefano, D. Bruneo, and M. Scarpa, Dependability
modeling of Software Defined Networking, Comput. Netw., vol. 83,
pp. 280296, Jun. 2015.
[19] A. Lara, A. Kolasani, and B. Ramamurthy, Network innovation using
OpenFlow: A survey, IEEE Commun. Surv. Tuts., vol. 16, no. 1, pp. 493
512, First Quart. 2013.
[20] A. Autenrieth, J.-P. Elbers, P. Kaczmarek, and P. Kostecki, Cloud orchestration with SDN/OpenFlow in carrier transport networks, in Proc. 15th
Int. Conf. Transparent Opt. Netw. (ICTON), Jun. 2327, 2013, pp. 14.
[21] R. Moreno-Vozmediano, R. S. Montero, and I. M. Llorente, IaaS cloud

architecture: From virtualized datacenters to federated cloud infrastructures, IEEE Comput., vol. 45, no. 12, pp. 6572, Dec. 2012.
[22] K. Bilal, S. U. R. Malik, S. Khan, and A. Zomaya, Trends and challenges
in cloud datacenters, IEEE Cloud Comput., vol. 1, no. 1, pp. 1020, May
2014.
[23] C. Yu, C. Lumenazu, Y. Zhang, V. Singh, G. Jiang, and H. V. Madhyastha,
FlowSense: Monitoring network utilization with zero measurement
cost, in Proc. 14th Int. Conf. Passive Act. Meas. (PAM), 2013,
pp. 3141.
[24] A. Khurshid, W. Zhou, M. Caesar, and P. Godfrey, Veriflow: Verifying
network-wide invariants in real time, ACM SIGCOMM Comput.
Commun. Rev., vol. 42, no. 4, pp. 467472, 2012.
[25] P. I. Heleno, J. W. Araujo, C. B. Both, J. Rochol, and G. L. Zambenedetti,
Interactive monitoring, visualization, and configuration of OpenFlowbased SDN, in Proc. IFIP/IEEE Int. Symp. Integr. Netw. Manage. (IM),
May 1115, 2015, pp. 207215.
[26] A. Lara, A. Kolasani, and B. Ramamurthy, Simplifying network
management using Software defined networking and OpenFlow, in
Proc. IEEE Int. Conf. Adv. Netw. Telecommun. Syst. (ANTS), 2012,
pp. 2429.
[27] D. Staessens, S. Sharma, D. Colle, M. Pickavet, and P. Demeester,
Software defined networking: Meeting carrier grade requirements, in
Proc. 18th IEEE Workshop Local Metrop. Area Netw. (LANMAN), 2011,
pp. 16.
[28] D. Hock, S. Gebert, M. Hartmann, T. Zinner, and P. Tran-Gia, POCOframework for Pareto-optimal resilient controller placement in SDNbased core networks, in Proc. IEEE Netw. Oper. Manage. Symp.
(NOMS), May 59 2015, pp. 12.
[29] Y. Hu, W. Wang, X. Gong, X. Que, and S. Cheng, On reliabilityoptimized controller placement for software-defined networks, China
Commun., vol. 11, no. 2, pp. 3854, Feb. 2014.
[30] D. Li et al., High availability for Non-stop network controller, in
Proc. IEEE Int. Symp. World Wireless Mobile Multimedia Netw., 2014,
pp. 15.
[31] P. Berde et al., ONOS: Towards an open, distributed SDN OS, in Proc.
3rd Workshop Hot Topics Softw. Defined Netw., Aug. 17 2014, pp. 16.
[32] D. Kreutz, F. M. V. Ramos, and P. Verssimo, Towards secure and
dependable software-defined networks, in Proc. ACM SIGCOMM
Workshop HotSDN, Sep. 2013, pp. 5560.
[33] R. Mahajan and R. Wattenhofer, On consistent updates in software
defined networks, in Proc. ACM SIGCOMM Workshop HotNets, 2013.
[34] R. Soul et al., Merlin: A language for provisioning network resources.,
in Proc. ACM CoNEXT, Dec. 2, 2014, pp. 213225.
[35] H. Kim, J. Reich, A. Gupta, M. Shabaz, N. Feamster, and R. Clark,
Kinetic: Verifiable dynamic network control, in Proc. 12th USENIX
NSDI, May 2015, pp. 5972.
[36] S. Yeganeh, A. Tootoonchian, and Y. Ganjali, On scalability of softwaredefined networking, IEEE Commun. Mag., vol. 51, no. 2, pp. 136141,
Feb. 2013.
[37] A. Tootoonchian, S. Gorbunov, Y. Ganjali, M. Casado, and R. Sherwood,
On controller performance in software-defined networks, in Proc. 2nd
USENIX Conf. Hot Topics Manage. Internet Cloud Enterp. Netw. Serv.
(Hot-ICE12), 2012, p. 10.
[38] Y. Hu, W. Wendong, X. Gong, X. Que, and C. Shiduan, Reliabilityaware controller placement for Software-Defined Networks, in Proc.
IFIP/IEEE Int. Symp. Integr. Netw. Manage. (IM13), 2013, pp. 672675.
[39] M. KangK.-H. Nam, J. Park, M.-K. Shin, J. Shin, and J.-Y. Choi
et al., Formal specification framework for software-defined networks (SDN), in Proc. 7th Int. Conf. Future Internet Technol.,
2012, pp. 51.
[40] M. Reitblatt, M. Canini, A. Guha, and N. Foster, FatTire: Declarative
fault tolerance for software-defined networks, in Proc. ACM SIGCOMM
Workshop HotSDN, 2013, pp. 109114.
[41] N. Gude et al., NOX: Towards an operating system for networks, ACM
SIGCOMM Comput. Commun. Rev., vol. 38, 2008, pp. 105110.
[42] R. H. Bordini et al., A survey of programming languages and platforms
for multi-agent systems, Informatica Slovenia, vol. 30, no. 1, pp. 3344,
2006.
[43] H. Nilsson, A. Courtney, and J. Peterson, Functional Reactive
Programming, Continued. New York, NY, USA: ACM, Oct. 2002,
pp. 5164.
[44] E. Bainomugisha, A. L. Carreton, T. V. Cutsem, S. Mostinckx, and
W. D. Meuter, A survey on reactive programming, ACM Comput. Surv.
(CSUR), vol. 45, p. 52, Aug. 2013.
[45] C. Elliot and P. Hudak, Functional reactive animation, in Proc. Int.
Conf. Funct. Programm., 1997, pp. 163173.
[46] D. M. Jones, Forms of language specification examples from commonly used computer languages, ISO/IEC JTC1/SC22/OWG/N0121,
Feb. 2008.
[47] M. Satpathy, R. Harrison, C. Snook, and M. Butler, A comparative study
of formal and informal specifications through an industrial case study,
in Proc IEEE/IFIP Workshop Formal Specif.Comput. Based Syst., 2001,
pp. 318321.
[48] E. C. R. Hehner, Specifications, programs, and total correctness, J. Sci.
Comput. Programm., vol. 34, no. 3, pp. 191205, Jul. 1999.
[49] A. Guha, M. Reitblatt, and N. Foster, Formal foundations for software
defined networks, in Proc. Open Netw. Summit (ONS) Res. Track, 2013.
[50] M. Fowler, Domain-Specific Languages. Reading, MA, USA: AddisonWesley, 2010.
[51] M. Strembeck and U. Zdun, An approach for the systematic development of domain-specific languages, J. Softw. Pract. Exp., vol. 39, no. 15,
pp. 12531292, Oct. 2009.
[52] A. Voellmy, H. Kim, and N. Feamster, Procera: A language for highlevel reactive network control, in Proc. 1st Workshop Hot Topics Softw.
Defined Netw. (HotSDN12), 2012, pp. 4348.
[53] D. C. Schmidt, Model-driven engineering, IEEE Comput., vol. 39,
no. 2, pp. 2531, Feb. 2006.
[54] A. Bariic, M. Goulo, and B. Barroca, Quality in use of domain specific
languages: A case study, in Proc. 3rd ACM SIGPLAN Workshop Eval.
Usability Programm. Lang. Tools (PLATEAU11), 2011, pp. 6572.
[55] A. Van Deursen, P. Klint, and J. Visser, Domain-specific languages: An
annotated bibliography, in Sigplan Notices, vol. 35.6, 2000, pp. 2636.
[56] A. F. Case, Computer-aided software engineering (CASE): Technology
for improving software development productivity, ACM SIGMIS
Database, vol. 17 no. 1, pp. 3543, 1985.
[57] D. Frankel, Model Driven Architecture: Applying MDA to Enterprise
Computing. Hoboken, NJ, USA: Wiley, 2002.
[58] T. Stahl, M. Voelter, and K. Czarnecki, Model-Driven Software
Development: Technology, Engineering, Management. Hoboken, NJ,
USA: Wiley, 2006.
[59] R. C. Gronback, Eclipse Modeling Project: A Domain-Specific Language
(DSL) Toolkit. Reading, MA, USA: Addison-Wesley, 2009.
[60] T. zgr, Comparison of microsoft DSL tools and eclipse modeling
frameworks for domain-specific modeling in the context of the model
driven development, M.S. thesis, School of Engineering, Blekinge Inst.
Technology, Ronneby, Sweden, 2007, p. 56.
[61] T. L. Hinrichs, N. S. Gude, M. Casado, J. C. Mitchell, and S. Shenker,
Practical declarative network management, in Proc. ACM Workshop
Res. Enterp. Netw. (WREN09), Aug. 21, 2009, pp. 110.
[62] A. Voellmy, A. Agarwal, and P. Hudak, Nettle: Functional reactive programming for OpenFlow networks, in Proc. Pract. Aspects Declarative
Lang. (PADL), Jul. 2011, pp. 235249.
[63] C. Monsanto, N. Foster, R. Harrison, and D. Walker, A compiler
and run-time system for network programming languages, in Proc.
Principles Programm. Lang. (POPL), Jan. 2527, 2012.
[64] C. Monsanto, J. Reich, N. Foster, J. Rexford, and D. Walker, Composing
software-defined networks, in Proc. 10th USENIX Symp. Netw. Syst.
Des. Implement. (NSDI), 2013, pp. 114.
[65] N. P. Katta, J. Rexford, and D. Walker, Logic programming for softwaredefined networks, in Proc. ACM SIGPLAN Workshop Cross-Model
Lang. Des. Implement., 2012.
[66] T. Koponen et al., Network virtualization in multi-tenant datacenters, in
Proc. 11th USENIX Symp. Netw. Syst. Des. Implement. (NSDI 14), Apr.
2014, pp. 203216.
[67] T. Nelson, A. D. Ferguson, M. J. Scheer, and S. Krishnamurthi, Tierless
programming and reasoning for software-defined networks, in Proc.
11th USENIX Symp. Netw. Syst. Des. Implement., Apr. 24, 2014.
[68] N. Foster et al., Languages for software-defined networks, IEEE
Commun. Mag., Feb. 2013.
[69] T. Koponen et al., Onix: A distributed control platform for largescale production networks, in Proc. USENIX Symp. Oper. Syst. Des.
Implement. (OSDI), Oct. 2010, pp. 351364.
[70] POX [Online]. Available: http://www.noxrepo.org/pox/about-pox/
[71] D. Jackson, Alloy: A lightweight object modelling notation, ACM
Trans. Softw. Eng. Methodol., Apr. 2002, pp. 256290.
[72] S. S. Huan, T. J. Green, and B. T. Loo, Datalog and emerging applications: An interactive tutorial, in Proc. ACM SIGMOD Int. Conf. Manage.
Data (SIGMOD11), 2011, pp. 12131216.
[73] P. Bosshart et al., P4: Programming protocol-independent packet processors, SIGCOMM Comput. Commun., Jul. 2014, pp. 8795.
[74] A. Sivaraman, C. Kim, R. Krishnamoorthy, A. Dixit, and M. Budiu,
DC.p4: Programming the forwarding plane of a data-center switch, in
Proc. 1st ACM SIGCOMM Symp. Softw. Defined Netw. Res., 2015.
1271
[75] K. Barrett, S. Davy, J. Strassner, B. Jennings, S. van der Meer, and

W. Donnelly, A model based approach for policy tool generation and
policy analysis, in Proc. IEEE Global Inf. Infrastruct. Symp., 2007,
pp. 99105.
[76] N. Handigol, M. Flajslik, S. Seetharaman, N. McKeown, and R. Johari,
Aster* x: Load-balancing as a network primitive, in 9th GENI Eng.
Conf. (Plenary), Nov. 2010 , pp. 12.
[77] J. Qadir and O. Hasan, Applying formal methods to networking: Theory,
techniques, and applications, Commun. Surv. Tuts., vol. 17, no. 1,
pp. 256291, 2015.
[78] P. Kazemian, M. Chang, H. Zeng, G. Varghese, and N. McKeown,
Real time network policy checking using header space, in
Proc. USENIX Symp. Netw. Syst. Des. Implement. (NSDI), 2013,
pp. 99112.
[79] D. Sethi, S. Narayana, and S. Malik, Abstractions for model checking SDN controllers, in Formal Methods in Computer Aided Design,
pp. 145148, 2013.
[80] A. D. Ferguson, A. Guha, C. Liang, R. Fonseca, and S. Kishnamurthi,
Participatory networking: An API for application control of SDNs, in
Proc. ACM SIGCOMM Conf., 2013, pp. 327338.
[81] M. Canini, D. Venzano, P. Pereni, D. Kostic, and J. Rexford, A NICE
way to test OpenFlow applications, in Proc. 9th USENIX Conf. Netw.
Syst. Des. Implement. (NSDI12), 2012, p. 10.
[82] S. Vissicchio, D. Lebrun, and O. Bonaventure, Towards test-driven software defined networking, in Proc. IEEE Netw. Oper. Manage. Symp.
(NOMS), May 2014, pp. 19.
[83] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design
Patterns: Elements of Reusable Object-Oriented Software. Boston,
MA, USA: Addison-Wesley Longman Publishing Co., Inc.,
1994.
[84] B. Lantz, B. Heller, and N. McKeown, A network in a laptop: Rapid prototyping for software-defined networks, in Proc. 9th ACM SIGCOMM
Workshop Hot Topics Netw. (Hotnets-IX), 2010, p. 19.
[85] F. A. Lopes, M. Santos, R. Fidalgo, and S. Fernandes, Model-driven
networking: A novel approach for SDN applications development, in
Proc. IFIP/IEEE Int. Symp. Integr. Netw. Manage. (IM), May 2015,
pp. 770773.
[86] B. Nunes, M. Mendona, X. Nguyen, K. Obraczka, and T. Turletti,
A survey of software-defined networking: Past, present, and future of
programmable networks, IEEE Commun. Surv. Tuts., vol. 16, no. 3,
pp. 16171634, Third Quart. 2014.
[87] F. Hu, Q. Hao, and K. Bao, A survey on software-defined network
and OpenFlow: From concept to implementation, IEEE Commun. Surv.
Tuts., vol. 16, no. 4, pp. 21812206, Fourth Quart. 2014.
[88] W. Xia, Y. Wen, C. Foh, and D. Niyato, A survey on software-defined
networking, IEEE Commun. Surv. Tuts., vol. 17, no. 1, pp. 2751, First
Quart. 2015.
[89] A. R. Curtis, J. C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma, and
S. Banerjee, DevoFlow: Scaling flow management for high-performance
networks, in Proc. ACM SIGCOMM Conf. (SIGCOMM11), 2011,
pp. 254265.
[90] D. Erickson, The beacon OpenFlow controller, in Proc. 2nd ACM
SIGCOMM Workshop Hot Topics Softw. Defined Netw. (HotSDN13),
2013, pp. 1318.
[91] E. Mannie, Generalized multi-protocol label switching (GMPLS) architecture, IETF, 2004 [Online]. Available: https://tools.ietf.org/html/
rfc3945, Tech. Rep. RFC 3945, accessed on Nov. 18, 2014.
[92] S. Das, G. Parulkar, and N. McKeown, Why OpenFlow/SDN can succeed where GMPLS failed, in Proc. Eur. Conf. Exhib. Opt. Commun.,
2012, pp. 13.
[93] H. Kim and N. Feamster, Improving network management with software
defined networking, IEEE Commun. Mag., vol. 51, no. 2, pp. 114119,
Feb. 2013.
[94] F. J. Ros and P. M. Ruiz, Five nines of southbound reliability in softwaredefined networks, in Proc. 3rd Workshop Hot Topics Softw. Defined
Netw. (HotSDN14), 2014, pp. 3136.
[95] V. Lira, E. Tavares, S. Fernandes, P. Maciel, and R. M. A. Silva, Virtual
network resource allocation considering dependability issues, in Proc.
IEEE 16th Int. Conf. Comput. Sci. Eng. (CSE), Dec. 35, 2013, pp. 330
337.
[96] V. Lira, E. Tavares, S. Fernandes, and P. Maciel, Dependable virtual network mapping, Computing, vol. 97, no. 5, pp. 459481,
2014.
[97] M. Santos, R. Martins, M. Santana, and S. Fernandes, An adaptive random heuristic in virtual networks: Dependability analysis, in
Proc. 8th Latin Amer. Netw. Oper. Manage. Symp. (LANOMS15),
2015.
1272
Felipe A. Lopes, received the bachelors degree in

information systems from the Federal Institute of
Alagoas (IFAL), Macei, Brazil, in 2013, and the
M.Sc. degree in computer science from the Federal
University of Pernambuco (UFPE), Recife, Brazil, in
2015.
Currently, he is a temporary Assistant Professor
at the IFAL and is working toward the Ph.D. degree
in computer science from UFPE. His research interests include software-defined networking, modeldriven engineering, parallel computing, and machine
learning.
Marcelo Santos, received the M.Sc. degree in information engineering from Federal University of ABC
(2011) in So Paulo, Brazil. He is currently a Ph.D.
student in computer science at the Federal University
of Pernambuco, Brazil. He did partial completion
of a doctorate program at IBISC Lab (20142015),
University of Evry Val dEssonne, France (project
SLA4Cloud).
His research interests include cloud computing,
software defined networking, network functions virtualization, virtual environments, OpenFlow protocol, and optimization techniques.
Robson Fidalgo, received the M.Sc. and Ph.D.
degrees in computer science from the Federal
University of Pernambuco (UFPE), Recife, Brazil, in
2000 and 2005, respectively.
In 2012, he performed postdoctoral research in
Computer Science at the Polytechnic University of
Valencia. Since 2006, he has been with the Center
of Informatics (CIn), UFPE, where he is currently an
Adjunct Professor. His research interests include systems and data modeling and metamodeling, domainspecific modeling languages (DSML), model-driven
development (MDD), CASE tools, systems and data integration, decision support systems, data warehouse (DW), online analytical processing (OLAP),
geographic information systems (SIG), geographic databases, ontologies and
assistive technologies focusing in alternative communication boards.
Stenio Fernandes (M97SM13) is a Professor

of Computer Science at the Center of Informatics
(CIn), Federal University of Pernambuco (UFPE),
Recife, Brazil. He is an Adjunct Professor at the
School of Electrical Engineering and Computer
Science (SEECS), University of Ottawa and at
the Department of Computer Science at Dalhousie
University (Halifax), both in Canada. He is currently
a Visiting Scholar at Carleton University, Canada.
His research interests include performance evaluation
of network and communications systems, internet
traffic measurement, modeling, and analysis, cloud computing, internet of
things/smart cities, network virtualization, and software-defined networking.
He is a Brazilian Research Chair (Tier 2 CNPq PQ-2). He has been
serving for a number of scientific journals, such as IEEE T RANSACTIONS
ON C OMPUTERS , IEEE T RANSACTIONS ON PARALLEL AND D ISTRIBUTED
S YSTEMS, IEEE C OMMUNICATIONS S URVEYS AND T UTORIALS, Elsevier
Computer Communications, Elsevier Computer Networks, and Springer
Wireless Networks. He is also in the Technical Program Committees for scientific conferences, such as IEEE ICC, IEEE Globecom, IEEE WCNC, and
IEEE CCNC. He has a decade of experience in conducting Research and
Development (R&D) projects, funded by either public or private grants, in the
computer networking field. He has been involved, as Principal Investigator (PI)
or Co-PI, in 20 research projects in the last 5 years, including several international projects. He has a solid record of research accomplishments in computer
communications and networks, as he has published more than 100 research
papers in major peer-reviewed conferences and journals organized by IEEE,
ACM, Elsevier, and Springer.

A Software Engineering Perspective On SDN PDF

Uploaded by

Copyright:

Available Formats

You might also like

A Software Engineering Perspective On SDN PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Software Engineering Perspective On SDN PDF

Uploaded by

Copyright:

Available Formats

IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 18, NO.

2, SECOND QUARTER 2016

A Software Engineering Perspective on SDN

AbstractSoftware-defined networking (SDN) has received a

HE INTERNET architecture has become complex and

Manuscript received December 23, 2014; revised September 7, 2015 and

the Open Network Foundation (ONF), Internet Research Task

respectively. Section 7 presents research challenges and future

Fig. 1. Northbound and Southbound interfaces in an SDN architecture.

B. The Northbound and Southbound Interfaces in SDN

LOPES et al.: SOFTWARE ENGINEERING PERSPECTIVE

are verified and compared to related fields in the flow table

D. The OpenFlow Protocol

The benefits of SDN would not be clear if this paradigm

links, offering alternative routes. According to [12], dedicated

Fig. 3. Frenetic declaration to filter packets.

However, such implementation involves a variety of techniques

III. P ROGRAMMING PARADIGMS , L ANGUAGES

A. Programming Paradigms in SDN

LOPES et al.: SOFTWARE ENGINEERING PERSPECTIVE

an OpenFlow-based mode and showed that it has a precise

to express applications parts as behaviors that react to external

B. SDN Languages Specification

Software can be created using a Domain-Specific Language

compatibility of policies in different scenarios. Therefore, the

Fig. 5. Key concepts and technologies related to Modelling Languages.

more general approach. That is, in MDD, a DSML is able to

Since the first OpenFlow specification was released in 2008,

LOPES et al.: SOFTWARE ENGINEERING PERSPECTIVE

Fig. 6. The SDN programming languages timeline.

and (ii) the maturity of SDN open avenues to the development

A. FML Flow Management Language

1) Core language based on FRP. Using this approach, users

able to reason about the interactions between those constructs

LOPES et al.: SOFTWARE ENGINEERING PERSPECTIVE

runs on the switches and another that runs on the controller.

First, the SDN programming languages analyzed in this

controller before the SDN programming language that will be

LOPES et al.: SOFTWARE ENGINEERING PERSPECTIVE

B. Why There Are Different Trends of the SDN Programming

C. What is the Best Paradigm for an SDN Programming

In Table II, specifically, we point out a not exhaustive list of

that may be used by developers to write them, as shown in

This is because end-user software can communicate with the

LOPES et al.: SOFTWARE ENGINEERING PERSPECTIVE

VII. R ESEARCH C HALLENGES AND F UTURE D IRECTIONS

A. Open Research Issues

What approaches ensure the correctness for SDN application

with the OpenFlow protocol and adding a layer to specify

LOPES et al.: SOFTWARE ENGINEERING PERSPECTIVE

deployed on data plane without the dependency of a specific

correct applications with efficiency and efficacy is still a work

[21] R. Moreno-Vozmediano, R. S. Montero, and I. M. Llorente, IaaS cloud

LOPES et al.: SOFTWARE ENGINEERING PERSPECTIVE

[75] K. Barrett, S. Davy, J. Strassner, B. Jennings, S. van der Meer, and

Felipe A. Lopes, received the bachelors degree in

Stenio Fernandes (M97SM13) is a Professor

You might also like