UNIT IV SOFTWARE DEFINED NETWORKS : SDN Architecture.

Characteristics of
Software-Defined Networking. SDN- and NFV-Related Standards. SDN Data
Plane. Data Plane Functions. Data Plane Protocols. OpenFlow Logical Network
Device. Flow Table Structure. Flow Table Pipeline. The Use of Multiple Tables.
Group Table. OpenFlow Protocol. SDN Control Plane Architecture. Control Plane
Functions. Southbound Interface. Northbound Interface. Routing. ITU-T Model.
OpenDaylight. OpenDaylight Architecture. OpenDaylight Helium. SDN
Application Plane Architecture. Northbound Interface. Network Services
Abstraction Layer. Network Applications. User Interface.

SDN Architecture:

In traditional networks, the control and data plane are embedded together as a
single unit. The control plane is responsible for maintaining the routing table of
a switch which determines the best path to send the network packets and the
data plane is responsible for forwarding the packets based on the instructions
given by the control plane. Whereas in SDN, the control plane and data plane
are separate entities, where the control plane acts as a central controller for
many data planes.

There are many approaches that lead to the development of today’s Software
Defined Networks(SDN). They are:
 Forces
 4D approach
 Ethane

FORCES(Forwarding and control element separation):

 The idea of separation of data plane(forwarding element) and control

plane was first proposed by FORCES. It is said that hardware-based
forwarding entities are controlled by a software-based control plane.
FORCES can be implemented in two ways:
1. The forwarding element and control plane are located within the same
network device
2. The control element is taken off the device and placed in a separate system.

4D approach:

The 4D approach has four planes that control

 Decision
 Dissemination
 Discovery
 Data
It follows three principles:

 Network-level objectives: The objectives should be stated in terms of the

whole network instead of individual devices. So that there won’t be any need
to depend on proprietary devices.
 Network-wide view: Decisions should be made based on the understanding
of the whole network’s traffic, topology, and events. Actions should be taken
based on considering a network-wide view.
 Direct control: The control plane elements should directly be able to control
the data plane elements. It should have the ability to program the forwarding
table on individual devices.

Ethane: Ethane specifies network-level access of users which is defined by

network administrators. Ethane is the exact forerunner of Software Defined
Networks(SDN)

Principles of Ethane:
 High-level policies should inspect the network
 Routing should follow High-level policies.
 There should be a connection between packets and their origin in the
network
Characteristics of Software
Software is defined as a collection of computer programs, procedures, rules,
and data. Software Characteristics are classified into six major components:
Software engineering is the process of designing, developing, testing, and
maintaining software.
The characteristics of software include:
1. It is intangible, meaning it cannot be seen or touched.
2. It is non-perishable, meaning it does not degrade over time.
3. It is easy to replicate, meaning it can be copied and distributed easily.
4. It can be complex, meaning it can have many interrelated parts and features.
5. It can be difficult to understand and modify, especially for large and complex
systems.
6. It can be affected by changing requirements, meaning it may need to be
updated or modified as the needs of users change.
7. It can be affected by bugs and other issues, meaning it may need to be
tested and debugged to ensure it works as intended.

Defined Networking:
The physical separation of the network control plane from the forwarding
plane, and where a control plane controls several devices.

Software Defined Networking (SDN) :

SDN is a networking architecture which aims to improve overall network
performance and make networks agile and flexible by enabling a dynamic and
programmatically efficient network configuration. SDN is a technology that
separates control plane management of network devices from underlying data
plane that forwards network traffic in order to enable more automated
provisioning and policy-based management of network resources.
Basically, SDN makes network programmable by separating system that is
going to decide that where should traffic be sent i.e., control plane from
underlying system that pushes packets of data to a particular destinations i.e.,
data plane. SDN offer its users a way to managed network services with help of
software that makes networks centrally programmable, and allowing it for faster
configuration. Software Defined Networking enables enterprises and service
providers to respond quickly if business needs and requirements are changing
which ultimately improves network control.
2. Network Functions Virtualization (NFV) :
NFV is a network architecture which aims to accelerate service deployment for
network operators and reduce cost by separating functions like firewall or
encryption from dedicated hardware and moving them to virtual servers,
collapsing various functions into a physical server, which ultimately reduces
overall cost. NFV allows various network operators to implement network policy
without being taken care of where to place functions in network and how to
route traffic through these functions.
It is a way to virtualize network services, such as routers, firewalls, and load
balances, that have traditionally been run on computer hardware whose
interface is controlled by proprietor (proprietary hardware) and allows network
services to be hosted on virtual machines. Virtual machines have a hypervisor,
called a virtual machine manager, by which multiple operating systems can
share a single hardware processor. It will deliver high-performance networks
which have greater scalability, elasticity, and adaptability at low costs as
compared to those networks which are built from traditional networking
equipment. So it comes to overcome drawback of traditional, custom-designed
network equipment and reduces need for dedicated or proprietary hardware to
deploy and manage networks.
SDN DATA PLAN:
The data plane is a part of a network through which user packets are
transmitted.

