a software engineering perspective on sdn programmability

IEEE COMMUNICATIONS SURVEYS & TUTORIALS 2015

A Software Engineering Perspective on SDN ProgrammabilityFelipe A. Lopes, Marcelo Santos, Robson Fidalgo, Stenio FernandesCenter 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.

Agenda






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.

Agenda






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…


ArchitectureSDN 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 thenetwork component responsiblefor network management.


Architecture: The Northbound and Southbound interfacesSouthbound 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 ControllersThe SDN controllers are strategic control elements that communicate with the underlying switches (via SI) and with applications on the top (via NI).


The OpenFlow ProtocolThis 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 CasesRouting: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 BalancingSDN 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 CasesNetwork 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 CasesSecurity 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.

Agenda






Programming Paradigms, Languages Specification, and Software Engineering in SDNProgramming Paradigms in SDNThe 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, Languages Specification, and Software Engineering in SDNProgramming Paradigms in SDNAnother 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).

Programming Paradigms, Languages Specification, and Software Engineering in SDNSDN Languages SpecificationThe 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].

Programming Paradigms, Languages Specification, and Software Engineering in SDNSDN Languages SpecificationShin 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.

Programming Paradigms, Languages Specification, and Software Engineering in SDNSDN Languages SpecificationAnother 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.

Programming Paradigms, Languages Specification, and Software Engineering in SDNSoftware Engineering in Network ProgrammabilitySoftware 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.

Programming Paradigms, Languages Specification, and Software Engineering in SDNSoftware Engineering in Network ProgrammabilityQuestion:How (and what) Software Engineering techniques can be used to improve productivity and quality of software programming for SDN?

Programming Paradigms, Languages Specification, and Software Engineering in SDNSoftware Engineering in Network ProgrammabilityModel-Driven Engineering (MDE) can be used to hide implementation details [20].

Overview of MDE and underlying concepts.

Agenda






State-of-the-art in Programming Languagesfor SDNSince 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.

State-of-the-art in Programming Languagesfor SDN

The northbound and policy layer where the SDN programming languagesfit into the SDN architecture.


Timeline of releases of SDN programming languages.

Skip languages’definition

State-of-the-art in Programming Languagesfor SDNFlow-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.

State-of-the-art in Programming Languagesfor SDNNettleNettle [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.

State-of-the-art in Programming Languagesfor SDNProceraProcera [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.

State-of-the-art in Programming Languagesfor SDNProceraProcera 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.

State-of-the-art in Programming Languagesfor SDNFreneticFrenetic 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.

State-of-the-art in Programming Languagesfor SDNFreneticFrenetic [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.

State-of-the-art in Programming Languagesfor SDNFlogIt 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.

State-of-the-art in Programming Languagesfor SDNFatTireFatTire’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.

State-of-the-art in Programming Languagesfor SDNPyreticIt 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.

State-of-the-art in Programming Languagesfor SDNNetCoreIt 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.

State-of-the-art in Programming Languagesfor SDNNlogPart 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.

State-of-the-art in Programming Languagesfor SDNFlowlogFlowlog [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.

State-of-the-art in Programming Languagesfor SDNMerlinMerlin 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.

State-of-the-art in Programming Languagesfor SDNKineticIt 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.


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.


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

Agenda






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

Lessons Learned from the SDN Programming LanguagesAfter 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?

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

Lessons Learned from the SDN Programming LanguagesWhat SDN programming language to use? When? How?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.

Lessons Learned from the SDN Programming LanguagesWhat SDN programming language to use? When? How?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.

Lessons Learned from the SDN Programming LanguagesWhat SDN programming language to use? When? How?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.

Lessons Learned from the SDN Programming LanguagesWhat SDN programming language to use? When? How?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.

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

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

Lessons Learned from the SDN Programming LanguagesWhat is the best paradigm for an SDN programming language? What are their pros and cons?

Paradigm: Functional Reactive ProgrammingPros ConsEfficiency (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 ConsHigh 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: ImperativePros ConsFlexibility, 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: DeclarativePros ConsHigh 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 ProgrammingPros ConsThe 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.

Agenda






Analysis of Use Cases and Applications forSDN Programming LanguagesProspective 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.

Analysis of Use Cases and Applications forSDN Programming Languages

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 CasesRouting

Cloud Orchestration

Load Balancing

Network Monitoring

Network Management

Application-Based Network

Security and Dependability

Correctness

SDN Applications

SDN Programming Languages

Traffic Shapping

Cloud Orchestrator

Load Balancing

Network Monitor

Network Measurement

Policy Specification

NAT Administration

Quality of Service

Fault Tolerance

Deep Packet Inspection

Security Rules

Access Control

Admission Control

FML [61] ● ◐◐ ● ● ● ● ● ● ○ ○ ● ● ● ◐

Nettle [62] ● ◐◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ○

Procera [52] ● ◐◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ○

Flog [65] ● ◐◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ◐



Use CasesRouting

Cloud Orchestration

Load Balancing

Network Monitoring

Network Management



Correctness

SDN Applications


Traffic Shapping

Cloud Orchestrator

Load Balancing

Network Monitor

Network Measurement


NAT Administration

Quality of Service

Fault Tolerance


Security Rules

Access Control

Admission ControlFatTire [40] ● ◐ ● ● ● ● ◐ ● ● ◐ ● ● ◐ ●

Frenetic [10]/Pyretic [64] ● ◐ ● ● ● ● ● ● ○ ● ● ● ● ◐

NetCore [63] ● ◐ ● ● ● ● ● ● ○ ● ● ● ● ◐

Nlog [66] ● ◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ◐



Use CasesRouting

Cloud Orchestration

Load Balancing

Network Monitoring

Network Management



Correctness

SDN Applications


Traffic Shapping

Cloud Orchestrator

Load Balancing

Network Monitor

Network Measurement


NAT Administration

Quality of Service

Fault Tolerance


Security Rules

Access Control

Admission ControlFlowlog [67] ● ◐ ● ● ● ● ◐ ● ○ ◐ ● ● ● ●

Merlin [34] ● ◐ ● ◐ ● ● ◐ ● ○ ● ● ● ● ●

Kinetic [35] ● ◐ ● ◐ ● ● ◐ ● ○ ● ● ● ● ●

Agenda






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 IssuesWe 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?


Open Research IssuesWhat 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.


Open Research IssuesWhat 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.


Open Research IssuesHow 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.


Open Research IssuesHow 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.


Open Research IssuesHow 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).


Open Research IssuesHow 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.


Open Research IssuesHow 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.


Open Research IssuesBe 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.


Open Research IssuesBe 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.


Open Research IssuesHow 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 ProgrammabilityThough 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 ProgrammabilityWe 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.

Agenda






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

Technology