Software Defined Networks
Interface Protocols for SDN
Layered View of
SDN Architecture
The interaction
among three layers
of SDN is done
through interfaces
which work as
communication /
programming
protocols.
SDN Interfaces
Application
Programmable Interfaces
(APIs) play a vital role
in SDN and provide
interaction among the
planes.
Southbound API
SBI provides a communication protocol between control plane and data plane.
This API is used to push configuration information and install flow entries in data
plane.
It also provides an abstraction of network device’s functionality to the control plane.
Major challenges of southbound interfaces are heterogeneity, vendor specific network
elements, and language specifications.
Southbound interface in SDN resolves these issues by providing an open and standardized
interface.
There are a number of examples for Southbound APIs but OpenFlow is considered as a
standard in SDN.
Northbound API
SDN adoption depends on its ability to support a wide range of applications.
Northbound APIs (NBIs) play an integral role for application developers and provides a
common interface between controller and management plane.
It helps to provide the information of underlying devices for application development
which makes SDN control easy and dynamic.
Unlike southbound interface, northbound interface has seen less standardization efforts
because it is a software ecosystem.
A wide range of NBIs are offered by current controllers and programming languages.
East/Westbound API
Centralized control over the network is the key feature of SDN, but only a limited number
of switches can be handled by a single controller.
Due to an exponential increase in the network devices and for large scale networks,
distributed controllers become a requirement.
In such a distribution, every controller has its own domain with underlying forwarding
devices.
Controllers need to share information of their respective domains for a consistent global
view of the entire network.
Eastbound APIs are used to import and export information among distributed controllers.
Westbound APIs enable the communication between legacy network devices (routers etc.)
with the controllers.
SDN Controllers
A controller is the fundamental component of SDN control plane.
One of the key role of a controller is to manage the traffic in underlying network
elements by using a set of instructions, referred as flows.
Controllers can be categorized with many aspects, however one of the key aspect is
architecture where controllers can be classified into either centralized or distributed.
In centralized controllers, a single entity is responsible for managing all the network devices.
Whereas, in distributed controllers a number of entities cooperate with each other to manage
the underlying elements. East/westbound interfaces are the key enabler for distributed
environments.
SDN Controllers Contd…
SOUTHBOUND INTERFACES (SBIs) IN SDN
Main objective of this interface is to push notifications given by controller, to
data plane devices, and provide information of these devices to controller.
It allows the discovery of network topology, define network flows, and
implement requests sent by management plane.
Some of commonly known southbound interfaces are OpenFlow (OF),
FORwarding & Control Element Separation (ForCES), Open virtual Switch
Database (OvSDB), Protocol Oblivious Forwarding (POF), OpFlex, OpenState,
etc.
Classification of OpenFlow dependent and
independent SBI proposals.
OpenFlow
OpenFlow Protocol
OpenFlow is a standardized and most commonly used
southbound interface.
It was designed particularly for SDN to provide
communication between controller and forwarding
elements.
Use TCP for communication (encryption is optional).
OpenFlow has evolved from version 1.0 with only 12
fixed matching fields and a single flow table, to version
1.5 with 41 matching fields and a number of new
functionalities.
OpenFlow version 1.0 had only one flow table with
three components: Header fields, counters, and
actions.
OpenFlow Architecture
OpenFlow enabled devices must have three main components; Flow Table, Secure
Channel, and OpenFlow protocol.
Devices may have one or more flow table, secure channel connects it with the
controller and a protocol provides communication with external controller.
OpenFlow pipeline has a number of flow tables along with group table and meter
table.
Tables in OpenFlow enabled switches have flow entries in the format of match,
actions, and statistics.
OpenFlow Structure
OpenFlow Messages
1. Controller-to-switch
2. Asynchronous (switch to controller)
3. Symmetric (misc)
Key controller-to-switch
messages
1. features: controller queries switch features,
switch replies
2. configure: controller queries/sets switch
configuration parameters
3. modify-state: add, delete, modify flow entries
in the OpenFlow tables
4. packet-out: controller can send this packet out
of specific switch port
Key switch-to-controller messages
1. Packet_in: transfer packet (and its control) to controller. See packet_out
message from controller
2. flow-removed: flow table entry deleted at switch
3. port status: inform controller of a change on a port
Controller
PC
Software
Layer
OpenFlow Client
Flow Table
MAC MAC IP IP TCP TCP
Action
src dst Src Dst sport dport
Hardware
* * * 5.6.7.8 * * port 1
Layer
port 1 port 2 port 3 port 4
5.6.7.8 1.2.3.4
Centralized vs Distributed Control
Both models are
possible with OpenFlow
Flow Routing vs. Aggregation
Both models are possible
with OpenFlow
Reactive vs. Proactive (pre-populated)
Both models are
possible with OpenFlow
OpenFlow 1.0
Ports and Port queues
Flow table
Packet matching
Actions and packet forwarding
Messaging between controller and switch
OpenFlow 1.1
Multiple flow tables
Pipeline processing: A switch can have multiple flow tables that are matched in a
pipeline fashion.
Groups
MPLS and VLAN tag support
Virtual ports
Controller connection failure
Pipeline Processing
Per table packet processing
OPENFLOW VERSION TIMELINE AND MAJOR
CHANGES
Toward Adaptive and Scalable OpenFlow
Focuses on:
◦ minimizing the control-to-data planes communication overhead, and
◦ controllers’ consistency traffic
The new communication channel between control and data planes adds extra delay and
increases the amount of control traffic, which can be vertical between the control and data
planes or horizontal among the distributed controllers.
This amount of traffic increases proportionally to the time-varying changes and scaling of
the network, resulting in high communication and computational load in the control plane.
OpenFlow version 1.5 switch components
OpenFlow 1.5
flow entry
OpenFlow-based controller’s response time to
the flow rules placement request.
Physically distributed but logically
centralized SDN architecture.
Forwarding and Control Element
Separation (ForCES)
ForCES standardized by IETF, is a proposal which is designed to replace OpenFlow.
It defines two entities as: Control Element (CE) and Forwarding Element (FE), that
are logically kept in same physical device without changing the architecture of traditional
networks and without involvement of an external controller.
It uses a Logical Function Block (LFB) which resides inside FE and has a specific
function to process packets and allows CE to control FE.
FEs take LFBs as a graph, and uses it to perform well-defined actions and do logical
computations on packets which are passing through them.
Each LFB can perform a single action on a packet.
ForCES Contd…
ForCES messages are the key enabler to provide the control of FEs to CEs, and just like
OpenFlow it also requires a transport protocol.
This transport protocol not only provides the communication between FE and CE but also
provides some extra services like reliability and security mechanisms.
Rather than using TCP for this purpose (as used in OpenFlow), ForCES uses Stream
Controlled Transmission Protocol (SCTP) which provides a range of reliability levels.
Another major reason for using SCTP is duplication and retransmission nature of TCP,
which in case of congestion, will make things worse. SCTP is also a good design choice for
ForCES for it resiliency to failure detection with built in recovery mechanisms.
ForCES
Architecture
OpFlex
OpFlex is based on declarative policy information model that means it centralizes only policy
management and implementation, but distributes intelligence and control.
With the aim of scalability, OpFlex tries to distribute the complexity in such a way that
forwarding devices are responsible for managing the whole network except policies.
These policies are defined at logically centralized Policy Repository (PR) which
communicates with Policy Elements (PE) using OpFlex protocol.
End Point devices are connected with Policy Elements and get registered by using End Point
Registry which is responsible for the addition/removal of End Points.
Another repository in OpFlex is Observer (OB) which is responsible for statistics faults and
events.
One major limitation of OpFlex, as compared to OpenFlow, is that it takes away the key
feature of programming the network from a centralized controller.
OpFlex
Architecture
NORTHBOUND INTERFACES (NBI) IN SDN
It acts as a bridge between control and management plane, and provides high level abstraction
for application development.
The application development in management plane is not as easy as it should be, and the main
reason for it is the lack of standardization of northbound interface.
Unlike OpenFlow, there is no single API or protocol which different developers/vendors can
use.
One reason for lack of this standardization is the variation in applications and their
requirements.
Northbound Interface Work Group (NBIWG) is an initiative of ONF, which has been
established for standardization purposes.
Programmers and most of the controllers usually use REST API as Northbound Interface.
REST API
A REST API (also known as RESTful API) is an application programming interface (API
or web API).
Introduced by Roy Fielding.
REST is an architectural style that defines a set of constraints to be used for creating web
services.
REST API is a way of accessing web services in a simple and flexible way without
having any processing.
It’s used to fetch or give some information from a web service.
All communication done via REST API uses only HTTP request.
Server is stateless.
Responses can be cached for the specified time.
Contd… Working
A request is sent from client to server in the form of a web URL as HTTP GET or
POST or PUT or DELETE request.
After that, a response comes back from the server in the form of a resource which can
be anything like HTML, XML, Image, or JSON.
Now JSON is the most popular format being used in Web Services.
In HTTP there are five methods that are
commonly used in a REST-based Architecture
i.e., POST, GET, PUT, PATCH, and DELETE.
These correspond to create, read, update, and
delete (or CRUD) operations respectively.
REST Design Principles
1. Uniform Interface: All API requests for the same resource should look the same, no
matter where the request comes from.
2. Client Server Decoupling: Client and server applications must be completely
independent of each other.
3. Statelessness: REST APIs are stateless, meaning that each request needs to include
all the information necessary for processing it.
4. Cacheability: When possible, resources should be cacheable on the client or server
side.
5. Layered system architecture: As a rule of thumb, don’t assume that the client and
server applications connect directly to each other. There may be a number of different
intermediaries in the communication loop.
Properties of NBIs
1. Portability:
provides low level abstraction and is used to resolve the compatibility issues among
different versions of OpenFlow or other southbound APIs and different hardware.
It provides the guarantee of correct packet processing on wide range of data plane
devices.
2. Programmability:
refers to the use of high level programming languages or dedicated languages for
SDN.
By using high level languages, networks can be configured for the services required,
Contd…
3. Controller based:
Due to the absence of a standardized northbound interface, many of the controllers
use ad-hoc APIs.
Whereas, some of the controllers proposed their own high level interfaces referred as
controller based APIs.
4. Intent based:
Moreover, some of the controllers also support intents where high level policies can
be declared.
References
1. Latif, Z., Sharif, K., Li, F., Karim, M. M., Biswas, S., & Wang, Y. (2020). A
comprehensive survey of interface protocols for software defined networks. Journal of
Network and Computer Applications, 156, 102563.
2. Bannour, F., Souihi, S., & Mellouk, A. (2017). Distributed SDN control: Survey,
taxonomy, and challenges. IEEE Communications Surveys & Tutorials, 20(1), 333-354.
3. Software Defined Networking by Mahesh Marina @ The University of Edinburgh.
4. Introduction to Software Defined Networking by Raj Jain @ Washington University in
Saint Louis.
5. Alsaeedi, M., Mohamad, M. M., & Al-Roubaiey, A. A. (2019). Toward adaptive and
scalable OpenFlow-SDN flow control: A survey. IEEE Access, 7, 107346-107379.
