A Software Engineering Perspective on SDN Programmability

IEEE COMMUNICATIONS SURVEYS & TUTORIALS 2015
A Software Engineering Perspective
on SDN Programmability
Felipe A. Lopes, Marcelo Santos, Robson Fidalgo, Stenio Fernandes
Center of Informatics (CIn), Federal University of Pernambuco (UFPE)

Agenda
• Abstract
• Introduction
• Software-Defined Networking (SDN)
• SDN Architecture
• Controllers
• The OpenFlow protocol
• SDN Use Cases
• Programming Paradigms, Languages Specification, and Software
Engineering in SDN
• State-of-the-art in Programming Languages for SDN
• Lessons Learned from the SDN Programming Languages
• Analysis of Use Cases and Applications for SDN Programming
Languages
• Research Challenges and Future Directions
• Conclusion

Abstract
Software-Defined Networking (SDN) has received a great deal of attention
from both academia and industry in recent years (since 2008).
Studies on SDN have brought a number of interesting technical discussions:
Network Architecture Network Performance

Abstract
Researchers, Network Operators, and Vendors are trying to establish new
standards and provide guidelines for proper implementation of SDN.
Many efforts in the southbound of the SDN architecture:
The northbound still needs improvements.
By focusing in the SDN northbound, this paper surveys the body of
knowledge and discusses the challenges for developing SDN software.
The most widely accepted SDN southbound protocol.

Abstract
We present existing solutions, 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.

Introduction
The Internet architecture has become complex and hard to manage. It is
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].

Introduction
In its essence, SDN decouples the control plane from the forwarding plane.
SDN 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.

Introduction
A number of organizations and research groups have embraced such new
paradigm and brought standardized protocols and recommended practices
into play.

Introduction
Brief history...
Programmable networks has been the subject of active research in the past
(e.g., Open Signaling [7], Active Networking [8], and Ethane [9]).
These researches failed to be fully adopted by the industry:
• Focus on data plane programmability;
• Programmability for specific network devices vendors.

Introduction
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.
OpenFlow and SDN terms cannot be used
interchangeably.

Introduction
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.
Cons:
• Low-level implementation and basic features to developers;
• Complexity in developing advanced SDN software applications;
Challenge:
• Full development and deployment of SDN software applications in staging and
production environments remains a challenge for network operators [6].

Introduction
Although some previous studies have surveyed the state-of-the-art on
SDN programmability, we take a different perspective on the topic:
• Techniques, methodologies, and challenges to develop and deploy SDN software
applications.
We provide a unique view from the perspective of the Software
Engineering discipline:
• Evolution, current maturity, and prospective research directions and challenges
to develop applications for SDN.
Besides, this paper 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.

Software-Defined Networking (SDN)
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.
More history...
The research community made several attempts to provide network
programmability, where Active Networking (AN) and Open Signaling
(Opensig) are considered the seminal approaches [7].
Questions:
1. Why previous approaches did not succeed?
2. What are the main differences between SDN and those previous approaches?

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.
More history...
The research community made several attempts to provide network
programmability, where Active Networking (AN) and Open Signaling
(Opensig) are considered the seminal approaches [7].
Questions:
1. Why previous approaches did not succeed? Focus on data plane, vendor-
specific solutions, inconsistent applications, security…
2. What are the main differences between SDN and those previous approaches?
Focus on overcoming the dependency on vendor-specific interfaces, well
defined separation between control and data plane, global network view…

Architecture
SDN decouples all the control logic from the forwarding devices, network
intelligence (e.g., decisions about routing, permissions) is moved to an
SDN controller.
The SDN controller becomes the
network component responsible
for network management.

Architecture: The Northbound and Southbound interfaces
Southbound Interface (SI) enables SDN switches to communicate with the
controllers. One can argue that the SI has converged to the OpenFlow
protocol standard [7]. There is room for discussions and improvements
[8][9].
The Northbound Interface (NI) encompasses the relationships between
controllers, network applications or services, and user applications [7]. NI
has still no widely accepted standard. Fortunately, there are already some
initiatives towards this direction (e.g., ONF, IRTF).

Architecture: SDN Controllers
The SDN controllers are strategic control elements that communicate with
the underlying switches (via SI) and with applications on the top (via NI).