It is a theoretical term used to conceptualize the flow of data packets

through a network infrastructure.

It is often included in diagrams and illustrations to give a visual

representation of user traffic.

The data plane is also known as the user plane, the forwarding plane or the
carrier plane.

Software-defined networking (SDN) is the separation of the control

functions from the forwarding functions, which enables greater
automation and programmability in the network.

It is often paired with network function virtualization (NFV), which

separates network functions from hardware in the form of virtualized
network functions (VNFs).
SDN enables cloud-like computing within a network. This enables
network engineers and administrators to respond quickly to changes
in business requirements through a centralized control console that is
abstracted from the physical hardware of the network. In other words,

SDN creates a centralized brain for the network that can

communicate and command the rest of the network. SDN is used to
create virtual overlay networks; software-defined networks that sit on
top of the physical hardware infrastructure

Architecture:
The three layers in an SDN architecture are:
 Application: the applications and services running on the
network
 Control: the SDN controller or “brains” of the network
 Infrastructure: switches and routers, and the supporting
physical hardware

To communicate between these layers, SDN uses northbound

and southbound application program interfaces (APIs) where
the northbound API communicates between the application
and the control layers and the southbound API communicates
between the infrastructure and control layers.

Northbound APIs:

Applications using an SDN rely on the controller to tell them

what the status of the network infrastructure is so that they
can know what resources are available.

Additionally, the SDN controller can automatically ensure

application traffic is routed according to policies established
by network administrators. The applications talk to the control
layer via the northbound APIs and tell the layer what resources
the applications need, and their destination.

The control layer orchestrates how the applications are given

the resources available in the network. It also uses its
intelligence to find the optimal path for the application in the
context of its latency and security needs.

Northbound APIs are often RESTful APIs. Orchestration is

automated and not manually configured.

Southbound APIs:
 The SDN controller communicates with the network
infrastructure, such as routers and switches, through
southbound APIs.

The network infrastructure is told what path the application

data must take as decided by the controller.

In real time, the controller can change how the routers and
switches are moving data.

The data no longer relies on the devices and routing tables to

determine where the data goes. Instead, the controller’s
intelligence makes informed decisions that optimize the data’s
path.

SDN Controllers
An SDN controller is the software that provides a centralized view of and control over the entire
network. Network administrators use the controller to govern how the underlying infrastructure’s
forwarding plane should handle the traffic.

The controller is also used to enforce policies that dictate network behavior. Network
administrators establish policies that are uniformly applied to multiple nodes in the network.
Network policies are rules that are applied to traffic that determines what level of access it has to
the network, how much resources it is allowed, or what priority it is assigned

. Having a centralized view of the network and the policies in place makes for simpler
management of the network that is more uniform and consistent.
The application, control, and infrastructure layers are kept separate in SDN and communicate through
APIs. Source: Open Networking Foundation

SDN Benefits
SDN offers a centralized, programmable network that can dynamically provision network resources so as
to address the changing needs of businesses. It also provides the following technical and business
benefits:

Direct programmability: SDN network policy is directly programmable because the control functions are
decoupled from forwarding functions, which enables the network to be programmatically configured by
proprietary or open source automation tools, including OpenStack, Puppet, Salt, Ansible, and Chef.

Centralized management: Network intelligence is logically centralized in SDN controller software that
maintains a global view of the network, which appears to applications and SDN network policy engines
as a single, logical switch.

Reduced capex: SDN potentially limits the need to purchase purpose-built, ASIC-based networking
hardware, and instead supports pay-as-you-grow models with its scaling capabilities. Most switches on
the market support SDN capabilities and software like OpenFlow (an SDN communications protocol).
Whether it is in a data center or other network, if the infrastructure contains switches with SDN
capabilities, they simply need to have the option activated. A massive truck roll is not needed to rip and
replace the infrastructure.

Reduced opex: The ability to automate the updates to the network’s software means there is no need to
rip and replace the whole infrastructure when business needs or network demand necessitate a change.
Additionally, policies can be uniformly spread network wide, reducing the chance for human error when
updating the network. Automation takes over the monotonous tasks from network administrators and
operators, which reduces the overall network management time.

