SDN
CONTROL
PLANE
NORTHBOUND INTERFACE
The northbound interface
enables applications to access
control plane functions and
services without needing to
know the details of the
underlying network switches.
The Open Networking
Foundation formed the
Northbound Interface Working
Group (NBI-WG) in 2013.
Its objective is of defining and
standardizing a number of
broadly useful northbound
APIs.
The Figure shows the concept
of multiple API latitudes from
the NBI-WG charter.
NORTHBOUND INTERFACE
The figure shows a simplified
example of an architecture with
multiple levels of northbound
APIs.
The levels of northbound API’s
are:
1. Base controller function
APIs: These APIs expose the
basic functions of the
controller and are used by
developers to create network
services.
2. Network service APIs:
These APIs expose network
services to the north.
3. Northbound interface
application APIs: These
APIs expose application-
related services that are built
on top of network services.
ROUTING
In SDN, the routing function comprises a protocol for collecting information about the
topology and traffic conditions of the network, and an algorithm for designing routes
through the network.
Two categories of routing protocols:
Interior Router Protocols (IRPs) that operate within an autonomous system.
Exterior router protocols (ERPs) that operate between autonomous system.
Interior Router Protocols (IRPs):
An IRP is concerned with discovering the topology of routers within an AS and
then determining the best route to each destination based on different metrics.
Two widely used IRPs are Open Shortest Path First (OSPF) Protocol and
Enhanced Interior Gateway Routing Protocol (EIGRP).
Exterior router protocols (ERPs):
The primary concern with an ERP is to determine reachability of networks and
end systems outside of the AS.
Therefore, the ERP is typically executed only in edge nodes that connect one AS
to another. Border Gateway Protocol (BGP) is commonly used for the ERP.
ROUTING
Each router is responsible for building up an image of the topology of the
network.
For interior routing, each router as well must collect information about
connectivity and delays and then calculate the preferred route for each IP
destination address.
The controller can develop a consistent view of the network state for calculating
shortest paths, and can implement application-aware routing policies.
The data plane switches are relieved of the processing and storage burden
associated with routing, leading to improved performance.
The centralized routing application performs two distinct functions:
1. Link discovery
2. Topology manager
LINK DISCOVERY
For link discovery, the routing function needs to be aware of links between
data plane switches.
For internetwork, the links between routers are networks, whereas for Layer 2
switches, such as Ethernet switches, the links are direct physical links.
In addition, link discovery must be performed between a router and a host
system and between a router in the domain of this controller and a router in a
neighboring domain.
Discovery is triggered by unknown traffic entering the controller’s network
domain either from an attached host or from a neighboring router.
TOPOLOGY MANAGER
The topology manager maintains the topology information for the network
and calculates routes in the network.
Route calculation involves determining the shortest path between two data
plane nodes or between a data plane node and a host.
ITU-T MODEL
As shown in Figure, the Y.3300
model consists of three layers:
Application, Control, and
Resource.
The application layer is where
SDN applications specify network
services or business applications
by defining a service-aware
behavior of network resources.
The control layer provides a
means to dynamically control the
behavior of network resources, as
instructed by the application layer.
The resource layer consists of an
interconnected set of data plane
forwarding elements (switches).
ITU-T MODEL
Application Layer:
The applications interact with the
SDN control layer via APIs that
form an application-control
interface.
The applications make use of an
abstracted view of the network
resources provided by the SDN
control layer by means of
information and data models
exposed via the APIs.
ITU-T MODEL
Control Layer:
The control layer can be viewed as
having the following sublayers:
Application support: Provides an API
for SDN applications to access network
information and program application
specific network behavior.
Orchestration: Provides the automated
control and management of network
resources and coordination of requests
from the application layer for network
resources.
Abstraction: Interacts with network
resources, and provides an abstraction
of the network resources, including
network capabilities and characteristics.
ITU-T MODEL
Resource Layer:
Collectively, the switches perform the
transport and processing of data
packets according to decisions
made by the SDN control layer.
However, the SDN control layer, on
its own behalf, may execute control
of the resource layer for the sake of
performance.
The resource layer can be viewed as
having the following sublayers:
1. Control support: Supports
programmability of resource layer
functions via the resource-control
interface.
2. Data transport and processing:
Provides data forwarding and data
routing functions.
OPENDAYLIGHT
The OpenDaylight Project is an open source project hosted by the Linux Foundation
and includes the involvement of virtually every major networking organization,
including users of SDN technology and vendors of SDN products.
OpenDaylight Architecture:
As shown in figure, the architecture provides a top-level view of the OpenDaylight
architecture. It consists of five logical layers, as further described in the list that
follows.
OPENDAYLIGHT ARCHITECTURE
Network applications, orchestration, and services:
Consists of business and network logic applications that control and monitor
network behavior.
APIs:
A set of common interfaces to OpenDaylight controller functions.
OpenDaylight supports the Open Service Gateway Initiative (OSGi) framework
and bidirectional REST for the northbound API.
The OSGi framework is used for applications that will run in the same address
space as the controller, while the REST (web-based) API is used for
applications that do not run in the same address space as the controller.
Controller functions and services:
SDN control plane functions and services.
Service abstraction layer (SAL):
Provides a uniform view of data plane resources, so that control plane functions
can be implemented independent of the specific southbound interface and
protocol.
Southbound interfaces and protocols:
Supports OpenFlow, other standard southbound protocols, and vendor-specific
interfaces.
SERVICE APSTRACTION LAYER
The Figure illustrates the
operation of the SAL.
The OSGi framework provides for
dynamically linking plug-ins for the
available southbound protocols.
The capabilities of these protocols
are abstracted to a collection of
features that can be invoked by
control plane services via a
services manager in the SAL.
The services manager maintains a
registry that maps service
requests to feature requests.
Based on the service request, the
SAL maps to the appropriate plug-
in and thus uses the most
appropriate southbound protocol
to interact with a given network
device.
OPENDAYLIGHT HELIUM
OPENDAYLIGHT HELIUM
The OpenDaylight Architecture as shown in figure which has a controller
platform consists of a growing collection of dynamically pluggable modules,
each of which performs one or more SDN related functions and services.
Five modules are considered base network service functions, likely to be
included in any OpenDaylight implementation.
Topology manager: A service for learning the network layout by subscribing
to events of node addition and removal and their interconnection.
Statistics manager: Collects switch-related statistics, including flow statistics,
node connector, and queue occupancy.
Switch manager: Holds the details of the data plane devices.
Forwarding rules manager: Installs routes and tracks next hop information.
Host tracker: Tracks and maintains information about connected hosts.
REST
REpresentational State Transfer (REST) is an architectural style used to
define APIs. It has become a standard way of constructing northbound APIs
for SDN controllers.
A REST API, or an API that is RESTful is not a protocol, language, or
established standard. It is essentially six constraints that an API must follow to
be RESTful.
The objective of these constraints is to maximize the scalability and
independence/interoperability of software interactions, and to provide for a
simple means of constructing APIs.
REST CONSTRAINTS
REST assumes that the concepts of web-based access are used for
interaction between the application and the service that are on either side of
the API.
REST does not define the specifics of the API but imposes constraints on the
nature of the interaction between application and service.
The six REST constraints are as follows:
1. Client-server
2. Stateless
3. Cache
4. Uniform interface
5. Layered system
6. Code on demand
CLIENT-SERVER CONSTRAINTS
This simple constraint dictates that interaction between application and server
is in the client-server request/response style.
The principle defined for this constraint is the separation of user interface
concerns from data storage concerns.
STATELESS CONSTRAINTS
The stateless constraint dictates that each request from a client to a server
must contain all the information necessary to understand the request and
cannot take advantage of any stored context on the server.
CACHE CONSTRAINTS
The cache constraint requires that the data within a response to a request be
implicitly or explicitly labeled as cacheable or non-cacheable.
UNIFORM INTERFACE
REST emphasizes a uniform interface between components, regardless of the
specific client-server application API implemented using REST.
To obtain a uniform interface, REST defines four interface constraints:
1. Identification of resources: Individual resources are identified using a
resource identifier (for example, a URI – Uniform Resource Identifier)
2. Manipulation of resources through representations: Resources are
represented in a format like JSON, XML, or HTML.
3. Self-descriptive messages: Each message has enough information to
describe how the message is to be processed.
4. Hypermedia as the engine of the application state: A client needs no
prior knowledge of how to interact with a server, because the API is not
fixed but dynamically provided by the server.
LAYERED SYSTEM CONSTRAINTS
The layered system constraint simply means that a given function is organized
in layers, with each layer only having direct interaction with the layers
immediately above and below.
CODE ON DEMAND CONSTRAINTS
REST allows client functionality to be extended by downloading and executing
code in the form of applets or scripts.