The OpenFlow Protocol
This protocol defines how the exchange of information between control-
plane and data-plane must occur [10].
Currently, OpenFlow is the widely adopted protocol to perform the
communication between controllers and switches [2].

SDN Use Cases
Routing:
Several possibilities in adapting routing protocols. Implementation of
routing services for many contexts (e.g., route selection, traffic
optimization, secure routing)
Cloud Orchestration:
Unified orchestration of IT and networking resources (e.g., forwarding
devices). 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.
Load Balancing
SDN enables load balances to be part of the controller logic.
According to [12], dedicated balancer devices can be replaced by SDN
controllers and load balancers as software components.

SDN Use Cases
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 [11].
Network Management:
The logically centralized control-plane of SDN enables operators to define
policies from a single logical point in the network.
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.

SDN Use Cases
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.
SDN has potential 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.

Programming Paradigms, Languages
Specification, and Software Engineering in SDN
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 [12][6][13].
Select(packets) *
GroupBy([srcmac]) *
SplitWhen([inport]) *
Limit(1)
Frenetic declaration to filter packets.

Programming Paradigms in SDN
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 [14].
There are other paradigms in use (e.g., domain-specific languages,
imperative, logic programming).

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 [15].
On the other hand, an informal specification can be expressed through a
model such as UML or in natural language [16].

Shin et al. [17] presented a formal context to specify SDN programming
languages.
They used an SDN framework specification for SDN languages in order to
allow SDN applications development and to enable verification methods
(i.e., model checking and theorem proving).
This verifiable formal network can provide a logical framework to
unify the design, specification, verification, and implementation of
SDN applications.

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. [18].
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.

Software Engineering in Network Programmability
Software can be created using a Domain-Specific Language (DSL) and/or
a General-Purpose Language (GPL).
The DSL is tailored to a specific application domain, whereas the
latter is applicable across several domains.
DSLs have been used to create many SDN languages (e.g., Frenetic [6],
Procera [19]).
The focus is abstracting complexity for developers.

Question:
How (and what) Software Engineering techniques can be used to improve
productivity and quality of software programming for SDN?

Model-Driven Engineering (MDE) can be used to hide implementation
details [20].
Overview of MDE and underlying concepts.

State-of-the-art in Programming Languages
for SDN
Since the first OpenFlow specification was released in 2008, several
approaches emerged trying to raise the abstraction level for programming
in SDN.
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.

for SDN
The northbound and policy layer where the SDN programming languages
fit into the SDN architecture.

for SDN
Timeline of releases of SDN programming languages.
Skip languages’
definition

for SDN
Flow-based Management Language (FML)
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.
FML design was targeted as the policy language for NOX (i.e., an SDN
controller) [13].
FML assumes the possibility of distributed authorship within a single
policy domain, which can trigger policies conflicts [21]. 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.

for SDN
Nettle
Nettle [22] is a domain-specific language, embedded in Haskell¹. It allows
programming of OpenFlow networks in a declarative mode and it is also
based on FRP principles.
The noticeable difference in Nettle (as compared to NOX [13] and its FML
[21]) is the more declarative approach to event-based programming
through manipulating series of messages rather than handling individual
messages.
¹Haskell is a functional programming language for general purpose.
Site: http://www.haskell.org.

for SDN
Procera
Procera [19] 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.
Its principles are based on FRP, including a collection of domain-specific
temporal operators.

for SDN
Procera
Procera allows network operators to describe how an OpenFlow controller
should react to such events. It has four key features [19]:
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.

for SDN
Frenetic
Frenetic is a high-level language for programming distributed collections of
network switches [6].
It is a declarative query language in which 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.

for SDN
Frenetic
Frenetic [6] 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 high-level network
management goals, thus hiding low-level details relative to rules and
network events.

for SDN
Flog
It combines the main ideas of FML [21] and Frenetic [6].
Flog [23] 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.

for SDN
FatTire
FatTire’s 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 [12].
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.

for SDN
Pyretic
It was created to provide abstractions involving the building of SDN
applications with independent modules that jointly manage network traffic
[24].
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.

for SDN
NetCore
It is defined as “a high-level declarative language for expressing packet-
forwarding policies” on SDNs [25]. NetCore aims at enabling programmers
to construct and reason about rich policies in a natural way.
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.
It is also based on Frenetic [6]. 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. Furthermore, NetCore adds a
query language, which can be used to analyze traffic history.