Agility and flexibility: SDN can help organizations rapidly deploy new applications, services, and
infrastructure to quickly meet changing business goals and objectives because whenever something new
is created, a simple update deploys it network-wide.

SDN Challenges
SDN is not without its downsides. As with everything in the IT industry, there are security issues, scaling
problems, and a lack of widespread industry cooperation.

Security risks of centralized management: While this makes networking easier, it is also a security risk.
Centralized management is a single point of attack and if it goes down, the whole network is affected.

SDN controller bottleneck: When there is only a single instance of an SDN controller, it can become a
bottleneck for a network with a large amount of traffic, routers, and switches. There is simply too much
to communicate with for one instance of a controller.

No universally-accepted standard for northbound APIs: Without a universally-accepted standard for

northbound APIs, vendors and open source organizations are making dissimilar APIs for their SDN
controllers. This makes application development difficult because, in order to interoperate with different
controllers, the developers have to make multiple versions of applications.

SDN Use Cases

SDN software automation enables DevOps approaches including automated testing and deployment
changes to applications and virtualized portions of the network. Smart buildings can also take advantage
of SDN to handle the wireless network that connects all of the devices within the building.

The virtualization principles that SDN introduced to the networking world can also be used in vehicle-to-
everything (V2X) communication for autonomous driving. SDN software normally only covers a single
data center, however, it can extend over an enterprise’s entire campus. By using SDN technology, a
campus can simplify the wireless and wired network connections, whether it’s WiFi or Ethernet,
centrally manage them, and automate services.

OpenDaylight:

The typical OpenDaylight solution consists of five main components: the OpenDaylight APIs,
Authentication, Authorization and Accounting (AAA), Model-Driven Service Abstraction Layer (MD-SAL),
Services and Applications, and various southbound plug-ins.

The following diagram picture shows a simplified view of the typical OpenDaylight architecture. In this
chapter, the basic functionality of the main components will be described.
However, a detailed description of particular OpenDaylight components is out of scope of this guide.

Authentication, Authorization and Accounting (AAA)

The platform also provides a framework for Authentication, Authorization and Accounting (AAA), and
enables automatic identification and hardening of network devices and controllers.

OpenDaylight APIs

The northbound API, which is used to communicate with the OpenStack Networking service (neutron), is
primarily based on REST. The Model-Driven Service Abstraction Layer (described later) renders the REST
APIs according to the RESTCONF specification based on the YANG models defined by the applications
communicating over the northbound protocol.

Services and Applications

The business logic of the controller is defined in Services and Applications. The basic overview of
services and applications available with the Boron release can be found on the OpenDaylight Boron
release web page. A more detailed view can be obtained from the Project list. The OpenDaylight project
offers a variety of applications, but usually only a limited number of the applications is used in a
production deployment.

Model-Driven Service Abstraction Layer

The Model-Driven Service Abstraction Layer (MD-SAL) is the central component of the Red Hat
OpenDaylight platform. It is an infrastructure component that provides messaging and data storage
functionality for other OpenDaylight components based on user-defined data and interface models.

MD-SAL, in MD-SAL based applications, uses the YANG models to define all required APIs, including
inter-component APIs, plug-in APIs and northbound APIs. These YANG models are used by the
OpenDaylight YANG Tools to instantly generate Java-based APIs. These are then rendered according to
the RESTCONF specification into the REST APIs and provided to applications communication over the
northbound protocol.

Using YANG and YANG Tools to define and render the APIs greatly simplifies the development of new
applications. The code for the APIs is generated automatically which ensures that provided interfaces
are always consistent. As a result, the models are easily extendable.

Southbound Interfaces and Protocol Plug-ins

Applications typically use the services of southbound plug-ins to communicate with other devices,
virtual or physical. The basic overview of southbound plug-ins available with the Boron release can be
found on the OpenDaylight Boron release web page. The Project list shows them in more details.

Red Hat OpenDaylight components

The Red Hat OpenDaylight solution (part of the Red Hat OpenStack Platform) consists of the five main
parts, but the selection of applications and plug-ins is limited to a certain number only. The Controller
platform is based on the NetVirt application. This is the only application currently supported by Red Hat.
In the future releases, more applications will be added.

Most applications will only use a small subset of the available southbound plug-ins to control the data
plane. The NetVirt application of the Red Hat OpenDaylight solution uses OpenFlow and Open vSwitch
Database Management Protocol (OVSDB).

The overview of the Red Hat OpenDaylight architecture is shown in the following diagram.
 Opendaylight Helium
Opendaylight Helium is the second release after Hydrogen and it was
released late September 2014. Earlier, I was using Opendaylight Hydrogen
release and recently, I tried out Opendaylight Helium release. In this blog, I
have shared some of my experiences with Helium.