for SDN
Nlog
Part of the Network Virtualization Platform (NVP), Nlog [25] is a declarative
language to compute forwarding state, separating the logic specification
from the controller that implements such logic.

for SDN
Flowlog
Flowlog [26] 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.

for SDN
Merlin
Merlin is declarative language created to address problems related to
bandwidth and packet-processing functions. According to [27], it has high-
level components for:
i) classifying packets;
ii) controlling forwarding packets;
iii) specifying packet-processing functions;
iv) defining bandwidth properties.
Merlin goes beyond the features of existing languages like Frenetic [6] and
Pyretic [24].
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.

for SDN
Kinetic
It is a DSL that provides abstractions for automating changes in network
policy in response to dynamic network conditions [28].
In addition, it makes possible to verify if such changes will satisfy network
operator’s requirements and how it should react to changing network
conditions. Such a verification makes Kinetic different from several
previous languages.

for SDN
Paradigm Objective Year Limitations
FML [61] DSL,
Declarative,
Logic
Programming
Replace the various different
configuration mechanisms and
offer a higher level abstraction
to express network behavior.
2009 Does not allow arithmetic
constraints;
Static policies;
Does not address conflicting rules;
Does not allow explicit negation in
rule bodies.
Nettle [62] DSL,
Declarative,
FRP.
Allow programming OpenFlow
networks in a declarative style.
2011 Does not address conflicting rules.
Procera [52] DSL,
Declarative,
FRP.
Express reactive dynamic
policies in a declarative way.
2012 Does not directly support issuing
events or external queries [67].
Flog [65] DSL,
Declarative,
Logic
Programming.
Provide an event-driven and
forward-chaining language to
each time a network event
occurs the logic program
executes.
2012 Does not allow explicit negation in
rule bodies.
NetCore [63] DSL,
Declarative,
FRP.
Allow programmers to
describe what network behavior
they want, without how it
should be implemented.
2012 Cannot reference the state on
controller.

for SDN
Frenetic [10] DSL,
Declarative.
Raise the level of abstraction
for writing controller programs
for SDN, offering ways to query
the network state, and define
forwarding policies.
2013 Only provides consistency on a
single switch for each flow.
FatTire [40] DSL,
Declarative,
FRP.
Write programs in terms of
paths through the network and
explicit fault-tolerance
requirements.
2013 Failure-recovery and detection
mechanisms not integrated;
Does not address QoS and
performance requirements.
Pyretic [64] Imperative,
DSL.
Specify network policies at a
high level of abstraction.
2013 Only provides consistency on a
single switch for each flow.
Nlog [66] DSL,
Declarative,
Logic
Programming.
Compute the network
forwarding state and separate
the logic specification from the
controller that executes such
logic.
2013 Does not offer a way to verify the
correctness of SDN applications;
Does not allow explicit negation
in rule bodies.
Flowlog [67] DSL,
Declarative,
Logic
Programming.
Abstract the data-plane and
control-plane behaviors,
allowing reason about the
semantics of SDN applications
and its code.
2014 Does not have abstractions for
queries.
Merlin [34] Declarative. Express high-level policies
that provision network
resources.
2014 Does not grant consistency
between policies.
Kinetic [35] DSL. Provide abstractions for
automating changes in network
policies.
2015 Does not provide consistent
updates by itself.
Paradigm Objective Year Limitations

Lessons Learned from the SDN Programming
Languages
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.

Languages
After analyzing such SDN programming languages, we answer the
following questions:
A. What SDN programming language to use? When? How?
B. Why there are different trends of the SDN programming languages design?
C. What is the best paradigm for an SDN programming language? What are
their pros and cons?

Languages
What SDN programming language to use? When? How?
Obviously, 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, it
is important to observe some key characteristics for a proper a choice.

Languages
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.

Languages
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.

Languages
Third, SDN programming languages have the SDN controller as the
underlying element in the SDN architecture. 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.

Languages
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.

Languages
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.
Moreover, the gap between programming paradigms has been overcome
by multi-paradigm programming languages. Multi-paradigm approaches
generally involve the DSL paradigm (graphical or textual) in their design.

Languages
What is the best paradigm for an SDN programming language? What
are their pros and cons?
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;
ii) involve several events and rules, which its applications need to handle.
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.

Languages
What is the best paradigm for an SDN programming language? What
are their pros and cons?
Paradigm: Functional Reactive Programming
Pros Cons
Efficiency (from the perspective of
handling network events in an
application), enables modeling of
delays and state, implicit caching and
multicast.
Complexity in
creating structures,
memory/space leaks,
performance.
Paradigm: Domain-Specific Language (DSL)
Pros Cons
High abstraction level, fewer lines
of code, flexible, enables the
verification and validation of
applications, higher productivity in
the specific problem domain, layering
that can lead to languages
independent from underlying
infrastructure.
Performance,
language design is
hard, useless for
applications outside
the domain.
Paradigm: Imperative
Pros Cons
Flexibility, one might have high
abstraction level, enables a developer
to define how he wants a network
application feature.
Complexity in
creating structures,
one might have low
abstraction level.
Paradigm: Declarative
Pros Cons
High abstraction level, fewer
lines of code, simplicity in focusing
on what a developer wants for a
network application feature.
Hard to express
conditions,
inflexibility.
Paradigm: Logic Programming
Pros Cons
The network architecture or
protocol (e.g., OpenFlow) can be
changed without changing
programs or their underlying code,
flexibility, and reliability.
Poor facilities
for supporting
arithmetic, types,
and network
events,
complexity in
creating
structures,
performance.

Analysis of Use Cases and Applications for
SDN Programming Languages
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.

Mapping of SDN programming languages to SDN applications and their use cases. The feasibility
ofeach 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.
Use Cases
Routing
Cloud
Orchestration
LoadBalancing
Network
Monitoring
Network
Management
Application-
BasedNetwork
Securityand
Dependability
Correctness
SDN
Applications
SDN Programming
Languages
TrafficShapping
CloudOrchestrator
LoadBalancing
NetworkMonitor
NetworkMeasurement
PolicySpecification
NATAdministration
QualityofService
FaultTolerance
DeepPacketInspection
SecurityRules
AccessControl
AdmissionControl
FML [61] ● ◐◐ ● ● ● ● ● ● ○ ○ ● ● ● ◐
Nettle [62] ● ◐◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ○
Procera [52] ● ◐◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ○
Flog [65] ● ◐◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ◐

Use Cases
Routing
Cloud
Orchestration
LoadBalancing
Network
Monitoring
Network
Management
Application-
BasedNetwork
Securityand
Dependability
Correctness
SDN
Applications
SDN Programming
Languages
TrafficShapping
CloudOrchestrator
LoadBalancing
NetworkMonitor
NetworkMeasurement
PolicySpecification
NATAdministration
QualityofService
FaultTolerance
SecurityRules
AccessControl
AdmissionControl
FatTire [40] ● ◐ ● ● ● ● ◐ ● ● ◐ ● ● ◐ ●
Frenetic [10]/Pyretic [64] ● ◐ ● ● ● ● ● ● ○ ● ● ● ● ◐
NetCore [63] ● ◐ ● ● ● ● ● ● ○ ● ● ● ● ◐
Nlog [66] ● ◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ◐

Use Cases
Routing
Cloud
Orchestration
LoadBalancing
Network
Monitoring
Network
Management
Application-
BasedNetwork
Securityand
Dependability
Correctness
SDN
Applications
SDN Programming
Languages
TrafficShapping
CloudOrchestrator
LoadBalancing
NetworkMonitor
NetworkMeasurement
PolicySpecification
NATAdministration
QualityofService
FaultTolerance
SecurityRules
AccessControl
AdmissionControl
Flowlog [67] ● ◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ●
Merlin [34] ● ◐ ● ◐ ● ● ◐ ● ○ ● ● ● ● ●
Kinetic [35] ● ◐ ● ◐ ● ● ◐ ● ○ ● ● ● ● ●

Research Challenges and Future Directions
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.

Open Research Issues
We now pose a number of questions regarding the Software Engineering
discipline perspective (e.g., tools and methodologies) on SDN
programming:
A. What approaches ensure the correctness for SDN application
development?
B. How to handle network failures?
C. How to avoid conflicting rules?
D. How can one realize automated tests?
E. How to abstract the complexity in SDN development efficiently?
F. Be reactive or proactive?
G. How to improve the SDN programmability?

What approaches ensure the correctness for SDN application
development?
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. [18] try to specify and define constraints to
SDN programming languages, although there is no ultimate solution to this
issue yet.