Following are some important additions to Helium compared to Hydrogen.

For more details, please refer Opendaylight webpage.

 Hardening of the controller, Clustering capability, Security options like AAA.

 Better integration with Openstack which has features like Group based
policy, service function chaining.
 Use of Apache karaf container format so that individual features can be
installed.
 Better Dlux gui.

Following is Helium block diagram from Opendaylight webpage.

 Opendaylight Helium can be downloaded from here. Helium-SR1 got released
recently and this has important bug fixes after Helium. The download link
also has install guide, user guide and developer guide which are pretty
useful.

L2 switch application:

I tried out the L2switch application that comes with Helium. I installed
following features in Karaf.

 odl-openflowplugin-flow-services-ui odl-l2switch-switch-ui odl-l2switch-all o

dl-openflowplugin-all – L2 switch
 odl-dlux-core – Dlux gui
 odl-restconf – For restconf access

I connected Mininet with OF1.3 and a simple topology with 1 switch and 2
hosts and I was not able to ping between the hosts. After discussing
with Opendaylight mailer, I realized I need to upgrade my Open vswitch
version. I had Openvswitch version 1.4.6 and that worked with Hydrogen. I
had to upgrade Openvswitch to 2.1.3 version and the Mininet ping worked
after that.

To access the Dlux GUI, use this