What approaches ensure the correctness for SDN application
development?
Comparing an example of integrity issues in
programming SDN applications. 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.

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 fast-failover OpenFlow mechanisms directly due to the
increment of complexity in failure-handling control, which might make code
more complex.

How to handle network failures?
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.

How to avoid conflicting rules?
This is a challenge investigated by some research studies (e.g., PANE
[29], Pyretic [24]). Avoiding conflicts means that a policy rule X does not
invalidate a policy rule Y, and vice-versa.
Hinrichs et al. [21] proposed two conflict resolution mechanisms, which we
consider a valuable path to effective SDN programming:
i) one has its features at the level of keywords, identifying the conflicting
policies;
ii) the other mechanism is a schema that defines priority to each keyword (e.g.
the keyword deny has precedence over the keyword allow).

How can one realize automated tests?
In order to identify inconsistences or unexpected states in an SDN
application, Canini et al. [30] and Vissichio et al. [31] propose approaches
to realize tests in SDN applications.
In [30] 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).
In [31] 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.
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.

Be reactive or proactive?
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).

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.

Future Directions in SDN Programmability
We suggest some directions to develop SDN applications, from the
perspective of the Software Engineering discipline:
A. Standardize processes and development tools.
B. Design Patterns for SDN applications.
C. Test-Driven Development for SDN.
D. Increase the level of abstraction in SDN applications development.
E. Match applications development for the control-plane with algorithms in the
data-plane.

Conclusion
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. We conclude this by presenting
the following points:
• The specifications and paradigms used to build the SDN languages
avoid the low-level characteristics of OpenFlow, and also avoid the
complexities related to SDN features (e.g. policy conflicts, countless
rules, and the like).
• The programming 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 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].
• 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.

Conclusion
• 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 correct applications with
efficiency and efficacy is still a work in progress.

Conclusion
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.

References
[1] J. S. Turner and D. E. Taylor, "Diversifying the Internet," IEEE Global Telecommunications Conference,
GLOBECOM '05., pp. 760-765, 2 December 2005.
[2] N. McKeown, T. Anderson, H. Balakishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker and J. Turner,
"OpenFlow: enabling innovation in campus networks," ACM SIGCOMM Computer Communication Review, pp.
69-74, Apr 2008.
[3] A. T. Campbell, I. Katzela, K. Miki and J. Vicente, "Open signaling for atm, internet and mobile networks
(opensig’98)," ACM SIGCOMM Computer Communication Review, pp. 97-108, 1999.
[4] D. L. Tennenhouse, J. M. Smith, W. D. Sincoskie, D. J. Wetherall and G. J. Minden, "A survey of active
network research," IEEE Communications Magazine, pp. 80-86, 1997.
[5] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown and S. Shenker, "Ethane: Taking control of the
enterprise," ACM SIGCOMM Computer Communication Review, 2007.
[6] N. Foster, R. Harrison, M. F. J., C. Monsanto, J. Rexford, A. Story and D. Walker, "Frenetic: A Network
Programming Language," ICFP, September 2011.
[7] D. Kreutz, F. M. V. Ramos, P. Verissimo, C. E. Rothenberg, S. Azodolmolky and S. Uhlig, "Software-Defined
Networking: A Comprehensive Survey," Proceedings of the IEEE, vol. 103, no. 1, pp. 14-76, 2015.
[8] A. Doria, J. Hadi Salim, R. Haas, H. Khosravi, W. Wang, L. Dong, R. Gopal and J. Halpern, "Forwarding and
Control Element Separation," RFC 5810 (Proposed Standard), March 2010.
[9] Cisco, OpFlex: An Open Source Approach, 2014.
[10] Open Networking Foundation, "OpenFlow Switch Specification 1.4.0," 14 Oct 2013. [Online]. Available:
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-
specifications/openflow/openflow-spec-v1.4.0.pdf. [Accessed 20 Apr 2014].
[11] M. Jarschel, T. Zinner, T. Hossfeld, P. Tran-Gia and W. Kellerer, "Interfaces, attributes, and use cases: A
compass for SDN," IEEE Communications Magazine, vol. 52, no. 6, pp. 210-217, 2014.
[12] M. Reitblatt, M. Canini, A. Guha and N. Foster, "FatTire: Declarative Fault Tolerance for Software-Defined
Networks," HotSDN, 2013.
[13] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown and S. Shenker, "NOX: Towards an
Operating System for Networks," ACM SIGCOMM CCR 38, 2008.

References
[14] H. Nilsson, A. Courtney and J. Peterson, "Functional Reactive Programming, Continued," ACM Press, pp.
51-64, Oct 2002.
[15] D. M. Jones, "Forms of language specification Examples from commonly used computer languages,"
ISO/IEC JTC1/SC22/OWG/N0121, February 2008.
[16] M. Satpathy, R. Harrison, C. Snook and M. Butler, "A Comparative Study of Formal and Informal
Specifications through an Industrial Case Study," Proc IEEE/IFIP Workshop on Formal Specification of
Computer Based Systems, 2001.
[17] M. K. Shin, K. H. Nam and et al., "Formal specification framework for software-defined networks (SDN),"
IETF draft-shin-sdn-formal-specification-03, 2013.
[18] A. Guha, M. Reitblatt and N. Foster, "Formal Foundations for Software Defined Networks," Open
Networking Summit (ONS) Research Track, 2013.
[19] A. Voellmy, H. Kim and N. Feamster, "Procera: a language for high-level reactive network control," HotSDN
'12 Proceedings of the first workshop on Hot topics in software defined networks, pp. 43-48, 2012.
[20] D. C. Schmidt, "Model-Driven Engineering," IEEE Computer, 39(2) February 2006.
[21] T. L. Hinrichs, N. S. Gude, M. Casado, J. C. Mitchell and S. Shenker, "Practical Declarative Network
Management," WREN, 21 August 2009.
[22] A. Voellmy, A. Agarwal and P. Hudak, "Nettle: Functional Reactive Programming for OpenFlow Networks,"
PADL, July 2011.
[23] N. P. Katta, J. Rexford and D. Walker, "Logic Programming for Software-Defined Networks," ACM
SIGPLAN Workshop on Cross-Model Language Design and Implementation, 2012.
[24] C. Monsanto, J. Reich, N. Foster, J. Rexford and D. Walker, "Composing Software-Defined Networks,"
NSDI, 2013.
[25] T. Koponen, K. Amidon, P. Balland, M. Casado, A. Chanda, B. Fulton, I. Ganichev, J. Gross, P. Ingram, E.
Jackson, A. Lambeth, R. Lenglet, S. Li, A. Padmanabhan, J. Pettit, B. Pfaff, R. Ramanathan, S. Shenker, A.
Shieh, J. Stribling, P. Thakkar, D. Wendlandt, A. Yip and R. Zhang, "Network virtualization in multi-tenant
datacenters," 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 14), pp.
203-216, April 2014.

References
[26] T. Nelson, A. D. Ferguson, M. J. Scheer and S. Krishnamurthi, "Tierless Programming and Reasoning for
Software-Defined Networks," Proceedings of the 11th USENIX Symposium on Networked Systems Design and
Implementation, 2-4 April 2014.
[27] R. Soulé, S. Basu, P. J. Marandi, F. Pedone, R. Kleinberg, E. G. Sirer and N. Foster, "Merlin: A language
for provisioning network resources.," ACM CoNEXT, pp. 213-225, 2 December 2014.
[28] H. Kim, J. Reich, A. Gupta, M. Shabaz, N. Feamster and R. Clark, "Kinetic: Verifiable dynamic network
control," Proc. 12th USENIX NSDI, Oakland, CA, May 2015.
[29] A. D. Ferguson, A. Guha, C. Liang, R. Fonseca and S. Kishnamurthi, "Participatory networking: an API for
application control of SDNs," Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM, pp. 327-
338, 2013.
[30] M. Canini, D. Venzano, P. Perešíni, D. Kostić and J. Rexford, "A NICE way to test openflow applications,"
NSDI'12 Proceedings of the 9th USENIX conference on Networked Systems Design and Implementation, pp.
10-10, 2012.
[31] S. Vissicchio, D. Lebrun and O. Bonaventure, "Towards test-driven software defined networking,"
Proceedings of IEEE NOMS, May 2014.

A Software Engineering Perspective on SDN Programmability

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to A Software Engineering Perspective on SDN Programmability

Similar to A Software Engineering Perspective on SDN Programmability (20)

Recently uploaded

Recently uploaded (20)

A Software Engineering Perspective on SDN Programmability

Editor's Notes