address(http://localhost:8181/dlux/index.html) when the controller is running.

REST api access:

Hydrogen had REST api through which we can access the controller data
both for configuration and monitoring. With Helium, controller data is
maintained as a Yang model which uses MD-SAL that gets exposed using
RESTCONF. I had earlier written a Python library for Opendaylight
Hydrogen to access inventory, topology, flows etc. I had to rewrite the
library to get it working for Helium since RESTCONF is used and the the
grouping of information has changed with Helium. Helium python library that
I have written can be accessed from here. To browse through complete
RESTCONF tree as well as for configuring, following
link(http://localhost:8181/apidoc/explorer/index.html) can be used while
controller is running. Another approach to try out REST apis is through
postman client which is available for Chrome browsers.

SDN Application Plane Architecture:

SDN Architecture Planes SDN Application Layer:

The SDN Application Layer
The programs in the application layer or plane is applications of SDN, which insist on business
applications or services of network and describes a service-aware performance of network
resources for manner of programmatic.

These programs connect their requirements and response of network by relating with the SDN
controller plane through the Northbound Interface (NBI).

Therefore, plane of controller can modify the network resources activities automatically.
The global abstract network view of the network resources are accessed by the programs in the
application plane, for their purposes of internal decision-making, given by the controller plane of
SDN by using models of data displayed via the Northbound Interface.

UNIT V NETWORK FUNCTIONS VIRTUALIZATION Motivation-Virtual Machines –

NFV benefits-requirements – architecture- NFV Infrastructure - Virtualized
Network Functions - NFV Management and Orchestration- NFV Use Cases- NFV
and SDN –Network virtualization – VLAN and VPN
The Network Functions Virtualization (NFV) is a network architecture or concept that
utilizes the IT technology fundamentals to virtualize entire network node functions onto
industry standard high volume servers, switches and storage, which could be located in
Data centers or centralized locations. Network Nodes are in the end user premises to
create communication services and illustrated in Figure #1.

It involves implementing network functions in a software that can run on a range of

industry standard server hardware, and that can be moved to, or instantiated in, various
locations in the network as in when required, without
the need to install new hardware equipment.
ETSI NFVI Architecture:

ETSI has created different standards, the one provided below is one of the most
important, which illustrates how the NFVI help us to decouple the hardware and
software.

NFV blocks are shown in Figure #2. It can be divided into four layers:

1. Virtualization Network Function (VNF) Layer

2. NFV Infrastructure (NFVI) Layer
3. Operation Support Subsystem (OSS) Layer
4. Management and Orchestration (MANO) Layer

1. Virtualization Network Function (VNF) Layer

It has two subsections Virtual Network Function (VNF) and Element Management System (EMS)

A Virtual Network Function (VNF) is the basic block in NFV Architecture. It virtualized network
function. e.g. when a router is virtualized, we call it Router VNF and when a base station is virtual we
call it as base station VNF, similarly, it can be DHCP server VNF and Firewall VNF. Even when one sub-
function of a network element is virtualized, it is called VNF. For example in Evolved Packet Corer
case, various sub-functions like MME, Gateways, and HSS can be separate VNFs which together
function as virtual EPC.
A VNFs are deployed on Virtual Machines (VMs). A VNF can be deployed on multiple VMs where each
VM hosts a single function of VNF. However, the whole VNF can also be deployed be on a single VM as
well.

Element Management System (EMS) is responsible for the functional management of VNF. The
management functions include Fault, Configuration, Accounting, Performance and Security
Management. An EMS may manage the VNFs through proprietary interfaces. There may be one EMS
per VNF or one EMS that can manage multiple VNFs. EMS itself can be deployed as Virtual Network
Function (VNF).

2. NFV Infrastructure (NFVI) Layer

NFV Infrastructure is the totality of hardware and software components which build up the
environment in which VNFs are deployed, managed and executed. NFV infrastructure physically can
span across several locations, the network provides connectivity between these locations to be part of
NFV infrastructure.

NFV Infrastructure includes following

 Hardware Resources
 Virtualization Layer
 Virtual Resources

From VNF point of view, the virtualization layer and hardware resources shall be a single entity
providing it the desired resource.

Hardware Resource includes computing, storage and network the provides processing, storage and
connectivity to VNFs through virtualization (hypervisor) layer. Computing and storage resources are
commonly used in a pool.The network resource comprises of switching functions e.g. router, wired or
wireless network.

Virtualization Layer also known as a hypervisor, it abstracts the hardware resources and decouples
the VNF software from the underlying hardware to ensure a hardware independent life cycle for VNFs.
It is mainly responsible for following:

 Abstracting and logically partitioning physical resources, commonly as hardware abstraction

layer
 Enabling the software to implement the VNF to use the underlying Virtualization
Infrastructure
 Providing the virtualised resources to VNF, so that latter can be executed

The virtualization layer in middle ensures VNFs are decoupled from hardware resource and therefore
software can be deployed on different physical resources.

Virtual Resources
Virtualization layer abstracts the computing, storage, and network from hardware layer make
available as Virtual Resources.

3. Operation Support Subsystem (OSS)/Business Support System (BSS) Layer

OSS/BSS refers to OSS/BSS of an operator. OSS deals with network management, fault management,
configuration management and service management. BSS deals with customer management, product
management and order management etc.

In the NFV architecture, the decoupled BSS/OSS of an operator may be integrated with the NFV
Management and Orchestration using standard interfaces.

4. Management and Orchestration (MANO) Layer

Management and Orchestration Layer is also abbreviated as MANO and it includes three components:

 Virtualized Infrastructure Manager(s)

 VNF Manager(s)
 Orchestrator

MANO interacts with both NFVI and VNF layer. MANO layer manages all the resources in the
infrastructure layer, it also creates and deletes resources and manages their allocation of the VNFs.

Virtualised Infrastructure Manager (VIM) comprises the functionalities that are used to control and
manage the interaction of a VNF with computing, storage and network resources under its authority,
as well as their virtualisation. Virtualised infrastructure Manager performs the following:

 Inventory of software, computing, storage and network resources dedicated to NFV

infrastructure
 Management of infrastructure resource and allocation e.g. increasing the VMs, increasing
energy efficiency etc.
 Allocation of VMs on hypervisors, Compute resources, storage, and relevant network
connectivity
 Root cause analysis of performance issues from the NFV infrastructure perspective
 Collection of infrastructure fault information
 Collection of information for capacity planning, monitoring, and optimization

VNF Manager is responsible for VNF life cycle management which includes installation, updates,
query, scale up/down and termination. A VNF manager may be deployed for each VNF or a single VNF
manager may be deployed to serve multiple VNFs.

Orchestrator is in charge of the orchestration and management of NFV infrastructure and software
resources and realizing network services
There is one more independent block know as Service, VNF and Infrastructure apart from above
building blocks.This includes data-sets that provide information regarding VNF deployment template,
VNF forwarding graphs, service related information and NFV infrastructure information models.

NFV Infrastructure - Virtualized Network Functions:

Virtual Network Functions (VNFs) are virtualized network services running on open
computing platforms formerly carried out by proprietary, dedicated hardware
technology.

Common VNFs include virtualized routers, firewalls, WAN optimization, and network
address translation (NAT) services. Most VNFs are run in virtual machines (VMs) on
common virtualization infrastructure software such as VMWare or KVM.

VNFs can be linked together like building blocks in a process known as service
chaining. Although the concept is not new, service chaining—and the application
provisioning process—is simplified and shortened using VNF technology.

VNFs can help increase network scalability and agility, while also enabling better use of
network infrastructure resources. Other benefits include reducing power consumption
and increasing security and available physical space, since VNFs replace physical
hardware.

This also results in reduced operational and capital expenditures.