[Link] TABLE OF CONTENTS PG.

NO
I UNIT
SDN: INTRODUCTION 1-34
[Link] 1
1.1.1. Where is Software Defined Networking Used? 1
1.1.2. Why Software Defined Networking is Important? 1
1.1.3. How Does Software-Defined Networking (SDN) works? 2
1.1.4. What are the Different Models of SDN? 2
1.1.5. Difference Between SDN and Traditional Networking 5
1.2. Evolving Network Requirement. 6
1.2.1. Demand Is Increasing 6
1.2.2. Supply Is Increasing 6
1.2.3. Traffic Patterns Are More Complex 7
1.2.4. Traditional Network Architectures are Inadequate 8
1.2.5. Characteristics 8
1.3. SDN Approach. 9
1.3.1. Requirements. 9
1.4. SDN Architecture 10
1.4.1. Characteristics of Software-Defined Networking 14
1.5. SDN Data Plane. 14
[Link] Data Plane 15
1.5.2. Data Plane Functions 16
1.5.3. Data Plane Protocols 17
1.6. SDN Control Plan. 17
[Link] Control Plane Architecture 17
1.6.2. Control Plane Functions 18
1.7. SDN Application Plane. 26
1.7.1. SDN Application Plane Architecture 26
1.7.2. Northbound Interface 27
1.7.3. Network Services Abstraction Layer 28
1.7.4. Network Applications 28
1.7.5. User Interface 28
II UNIT
SDN DATA PLANE AND CONTROL PLANE 35-84
2.1. SDN Data Plane functions and protocols. 35
2.1.1. Data Plane Functions 36
2.1.2. Data Plane Protocols 37
2.2. OpenFlow Protocol. 37
 2.3. Flow Table Structure. 40
2.3.1. Match Fields Component 41
2.3.2. Instructions Component 43
2.3.3. Flow Table Pipeline 44
2.4. SDN Control Plane Function 48
[Link] Control Plane Architecture 48
2.4.2. Control Plane Functions 49
2.5. Southbound Interface 51
2.6. Northbound Interface 52
[Link] in SDN controller. 56
[Link] Architecture 57
2.7.2. Key Features of RYU as an SDN Controller: 58
2.7.3. Key Components of RYU 58
2.7.4. How RYU Works in SDN 59
2.7.5. Example of a Simple RYU Controller Application: 59
2.7.6. Benefits of RYU 60
2.7.7. Use Cases of RYU 61
2.8. Open Daylight Architecture 61
2.8.1. open Daylight Architecture 61
2.8.2. open Daylight Helium 64
2.9. ONOS in SDN Controller. 69
2.9.1. What is ONOS 69
2.9.2. The ONOS platform includes 69
2.9.3. Key Features of ONOS in SDN 70
2.9.4. ONOS in SDN Networks 72
2.9.5. Key Benefits of Using ONOS in SDN 72
2.10. Distributed Controllers 73
2.10.1. Key Concepts of Distributed
73
Controllers in SDN
2.10.2. Components and Architecture 74
2.10.3. Benefits of Distributed Controllers 75
2.10.4. Challenges of Distributed Controllers 75
2.10.5. Example Architectures: 76
III UNIT
SDN APPLICATIONS 85-120
[Link] Application Plane 85
[Link] Application Plane Architecture 86
3.1.2. Northbound Interface 87
3.1.3. Network Services Abstraction Layer 87
3.1.4. Network Applications 88
3.1.5. User Interface 88
 3.2. Network Services Abstraction Layer. 88
3.2.1. Abstractions in SDN 89
3.2.2. Forwarding Abstraction 89
3.2.3. Distribution Abstraction 90
3.2.4. Specification Abstraction 90
3.2.5. Frenetic 91
3.3 Traffic Engineering. 93
3.4. Measurement and Monitoring. 97
3.4.1. Key Aspects of Measurement and Monitoring in SDN 97
3.4.2. Types of Measurements in SDN 98
3.4.3. Techniques for Measurement and Monitoring 99
3.4.4. Role of Monitoring in SDN Operations 100
3.4.5. Challenges of Measurement and Monitoring in SDN 101
3.5. Security Open Day light DDoS Application 102
3.5.1. Applications in this area have one of two goals 102
3.5.2. open Daylight DDoS Application 102
3.6. Data Center Networking. 107
3.6. 1. Big Data over SDN 109
3.6.2. Cloud Networking over SDN 110
IV UNIT
NETWORK FUNCTION VIRTUALIZATION 121-156
4.1. Network Virtualization. 121
4.1.1. Network Virtualization Architecture 122
4.1.2. Types of Network Virtualization 124
4.1.3. Benefits of Network Virtualization 125
4.1.4. Network Virtualization Example 126
4. 2. Virtual LANs 127
4.2.1. The Use of Virtual LANs 129
4.2.2. Defining VLANs 131
4.2.3. Communicating VLAN Membership 131
4.3. OpenFlow VLAN Support. 132
4.3.1. VLAN in Networking 132
4.3.2. OpenFlow and VLANs 132
[Link] Concept 134
4.4.1. Simple Example of the Use of NFV 138
[Link] Principles 139
4.4.3. Need of NFV: 141
4.4.4. Advantages: 141
4.5. NFV Benefits and Requirements. 142
4.5.1. [Link] Benefits 142
[Link] Requirements 143
 [Link] Reference Architecture. 144
[Link] Management and Orchestration 146
4.6.2Reference Points 146
4.6.3. Implementation 147
V UNIT
NFV FUNTIONALITY 157-198
5.1. NFV Infrastructure. 157
5.1.1. Container Interface 158
5.1.2. Deployment of NFVI Containers 161
5.1.3. Logical Structure of NFVI Domains 163
5.1.4. Compute Domain 163
5.1.5. Hypervisor Domain 168
5.1.6. Infrastructure Network Domain 169
5.2. Virtualized Network Functions. 172
[Link] Interfaces 173
5.2.2. VNFC to VNFC Communication 174
[Link] Scaling 175
5.3. NFV Management. 176
5.3.1. Virtualized Infrastructure Manager 176
5.3.2. Virtual Network Function Manager 177
5.4. NFV Orchestrator 178
5.4.1. Repositories 178
5.4.2. Element Management 179
5.4.3. OSS/BSS 179
5.5. NFV Use cases. 180
5.5.1. Architectural Use Cases 181
5.5.2. Service-Oriented Use Cases 183
5.6. SDN and NFV 185
5.6.1. Difference between SDN and NFV 188
 UNIT –I
SDN: INTRODUCTION

Evolving Network Requirements – the SDN Approach – SDN

architecture
– SDN Data Plane, Control plane and Application Plane

[Link]:

Software defined networking (SDN) is an approach to network

management that enables dynamic, programmatically efficient network
configuration to improve network performance and monitoring. It is a new
way of managing computer networks that makes them easier and more
flexible to control.

In traditional networks, the hardware (like routers and switches) decides

how data moves through the network, but SDN changes this by moving the
decision-making to a central software system. This is done by separating
the control plane (which decides where traffic is sent) from the data plane
(which moves packets to the selected destination). In this article, we will
discuss Software-Defined Networking in detail, including its workings,
different models, and architecture.

1.1.1. Where is Software Defined Networking Used?

• Enterprises use SDN, the most widely used method for application
deployment, to deploy applications faster while lowering overall
deployment and operating costs. SDN allows IT administrators to
manage and provision network services from a single location.
• Cloud networking software-defined uses white-box systems. Cloud
providers often use generic hardware so that the Cloud data center can
be changed and the cost of CAPEX and OPEX saved.

1.1.2. Why Software Defined Networking is Important?

• Better Network Connectivity: SDN provides very better network
connectivity for sales, services, and internal communications. SDN also
helps in faster data sharing.

1
• Better Deployment of Applications: Deployment of new applications,
services, and many business models can be speed up using Software
Defined Networking.
• Better Security: Software-defined network provides better visibility
throughout the network. Operators can create separate zones for devices
that require different levels of security. SDN networks give more
freedom to operators.
• Better Control with High Speed: Software-defined networking
provides better speed than other networking types by applying an open
standard software-based controller.

1.1.3. How Does Software-Defined Networking (SDN) Works? In

Software-Defined Networking (SDN), the software that controls the
network is separated from the hardware. SDN moves the part that decides
where to send data (control plane) to software, while the part that actually
forwards the data (data plane) stays in the hardware.
This setup allows network administrators to manage and control the entire
network using a single, unified interface. Instead of configuring each device
individually, they can program and adjust the network from one central
place. This makes managing the network much easier and more efficient.
In a network, physical or virtual devices move data from one place to
another. Sometimes, virtual switches, which can be part of either software
or hardware, take over the jobs of physical switches. These virtual switches
combine multiple functions into one smart switch. They check the data
packets and their destinations to make sure everything is correct, then move
the packets to where they need to go.

1.1.4. What are the Different Models of SDN?

There are several models, which are used in SDN:
• Open SDN
• SDN via APIs
• SDN via Hypervisor-based Overlay Network
• Hybrid SDN

Open SDN:
Open SDN is implemented using the OpenFlow switch. It is a straight
forward implementation of SDN. In Open SDN, the controller
communicates with the switches using south-bound API with the help of
OpenFlow protocol shown in figure1.1.
2
 Figure1.1. Open SDN

SDN via APIs:

In SDN via API, the functions in remote devices like switches are invoked
using conventional methods like SNMP or CLI or through newer methods
like Rest API. Here, the devices are provided with control points enabling
the controller to manipulate the remote devices using APIs.

SDN via Hypervisor-based Overlay Network:

In SDN via the hypervisor, the configuration of physical devices is unchanged.
Instead, Hypervisor based overlay networks are created over the physical network.
Only the devices at the edge of the physical network are connected to the
virtualized networks, thereby concealing the information of other devices in the
physical network shown in figure.1.2.

3
 Figure.1.2. SDN via Hypervisor

Hybrid SDN:
Hybrid Networking is a combination of Traditional Networking with
software-defined networking in one network to support different types of
functions on a network.

4
1.1.5. Difference Between SDN and Traditional Networking:
Software Defined Networking Traditional Networking

Software Defined Network is a A traditional network is the old

virtual networking approach. conventional networking approach.

Software Defined Network is Traditional Network is distributed

centralized control. control.

This network is programmable.

This network is nonprogrammable.

Software Defined Network is the A traditional network is a closed

open interface. interface.

In Software Defined Network data In a traditional network data plane

plane and control, the plane is and control plane are mounted on the
decoupled by software. same plane.

For more details you can refer to the article differences between SDN and
Traditional Networking figure.1.3.

Figure.1.3. differences between SDN and Traditional Networking

5
1.2. Evolving Network Requirement:
• A number of trends are driving network providers and users to
reevaluate traditional approaches to network architecture.
• These trends can be grouped under the categories of demand,
supply, and traffic patterns.

1.2.1. Demand Is Increasing:

• A number of trends are increasing the load on enterprise networks,
the Internet, and other internets. Of particular note are the following:
o Cloud computing: There has been a dramatic shift by
enterprises to both public and private cloud services.
o Big data: The processing of huge data sets requires massive
parallel processing on thousands of servers, all of which
require a degree of interconnection to each other. Therefore,
there is a large and constantly growing demand for network
capacity within the data canter. o Mobile traffic: Employees
are increasingly accessing enterprise network resources via
mobile personal devices, such as smartphones, tablets, and
notebooks. These devices support sophisticated apps that can
consume and generate image and video traffic, placing new
burdens on the enterprise network.
o The Internet of Things (IoT): Most “things” in the IoT
generate modest traffic, although there are exceptions, such
as surveillance video cameras. But the sheer number of such
devices for some enterprises results in a significant load on
the enterprise network.

1.2.2. Supply Is Increasing:

• As the demand on networks is rising, so is the capacity of network
technologies to absorb rising loads. In terms of transmission
technology, established that the key enterprise wired and wireless
network technologies, Ethernet and Wi-Fi respectively, are well into
the gigabits per second (Gbps) range. Similarly, 4G and 5G cellular
networks provide greater capacity for mobile devices from remote
employees who access the enterprise network via cellular networks
rather than Wi-Fi.

6
 • The increase in the capacity of the network transmission
technologies has been matched by an increase in the performance of
network devices, such as LAN switches, routers, firewalls, intrusion
detection system/intrusion prevention systems (IDS/IPS), and
network monitoring and management systems. Year by year, these
devices have larger, faster memories, enabling greater buffer
capacity and faster buffer access, as well as faster processor speeds.

1.2.3. Traffic Patterns Are More Complex:

• If it were simply a matter of supply and demand, it would appear
that today’s networks should be able to cope with today’s data
traffic.
But as traffic patterns have changed and become more complex,
traditional enterprise network architectures are increasingly ill
suited to the demand.
• Until recently, and still common today, the typical enterprise
network architecture consisted of a local or campus-wide tree
structure of Ethernet switches with routers connecting large Ethernet
LANs and connecting to the Internet and WAN facilities. This
architecture is well suited to the client/server computing model that
was at one time dominant in the enterprise environment. With this
model, interaction, and therefore traffic, was mostly between one
client and one server. In such an environment, networks could be
laid out and configured with relatively static client and server
locations and relatively predictable traffic volumes between clients
and servers.
• A number of developments have resulted in far more dynamic and
complex traffic patterns within the enterprise data center, local and
regional enterprise networks, and carrier networks.
• These include the following:
o Client/server applications typically access multiple
databases and servers that must communicate with each
other, generating
“horizontal” traffic between servers as well as “vertical”
traffic between servers and clients. o Network convergence of
voice, data, and video traffic creates unpredictable traffic
patterns, often of large multimedia data transfers.
o Unified communications (UC) strategies involve heavy use
of applications that trigger access to multiple servers.
7
 o The heavy use of mobile devices, including personal bring
your own device (BYOD) policies, results in user access to
corporate content and applications from any device
anywhere any time.
o The widespread use of public clouds has shifted a significant
amount of what previously had been local traffic onto WANs
for many enterprises, resulting in increased and often very
unpredictable loads on enterprise routers.
o The now-common practice of application and database
server virtualization has significantly increased the number
of hosts requiring high-volume network access and results in
every changing physical location of server resources.
1.2.4. Traditional Network Architectures are Inadequate:
• Even with the greater capacity of transmission schemes and the
greater performance of network devices, traditional network
architectures are increasingly inadequate in the face of the growing
complexity, variability, and high volume of the imposed load. In
addition, as quality of service (QoS) and quality of experience
(QoE) requirements imposed on the network are expanded as a
result of the variety of applications, the traffic load must be handled
in an increasingly sophisticated and agile fashion.
• The traditional internetworking approach is based on the TCP/IP
protocol architecture. Three noteworthy characteristics of this
approach are as follows:
o Two-level end system addressing o The
protocol architecture built around the TCP
and IP protocols, consisting of five layers:
physical, data link, network/Internet
(usually IP), transport (usually TCP or
UDP), and application.
o Routing based on destination o
Distributed, autonomous control
1.2.5. Characteristics:
Based on these characteristics, the Open Networking Foundation (ONF)
cites four general limitations of traditional network architectures
Static, complex architecture: To respond for demands such as differing
levels of QoS, high and fluctuating traffic volumes, and security
requirements, networking technology has grown more complex and
difficult to manage.
8
 This has resulted in a number of independently defined protocols each of
which addresses a portion of networking requirements. An example of the
difficulty this presents is when devices are added or moved. The network
management staff must use device-level management tools to make changes
to configuration parameters in multiple switches, routers, firewalls, web
authentication portals, and so on. The updates include changes to access
control lists (ACLs), virtual LAN settings, QoS settings in numerous
devices, and other protocol-related adjustments. Another example is the
adjustment of QoS parameters to meet changing user requirements and
traffic patterns. Manual procedures must be used to configure each vendor’s
equipment on a per-application and even presession basis.
Inconsistent policies: To implement a network-wide security policy, staff
may have to make configuration changes to thousands of devices and
mechanisms.
In a large network, when a new virtual machine is activated, it can take
hours or even days to reconfigure ACLs across the entire network.
Inability to scale: Demands on networks are growing rapidly, both in
volume and variety. Adding more switches and transmission capacity,
involving multiple vendor equipment, is difficult because of the complex,
static nature of the network. One strategy enterprise has used is to
oversubscribe network links based on predicted traffic patterns. But with
the increased use of virtualization and the increasing variety of multimedia
applications, traffic patterns are unpredictable.
Vendor dependence: Given the nature of today’s traffic demands on
networks, enterprises and carriers need to deploy new capabilities and
services rapidly in response to changing business needs and user demands.
A lack of open interfaces for network functions leaves the enterprises
limited by the relatively slow product cycles of vendor equipment.

1.3. SDN Approach:

SDN Approach:
SDN and shows how it is designed to meet evolving network requirements.
1.3.1. Requirements:
Based on the narrative of we are now in a position to detail the principal
requirements for a modern networking approach.
The Open Data Center Alliance (ODCA) provides a useful, concise
list of requirements, which include the following [ODCA].
• Adaptability: Networks must adjust and respond dynamically,
based on application needs, business policy, and network conditions.
9
 • Automation: Policy changes must be automatically propagated so
that manual work and errors can be reduced.
• Maintainability. Introduction of new features and capabilities
(software upgrades, patches) must be seamless with minimal
disruption of operations.
• Model management: Network management software must allow
management of the network at a model level, rather than
implementing conceptual changes by reconfiguring individual
network elements.
• Mobility: Control functionality must accommodate mobility,
including mobile user devices and virtual servers.
• Integrated security: Network applications must integrate seamless
security as a core service instead of as an add-on solution.
• On-demand scaling: Implementations must have the ability to
scale up or scale down the network and its services to support on-
demand requests.

1.4. SDN Architecture:

An analogy can be drawn between the way in which computing evolved
from closed, vertically integrated, proprietary systems into an open
approach to computing and the evolution coming with SDN (see Figure
1.3).
• In the early decades of computing, vendors such as IBM and DEC
provided a fully integrated product, with proprietary processor
hardware, unique assembly language, unique operating system
(OS), and the bulk if not all of the application software.
• In this environment, customers, especially large customers, tended
to be locked in to one vendor, dependent primarily on the
applications offered by that vendor. Migration to another vendor’s
hardware platform resulted in major upheaval at the application
level.

10
 Figure 1.3. The Modern Approach to Computing and Networking
• Today, the computing environment is characterized by extreme
openness and great customer flexibility. The bulk of computing
hardware consists of x86 and x86-compatible processors for
standalone systems and ARM processors for embedded systems.
• This makes it easy to port operating systems implemented in C,
C++,
Java, and the like. Even proprietary hardware architectures, such as
IBM’s zEnterprise line, provide standardized compilers and
programming environments and so can easily run open sources
operating systems such as Linux.
Therefore, applications written for Linux or other open operating
systems can easily be moved from one vendor platform to another.
Even proprietary systems such as Windows and Mac OS provide
programming environments to make porting of applications an easy
matter. It also enables the development of virtual machines that can
be moved from one server to another across hardware platforms and
operating systems.
• The networking environment today faces some of the same
limitations faced in the pre-open era of computing. Here the issue is
not developing applications that can run on multiple platforms.
Rather, the difficulty is the lack of integration between applications
and network infrastructure. As demonstrated in the preceding
section, traditional network architectures are inadequate to meet the
demands of the growing volume and variety of traffic.
• The central concept behind SDN is to enable developers and
network managers to have the same type of control over network
equipment that they have had over x86 servers.
11
• The SDN approach splits the switching function between a data
plane and a control plane that are on separate devices (see Figure
1.3). The data plane is simply responsible for forwarding packets,
whereas the control plane provides the “intelligence” in designing
routes, setting priority and routing policy parameters to meet QoS
and QoE requirements and to cope with the shifting traffic patterns.
• Open interfaces are defined so that the switching hardware presents
a uniform interface regardless of the details of internal
implementation. Similarly, open interfaces are defined to enable
networking applications to communicate with the SDN controllers.

Figure 1.4 Control and Data Planes

• Software Defined Networking Figure 1.5 elaborates on the structure
showing more detail of the SDN approach.
• The data plane consists of physical switches and virtual switches. In
both cases, the switches are responsible for forwarding packets.
• The internal implementation of buffers, priority parameters, and
other data structures related to forwarding can be vendor dependent.
However, each switch must implement a model, or abstraction, of
packet forwarding that is uniform and open to the SDN controllers.
This model is defined in terms of an open application programming
interface (API) between the control plane and the data plane
(southbound API). The most prominent example of such an open
API is OpenFlow, “SDN Data
Plane and OpenFlow.”

12
 Figure 1.5 Software-Defined Architecture
• A language and message format used by an application program to
communicate with the operating system or some other control
program such as a database management system (DBMS) or
communications protocol. APIs are implemented by writing
function calls in the program, which provide the linkage to the
required subroutine for execution. An open or standardized API can
ensure the portability of the application code and the vendor
independence of the called service.

• SDN controllers can be implemented directly on a server or on a

virtual server. OpenFlow or some other open API is used to control
the switches in the data plane. In addition, controllers use
information about capacity and demand obtained from the
networking equipment through which the traffic flows. SDN
controllers also expose northbound APIs, which allow developers
and network managers to deploy a wide range of offthe-shelf and
custom-built network applications, many of which were not feasible
before the advent of SDN. As yet there is neither standardized
northbound API nor a consensus on an open northbound API. A
number of vendors offer a Representational State Transfer (REST)-
based API to provide a programmable interface to their SDN
controller.
13
 • “SDN Control Plane” Also envisioned but not yet defined are
horizontal APIs (east/westbound), which would enable
communication and cooperation among groups or federations of
controllers to synchronize state for high availability. At the
application plane are a variety of applications that interact with SDN
controllers.
• SDN applications are programs that may use an abstract view of the
network for their decision-making goals. These applications convey
their network requirements and desired network behavior to the
SDN controller via a northbound API. Examples of applications are
energy efficient networking, security monitoring, access control,
and network management.

1.4.1. Characteristics of Software-Defined Networking:

o The control plane is separated from the data plane. Data plane
devices become simple packet-forwarding devices.
o Open interfaces are defined between the devices in the control
plane (controllers) and those in the data plane.
o The network is programmable by applications running on top of
the SDN controllers. The SDN controllers present an abstract
view of network resources to the applications.

1.5. SDN Data Plane:

• Software-defined networking (SDN) with a discussion of the data
plane (Figure 1.6). The remainder of the chapter is devoted to
OpenFlow, the most widely used implementation of the SDN data
plane. OpenFlow is both a specification of the logical structure of
data plane functionality and a protocol between SDN controllers and
network devices.

14
 Figure 1.6 SDN Architecture

[Link] Data Plane:

• The SDN data plane, referred to as the resource layer in ITU-T
Y.3300 and also often referred to as the infrastructure layer, is
where network forwarding devices perform the transport and
processing of data according to decisions made by the SDN
control plane.
• The important characteristic of the network devices in an SDN
network is that these devices perform a simple forwarding
function, without embedded software to make autonomous
decisions.

15
1.5.2. Data Plane Functions:
Figure 1.7. illustrates the functions performed by the data plane network
devices (also called data plane network elements or switches). The
principal functions of the network device are the following.

Figure 1.7. Data Plane Network Device

• Control support function: Interacts with the SDN control layer

to support programmability via resource-control interfaces. The
switch communicates with the controller and the controller
manages the switch via the OpenFlow switch protocol.
• Data forwarding function: Accepts incoming data flows from
other network devices and end systems and forwards them along
the data forwarding paths that have been computed and established
according to the rules defined by the SDN applications.
• These forwarding rules used by the network device are embodied
in forwarding tables that indicate for given categories of packets
what the next hop in the route should be. In addition to simple
forwarding of a packet, the network device can alter the packet
header before forwarding, or discard the packet. As shown,
arriving packets may be placed in an input queue, awaiting
processing
• The network device in Figure 1.7 is shown with three I/O ports:
• One providing control communication with an SDN controller,
and two for the input and output of data packets.

16
 • This is a simple example. The network device may have multiple
ports to communicate with multiple SDN controllers, and may
have more than two I/O ports for packet flows into and out of the
device

1.5.3. Data Plane Protocols:

• Figure 1.5 suggests the protocols supported by the network device.
Data packet flows consist of streams of IP packets. It may be
necessary for the forwarding table to define entries based on fields
in upper-level protocol headers, such as TCP, UDP, or some other
transport or application protocol.
• The network device examines the IP header and possibly other
headers in each packet and makes a forwarding decision. The other
important flow of traffic is via the southbound application
programming interface (API), consisting of OpenFlow protocol
data units (PDUs) or some similar southbound API protocol
traffic.

1.6. SDN Control Plan:

Software-defined networking (SDN), focusing on the control plane (see
Figure 1.8).

[Link] Control Plane Architecture:

The control plane (see Figure 1.8). provides an overview of SDN control
plane architecture, discussing the functions and interface capabilities of a
typical SDN control plane implementation. Next, we summarize the ITU-T
layered SDN model, which provides additional insight into the role of the
control plane. This is followed by a description of one of the most
significant open source SDN controller efforts, known as OpenDaylight
• The SDN control layer maps application layer service requests
into specific commands and directives to data plane switches and
supplies applications with information about data plane topology
and activity. The control layer is implemented as a server or
cooperating set of servers known as SDN controllers. This section
provides an overview of control plane functionality.

17
 Figure 1.8 SDN Architecture

1.6.2. Control Plane Functions:

• Control Plane Functions Figure 1.9 illustrates the functions
performed by SDN controllers. The figure illustrates the essential
functions that any controller should provide, as suggested in a
paper by Kreutz, which include the following:

18
 Figure 1.9 SDN Control Plane Functions and Interfaces

o shortest path forwarding: Uses routing information

collected from switches to establish preferred routes.
o Notification manager: Receives, processes, and forwards to
an application event, such as alarm notifications, security
alarms, and state changes.
o Security mechanisms: Provides isolation and security
enforcement between applications and services.
o Topology manager: Builds and maintains switch
interconnection topology information.
o Statistics manager: Collects data on traffic through the
switches.
o Device manager: Configures switch parameters and
attributes and manages flow tables.
• The functionality provided by the SDN controller can be viewed
as a network operating system (NOS). As with a conventional OS,
an NOS provides essential services, common application
programming interfaces (APIs), and an abstraction of lower-layer
elements to developers.
• The functions of an SDN NOS, such as those in the preceding list,
enable developers to define network policies and manage
networks without concern for the details of the network device
characteristics, which may be heterogeneous and dynamic.
• The northbound interface, discussed subsequently, provides a
uniform means for application developers and network managers
to access SDN service and perform network management tasks.
19
 • Further, well-defined northbound interfaces enable developers to
create software that is independent not only of data plane details
but to a great extent usable with a variety of SDN controller
servers.
• A number of different initiatives, both commercial and open
source, have resulted in SDN controller implementations.
• The following list describes a few prominent ones:
• OpenDaylight: An open-source platform for network
programmability to enable SDN, written in Java. Open Daylight
was founded by Cisco and IBM, and its membership is heavily
weighted toward network vendors. Open Daylight can be
implemented as a single centralized controller, but enables
controllers to be distributed where one or multiple instances may
run on one or more clustered servers in the network.
• Open Network Operating System (ONOS): An open source
SDN NOS, initially released in 2014. It is a nonprofit effort funded
and developed by a number of carriers, such as AT&T and NTT,
and other service providers. Significantly, ONOS is supported by
the Open Networking Foundation, making it likely that ONOS
will be a major factor in SDN deployment. ONOS is designed to
be used as a distributed controller and provides abstractions for
partitioning and distributing network state onto multiple
distributed controllers.
• POX: An open source OpenFlow controller that has been
implemented by a number of SDN developers and engineers. POX
has a well written API and documentation. It also provides a web
based graphical user interface (GUI) and is written in Python,
which typically shortens its experimental and developmental
cycles compared to some other implementation languages, such as
C++.
• Beacon: An open-source package developed at Stanford. Written
in Java and highly integrated into the Eclipse integrated
development environment (IDE). Beacon was the first controller
that made it possible for beginner programmers to work with and
create a working SDN environment.
• Floodlight: An open-source package developed by Big Switch
Networks.

20
Although its beginning was based on Beacon, it was built using Apache Ant,
which is a very popular software build tool that makes the development of
Floodlight easier and more flexible.
Floodlight has an active community and has a large number of features that can
be added to create a system that best meets the requirements of a specific
organization. Both a web-based and Java based GUI are available and most of its
functionality is exposed through a REST API.
• Ryu: An open-source component-based SDN framework
developed by NTT Labs. It is open sourced and fully developed in
python.
• Onix: Another distributed controller, jointly developed by
VMWare, Google, and NTT. Onix is a commercially available
SDN controller.

Southbound Interface:
The southbound interface provides the logical connection between the
SDN controller and the data plane switches (see Figure 1.10). Some
controller products and configurations support only a single southbound
protocol. A more flexible approach is the use of a southbound
abstraction layer that provides a common interface for the control plane
functions while supporting multiple southbound APIs.

Figure 1.10. SDN Controller Interfaces

• The most commonly implemented southbound API is OpenFlow,

“SDN Data Plane and OpenFlow.”
21
 Other southbound interfaces include the following:
• Open vSwitch Database Management Protocol (OVSDB):
Open vSwitch (OVS) an open-source software project which
implements virtual switching that is interoperable with almost all
popular hypervisors. OVS uses OpenFlow for message forwarding
in the control plane for both virtual and physical ports. OVSDB is
the protocol used to manage and configure OVS instances.
• Forwarding and Control Element Separation (ForCES): An
IETF effort that standardizes the interface between the control
plane and the data plane for IP routers.
• Protocol Oblivious Forwarding (POF): This is advertised as an
enhancement to OpenFlow that simplifies the logic in the data
plane to a very generic forwarding element that need not
understand the protocol data unit (PDU) format in terms of fields
at various protocol levels. Rather, matching is done by means of
(offset, length) blocks within a packet. Intelligence about packet
format resides at the control plane level.

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 northbound interface is
more typically viewed as a software API rather than a protocol.
• Unlike the southbound and eastbound/westbound interfaces,
where a number of heterogeneous interfaces have been defined,
there is no widely accepted standard for the northbound interface.
• The result has been that a number of unique APIs have been
developed for various controllers, complicating the effort to
develop SDN applications.
• To address this issue the Open Networking Foundation formed the
Northbound Interface Working Group (NBI-WG) in 2013, with
the objective of defining and standardizing a number of broadly
useful northbound APIs. As of this writing, the working group has
not issued any standards. A useful insight of the NBI-WG is that
even in an individual SDN controller instance, APIs are needed at
different
“Latitudes.” That is, some APIs may be “further north” than others,
and Figure 1.11, from the NBI-WG charter document (October 2013),
illustrates the concept of multiple API latitudes.
22
 For example, an application may need one or more APIs that directly
expose the functionality of the controller, to access to one, several, or
all of these different APIs could be a requirement for a given
application manages a network domain, and use APIs that invoke
analytic or reporting services residing on the controller.

Figure 1.11. Latitude of Northbound Interfaces

Figure 1.12. Shows a simplified example of an architecture with multiple

levels of northbound APIs, the levels of which are described in the list that
follows.

23
 Figure [Link] Controller APIs
• Base controller function APIs: These APIs expose the basic
functions of the controller and are used by developers to create
network services.
• Network service APIs: These APIs expose network services to
the north.
• Northbound interface application APIs: These APIs expose
application-related services that are built on top of network
services.
• A common architectural style used for defining northbound APIs
is Representational State Transfer (REST).

Routing:
• As with any network or internet, an SDN network requires a
routing function. In general terms, 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.
• “Requirements and Technology,” that there are two categories
of routing protocols: interior router protocols (IRPs) that operate
within an autonomous system (AS), and exterior router
protocols (ERPs) that operate between autonomous systems.

24
• 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). An ERP need not collect as much detailed traffic
information. Rather, 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.
• Traditionally, the routing function is distributed among the
routers in a network. 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.
• However, in an SDN-controlled network, it makes sense to
centralize the routing function within the SDN controller. 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: link discovery and topology manager.
• For link discovery, the routing function needs to be aware of
links between data plane switches. Note that in the case of an
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.

25
 • 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.

1.7. SDN Application Plane:

[Link] Application Plane Architecture:

• The application plane contains applications and services that define,
monitor, and control network resources and behavior. These
applications interact with the SDN control plane via application-
control interfaces, for the SDN control layer to automatically
customize the behavior and the properties of network resources. The
programming of an SDN application makes use of the abstracted
view of network resources provided by the SDN control layer by
means of information and data models exposed via the application
control interface. depicted in Figure 1.13

Figure 1.13. SDN Architecture

26
 • This section provides an overview of application plane functionality,
depicted in Figure 1.14. The elements in this figure are analysed
through a bottom-up approach, and subsequent sections provide
detail on specific application areas.

Figure 1.14 SDN Application Plane Functions and Interfaces

1.7.2. Northbound Interface:

• The “SDN Control Plane,” the northbound interface enables
applications to access control plane functions and services without
needing to know the details of the underlying network switches.
Typically, the northbound interface provides an abstract view of
network resources controlled by the software in the SDN control
plane.
• Figure 1.18 indicates that the northbound interface can be a local or
remote interface. For a local interface, the SDN applications are
running on the same server as the control plane software (controller
network operating system).
• Alternatively, the applications could be run on remote systems and
the northbound interface is a protocol or application programming
interface (API) that connects the applications to the controller
network operating system (NOS) running on central server. Both
architectures are likely to be implemented.

27
 An example of a northbound interface is the REST API for the Ryu
SDN network operating system.
1.7.3. Network Services Abstraction Layer:
• RFC 7426 defines a network services abstraction layer between the
control and application planes and describes it as a layer that
provides service abstractions that can be used by applications and
services.
Several functional concepts are suggested by the placement of this
layer in the SDN architecture.
o This layer could provide an abstract view of network
resources that hides the details of the underlying data plane
devices. o This layer could provide a generalized view of
control plane functionality, so that applications could be
written that would operate across a range of controller
network operating systems. o This functionality is similar to
that of a hypervisor or virtual machine monitor that
decouples applications from the underlying OS and
underlying hardware. o This layer could provide a network
virtualization capability that allows different views of the
underlying data plane infrastructure.

1.7.4. Network Applications:

• There are many network applications that could be implemented for
an SDN. Different published surveys of SDN have come up with
different lists and even different general categories of SDN-based
network applications. Figure 1.18 includes six categories that
encompass the majority of SDN applications

1.7.5. User Interface;

• The user interface enables a user to configure parameters in SDN
applications and to interact with applications that support user
interaction. Again, there are two possible interfaces.
• A user that is collocated with the SDN application server (which
may or may not include the control plane) can use the server’s
keyboard/display. More typically, the user would log on to the
application server over a network or communications facility.

28
 PART –A
1. What are the requirements of SDN?
There are several hardware and software prerequisites for an SDN
infrastructure, including:
o Security groups and dynamic DNS registration. You must
prepare your datacenter for Network Controller deployment,
which requires a set of virtual machines (VMs). ...
o Physical network. ...
o Physical compute hosts.
2. What is network programmability in SDN?
Network programmability is the ability to consume and build a
system around these APIs. At very high level, SDN and network
programmability have four main components: Applications:
business logic based on use cases. Northbound APIs: exposes
programmable access to network functionalities and resources.
3. How do SDNs facilitate the integration of emerging technologies to
meet evolving network requirements?
SDN opens this environment up by providing three things: first,
standard application programming interfaces (API), so that
applications can talk directly to the network; second, SDN abstracts
the network so that the application does not need to know about the
complexity of all those low-level commands; and, finally, ...
4. What played a vital role in the evolution of SDN?
The Open Networking Foundation (ONF) has played a pioneering
role in the development and advancement of SDN.
5. What are the three components of SDN?
A typical representation of SDN architecture comprises three
layers: the application layer, the control layer and the infrastructure
layer. These layers communicate using northbound and southbound
application programming interfaces (APIs).
6. What is the basic principle of SDN in a network?
Concept. SDN architectures decouple network control and
forwarding functions, enabling the network control to become
directly programmable and the underlying infrastructure to be
abstracted from applications and network services. The OpenFlow
protocol can be used in SDN technologies.

29
7. What is network slicing in SDN?
Network slicing is a virtual networking architecture type that belongs to
the software-defined networking (SDN) family and network functions
virtualization (NFV). SDN and NFV allow far better network flexibility
through the partitioning of network architectures into virtual slices.
8. Why SDN is required for network automation?
SDN separates the network's control (brains) and forwarding
(muscle) planes and provides a centralized view of the distributed
network for more efficient orchestration and automation of network
services.
9. Where is SDN network used?
What are some of the main uses for SDN? Software-defined networks are
increasingly used in large data centers. A data center is a collection of
servers and networking equipment, typically within a single building,
which stores, processes, and exchanges data.
10. How does SDN provide network security?
In traditional networking, any security that impacts traffic is overarching.
With SDN, it's granular. This means that engineers can selectively block
malicious traffic throughout your network on a granular basis. So, if any
specific segments misbehave, you can deal with them accordingly.
11. Which is the main function of SDN?
SDN allows data to move easily between distributed locations,
which are critical for cloud applications. Additionally, SDN
supports moving workloads around a network quickly.
12. What is the full form of SDN in networking?
It enables the control and management of the network using
software applications. Through Software Defined Network (SDN)
networking behavior of the entire network and its devices are
programmed in a centrally controlled manner through software
applications using open APIs.
13. What are the different models of SDN?
The main types of SDN are:
Open, or switch-based, SDN – This is considered the most
straightforward SDN type. ...
SDN via API – This type uses programming interfaces, or
southbound APIs, to monitor and control network traffic into and
out of switches and other devices.

30
14. What are the two benefits of SDN?
The benefits of a separate control plane in SDN include greater
network flexibility and scalability, as the network policy can be
changed in realtime to meet changing network conditions. It also
allows for easier network management, as the network can be
managed from a centralized location.
15. What are the three phases in the history of SDN?
The history of SDN can be divided into three phases: Active
networks. Control and data plane separation. OpenFlow API and
network operating systems.
16. What are the SDN challenges?
The list of SDN challenges consists of:
o Controller placement o Scalability
o Performance o Security
o Interoperability and Reliability
o SDN controllers must be wisely
configured and the SDN's network
topology authenticated to prevent manual
errors and increase network availability.
17. What is the role of data plane in SDN?
A SDN consists of control, data, and management planes. The
control plane performs forwarding decisions and other functions,
like quality of service (QoS). In contrast, the data plane is the
network that switches or forwards devices handling the data packets
and taking inputs from the control plane.
18. What is the function of control plane in SDN?
SDN technology enables IT administrators to configure their
networks using a software application, instead of changing the
configuration of physical equipment. SDN is made possible by
separating the control plane from the forwarding/data plane.
19. Which layer is responsible for compiling the requirements of SDN
requests?
Control Layer: Control layer is the middle layer of architecture
proposed for SDN, which is responsible for application requirement
translation. This layer is also called the brain of SDN architecture,
as it manages all connected open-flow elements for execution as per
desired policies implemented on them.

31
20. What is the application layer of the SDN?
Application Layer: The applications layer includes network
programs and applications that communicate the desired network
behavior and requirements to the underlying SDN control layer. In
traditional networks, you would instead use a dedicated firewall as
an appliance or a load balancer.
21. What is SDN in OSI model?
Software-defined networking (SDN) acts as a centralized
management unit, especially in a network with devices that operate
under the transport layer of the OSI model. However, when a
network with layer 7 middle boxes (MBs) is considered, current
SDNs exhibit limitations.
22. What is an example of SDN network?
Examples of how software-defined networking (SDN) is used in
practice are network virtualization, SD-WAN (software-defined
wide area network), switching fabrics, traffic engineering, and
access networks.
23. What is the difference between SDN and router?
o Unlike SDN, traditional networks use routers, switches and
other hardware and physical infrastructure to generate
connections and run the networks. o SDN controllers use a
northbound interface that communicates with APIs, allowing
application developers to program the network.
24. What are disadvantages of SDN?
Disadvantages of SDN o It requires a change in the entire network
infrastructure to implement SDN protocol and SDN controller.
...
o Staff needs to be trained. o A new management tool
needs to be procured and everyone should be trained to use it.
o Security is a big challenge in SDN.
25. Is SDN used in IoT?
SDN is used in IoT networks to improve network performance,
provide more direct control over routing, analyze network traffic
and manage the network effectively with the centralized controller.

32
Part -B
1. Explain the detail about the SDN Approach.
2. Explain the Evolving Network Requirement.
3. Explain the Evolving Network Requirement.
Explain the SDN Architecture and Characteristics of Software-
Defined Networking
4. Explain the detail about the SDN Approach.
5. Discuss in detail about the SDN Data Plane Architecture.
6. Explain in detail how can SDN Control Plan Architecture.
7. Explain the SDN Application Plane Architecture.
8. Explain in detail about Flow Table Structure.
9. Explain in detail about the Openflow Protocol.
10. Explain in detail about SDN Data Plane functions and
protocols with neat diagram.

33
******************

34
 UNIT II
SDN DATA PLANE AND CONTROL PLANE

Data Plane functions and protocols - Openflow Protocol - Flow Table -

Control Plane Functions - Southbound Interface, Northbound Interface –
SDN Controllers - Ryu, OpenDaylight, ONOS - Distributed Controllers
2.1. SDN Data Plane functions and protocols:
The SDN data plane, referred to as the resource layer in ITU-T
Y.3300 and also often referred to as the infrastructure layer, is where
network forwarding devices perform the transport and processing of data
according to decisions made by the SDN control plane. The important
characteristic of the network devices in an SDN network is that these
devices perform a simple forwarding function, without embedded software
to make autonomous decisions shown in Figure 2.1.

Figure 2.1 SDN Architecture

35
2.1.1. Data Plane Functions :

Figure 2.2 illustrates the functions performed by the data plane

network devices (also called data plane network elements or switches). The
principal functions of the network device are the following:

Figure 2.2 Data Plane Network Device Control support

function

• Interacts with the SDN control layer to support programmability via

resource-control interfaces. The switch communicates with the
controller and the controller manages the switch via the Openflow
switch protocol.

Data forwarding function:

• Accepts incoming data flows from other network devices and end
systems and forwards them along the data forwarding paths that
have been computed and established according to the rules defined
by the SDN applications.
• These forwarding rules used by the network device are embodied in
forwarding tables that indicate for given categories of packets what
the next hop in the route should be.
• In addition to simple forwarding of a packet, the network device can
alter the packet header before forwarding, or discard the packet.
36
 • As shown, arriving packets may be placed in an input queue, a
waiting processing by the network device, and forwarded packets
are generally placed in an output queue, awaiting transmission.
• The network device in Figure 2.2 is shown with three I/O ports: one
providing control communication with an SDN controller, and two
for the input and output of data packets. This is a simple example.
The network device may have multiple ports to communicate with
multiple SD controllers, and may have more than two I/O ports for
packet flows into and out of the device.

2.1.2. Data Plane Protocols:

• Figure 2.2 suggests the protocols supported by the network device.
Data packet flows consist of streams of IP packets. It may be
necessary for the forwarding table to define entries based on fields
in upper-level protocol headers, such as TCP, UDP, or some other
transport or application protocol. The network device examines the
IP header and possibly other headers in each packet and makes a
forwarding decision. • The other important flow of traffic is via the
southbound application programming interface (API), consisting of
OpenFlow protocol data units (PDUs) or some similar southbound
API protocol traffic.

2.2. OpenFlow Protocol:

• The OpenFlow protocol describes message exchanges that take
place between an OpenFlow controller and an OpenFlow switch.
Typically, the protocol is implemented on top of TLS, providing a
secure OpenFlow channel.
• The OpenFlow protocol enables the controller to perform add,
update, and delete actions to the flow entries in the flow tables. It
supports three types of messages (see Table 2.1):

o Controller to switch
o Asynchronous
o Event-based messages
o Flow statistics
o Encapsulated packets

37
TABLE 2.1 OpenFlow Messages

38
• Controller to switch:
o These messages are initiated by the controller and, in some
cases, require a response from the switch.
o This class of messages enables the controller to manage the
logical state of the switch, including its configuration and
details of flow and group table entries.
o Also included in this class is the Packet-out message. This
message is sent by the controller to a switch when that switch
sends a packet to the controller and the controller decides not
to drop the packet but to direct it to a switch output port.
• Asynchronous:
o These types of messages are sent without solicitation from
the controller.
o This class includes various status messages to the controller.
Also included is the Packet-in message, which may be used
by the switch to send a packet to the controller when there is
no flow table match.
• Symmetric:
o These messages are sent without solicitation from either the
controller or the switch.
o They are simple yet helpful. Hello messages are typically
sent back and forth between the controllers and switch when
the connection is first established.
o Echo request and reply messages can be used by either the
switch or controller to measure the latency or bandwidth of
a controller switch connection or just verify that the device
is up and running.
o The Experimenter message is used to stage features to be
built in to future versions of OpenFlow.
o In general terms, the OpenFlow protocol provides the SDN
controller with three types of information to be used in
managing the network:
i. Event-based messages:
o Sent by the switch to the controller when a link or port change
occurs.

39
 ii. Flow statistics:
o Generated by the switch based on traffic flow. This
information enables the controller to monitor traffic,
reconfigure the network as needed, and adjust flow
parameters to meet QoS requirements.
iii. Encapsulated packets:
o Sent by the switch to the controller either because there is an
explicit action to send this packet in a flow table entry or
because the switch needs information for establishing a new
flow.
o The OpenFlow protocol enables the controller to manage the
logical structure of a switch, without regard to the details of
how the switch implements the OpenFlow logical
architecture.
2.3. Flow Table Structure:
o The basic building block of the logical switch architecture is
the flow table. Each packet that enters a switch passes
through one of more flow tables.
o Each flow table consists of a number of rows, called entries,
consisting of seven components (see part a of Figure 2.3),
as defined in the list that follows.

Figure 2.3 OpenFlow Table Entry Formats

o Match fields: Used to select packets that match the values in the
fields.
o Priority: Relative priority of table entries. This is a 16-bit field with
corresponding to the lowest priority. In principle, there could be 216
= 64k priority levels.

40
 o Counters: Updated for matching packets. The open flow
specification defines a variety of counters. Table 2.2 lists the
counters that must be supported by an OpenFlow switch.

TABLE 2.2Required OpenFlow Counters

o Instructions: Instructions to be performed if a match occurs. o

Timeouts: Maximum amount of idle time before a flow is expired
by the switch. Each flow entry has an idle timeout and a hard timeout
associated with it. A nonzero hard timeout field causes the flow entry
to be removed after the given number of seconds, regardless of how
many packets it has matched. A nonzero idle timeout field causes
the flow entry to be removed when it has matched no packets in the
given number of seconds.
o Cookie: 64-bit opaque data value chosen by the controller. May be
used by the controller to filter flow statistics, flow modification and
flow deletion; not used when processing packets.
o Flags: Flags alter the way flow entries are managed; for example,
then flag OFPFF_SEND_FLOW_REM triggers flow removed
messages for that flow entry.
2.3.1. Match Fields Component:
The match fields component of a table entry consists of the following
required fields (see part b of Figure 2.3):
o Ingress port: The identifier of the port on this switch on which the
packet arrived. This may be a physical port or a switch-defined
virtual port. Required in ingress tables.

41
o Egress port: The identifier of the egress port from action set.
Required in egress tables.
o Ethernet source and destination addresses: Each entry can be an
exact address, a bit masked value for which only some of the address
bits are checked, or a wildcard value (match any value).
o Ethernet type field: Indicates type of the Ethernet packet payload.
o IP: Version 4 or 6. o IPv4 or IPv6 source address, and
destination address: Each entry can be an exact address, a bit
masked value, a subnet mask value, or a wildcard value.
o TCP source and destination ports: Exact match or wildcard value.
o UDP source and destination ports: Exact match or wildcard value.
The preceding match fields must be supported by any
OpenFlowcompliant switch. The following fields may be optionally
supported.
o Physical port: Used to designate underlying physical port when
packet is received on a logical port.
o Metadata: Additional information that can be passed from one table
to another during the processing of a packet. Its use is discussed
subsequently.
o VLAN ID and VLAN user priority: Fields in the IEEE 802.1Q
virtual LAN header. IPv4 or IPv6 DS and ECN: Differentiated
Services and Explicit Congestion Notification fields.
o SCTP source and destination ports: Exact match or wildcard
value for Stream Transmission Control Protocol.
o ICMP type and code fields: Exact match or wildcard value.
o ARP opcode: Exact match in Ethernet Type field.
o Source and target IPv4 address in ARP payload: Can be an exact
address, a bit masked value, a subnet mask value, or a wildcard
value.
o IPv6 flow label: Exact match or wildcard. o ICMPv6 type and
code fields: Exact match or wildcard value.
o IPv6 neighbor discovery target address: In an IPv6 Neighbor
Discovery message.
o IPv6 neighbor discovery source and target addresses: Link-layer
address options in an IPv6 Neighbor Discovery message. o MPLS
label value, traffic class, and BoS: Fields in the top label of an
MPLS label stack.
o Provider bridge traffic ISID: Service instance identifier.

42
o Tunnel ID: Metadata associated with a logical port.
o TCP flags: Flag bits in the TCP header. May be used to detect start
and end of TCP connections.
o IPv6 extension: Extension header. Thus, OpenFlow can be used
with network traffic involving a variety of protocols and network
services. Note that at the MAC/link layer, only Ethernet is
supported. Therefore, OpenFlow as currently defined cannot control
Layer 2 traffic over wireless networks.
o A flow table may include a table-miss flow entry, which wildcards
all match fields (every field is a match regardless of value) and has
the lowest priority.
o We can now offer a more precise definition of the term flow. From
the point of view of an individual switch, a flow is a sequence of
packets that matches a specific entry in a flow table. The definition
is packet oriented, in the sense that it is a function of the values of
header fields of the packets that constitute the flow, and not a
function of the path they follow through the network. A combination
of flow entries on multiple switches defines a flow that is bound to
a specific path.

2.3.2. Instructions Component:

o The instructions component of a table entry consists of a set of
instructions that are executed if the packet matches the entry. Before
describing the types of instructions, we need to define the terms
action and action set. Actions describe packet forwarding, packet
modification, and group table processing operations. The Openflow
specification includes the following actions:
o Output: Forward packet to specified port. The port could be an
output port to another switch or the port to the controller. In the latter
case, the packet is encapsulated in a message to the controller.
o Set-Queue: Sets the queue ID for a packet. When the packet is
forwarded to a port using the output action, the queue ID determines
which queue attached to this port is used for scheduling and
forwarding the packet. Forwarding behavior is dictated by the
configuration of the queue and is used to provide basic QoS support.
o Group: Process packet through specified group. o Push-Tag/Pop-
Tag: Push or pop a tag field for a VLAN or Multiprotocol Label
Switching (MPLS) packet.

43
 o Set-Field: The various Set-Field actions are identified by their field
type and modify the values of respective header fields in the packet.
o Change-TTL: The various Change-TTL actions modify the values
of the IPv4 TTL (time to live), IPv6 hop limit, or MPLS TTL in the
packet.
o Drop: There is no explicit action to represent drops. Instead, packets
whose action sets have no output action should be dropped. An
action set is a list of actions associated with a packet that are
accumulated while the packet is processed by each table and that are
executed when the packet exits the processing pipeline.
The types of instructions can be grouped into four categories:
• Direct packet through pipeline: TheGoto-Table instruction directs
the packet to a table farther along in the pipeline. The Meter
instruction directs the packet to a specified meter.
• Perform action on packet: Actions may be performed on the
packet when it is matched to a table entry. The Apply-Actions
instruction applies the specified actions immediately, without any
change to the action set associated with this packet. This instruction
may be used to modify the packet between two tables in the pipeline.
• Update action set: The Write-Actions instruction merges specified
actions into the current action set for this packet. The Clear-Actions
instruction clears all the actions in the action set.
• Update metadata: A metadata value can be associated with a
packet. It is used to carry information from one table to the next. The
Write- Metadata instruction updates an existing metadata value or
creates anew value.

2.3.3. Flow Table Pipeline:

o A switch includes one or more flow tables. If there is more than one
flow table, they are organized as a pipeline, with the tables labeled
with increasing numbers starting with zero.
o The use of multiple tables in a pipeline, rather than a single flow
table, provides the SDN controller with considerable flexibility.
The OpenFlow specification defines two stages of processing:
• Ingress processing: Ingress processing always happens, beginning
with Table 0, and uses the identity of the input port.
• Table 0 may be the only table, in which case the ingress processing
is simplified to the processing performed on that single table, and
there is no egress processing.
44
• Egress processing: Egress processing is the processing that
happens after the determination of the output port. It happens in the
context ofthe output port. This stage is optional. If it occurs, it may
involve one or more tables. The separation of the two stages is
indicated by the numerical identifier of the first egress table. All
tables with a number lower than the first egress table must be used
as ingress tables, and notable with a number higher than or equal to
the first egress table can be used as an ingress table. o Pipeline
processing always starts with ingress processing at the first flow
table; the packet must be first matched against flow entries of flow
Table 0. Other ingress flow tables may be used depending on the
outcome of the match in the first table.
• If the outcome of ingress processing is to forward the packet to an
output port, the OpenFlow switch may perform egress processing in
the context of that output port. o When a packet is presented to a
table for matching, the input consists of the packet, the identity of
the ingress port, the associated metadata value, and the associated
action set. For Table 0, the metadata value is blank and the action
set is null. At each table, processing proceeds as follows (see Figure
2.4):
1. If there is a match on one or more entries, other than the table-miss
entry, the match is defined to be with the highest-priority matching
entry. As mentioned in the preceding discussion, the priority is a
component of a table entry and is set via OpenFlow; the priority is
determined by the user or application invoking OpenFlow. The
following steps may then be performed:
a. Update any counters associated with this entry.
b. Execute any instructions associated with this entry. This may include
updating the action set, updating the metadata value, and performing
actions.
c. The packet is then forwarded to a flow table further down the pipeline,
to the group table, to the meter table, or directed to an output port.
2. If there is a match only on a table-miss entry, the table entry may
contain instructions, as with any other entry. In practice, the table miss
entry specifies one of three actions:
a. Send packet to controller. This will enable the controller to define a
new flow for this and similar packets, or decide to drop the packet. o b.
Direct packet to another flow table farther down the pipeline. o c. Drop
the packet.
45
 Figure 2.4. Simplified Flowchart Detailing Packet Flow Through
An OpenFlow Switch

3. If there is no match on any entry and there is no table-miss entry, the

packet is dropped. For the final table in the pipeline, forwarding to another
flow table is not an option. If and when a packet is finally directed to an
output port, the accumulated action set is executed and then the packet is
queued for output.

46
Figure 2.5 illustrates the overall ingress pipeline process.

Figure 2.5 Packet Flow Through an OpenFlow Switch: Ingress

Processing
If egress processing is associated with a particular output port, then after a
packet is directed to an output port at the completion of the ingress
processing, the packet is directed to the first flow table of the egress
pipeline. Egress pipeline processing proceeds in the same fashion as for
ingress processing, except that there is no group table processing at the end
of the egress pipeline. Egress processing is shown in Figure 2.6.

Figure 2.6 Packet Flow Through OpenFlow Switch: Egress Processing

47
2.4. SDN Control Plane Function:
The control plane is responsible for populating the routing table, drawing
network topology, forwarding table, and hence enabling the data plane
functions. This means here the router makes its decision. In a single line, it
can be said that it is responsible for How packets should be forwarded.
Advantages of the Control Plane

[Link] Control Plane Architecture:

o The SDN control layer maps application layer service requests into
specific commands and directives to data plane switches and
supplies applications with information about data plane topology
and activity. The control layer is implemented as a server or
cooperating set of servers known as SDN controllers.
o This section provides an overview of control plane functionality.
Later, we look at specific protocols and standards implemented
within the control plane shown in figure 2.7.

Figure 2.7 SDN Architecture

48
2.4.2. Control Plane Functions:
Figure 2.8 illustrates the functions performed by SDN controllers. The figure
illustrates the essential functions that any controller should provide, as suggested
in a paper by Kreutz [KREU15], which include the following:

Figure 2.8 SDN Control Plane Functions and Interfaces

• Shortest path forwarding: Uses routing information collected

from switches to establish preferred routes.
• Notification manager: Receives, processes, and forwards to an
application event, such as alarm notifications, security alarms, and
state changes.
• Security mechanisms: Provides isolation and security enforcement
between applications and services.
• Topology manager: Builds and maintains switch interconnection
topology information.
• Statistics manager: Collects data on traffic through the switches.
• Device manager: Configures switch parameters and attributes and
manages flow tables. The functionality provided by the SDN
controller can be viewed as a network operating system (NOS).
o As with a conventional OS, an NOS provides essential
services, common application programming interfaces
(APIs), and an abstraction of lower-layer elements to
developers.

49
 The functions of an SDN NOS, such as those in the
preceding list, enable developers to define network policies
and manage networks without concern for the details of the
network device characteristics, which may be heterogeneous
and dynamic.
o The northbound interface, discussed subsequently, provides
a uniform means for application developers and network
managers to access SDN service and perform network
management tasks. Further, well-defined northbound
interfaces enable developers to create software that is
independent not only of data plane details but to a great
extent usable with a variety of SDN controller servers.
o A number of different initiatives, both commercial and open
source, have resulted in SDN controller implementations.
The following list describes a few prominent ones:
• Open Daylight: An open-source platform for network
programmability to enable SDN, written in Java.
o Open Daylight was founded by Cisco and IBM, and its
membership is heavily weighted toward network vendors.
o Open Daylight can be implemented as a single centralized
controller, but enables controllers to be distributed where
one or multiple instances may run on one or more clustered
servers in the network.
• Open Network Operating System (ONOS): An open source SDN
NOS, initially released in 2014. It is a nonprofit effort funded and
developed by a number of carriers, such as AT&T and NTT, and
other service providers.
o Significantly, ONOS is supported by the Open Networking
Foundation, making it likely that ONOS will be a major
factor in SDN deployment.
o ONOS is designed to be used as a distributed controller and
provides abstractions for partitioning and distributing
network state onto multiple distributed controllers.
• POX: An open source OpenFlow controller that has been
implemented by a number of SDN developers and engineers.

50
 o POX has a well written API and documentation. It also
provides a webbasedgraphical user interface (GUI) and is
written in Python, which typically shortens its experimental
and developmental cycles compared to some other
implementation languages, such as C++.
• Beacon: An open-source package developed at Stanford. Written in
Java and highly integrated into the Eclipse integrated development
environment (IDE). o Beacon was the first controller that made it
possible for beginner programmers to work with and create a
working SDN environment.
• Floodlight: An open-source package developed by Big Switch
Networks. Although its beginning was based on Beacon, it was built
using Apache Ant, which is a very popular software build tool that
makes the development of Floodlight easier and more flexible.
Floodlight has an active community and has a large number of
features that can be added to create a system that best meets the
requirements of a specific organization. Both a web-based and
JavabasedGUI are available and most of its functionality is exposed
through a REST API.
• Ryu: An open-source component-based SDN framework developed
by NTT Labs. It is open sourced and fully developed in python.
• Onix: Another distributed controller, jointly developed by VMware,
Google, and NTT. Onix is a commercially available SDN controller.

2.5. Southbound Interface:

o Open vSwitch Database Management Protocol (OVSDB)
o Forwarding and Control Element Separation (ForCES)
o Protocol Oblivious Forwarding (POF).
o The southbound interface provides the logical connection between the
SDN controller and the data plane switches (see Figure 2.9). Some
controller products and configurations support only a single
southbound protocol.
o A more flexible approach is the use of a southbound abstraction layer
that provides a common interface for the control plane functions while
supporting multiple southbound APIs.

51
 Figure 2.9 SDN Controller Interfaces
Open vSwitch Database Management Protocol (OVSDB): Open vSwitch
(OVS) an open-source software project which implements virtual switching that is
interoperable with almost all popular hypervisors. OVS uses OpenFlow for
message forwarding in the control plane for both virtual and physical ports.
OVSDB is the protocol used to manage and configure OVS instances.
• Forwarding and Control Element Separation (ForCES): An
IETF effort that standardizes the interface between the control plane
and the data plane for IP routers.
• Protocol Oblivious Forwarding (POF): This is advertised as an
enhancement to OpenFlow that simplifies the logic in the data plane
to a very generic forwarding element that need not understand the
protocol data unit (PDU) format in terms of fields at various
protocol levels. Rather, matching is done by means of (offset,
length) blocks within a packet. Intelligence about packet format
resides at the control plane level.
2.6. Northbound Interface:
o The northbound interface enables applications to access control plane
functions and services without needing to know the details of the
underlying network switches. The northbound interface is more
typically viewed as a software API rather than a protocol.

52
o Unlike the southbound and eastbound/westbound interfaces, where a
number of heterogeneous interfaces have been defined, there is no
widely accepted standard for the northbound interface. The result has
been that a number of unique APIs have been developed for various
controllers, complicating the effort to develop SDN applications.
o To address this issue the Open Networking Foundation formed the
Northbound Interface Working Group (NBI-WG) in 2013, with the
objective of defining and standardizing a number of broadly useful
northbound APIs. As of this writing, the working group has not issued
any standards. A useful insight of the NBI-WG is that even in an
individual SDN controller instance, APIs are needed at different
“latitudes.”
o That is, some APIs may be “further north” than others, and access to
one, several, or all of these different APIs could be a requirement for a
given application.
o Figure 2.10, from the NBI-WG charter document (October 2013),
illustrates the concept of multiple API latitudes. For example, an
application may need one or more APIs that directly expose the
functionality of the controller, to manage a network domain, and use
APIs that invoke analytic or reporting services residing on the controller.

Figure 2.10. Latitude of Northbound Interfaces

53
Figure 2.11 shows a simplified example of an architecture with multiple
levels of northbound APIs, the levels of which are described in the list that
follows.

Figure 2.11 SDN Controller APIs

• Base controller function APIs: These APIs expose the basic
functions of the controller and are used by developers to create
network services.
• Network service APIs: These APIs expose network services to the
north.
• Northbound interface application APIs: These APIs expose
application-related services that are built on top of network services.
o As with any network or internet, an SDN network requires a
routing function. In general terms, 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. o 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). An
ERP need not collect as much detailed traffic information.

54
 Rather, 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.
o Traditionally, the routing function is distributed among the
routers in a network. Each router is responsible for building
up an image of the topology of the network.
o 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. However,
in an SD controlled network, it makes sense to centralize the
routing function within the SDN controller.
o 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. o The
centralized routing application performs two distinct
functions: link discovery and topology manager.
• For link discovery, the routing function needs to be aware of links
between data plane switches.
• Note that in the case of an internetwork, the links between routers
are networks, whereas for Layer 2 switches, such as Ethernet
switches, the links are direct physical links.
o 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.
o Discovery is triggered by unknown traffic entering the
controller’s network domain either from an attached host or
from a neighboring router.
• The topology manager maintains the topology information for the
network and calculates routes in the network.
o Route calculation involves determining the shortest path
between two data plane nodes or between a data plane node
and a host.

55
[Link] in SDN controller:
o Ryu Controller is an open, software -defined networking
(SDN) Controller designed to increase the agility of the network by
making it easy to manage and adapt how traffic is handled. In general,
the SDN Controller is the brain of the SDN environment,
communicating information down to the switches and routers with
southbound APIs, and up to the applications and business logic with
northbound APIs.
o The Ryu Controller is supported by NTT and is deployed in NTT cloud
data centers as well. The Ryu Controller provides software components,
with well-defined application program interfaces (APIs), that make it
easy for developers to create new network management and control
applications.
o This component approach helps organizations customize deployments
to meet their specific needs; developers can quickly and easily modify
existing components or implement their own to ensure the underlying
network can meet the changing demands of their applications shown in
Figure 2.12.

Figure 2.12 RYU SDN controller

o The Ryu Controller source code is hosted on GitHub and managed
and maintained by the open Ryu community. Open Stack, which
runs an open collaboration focused on developing a cloud operating
system that can control the compute, storage, and networking
resources of an organization, supports deployments of Ryu as the
Network Controller.
o Written entirely in Python, all of Ryu’s code is available under the
Apache 2.0 license and open for anyone to use.

56
 o The Ryu Controller supports NETCONF and OF-config network
management protocols, as well as Openflow, which is one of the first
and most widely deployed SDN communications standards. It also
supports Nicira extensions.

[Link] Architecture:
Ryu[86] is a component-based, open source (supported by NTT Labs)
framework implemented entirely in Python (Figure 2-13). The Ryu
messaging service does support components developed in other languages.

Components include an OpenFlow wire protocol support (up through

version 1.3 of OF-wire including Nicira extensions), event management,
messaging, inmemory state management, application management,
infrastructure services and a series of reusable libraries (e.g., NETCONF
library, sFlow/Netflow library).

Additionally, applications like Snort, a layer 2 switch, GRE tunnel

abstractions, VRRP, as well as services (e.g., topology and statistics) are
available. At the API layer, Ryu has an Openstack Quantum plug-in that
supports both GRE based overlay and VLAN configurations.
Ryu also supports a REST interface to its OpenFlow operations.

Figure 2-13. Ryu architecture, applications (non-exhaustive), and APIs

A prototype component has been demonstrated that uses HBase for statistics
storage, including visualization and analysis via the stats component tools.

57
While Ryu supports high availability via a Zookeeper component, it does
not yet support a cooperative cluster of controllers.

2.7.2. Key Features of RYU as an SDN Controller:

1. OpenFlow Support: RYU supports OpenFlow 1.0 and 1.3,
enabling communication with OpenFlow-enabled switches, which
is a common standard for SDN networks.
2. Python-based: RYU is written in Python, which makes it easy to
use and extend. Python’s extensive libraries can be leveraged to add
functionality quickly.
3. Modular Architecture: RYU provides a modular and extensible
framework, where different network functionalities can be created
as independent modules (such as forwarding, traffic engineering,
etc.) and then combined.
4. REST API: RYU supports REST APIs that allow external
applications or users to interact with the SDN controller. This makes
it easy to manage and monitor the network programmatically.
5. Multi-Protocol Support: In addition to OpenFlow, RYU supports
other protocols, such as OVSDB (Open vSwitch Database) and
NetFlow, allowing it to interact with various network devices and
platforms.
6. Network Management & Traffic Monitoring: RYU provides
capabilities to manage traffic flows, including setting up flow tables,
monitoring traffic patterns, and implementing security policies.

2.7.3. Key Components of RYU:

• RYU Controller: The main entity that controls the network. It
communicates with the network devices (like switches) and other
components using OpenFlow or other protocols.
• Applications: RYU allows you to write SDN applications in
Python.
These applications can manage flows, collect statistics, set policies, etc.
• OpenFlow Switches: Devices that support OpenFlow can be
controlled by RYU. These switches forward packets based on flow
entries provided by the controller.

58
2.7.4. How RYU Works in SDN:
1. Switch Discovery: RYU detects switches using OpenFlow's
features. When a switch connects to the RYU controller, the
controller learns about the switch, its capabilities, and its ports.
2. Flow Table Management: RYU can program flow tables in
OpenFlow enabled switches. Flow entries determine how packets
are forwarded through the network. RYU can add, modify, or delete
flow entries based on the network topology and policies defined by
the application.
3. Packet Processing: The controller can handle events, such as
packet-in or packet-out messages. This allows for processing of
specific packets, such as those requiring special handling (e.g.,
security checks or routing decisions).
4. Network Topology: RYU can learn and maintain a map of the
network topology (e.g., which switches are connected to which other
switches), and this information can be used for advanced network
management tasks like load balancing, path optimization, or fault
tolerance.

2.7.5. Example of a Simple RYU Controller Application:

Here’s a simple example of a RYU controller application that sets up a basic
OpenFlow flow on a switch.
python
Copy
code
from [Link] import app_manager
from [Link] import
ofp_event
from [Link] import MAIN_DISPATCHER, set_ev_cls
from [Link] import ofproto_v1_3 class
SimpleSwitch(app_manager.RyuApp):
OFP_VERSIONS =
[ofproto_v1_3.OFP_VERSION] def
__init__(self, *args, **kwargs):
super(SimpleSwitch, self).__init__(*args,
**kwargs)
@set_ev_cls(ofp_event.EventOFPSwitchFeatures,
MAIN_DISPATCHER) def
switch_features_handler(self, ev):
59
 # When a switch connects to the controller, we install a default
flow datapath = [Link] ofproto = [Link] parser =
datapath.ofproto_parser

# Install a flow to flood all packets

match = [Link]()
actions = [[Link](ofproto.OFPP_FLOOD)]
self.add_flow(datapath, 0, match, actions)

def add_flow(self, datapath, priority, match,

actions): ofproto = [Link] parser =
datapath.ofproto_parser

# Create flow mod message

inst = [[Link](ofproto.OFPIT_APPLY_ACTIONS,
actions)]
mod = [Link](datapath=datapath, priority=priority,
match=match, instructions=inst)

# Send the flow mod message to the switch

datapath.send_msg(mod)
This is a simple controller application that installs a flow to forward all
packets to the flood output port when a new switch is connected. The
switch_features_handler method handles the event when a switch connects
to the controller.

2.7.6. Benefits of RYU:

• Ease of Use: Python’s syntax makes RYU accessible, even for
developers who are not networking experts.
• Flexible: RYU provides a wide range of APIs and abstractions,
making it suitable for diverse SDN applications such as network
monitoring, traffic management, and security.
• Extensibility: Due to its modular architecture, you can easily extend
RYU to support custom protocols, devices, or other SDN-specific
features.

60
2.7.7. Use Cases of RYU:
• Network Virtualization: RYU can manage virtualized networks in
data centers, allowing for better resource utilization and dynamic
reconfiguration.
• Traffic Engineering: By controlling traffic flows, RYU can
optimize network paths and load balancing to ensure efficient traffic
management.
• Security and Access Control: RYU can implement network
security policies such as firewall rules, intrusion detection, or access
control.

2.8. Open Daylight Architecture:

o The open Daylight 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.
o ensible, open source, virtual networking platform atop such existing
standards as OpenFlow.
o The approach of open Daylight is to enable industry participants to
come together to develop core open-source modules collaboratively,
around which participants can add unique value. The goal is a
common and open SDN platform for developers to utilize,
contribute to, and build commercial products and technologies upon.
o It is worthwhile to examine open Daylight in some detail, as it gives
the reader a good idea of the scope of functionality of a typical SDN
controller.

2.8.1. open Daylight Architecture:

Figure 2.13 provides a top-level view of the open Daylight
architecture. It consists of five logical layers, as further described in
the list that follows.

61
 Figure 2.13 open Daylight Architecture
• Network applications, orchestration, and services: Consists of
business and network logic applications that control and monitor
network behavior. These applications use the controller to gather
network intelligence, run algorithms to perform analytics, and then
use the controller to orchestrate the new rules, if any, throughout the
network.
• APIs: A set of common interfaces to open Daylight controller
functions. Open Daylight supports the Open Service Gate Way
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 (or even necessarily on the same machine) 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.

62
• Southbound interfaces and protocols: Support open flow, other
standard southbound protocols, and vendor-specific interfaces.
There are several noteworthy aspects to the open Daylight
architecture.
o First, open Daylight encompasses both control plane and
application plane functionality. Thus, open Daylight is more
than just an SDN controller implementation.
o This enables enterprise and telecommunications network
managers to host open-source software on their own servers
to construct an SDN configuration. o Vendors can use this
software to create products with value-added additional
application plane functions and services. A second
significant aspect of the open Daylight design is that it is not
tied to OpenFlow or any other specific southbound interface.
o This provides greater flexibility in constructing SDN
network configurations. The key element in this design is the
SAL, which enables the controller to support multiple
protocols on the southbound interface and provide
consistent, services for controller functions and for SDN
applications.
o Figure 2.14illustrates 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.
o 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.

63
 FIGURE 2.14 Service Abstraction Layer Model

o The emphasis in the open Daylight project is that the software suite be
modular, pluggable, and flexible. All of the code is implemented in Java
and is contained within its own Java Virtual Machine (JVM). As such,
it can be deployed on any hardware and operating system platform that
supports Java.

2.8.2. open Daylight Helium:

At the time of this writing, the most recent release of open Daylight
is the Helium release, illustrated in Figure 2.15. The controller
platform (exclusive of applications, which may also run on the
controller) 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 open Daylight implementation, as described in
the list that follows.

64
 Figure 2.15OpenDaylight Structure (Helium)

• Topology manager: A service for learning the network layout by

subscribing to events of node addition and removal and their
interconnection. Applications requiring network view can use this
service.
• Statistics manager: Collects switch-related statistics, including
flow statistics, node connector, and queue occupancy.
• Switch manager: Holds the details of the data plane devices. As a
switch is discovered, its attributes (for example, what switch/router
it is, software version, capabilities) are stored in a database by the
switch manager.
• Forwarding rules manager: Installs routes and tracks next-hop
information. Works in conjunction with switch manager and
topology manager to register and maintain network flow state.
Applications using this need not have visibility of network device
specifics.
• Host tracker: Tracks and maintains information about connected
hosts. To augment these base services, a number of other modules
have been developed to enable implementation of more
sophisticated and featurerich controllers, as described in Table 2.3.
65
66
67
TABLE 2.3 open Daylight Modules

68
2.9. ONOS in SDN Controller:
2.9.1. What is ONOS:
ONOS (Open Network Operating System) is a network operating system
designed for Software-Defined Networking (SDN). It is an open-source
SDN controller that provides a platform for building and managing SDN-
based networks. ONOS is primarily aimed at large-scale service providers,
enterprises, and telecommunications networks. It supports SDN
architectures and integrates with various network technologies, enabling
flexible and scalable network management.
o ONOS was designed to meet the needs of operators wishing to build
carrier-grade solutions that leverage the economics of white box
merchant silicon hardware while offering the flexibility to create and
deploy new dynamic network services with simplified
programmatic interfaces.
o ONOS supports both configuration and real-time control of the
network, eliminating the need to run routing and switching control
protocols inside the network fabric.
o By moving intelligence into the ONOS cloud controller, innovation
is enabled and end-users can easily create new network applications
without the need to alter the data plane systems in Figure 2.16.

2.9.2. The ONOS platform includes:

o A platform and a set of applications that act as an extensible, modular,
distributed SDN controller. o Simplified management, configuration
and deployment of new software, hardware & services.
o A scale-out architecture to provide the resiliency and scalability
required to meet the rigors of production carrier environments.

69
 Figure 2.16 ONOS Controller

2.9.3. Key Features of ONOS in

SDN:
1. Controller for SDN:
ONOS serves as the central controller in SDN architectures,
responsible for managing and controlling network devices (such as
switches and routers) in a decoupled, software-driven way. It
provides a centralized point of control for network traffic and
policies.
2. Southbound Protocols:
ONOS uses southbound protocols like OpenFlow, NETCONF, and
OVSDB to communicate with the network devices (data plane).
OpenFlow is the most commonly used protocol for SDN, enabling
ONOS to send control messages to switches and other devices to
manage how data flows through the network.
3. Distributed and Scalable Architecture:
ONOS is designed to be highly scalable and can run on multiple
nodes in a distributed fashion. This allows it to handle large-scale
networks and provides high availability and fault tolerance.

70
 It is optimized to operate in high-performance environments, such
as large data centers or service provider networks.
4. Intent-Based Networking:
ONOS supports intent-based networking, which allows network
administrators to specify high-level "intents" or desired outcomes
(such as "ensure low latency between these two data centers") rather
than configuring network devices in a detailed, low-level way.
ONOS then translates these high-level intents into specific network
configurations and policies.
5. High Availability and Fault Tolerance:
ONOS provides fault-tolerant mechanisms such as leader election
and state replication, ensuring that the network can continue
functioning even if a controller node fails. It can automatically
detect failure and recover the network control plane without
impacting network services.
6. API and Extensibility:
ONOS provides a rich set of REST APIs and other interfaces for
developers to integrate with other network management systems,
applications, and network devices. It also allows custom
applications to be developed and run on top of the ONOS platform
to add specific functionalities or services to the network.
7. Application Layer:
ONOS enables developers to write applications that run on top of
the controller, which can be used to manage the network. These
applications can implement various network functions such as
traffic engineering, security enforcement, and fault detection.
8. Performance Optimization:
ONOS is built with performance in mind, using efficient data
structures and algorithms to manage the network state and control
traffic. It is capable of handling large-scale networks with high
throughput and low latency, making it suitable for carrier-grade
deployments.
9. Support for Various Network Technologies:
ONOS is designed to support not just OpenFlow-based networks,
but also other network technologies and protocols like P4
(Programming Protocol-Independent Packet Processors) and
NETCONF. This allows it to be used in heterogeneous network
environments.

71
2.9.4. ONOS in SDN Networks:
• Centralized Control:
In an SDN architecture, ONOS acts as the centralized brain of the
network.
It uses the SDN controller to configure and manage the network
infrastructure (e.g., switches, routers) based on real-time
requirements.
• Network Abstraction:
ONOS abstracts the underlying network infrastructure, allowing
administrators to focus on higher-level network management tasks
like routing, traffic engineering, and service delivery. The controller
decouples control and data planes, allowing the network to be more
programmable and flexible.
• Traffic Engineering and Optimization:
ONOS can dynamically adapt to traffic patterns, optimize paths, and
allocate resources based on current network conditions, enhancing
network performance. It supports advanced features like load
balancing, QoS (Quality of Service), and fault-tolerant routing.
• Security and Policy Enforcement:
ONOS enables the enforcement of security policies (e.g., access
control lists, firewalls) at a centralized level. Policies can be applied
across the entire network or specific segments based on the business
requirements.

2.9.5. Key Benefits of Using ONOS in SDN:

• Scalability: ONOS is built to scale horizontally, meaning that
additional controller nodes can be added to meet the growing
demands of large networks without performance degradation.
• Flexibility: With ONOS, network administrators have the flexibility
to configure, manage, and optimize networks dynamically using
software based control rather than relying on static, hardware-based
configurations.
• Reliability and Availability: ONOS ensures that the network can
continue functioning in the event of hardware failures or controller
crashes, thanks to its fault-tolerant features.
• Open Source: ONOS is open-source, meaning that it benefits from
the contributions of a large community, and it can be customized to
meet the needs of specific use cases.

72
 • Multi-Tenant Support: ONOS provides the ability to support
multiple tenants in large-scale multi-tenant networks, which is
critical for cloud service providers and telecom operators.
2.10. Distributed Controllers:

In the context of Software-Defined Networking (SDN), a Distributed

Controller refers to an architecture where the network control plane is
spread across multiple controllers instead of being centralized in one single
controller. This setup contrasts with a Centralized Controller architecture,
where a single entity manages all the decision-making processes for the
network.

2.10.1. Key Concepts of Distributed Controllers in SDN:

1. Decentralization:
o Distributed SDN controllers aim to overcome the limitations
of a single point of failure and scalability concerns that are
inherent in centralized controllers. By having multiple
controllers working together, the system can handle larger,
more complex networks efficiently.
2. Coordination:
o The controllers in a distributed SDN architecture need to
coordinate with each other to ensure consistency, reliability,
and network-wide policies. This can be achieved through
protocols, such as controller-to-controller communication
and synchronization mechanisms, to ensure that all
controllers have a coherent view of the network.
3. Load Balancing:
o Multiple controllers can distribute the workload of managing
the network, balancing tasks like flow table management,
network state, and topology awareness. Load balancing
helps in optimizing performance and reducing the risk of
congestion or bottlenecks at a single controller.
4. Fault Tolerance:
o A distributed controller system is more resilient than a single
controller. If one controller fails or becomes unreachable, the
others can continue to manage the network. Redundancy and
failover mechanisms ensure high availability.

73
 5. Scalability:
o Distributed controllers enable better scaling. As the network
grows, more controllers can be added to handle additional
load, without degrading the performance of the system.

2.10.2. Components and Architecture:

The Architecture Distributed Controller shown in Figure 2.17.

Figure 2.17. Distributed Controller

1. Controller Instances:
o Each distributed controller is typically responsible for
managing a part of the network. This could be based on
geographical location, network domain, or logical
partitioning of the network.
2. Controller Communication:
o Controllers need to communicate with each other to
exchange information about the network state, topology, and
configurations. Common protocols include OpenFlow,
RESTful APIs, or custom communication protocols built
for inter-controller communication.
3. Data Plane and Control Plane Separation:
o SDN architecture is based on the separation of the data
plane (forwarding devices such as switches and routers) and
the control plane (where decisions and policies are made).

74
 o Distributed controllers interact with the data plane elements
via protocols like OpenFlow, providing control over network
behaviors.

Global View of Network State:

o In distributed SDN, the global state is typically synchronized
across controllers to ensure a consistent view of the network
topology and flow rules. Different controllers may manage
different parts of the network, but they must share updates to
maintain this global consistency.

2.10.3. Benefits of Distributed Controllers:

1. Improved Performance: By distributing control, each controller
handles a smaller segment of the network, reducing the latency
associated with network decisions and enabling faster reaction
times.
2. Fault Tolerance and Resilience: In the event of controller failure,
other controllers can take over the management of the affected part
of the network, improving overall system resilience.
3. Scalability: Networks can scale more effectively by adding more
controllers as the network grows, without overwhelming a single
centralized controller.
4. Geographic Distribution: For large-scale or geographically
dispersed networks, having controllers in different locations can
help reduce the distance and latency for communication between
controllers and network devices.

2.10.4. Challenges of Distributed Controllers:

1. Complexity of Coordination: Managing multiple controllers and
ensuring they stay synchronized is more complex than in a
centralized architecture. This requires sophisticated coordination
protocols.
2. Consistency Issues: Ensuring that all controllers have a consistent
view of the network state can be challenging, especially when
network conditions change rapidly.
3. Increased Overhead: The communication between distributed
controllers can introduce overhead, especially when sharing updates
about network topology and state.

75
 4. Security: A distributed system increases the attack surface.
Ensuring secure communication between controllers and the devices
they manage is critical to prevent unauthorized access or
manipulation of network resources.

2.10.5. Example Architectures:

1. Master-Slave (or Leader-Follower):
o In this architecture, one controller (the "master") takes the
lead in managing the network, while others (the "slaves")
perform backup or less critical functions. This is a hybrid
between centralized and distributed systems, where the
master coordinates the overall network state, and slaves
handle local tasks.
2. Peer-to-Peer (P2P):
o In this fully distributed architecture, each controller is equal,
and there is no central "master" controller. Instead, all
controllers share the network management responsibilities
and coordinate to achieve a global network view. This model
is more fault-tolerant but can be more complex to manage.
3. Hierarchical Control:
o This model involves organizing controllers in a hierarchical
fashion, where high-level controllers manage larger regions
or domains, and lower-level controllers manage specific
areas or devices. This can help reduce the complexity of
coordination and improve scalability.
Example Use Cases for Distributed SDN Controllers:
• Large-scale Data Centers: In a large data center, multiple
controllers can be distributed to handle different racks or zones,
improving responsiveness and fault tolerance.
• Telecommunication Networks: For service providers with wide
geographical networks, distributed controllers can help in managing
the network infrastructure across different locations.
• Campus or Metropolitan Area Networks: Large university
campuses or cities with complex networking needs can benefit from
a distributed SDN controller system for better performance and
resilience. In conclusion, distributed SDN controllers offer an
effective way to manage large-scale and geographically dispersed
networks, improving scalability, performance, and fault tolerance.

76
 However, they introduce complexity in terms of coordination,
consistency, and overhead, which must be managed effectively.
PART A
1. Define SDN Data Plane.
The SDN data plane, referred to as the resource layer in ITU-T
Y.3300 and also often referred to as the infrastructure layer, is where
network forwarding devices perform the transport and processing of
data according to decisions made by the SDN control plane.
The important characteristic of the network devices in an SDN
network is that these devices perform a simple forwarding function,
without embedded software to make autonomous decisions.
2. What is Control support function?
Interacts with the SDN control layer to support programmability via
resource-control interfaces. The switch communicates with the
controller and the controller manages the switch via the OpenFlow
switch protocol.
3. Define Control support function.
Interacts with the SDN control layer to support programmability via
resource-control interfaces. The switch communicates with the
controller and the controller manages the switch via the OpenFlow
switch protocol.
4. How Data forwarding function works in Data Plane?
Accepts incoming data flows from other network devices and end
systems and forwards them along the data forwarding paths that
have been computed and established according to the rules defined
by the SDN applications.
These forwarding rules used by the network device are embodied in
forwarding tables that indicate for given categories of packets what
the next hop in the route should be. In addition to simple forwarding
of a packet, the network device can alter the packet header before
forwarding, or discard the packet.
5. Define Data Plane Protocols.
Data packet flows consist of streams of IP packets. It may be
necessary for the forwarding table to define entries based on fields
in upper-level protocol headers, such as TCP, UDP, or some other
transport or application protocol.
The network device examines the IP header and possibly other
headers in each packet and makes a forwarding decision.

77
6. Define OpenFlow Protocol.
The OpenFlow protocol describes message exchanges that take
place between an OpenFlow controller and an OpenFlow switch.
Typically, the protocol is implemented on top of TLS, providing a
secure OpenFlow channel.
The OpenFlow protocol enables the controller to perform add,
update, and delete actions to the flow entries in the flow tables.
7. How pass messages Controller to switch in OpenFlow protocol?
These messages are initiated by the controller and, in some cases,
require a response from the switch. This class of messages enables
the controller to manage the logical state of the switch, including its
configuration and details of flow and group table entries. Also
included in this class is the Packet-out message.
This message is sent by the controller to a switch when that switch
sends a packet to the controller and the controller decides not to drop
the packet but to direct it to a switch output port.
8. What is Asynchronous?
These types of messages are sent without solicitation from the
controller. This class includes various status messages to the
controller. Also included is the Packet-in message, which may be
used by the switch to send a packet to the controller when there is
no flow table match.
9. What is Symmetric?
These messages are sent without solicitation from either the
controller or the switch. They are simple yet helpful. Hello messages
are typically sent back and forth between the controllers and switch
when the connection is first established.
Echo request and reply messages can be used by either the switch or
controller to measure the latency or bandwidth of a controller-switch
connection or just verify that the device is up and running. The
Experimenter message is used to stage features to be built in to
future versions of OpenFlow.
10. Define Flow statistics.
Generated by the switch based on traffic flow. This information
enables the controller to monitor traffic, reconfigure the network as
needed, and adjust flow parameters to meet QoS requirements.

78
11. Define encapsulated packets.
Sent by the switch to the controller either because there is an explicit
action to send this packet in a flow table entry or because the switch
needs information for establishing a new flow.
The OpenFlow protocol enables the controller to manage the logical
structure of a switch, without regard to the details of how the switch
implements the OpenFlow logical architecture.
12. What is Match fields and Priority?
• Match fields: Used to select packets that match the values in the
fields.
• Priority: Relative priority of table entries. This is a 16-bit field with
corresponding to the lowest priority. In principle, there could be 216
= 64k priority levels.
13. What is Counters and Instructions?
• Counters: Updated for matching packets. The OpenFlow
specification defines a variety of counters. Table 2.2 lists the
counters that must be supported by an Openflow switch.
• Instructions: Instructions to be performed if a match occurs.
14. What is Timeouts?
Maximum amount of idle time before a flow is expired by the
switch. Each flow entry has an idle timeout and a hard timeout
associated with it.
A nonzero hard timeout field causes the flow entry to be removed
after the given number of seconds, regardless of how many packets
it has matched.
A nonzero idle timeout field causes the flow entry to be removed
when it has matched no packets in the given number of seconds.
15. What is Cookie and Flags?
• Cookie: 64-bit opaque data value chosen by the controller. May be
used by the controller to filter flow statistics, flow modification and
flow deletion; not used when processing packets.
• Flags: Flags alter the way flow entries are managed; for example,
then flag OFPFF_SEND_FLOW_REM triggers flow removed
messages for that flow entry.
16. List out the Match Fields Component.
• Ingress port
• Egress port.
• Ethernet source and destination addresses

79
 • Ethernet type fieldIPIPv4 or IPv6 source address, and destination
address
TCP source and destination
ports. • UDP source and destination
ports
• Physical port.
• Metadata
• VLAN ID and VLAN user priority
• IPv4 or IPv6 DS and ECN
17. Write down the Control Plane Functions.
• Shortest path forwarding: Uses routing information collected
from switches to establish preferred routes.
• Notification manager: Receives, processes, and forwards to an
application event, such as alarm notifications, security alarms, and
state changes.
• Security mechanisms: Provides isolation and security enforcement
between applications and services.
• Topology manager: Builds and maintains switch interconnection
topology information.
• Statistics manager: Collects data on traffic through the switches.
• Device manager: Configures switch parameters and attributes and
manages flow tables.
18. Define open Daylight.
An open-source platform for network programmability to enable
SDN, written in Java. open Daylight was founded by Cisco and
IBM, and its membership is heavily weighted toward network
vendors.
open Daylight can be implemented as a single centralized controller,
but enables controllers to be distributed where one or multiple
instances may run on one or more clustered servers in the network.
19. Define Open Network Operating System (ONOS).
An open source SDN NOS, initially released in 2014. It is a
nonprofit effort funded and developed by a number of carriers, such
as AT&T and NTT, and other service providers.
Significantly, ONOS is supported by the Open Networking
Foundation, making it likely that ONOS will be a major factor in
SDN deployment.

80
 ONOS is designed to be used as a distributed controller and provides
abstractions for partitioning and distributing network state onto
multiple distributed controllers.
20. Define POX.
An open-source open flow controller that has been implemented by
a number of SDN developers and engineers. POX has a well written
API and documentation.
It also provides a web based graphical user interface (GUI) and is
written in Python, which typically shortens its experimental and
developmental cycles compared to some other implementation
languages, such as C++.
21. Define Beacon.
An open-source package developed at Stanford. Written in Java and
highly integrated into the Eclipse integrated development
environment (IDE). Beacon was the first controller that made it
possible for beginner programmers to work with and create a
working SDN environment.
22. Define Floodlight.
An open-source package developed by Big Switch Networks.
Although its beginning was based on Beacon, it was built using
Apache Ant, which is a very popular software build tool that makes
the development of Floodlight easier and more flexible. Floodlight
has an active community and has a large number of features that can
be added to create a system that best meets the requirements of a
specific organization.
Both a web-based and Java based GUI are available and most of its
functionality is exposed through a REST API.
23. Define Ryu.
An open-source component-based SDN framework developed by
NTT Labs. It is open sourced and fully developed in python.
24. Define Onix.
Another distributed controller, jointly developed by VMware,
Google, and NTT. Onix is a commercially available SDN controller.
25. list out the two stages of processing in OpenFlow.
• Ingress processing: Ingress processing always happens, beginning
with Table 0, and uses the identity of the input port. Table 0 may be
the only table, in which case the ingress processing is simplified to
the processing performed on that single table, and there is no egress
processing.
81
 • Egress processing: Egress processing is the processing that
happens after the determination of the output port. It happens in the
context of the output port. This stage is optional. If it occurs, it may
involve one or more tables. The separation of the two stages is
indicated by the numerical identifier of the first egress table. All
tables with a number lower than the first egress table must be used
as ingress tables, and no table with a number higher than or equal to
the first egress table can be used as an ingress table.
26. Define Southbound Interface.
The southbound interface provides the logical connection between
the SDN controller and the data plane switches.
Some controller products and configurations support only a single
southbound protocol.
A more flexible approach is the use of a southbound abstraction
layer that provides a common interface for the control plane
functions while supporting multiple southbound APIs.
27. Define Open vSwitch Database Management Protocol (OVSDB).
Open vSwitch (OVS) an open-source software project which
implements virtual switching that is interoperable with almost all
popular hypervisors. OVS uses OpenFlow for message forwarding
in the control plane for both virtual and physical ports. OVSDB is
the protocol used to manage and configure OVS instances.
28. Define Forwarding and Control Element Separation (ForCES).
An IETF effort that standardizes the interface between the control
plane and the data plane for IP routers.
29. Define Protocol Oblivious Forwarding (POF).
This is advertised as an enhancement to OpenFlow that simplifies
the logic in the data plane to a very generic forwarding element that
need not understand the protocol data unit (PDU) format in terms of
fields at various protocol levels.
Rather, matching is done by means of (offset, length) blocks within
a packet. Intelligence about packet format resides at the control
plane level.
30. Define 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 northbound interface is more
typically viewed as a software API rather than a protocol.

82
31. Write down the multiple levels of northbound APIs.
The levels of which are described in the list that follows.
• Base controller function APIs: These APIs expose the basic
functions of the controller and are used by developers to create
network services.
• Network service APIs: These APIs expose network services to the
north.
• Northbound interface application APIs: These APIs expose
application-related services that are built on top of network services.
32. What is Network applications, orchestration, and services?
Consists of business and network logic applications that control and
monitor network behavior. These applications use the controller to
gather network intelligence, run algorithms to perform analytics,
and then use the controller to orchestrate the new rules, if any,
throughout the network.
33. What are APIs?
A set of common interfaces to open Daylight controller functions.
open Daylight 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
(or even necessarily on the same machine) as the controller.
34. What is Controller functions and services and Service abstraction layer
?
• 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.
35. Define southbound interfaces and protocols.
Supports OpenFlow, other standard southbound protocols, and
vendor specific interfaces. There are several noteworthy aspects to
the open Daylight architecture.
First, open Daylight encompasses both control plane and application
plane functionality.
A second significant aspect of the open Daylight design is that it is
not tied to OpenFlow or any other specific southbound interface.

83
36. List out the Five modules of network service functions open Daylight
implementation.
• Topology manager
• Statistics manager
• Switch manager
• Forwarding rules manager
• Host tracker
PART-B
1. Explain in detail about SDN Control Plane with neat diagram and
control plane function.
2. Explain in detail about Southbound Interface with neat diagram.
3. Explain in detail about Northbound Interface with neat diagram.
4. Explain in detail about RYU in SDN controller.
5. Explain in detail about Open Daylight Architecture with neat
diagram.
6. Explain in detail about ONOS in SDN Controller.
7. Explain in detail about Distributed Controllers.
8. Explain the SDN Application Plane Architecture

84
 UNIT III
SDN APPLICATIONS

SDN Application Plane Architecture – Network Services Abstraction Layer

–
Traffic Engineering – Measurement and Monitoring – Security – Data
Center Networking
[Link] Application Plane:
The power of the software-defined networking (SDN) approach to
networking is in the support it provides for network applications to
monitor and manage network behavior. The SDN control plane provides
the functions and services that facilitate rapid development and
deployment of network applications.

While the SDN data and control planes are well defined, there is much
less agreement on the nature and scope of the application plane. At
minimum, the application plane includes a number of network
applications—that is, applications that specifically deal with network
management and control. There is no agreed-upon set of such
applications or even categories of such applications.

Further, the application layer may include general-purpose network

abstraction tools and services that might also be viewed as part of the
functionality of the control plane.

With these limitations in mind, this chapter provides an overview of the

SDN application plane. Figure 3.1 begins with an overview of the SDN
application plane architecture. Figure 3.2 looks at a key component of
that architecture, the network services abstraction layer. The remaining
sections look at six major application areas that can be supported by
SDN. These sections also describe a number of specific examples. The
examples were chosen to give the reader a feel for the range of
applications that can benefit from an SDN infrastructure.

85
 Figure [Link] Architecture

[Link] Application Plane Architecture:

• The application plane contains applications and services that define,
monitor, and control network resources and behavior.
• These applications interact with the SDN control plane via
application control interfaces, for the SDN control layer to
automatically customize the behavior and the properties of network
resources. The programming of an SDN application makes use of
the abstracted view of network resources provided by the SDN
control layer by means of information and data models exposed via
the application control interface.
• This section provides an overview of application plane functionality,
depicted in Figure 3.2. The elements in this figure are analyzed
through a bottom-up approach, and subsequent sections provide
detail on specific application areas.

86
 Figure 3.2 SDN Application Plane Functions and Interfaces

3.1.2. Northbound Interface :

• The “SDN Control Plane,” the northbound interface enables
applications to access control plane functions and services without
needing to know the details of the underlying network switches.
Typically, the northbound interface provides an abstract view of
network resources controlled by the software in the SDN control
plane.
• Figure 1.18 indicates that the northbound interface can be a local or
remote interface. For a local interface, the SDN applications are
running on the same server as the control plane software (controller
network operating system).
• Alternatively, the applications could be run on remote systems and
the northbound interface is a protocol or application programming
interface (API) that connects the applications to the controller
network operating system (NOS) running on central server.
• Both architectures are likely to be implemented. An example of a
northbound interface is the REST API for the Ryu SDN network
operating system.

3.1.3. Network Services Abstraction Layer:

• RFC 7426 defines a network services abstraction layer between the
control and application planes and describes it as a layer that
provides service abstractions that can be used by applications and
services. Several functional concepts are suggested by the
placement of this layer in the SDN architecture.

87
 o This layer could provide an abstract view of network
resources that hides the details of the underlying data plane
devices. o This layer could provide a generalized view of
control plane functionality, so that applications could be
written that would operate across a range of controller
network operating systems. o This functionality is similar
to that of a hypervisor or virtual machine monitor that
decouples applications from the underlying OS and
underlying hardware. o This layer could provide a network
virtualization capability that allows different views of the
underlying data plane infrastructure.

3.1.4. Network Applications:

• There are many network applications that could be implemented for
an SDN. Different published surveys of SDN have come up with
different lists and even different general categories of SDN-based
network applications. Figure 1.18 includes six categories that
encompass the majority of SDN applications

3.1.5. User Interface:

• The user interface enables a user to configure parameters in SDN
applications and to interact with applications that support user
interaction. Again, there are two possible interfaces.
• A user that is collocated with the SDN application server (which
may or may not include the control plane) can use the server’s
keyboard/display. More typically, the user would log on to the
application server over a network or communications facility.

3.2. Network Services Abstraction Layer.

• In the context of the discussion, abstraction refers to the amount
detail about lower levels of the model that is visible to higher levels.
More abstraction means less detail; less abstraction means more
detail. An abstraction layer is a mechanism that translates a high-
level request into the low-level commands required to perform the
request.
• An API is one such mechanism. It shields the implementation details
of a lower level of abstraction from software at a higher level.

88
 A network abstraction represents the basic properties or
characteristics of network entities (such as switches, links, ports, and
flows) is such a way that network programs can focus on the desired
functionality without having to program the detailed actions.

3.2.1. Abstractions in SDN:

Scott Shenker, an Open Networking Foundation (ONF) board
member and OpenFlow researcher, indicates that SDN can be defined by
three fundamental abstractions [SHEN11]: forwarding, distribution, and
specification, as illustrated in Figure [Link] described further in the
sections that follow.

Figure [Link] Architecture and Abstractions

3.2.2. Forwarding Abstraction:

The forwarding abstraction allows a control program to specify data
plane forwarding behavior while hiding details of the underlying switching
hardware. This abstraction supports the data plane forwarding function. By
abstracting away from the forwarding hardware, it provides flexibility and
vender neutrality.

89
The OpenFlow API is an example of a forwarding abstraction.

3.2.3. Distribution Abstraction:

• This abstraction arises in the context of distributed controllers. A
cooperating set of distributed controllers maintains a state
description of the network and routes through the networks. The
distributed state of the entire network may involve partitioned data
sets, with controller instances exchanging routing information, or a
replicated data set, so that the controllers must cooperate to maintain
a consistent view of the global network.
• This abstraction aims at hiding complex distributed mechanisms
(used today in many networks) and separating state management
from protocol design and implementation. It allows providing a
single coherent global view of the network through an annotated
network graph accessible for control via an API. An implementation
of such an abstraction is an NOS, such as open Daylight or Ryu.

3.2.4. Specification Abstraction:

The distribution abstraction provides a global view of the network as if there is a
single central controller, even if multiple cooperating controllers are used. The
specification abstraction then provides an abstract view of the global network.
This view provides just enough detail for the application to specify goals, such as
routing or security policy, without providing the information needed to implement
the goals.

The presentation by Shenker [SHEN11] summarizes these abstractions as

follows:
o Forwarding interface: An abstract forwarding model that
shields higher layers from forwarding hardware.
o Distribution interface: A global network view that shields
higher layers from state dissemination/collection.
o Specification interface: An abstract network view that shields
application program from details of physical network.
Network is a collection of interconnected SDN data plane switches. The
abstract view is a single virtual switch Shown in figure 3.4. The physical
network may consist of a single SDN domain. Ports on edge switches that
connect to other domains and to hosts are mapped into ports on the virtual
switch.

90
At the application level, a module can be executed to learn the media access
control (MAC) address of hosts. When a previously unknown host sends a
packet, the application module can associate that address with the input port
and direct future traffic direct to this host to this port. Similarly, if a packet
arrives at one of the virtual switch ports with an unknown destination
address, the module floods that packet to all output ports. The abstraction
layer translates these actions into actions on the entire physical network,
performing the internal forwarding with the domain.

Figure 3.4. Virtualization of a Switching Fabric for MAC Learning

3.2.5. Frenetic :
• An example of a network services abstraction layer is the
programming language Frenetic. Frenetic enables networks
operators to program the network as a whole instead of manually
configuring individual network elements.

91
• Frenetic was designed to solve challenges with the use of
OpenFlow based models by working with an abstraction at the
network level as opposed to OpenFlow, which directly goes down
to the network element level.
• Frenetic includes an embedded query language that provides
effective abstractions for reading network state. This language is
similar to SQL and includes segments for selecting, filtering,
splitting, merging and aggregating the streams of packets. Another
special feature of this language is that it enables the queries to be
composed with forwarding policies. A compiler produces the
control messages needed to query and tabulate the counters on
switches.
• Frenetic consists of two levels of abstraction, as illustrated in
Figure 3.5. Theupper level, which is the Frenetic source-level API,
provides a set of operators for manipulating streams of network
traffic. The query language provides means for reading the state of
the network, merging different queries, and expressing high-level
predicates for classifying, filtering, transforming, and aggregating
the packet streams traversing the network.
• The lower level of abstraction is provided by a run-time system that
operates in the SDN controller. It translates high-level policies and
queries into low level flow rules and then issues the needed
OpenFlow commands to install these rules on the switches.

Figure 3.4Frenetic Architecture

92
3.3 Traffic Engineering:
• Traffic engineering is a method for dynamically analyzing,
regulating, and predicting the behavior of data flowing in networks
with the aim of performance optimization to meet service level
agreements (SLAs).
• Traffic engineering involves establishing routing and forwarding
policies based on QoS requirements. With SDN, the task of traffic
engineering should be considerably simplified compared with a
nonSDN network. SDN offers a uniform global view of
heterogeneous equipment and powerful tools for configuring and
managing network switches.
• lists the following traffic engineering functions that have been
implemented as SDN applications:
o On-demand virtual private networks
o Load balancing
o Energy-aware routing
o Quality of service (QoS) for broadband access networks
o Scheduling/optimization
o Traffic engineering with minimal overhead
o Dynamic QoS routing for multimedia apps
o Fast recovery through fast-failover groups
o QoS policy management framework
o QoS enforcement
o QoS over heterogeneous networks
o Multiple packet schedulers
o Queue management for QoS enforcement
o Divide and spread forwarding tables

93
PolicyCop :
An instructive example of a traffic engineering SDN application is
PolicyCop [BARI13], which is an automated QoS policy enforcement
framework. It leverages the programmability offered by SDN and
OpenFlow for
• Dynamic traffic steering
• Flexible Flow level control
• Dynamic traffic classes
• Custom flow aggregation levels
Key features of PolicyCop are that it monitors the network to detect policy
violations (based on a QoS SLA) and reconfigures the network to reinforce
the violated policy.
As shown in Figure 3.6, Policy Cop consists of eleven software
modules and two databases, installed in both the application plane and the
control plane. policy Cop uses the control plane of SDNs to monitor the
compliance with QoS policies and can automatically adjust the control
plane rules and flow tables in the data plane based on the dynamic network
traffic statistics.
In the control plane, policy Cop relies on four modules and a database for
storing control rules, described as follows:
• Admission Control: Accepts or rejects requests from the resource
provisioning module for reserving network resources, such as
queues, flow-table entries, and capacity.
• Routing: Determines path availability based on the control rules in
the rule database.
• Device Tracker: Tracks the up/down status of network switches and
their ports.
• Statistics Collection: Uses a mix of passive and active monitoring
techniques to measure different network metrics.
Rule Database: The application plane translates high-level
networkwide policies to control rules and stores them in the rule database

94
 Figure 3.6. PolicyCop Architecture

A RESTful northbound interface connects these control plane

modules to the application plane modules, which are organized into two
components: a policy validator that monitors the network to detect policy
violations, and a policy enforcer that adapts control plane rules based on
network conditions and high-level policies. Both modules rely on a policy
database, which contains QoS policy rules entered by a network manager.
The modules are as follows:
• Traffic Monitor: Collects the active policies from policy
database, and determines appropriate monitoring interval,
network segments, and metrics to be monitored.
• Policy Checker: Checks for policy violations, using input
from the policy database and the Traffic Monitor.
• Event Handler: Examines violation events and, depending on
event type, either automatically invokes the policy enforcer or
sends an action request to the network manager.
• Topology Manager: Maintains a global view of the network,
based on input from the device tracker.
• Resource Manager: Keeps track of currently allocated
resources using admission control and statistics collection.

95
 • Policy Adaptation: Consists of a set of actions, one for each
type of policy violation. Table 3.1shows the general
functionality of some of the policy adaptation actions. The
actions are pluggable components that can be specified by the
network manager.

TABLE 3.1 Functionality of Some Example Policy AdaptationActions

(PAAs)
• Resource Provisioning: This module either allocates more resources
or releases existing ones or both based on the violation event.

Figure 3.7. shows the process workflow in PolicyCop.

Figure 3.7 PolicyCop Workflow

96
3.4. Measurement and Monitoring:
In Software-Defined Networking (SDN), measurement and monitoring
play a critical role in ensuring that the network operates efficiently,
providing insights into network performance, detecting anomalies, and
supporting network management tasks such as traffic optimization, fault
detection, and policy enforcement. Since SDN separates the control plane
from the data plane, these monitoring functions provide a way for the
controller to maintain an up-to-date and accurate view of the network state.

3.4.1. Key Aspects of Measurement and Monitoring in SDN:

1. Network State Collection:
o The SDN controller continuously collects and monitors data
from the data plane devices (such as switches, routers, or
other network elements) to gain visibility into the current
state of the network. This includes metrics like:
▪ Flow statistics (e.g., number of packets, bytes)
▪ Link status (up/down, utilization, bandwidth)
▪ Latency and delay
▪ Error rates (e.g., dropped packets, CRC errors)
▪ Topology information (e.g., switch ports, links)
2. Telemetry and Measurement Tools:
o SDN networks employ telemetry protocols and tools to gather
and send real-time data about the network state to the SDN
controller. Common telemetry methods include:
▪ OpenFlow Statistics: OpenFlow allows for the
collection of detailed statistics related to flows,
queues, and port counters. The SDN controller can
request these statistics from switches, such as flow
table statistics (packets, bytes, timeouts), port
statistics, and flow duration.
▪ NetFlow/IPFIX: These flow measurement protocols
provide information about traffic flows, which can
help identify traffic patterns and diagnose network
issues.
▪ SNMP (Simple Network Management Protocol):
Although traditionally used in legacy networks,
SNMP can still be employed to gather network
device status and performance metrics in SDN
environments.
97
 ▪sFlow: A sampling-based technology used to capture
network traffic, enabling the monitoring of flow
statistics across the network.
▪ Telemetry via gRPC or REST APIs: These
protocols enable the exchange of detailed
measurement data, allowing controllers to pull real-
time information from network elements.
3. Centralized vs. Distributed Monitoring:
o Centralized Monitoring: In a centralized SDN architecture,
the SDN controller collects and processes network data from
all devices in the network. This gives the controller a global
view of the network, allowing for centralized analytics and
decision-making.
o Distributed Monitoring: In a distributed SDN setup (with
multiple controllers), monitoring tasks might be delegated
across several controllers, each responsible for a part of the
network.
This approach helps in scaling network monitoring, reducing
the burden on a single controller, and enabling more
localized, efficient responses to network events.

3.4.2. Types of Measurements in SDN:

1. Traffic Monitoring:
o Flow monitoring: Track the flow of packets through the
network, including the number of flows, flow durations, and
flow statistics (e.g., byte and packet counts).
o Bandwidth utilization: Measure how much bandwidth is
being used at various points in the network (e.g., on switches
or links).
o Traffic volume analysis: Monitor the total traffic (in terms
of packets or bytes) flowing through the network or specific
paths. This helps in detecting congestion or abnormal traffic
patterns.
2. Link and Path Monitoring:
o Measure the health and performance of links (e.g.,
availability, latency, packet loss) and paths (e.g., the route
taken by packets). This data helps the controller make
routing decisions and optimize traffic flow.

98
 o Link failure detection: When a link goes down or
experiences high packet loss or latency, the SDN controller
can quickly reroute traffic around the failure.
3. Latency and Delay Measurement:
o Measure the time taken by packets to travel through the
network, both on a per-hop basis and end-to-end. o This
information is essential for applications requiring low latency
communication, like video conferencing, VoIP, or real-time
services.
4. Quality of Service (QoS) Monitoring:
o Monitor metrics like jitter, packet loss, and latency to ensure
that applications receive the required level of service. This
can help in ensuring that SLA (Service Level Agreements)
are met for critical applications.
5. Error Monitoring:
o Track the number of errors or failures occurring in the network,
such as dropped packets, CRC errors, or timeouts in flow
processing. This can help in identifying faulty network
elements or performance degradation.

6. Flow-Level Measurement:
o Flow creation and teardown: Track the creation,
management, and removal of flows in the SDN network.
This helps in understanding traffic patterns, such as how
long flows persist, how they evolve, and which applications
or devices generate traffic.
o Flow monitoring and enforcement: The SDN controller
can collect flow statistics to enforce traffic management
policies or make decisions about rerouting flows.

3.4.3. Techniques for Measurement and Monitoring:

1. Polling and Push Mechanisms:
o Polling: The controller periodically requests measurement
data from the network devices (e.g., switches and routers) to
get updates about the network state. This can be done using
OpenFlow’s statistics requests or other APIs.

99
 o Push Mechanism: Devices push measurement data to the
controller automatically, either periodically or when certain
thresholds are exceeded. This can reduce the load on the
controller since it does not have to make frequent requests.
2. Sampling:
o To avoid overwhelming the network with monitoring traffic,
sampling techniques like sFlow can be used. Here, a small
fraction of packets or flows are sampled and analyzed,
providing an approximation of the overall network state. o
Sampling allows for more scalable monitoring without
incurring significant overhead, though it may lose some
granularity in analysis.
3. Proactive vs. Reactive Monitoring:
o Proactive Monitoring: This involves continuous, real-time
collection and analysis of network data to detect anomalies
or potential failures before they impact the network. This is
more resource-intensive but can offer better predictive
insights.
o Reactive Monitoring: This approach collects data only after
a problem is detected or reported. It is more resource-
efficient but may result in slower responses to network
issues.
4. Anomaly Detection:
o Monitoring tools can be used to detect deviations from
normal traffic patterns (e.g., sudden spikes in traffic or
unusual flow behavior), which may indicate a network issue
or a security threat such as a DDoS attack. o Machine
learning-based techniques are increasingly used to identify
anomalies in traffic, which might be too subtle for traditional
rule-based monitoring systems.
3.4.4. Role of Monitoring in SDN Operations:
1. Network Optimization:
o By monitoring traffic and performance metrics, SDN
controllers can optimize the routing of traffic, balance loads,
and ensure that the network resources are used efficiently.
2. Fault Detection and Recovery:
o Real-time monitoring helps detect faults, such as device
failures or link outages.

100
 o The SDN controller can respond quickly to these issues by
rerouting traffic, reconfiguring the network, or triggering
alarms.
3. Security:
o Continuous monitoring can identify potential security
threats, such as abnormal traffic patterns (e.g., DDoS
attacks) or unauthorized network access. The SDN controller
can then take corrective actions, such as blocking suspicious
flows or isolating compromised devices.
4. Network Planning and Capacity Management:
o Performance and traffic metrics gathered from monitoring
help in capacity planning for future network growth.
Understanding traffic trends and utilization patterns allows
for informed decisions about hardware upgrades or network
topology changes.
5. Policy Enforcement:
o The SDN controller can use monitoring data to enforce
network policies (such as Quality of Service (QoS) or
Access Control Lists (ACLs)), ensuring that network
resources are allocated according to business priorities.
3.4.5. Challenges of Measurement and Monitoring in SDN:
1. Scalability:
o As SDN networks grow, the volume of monitoring data
increases, which can lead to challenges in data processing
and management. Distributed measurement techniques may
be needed to handle this scaling issue.
2. Data Overload:
o Continuous measurement and monitoring can generate vast
amounts of data, leading to performance issues if not
managed properly. Balancing granularity and frequency of
data collection is crucial.
3. Consistency and Synchronization:
o In distributed SDN setups, ensuring that measurement data is
synchronized across controllers is critical to avoid
inconsistencies that could lead to erroneous network
management decisions.
4. Privacy and Security:
o Monitoring involves collecting a wide range of data, which
may contain sensitive information.
101
 It is important to secure measurement data and ensure that only
authorized parties have access to it.

3.5. Security Open Day light DDoS Application :

3.5.1. Applications in this area have one of two goals:
o Address security concerns related to the use of SDN: SDN involves
a three-layer architecture (application, control, data) and new
approaches to distributed control and encapsulating data. All of this
introduces the potential for new vectors for attack. Threats can occur at
any of the three layers or in the communication between layers. SDN
applications are needed to provide for the secure use of SDN itself. o
Use the functionality of SDN to improve network security: Although
SDN presents new security challenges for network designers and
managers, it also provides a platform for implementing consistent,
centrally managed security policies and mechanisms for the network.
SDN allows the development of SDN security controllers and SDN
security applications that can provision and orchestrate security services
and mechanisms.
3.5.2. open Daylight DDoS Application:
• In 2014, Radware, a provider of application delivery and application
security solutions for virtual and cloud data centers, announced its
contribution to the open Daylight Project with Defense4All, an open
SDN security application integrated into open Daylight.
• Defense4All offers carriers and cloud providers distributed denial of
service (DDoS) detection and mitigation as a native network service.
Using the open Daylight SDN Controller that programs SDN-
enabled networks to become part of the DoS/DDoS protection
service itself, Defense4All enables operators to provision a
DoS/DDoS protection service per virtual network segment or per
customer.
• Defense4All uses a common technique for defending against DDoS
attacks, which consists of the following elements:
o Collection of traffic statistics and learning of statistics behavior
of protected objects during peacetime. The normal traffic
baselines of the protected objects are built from these collected
statistics.
o Detection of DDoS attack patterns as traffic anomalies deviating
from normal baselines.

102
 o Diversion of suspicious traffic from its normal path to attack
mitigation systems (AMSs) for traffic scrubbing, selective source
blockage, and so on. Clean traffic exiting out of scrubbing centers
is re-injected back into the packet’s original destination Figure 3.8
shows the overall context of the Defense4All application. The
underlying SDN network consists of a number of data plane
switches that support traffic among client and server devices.
Defense4All operates as an application that interacts with the
controller over an Open Daylight controller (ODC) northbound
API. Defense4All supports a user interface for network managers
that can either be a command line interface or a RESTful API.
Finally, Defense4All has an API to communicate with one or more
AMSs.

Figure 3.8 OpenDaylight DDoS Application

• Administrators can configure Defense4All to protect certain

networks and servers, known as protected networks (PNs) and
protected objects (POs).
• The application instructs the controller to install traffic counting
flows for each protocol of each configured PO in every network
location through which traffic of the subject PO flows.
• Defense4All then monitors traffic of all configured POs,
summarizing readings, rates, and averages from all relevant network
locations.
103
 • If it detects a deviation from normal learned traffic behavior in a
protocol (such as TCP, UDP, ICMP, or the rest of the traffic) of a
particular PO, Defense4All declares an attack against that protocol
in the subject PO. Specifically, Defese4All continuously calculates
traffic averages for real time traffic it measured using OpenFlow;
when real time traffic deviates by 80% from average then an attack
is assumed.

To mitigate a detected attack, Defense4All performs the following

procedure:

1. It validates that the AMS device is alive and selects a live connection to
it.
Currently, Defense4All is configured to work with Radware’s AMS, known
as DefensePro.
2. It configures the AMS with a security policy and normal rates of the
attacked traffic. This provides the AMS with the information needed to
enforce a mitigation policy until traffic returns to normal rates.
3. It starts monitoring and logging syslog’s arriving from the AMS for the
subject traffic. As long as Defense4All continues receiving syslog attack
notifications from the AMS regarding this attack, Defense4All continues to
divert traffic to the AMS, even if the flow counters for this PO do not
indicate any more attacks.
4. It maps the selected physical AMS connection to the relevant PO link.
This typically involves changing link definitions on a virtual network, using
OpenFlow.
5. It installs higher-priority flow table entries so that the attack traffic flow
is redirected to the AMS and re-injects traffic from the AMS back to the
normal traffic flow route. When Defense4All decides that the attack is over
(no attack indication from either flow table counters or from the AMS), it
reverts the previous actions: It stops monitoring for syslogs about the
subject traffic, it removes the traffic diversion flow table entries, and it
removes the security configuration from the AMS. Defense4All then
returns to peacetime monitoring.
• Figure 3.9 shows the principal software components of Defense4All.
The overall application structure, referred to as a framework,
contains the modules described in the list that follows
o Web (REST) Server: Interface to network manager. Framework
Main: Mechanism to start, stop, or reset the framework.
104
o Framework REST Service: Responds to user requests
received through the web (REST) server. o Framework
Management Point: Coordinates and invokes control and
configuration commands.
o Defense4All Application: Described subsequently.
o Common Classes and Utilities: A library of convenient
classes and utilities from which any framework or SDN
application module can benefit.
o Repository Services: One of the key elements in the
framework philosophy is decoupling the compute state from
the compute logic. All durable states are stored in a set of
repositories that can be then replicated, cached, and
distributed, with no awareness of the compute logic
(framework or application).
o Logging and Flight Recorder Services: The logging service
uses logs error, warning, trace, or informationalmessages.
These logs are mainly for Defense4All developers.
o The Flight Recorder records events and metrics during run time
o from Java applications.
o Health Tracker: Holds aggregated run-time indicators of the
operational health of Defense4All and acts in response to
severe functional or performance deteriorations.
o Cluster Manager: Responsible for managing coordination
with other Defense4All entities operating in a cluster mode.

105
 Figure 3.8 Defense4All Software Architecture Detail

• The Defense4All Application module consists of the following elements.

o DF App Root: The root module of the application.

DF Rest Service: Responds to Defense4All application REST requests.
o DF Management Point: The point to drive control and configuration
commands. DFMgmtPoint in turn invokes methods against other
relevant modules in the right order.
o ODL Reps: A pluggable module set for different versions of the ODC.
Comprises two functions in two submodules: stats collection for and
traffic diversion of relevant traffic.
o SDN Stats Collector: Responsible for setting “counters” for every PN
at specified network locations (physical or logical). A counter is a set of
OpenFlow flow entries in ODC-enabled network switches and routers.
The module periodically collects statistics from those counters and feeds
them to the SDNBasedDetectionMgr.

106
 o The module uses the SDNStatsCollectionRep to both set the
counters and read latest statistics from those counters. A stat report
consists of read time, counter specification, PN label, and a list of
trafficData information, where each traffic Data element contains the
latest bytes and packet values for flow entries configured for in the
counter location. The protocol can be {tcp,udp,icmp,other ip}, the port
is any Layer 4 port, and the direction can be {inbound, outbound}.
o SDN Based Detection Manager: A container for pluggable SDNbased
detectors. It feeds stat reports received from the SDNStatsCollector to
plugged-in SDN based detectors. It also feeds all SDN based detectors
notifications from the AttackDecisionPoint about ended attacks (so as to
allow reset of detection mechanisms). Each detector learns for each PN
its normal traffic behavior over time, and notifies
AttackDecisionPoint when it detects traffic anomalies.
o Attack Decision Point: Responsible for maintaining attack lifecycle,
from declaring a new attack, to terminating diversion when an attack is
considered over.
o Mitigation Manager: A container for pluggable mitigation drivers. It
maintains the lifecycle of each mitigation being executed by an AMS.
Each mitigation driver is responsible for driving attack mitigations using
AMSs in their sphere of management.
AMS Based Detector: This module is responsible for
monitoring/querying attack mitigation by AMSs.
o AMS Rep: Controls the interface to AMSs.
• Figure 3.10. suggests the complexity of even a relatively straightforward SDN
application. Finally, it is worth noting that Radware has developed a
commercial version of Defese4All, named DefenseFlow. DefenseFlow
implements more sophisticated algorithms for attack detection based on fuzzy
logic.
• The main benefit is that DefenseFlow has a greater ability to distinguish attack
traffic from abnormal but legitimate high volume of traffic.

3.6. Data Center Networking:

• So far, we’ve discussed three areas of SDN applications: traffic engineering,
measurement and monitoring, and security.
• The provided examples of these applications suggest the broad range of use
cases for them, in many different kinds of networks.

107
• The remaining three applications areas (data center networking, mobility and
wireless, and information-centric networking) have use cases in specific types
of networks.
• Cloud computing, big data, large enterprise networks, and even in many cases,
smaller enterprise networks, depend strongly on highly scalable and efficient
data centers.
• lists the following as key requirements for data centers: high and flexible cross-
section bandwidth and low latency, QoS based on the application requirements,
high levels of resilience, intelligent resource utilization to reduce energy
consumption and improve overall efficiency, and agility in provisioning
network resources (for example, by means of network virtualization and
orchestration with computing and storage).
• With traditional network architectures, many of these requirements are difficult
to satisfy because of the complexity and inflexibility of the network. SDN offers
the promise of substantial improvement in the ability to rapidly modify data
center network configurations, to flexibly respond to user needs, and to ensure
efficient operation of the network. The remainder of this subsection, examines
two example data center SDN applications.

108
3.6. 1. Big Data over SDN:

• To use SDN to optimize data center networking for big data applications. The
approach leverages the capabilities of SDN to provide application-aware
networking. It also exploits characteristics of structured big data applications as
well as recent trends in dynamically reconfigurable optical circuits. With
respect to structured big data applications, many of these applications process
data according to well defined computation patterns, and also have a centralized
management structure that makes it possible to leverage application-level
information to optimize the network.
• That is, knowing the anticipated computation patterns of the big data
application, it is possible to intelligently deploy the data across the big data
servers and, more significantly, react to changing application patterns by using
SDN to reconfigure flows in the network.
• Compared to electronic switches, optical switches have the advantages of
greater data rates with reduced cabling complexity and energy consumption.
• A number of projects have demonstrated how to collect network-level traffic
data and intelligently allocate optical circuits between endpoints (for example,
top-of-rack switches) to improve application performance. • However, circuit
utilization and application performance can be inadequate unless there is a true
application-level view of traffic demands and dependencies. Combining an
understanding of the big data computation patterns with the dynamic
capabilities of SDN, efficient data center networking configurations can be used
to support the increasing big data demands.
• Figure 3.11 shows a simple hybrid electrical and optical data center network,
in which OpenFlow-enabled top-of-rack (ToR) switches are connected to two
aggregation switches: an Ethernet switch and an optical circuit switch (OCS).
• All the switches are controlled by a SDN controller that manages physical
connectivity among ToR switches over optical circuits by configuring the
optical switch.
It can also manage the forwarding at ToR switches using OpenFlow rules.
o The SDN controller is also connected to the Hadoop scheduler, which
forms queues of jobs to be scheduled and the HBase Master controller
of a relational database holding data for the big data applications.
o In addition, the SDN controller connects to a Mesos cluster manager.
Mesos is an open-source software package that provides scheduling and
resource allocation services across distributed applications.

109
 Figure 3.11. Integrated Network Control for Big Data Applications
[WANG12]
• The SDN controller makes available network topology and traffic information
to the Mesos cluster manager. In turn, the SDN controller accepts traffic demand
request from Mesos managers.

3.6.2. Cloud Networking over SDN:

• Cloud Network as a Service (CloudNaaS) is a cloud networking system that

exploits OpenFlow SDN capabilities to provide a greater degree of control over
cloud network functions by the cloud customer CloudNaaS enables users to
deploy applications that include a number of network functions, such as virtual
network isolation, custom addressing, service differentiation, and flexible
interposition of various middle boxes.
CloudNaaS primitives are directly implemented within the cloud infrastructure
itself using high-speed programmable network elements, making CloudNaaS
highly efficient.
• Figure 3.12 illustrates the principal sequence of events in the CloudNaaS
operation, as described in the list that follows.
o A cloud customer uses a simple policy language to specify network
services required by the customer applications. These policy
statements are issued to a cloud controller server operated by the
cloud service provider.
o The cloud controller maps the network policy into a communication
matrix that defines desired communication patterns and network
services.

110
 The matrix is used to determine the optimal placement of virtual
machines (VMs) on cloud servers such that the cloud can satisfy the
largest number of global policies in an efficient manner. This is done
based on the knowledge of other customers’ requirements and their
current levels of activity.
o The logical communication matrix is translated into network-level
directives for data plane forwarding elements. The customer’s VM
instances are deployed by creating and placing the specified number
of VMs. o The network-level directives are installed into the
network devices via OpenFlow.

Figure 3.12 Various Steps in the CloudNaaS Framework

The abstract network model seen by the customer consists of VMs and virtual
network segments that connect VMs together. Policy language constructs
identify the set of VMs that comprise an application and define various
functions and capabilities attached to virtual network segments.
• The main constructs are as follows:
o Address: Specify a customer-visible custom address for a VM.
o Group: Create a logical group of one or more VMs. Grouping VMs with
similar functions makes it possible for modifications to apply across the
entire group without requiring changing the service attached to individual
VMs.
o Middle box: Name and initialize a new virtual middle box by specifying its
type and a configuration file. The list of available middle boxes and their
configuration syntax is supplied by the cloud provider.

111
o Examples include intrusion detection and audit compliance systems. o
Network service: Specify capabilities to attach to a virtual network
segment, such as Layer 2 broadcast domain, link QoS, and list of
middleboxes that must be traversed. o virtual net: Virtual network
segments connect groups of VMs and are associated with network services.
A virtual network can span one or two groups. With a single group, the
service applies to traffic between all pairs of VMs in the group. With a pair
of groups, the service is applied between any VM in the first group and any
VM in the second group. Virtual networks can also connect to some
predefined groups, such as EXTERNAL, which indicates all endpoints
outside of the cloud.
Figure 3.13 provides an overview of the architecture of CloudNaaS. Its two
main components are a cloud controller and a network controller. The cloud
controller provides a base Infrastructure as a Service (IaaS) service for
managing VM instances.
• The user can communicate standard IaaS requests, such as setting up
VMs and storage. In addition, the network policy constructs enable the user to
define the virtual network capabilities for the VMs.
• The cloud controller manages a software programmable virtual switch
on each physical server in the cloud that supports network services for tenant
applications, including the management of the user-defined virtual network
segments. The cloud controller constructs the communication matrix and
transmits this to the network controller.
o The network controller uses the communication matrix to configure data
plane physical and virtual switches. It generates virtual networks between
VMs and provides VM placement directives to the cloud controller. It
monitors the traffic and performance on the cloud data plane switches and
makes changes to the network state as needed to optimize use of resources
to meet tenant requirements.
o The controller invokes the placement optimizer to determine the best
location to place VMs within the cloud (and reports it to the cloud
controller for provisioning). The controller then uses the network
provisionary module to generate the set of configuration commands for
each of the programmable devices in the network and configures them
accordingly to instantiate the tenant’s virtual network segment

112
 Figure .13 CloudNaaS Architecture

Part –A
[Link] is Abstraction Layer?
An abstraction layer is a mechanism that translates a high-level request into
the low-level commands required to perform the request. An API is one such
mechanism. It shields the implementation details of a lower level of abstraction from
software at a higher level.
[Link] Services Abstraction Layer.
RFC 7426 defines a network services abstraction layer between the control
and application planes and describes it as a layer that provides service abstractions
that can be used by applications and services.
3. What are the functional concepts of Network Services Abstraction Layer?
Several functional concepts are suggested by the placement of this layer in the
SD architecture:
o This layer could provide an abstract view of network resources that hides the
details of the underlying data plane devices.
o This layer could provide a generalized view of control plane functionality, so
that applications could be written that would operate across a range of
controller network operating systems.
113
 o This functionality is similar to that of a hypervisor or virtual machine monitor
that decouples applications from the underlying OS and underlying hardware.
This layer could provide a network virtualization capability that allows
different views of the underlying data plane infrastructure. Arguably, the
network services abstraction layer could be considered to be part of the
northbound interface, with the functionality incorporated in the control plane
or the application plane. A wide range of schemes have been developed that
roughly fall into this layer, and a full treatment is beyond our scope.
[Link] SDN Application Plane.
The application plane contains applications and services that define,
monitor,and control network resources and behavior. These applications interact
with the SDN control plane via application-control interfaces, for the SDN control
layer to automatically customize the behavior and the properties of network
resources.
The programming of an SDN application makes use of the abstracted view of
network resources provided by the SDN control layerby means of information and
data models exposed via the application control interface.
[Link] are types of Abstraction in SDN?
▪ Forwarding Abstraction
▪ Distribution Abstraction
▪ Specification Abstraction
[Link] forwarding abstraction.
The forwarding abstraction allows a control program to specify data plane
forwarding behavior while hiding details of the underlying switching hardware.
This abstraction supports the data plane forwarding function. By abstracting away
from the forwarding hardware, it provides flexibility and vender neutrality.
7. Define Distribution Abstraction.
This abstraction arises in the context of distributed controllers. A
cooperating set of distributed controllers maintains a state description of the
network and routes through the networks. The distributed state of the entire network
may involve partitioned data sets, with controller instances exchanging routing
information, or a replicated data set, so that the controllers must cooperate to
maintain a consistent view of the global network.

114
 [Link] Specification Abstraction.
The distribution abstraction provides a global view of the network as if
there is a single central controller, even if multiple cooperating controllers are
used. The specification abstraction then provides an abstract view of the global
network.
[Link] Frenetic.
Frenetic enables networks operators to program the network as a whole
instead of manually configuring individual network elements. Frenetic was
designed to solve challenges with the use of OpenFlow-based models by working
with an abstraction at the network level as opposed to OpenFlow, which directly
goes down to the network element level.
10. What is Traffic engineering?
Traffic engineering is a method for dynamically analyzing, regulating, and
predicting the behavior of data flowing in networks with the aim of performance
optimization to meet service level agreements (SLAs). Traffic engineering involves
establishing routing and forwarding policies based on QoS requirements. With SDN,
the task of traffic engineering should be considerably simplified compared with a
non-SDN network.
[Link] Out the traffic engineering functions that have been implemented as
SDN applications.
lists the following traffic engineering functions that have been
implemented as SDN applications:
• On-demand virtual private networks
• Load balancing
• Energy-aware routing
• Quality of service (QoS) for broadband access networks
• Scheduling/optimization
• Traffic engineering with minimal overhead
• Dynamic QoS routing for multimedia apps
• Fast recovery through fast-failover groups
• QoS policy management framework
• QoS enforcement
• QoS over heterogeneous networks
• Multiple packet schedulers
• Queue management for QoS enforcement
• Divide and spread forwarding tables

115
 [Link] PolicyCop and write down the key features of PolicyCop. An
instructive example of a traffic engineering SDN application is PolicyCop [BARI13],
which is an automated QoS policy enforcement framework. It leverages the
programmability offered by SDN and OpenFlow for
• Dynamic traffic steering
• Flexible Flow level control
• Dynamic traffic classes
• Custom flow aggregation levels
Key features of PolicyCop are that it monitors the network to detect policy
violations (based on a QoS SLA) and reconfigures the network to reinforce the
violated policy.
13. What are the PolicyCop relies on four modules? and write down the
database for storing control rules?
PolicyCop relies on four modules and a database for storing control rule,
described as follows:
• Admission Control: Accepts or rejects requests from the resource
provisioning module for reserving network resources, such as queues,
flow-table entries, and capacity.
• Routing: Determines path availability based on the control rules in the
rule database.
• Device Tracker: Tracks the up/down status of network switches and
their ports.
• Statistics Collection: Uses a mix of passive and active monitoring
techniques to measure different network metrics.
• Rule Database: The application plane translates high-level networkwide
policies to control rules and stores them in the rule database.
14. Explain about Measurement and Monitoring.
The area of measurement and monitoring applications can roughly be divided
into two categories:
• applications that provide new functionality for other networking
services
• applications that add value to OpenFlowbasedSDNs.

116
15. Write Down the Functionality of Some Example Policy Adaptation Actions
(PAAs).

16. What are the two goals in security?

Applications in this area have one of two goals:
• Address security concerns related to the use of SDN:
SDN involves a three-layer architecture (application, control, data) and new approaches
to distributed control and encapsulating data.
• Use the functionality of SDN to improve network security: Although
SDN presents new security challenges for network designers and managers,
it also provides a platform for implementing consistent, centrally managed
security policies and mechanisms for the network.
What are the techniques used against DDoS attacks?
Defense4All uses a common technique for defending against DDoS attacks, which
consists of the following elements:
• Collection of traffic statistics and learning of statistics behavior of protected
objects during peacetime. The normal traffic baselines other protected
objects are built from these collected statistics.
• Detection of DDoS attack patterns as traffic anomalies deviating from
normal baselines.
• Diversion of suspicious traffic from its normal path to attack mitigation
systems (AMSs) for traffic scrubbing, selective source blockage, and so on.
Clean traffic exiting out of scrubbing centers isre-injected back into the
packet’s original destination.
[Link] Repository Services.
One of the key elements in the framework philosophy is decoupling the
compute state from the compute logic. All durable states are stored in a set of
repositories that can be then replicated, cached, and distributed, with no
awareness of the compute logic (framework or application).

117
19. What is Logging and Flight Recorder Services?
The logging service uses logs error, warning, trace, or informational
messages. These logs are mainly for Defense4All developers. The Flight Recorder
records events and metrics during run time from Java applications.
[Link] down the Defense4All Application module elements.
The Defense4All Application module consists of the following elements.
• DF App Root
• DF Rest Service
• DF Management Point
• ODL Reps
• SDN Stats Collector
• SDN Based Detection Manager
• Attack Decision Point
• Mitigation Manager
• AMS Based Detector
• AMS Rep
[Link] SDN Based Detection Manager.
A container for pluggable SD based detectors. It feeds stat reports received
from the SDNStatsCollector to plugged-in SDN based detectors. It also feeds all
SDN based detectors notifications from the AttackDecisionPoint about ended
attacks (so as to allow reset of detection mechanisms). Each detector learns for each
PN its normal traffic behavior over time, and notifies AttackDecisionPoint when it
detects traffic anomalies.
22. Define Mitigation Manager.
A container for pluggable mitigation drivers. It maintains the lifecycle of
each mitigation being executed by an AMS. Each mitigation driver is responsible
for driving attack mitigations using AMSs in their sphere of management.
[Link] is SDN Stats Collector?
Responsible for setting “counters” for every PN at specified network
locations (physical or logical). A counter is a set of OpenFlow flow entries in ODC-
enabled network switches and routers. The module periodically collects statistics
from those counters and feeds them to the SDNBasedDetectionMgr. The module
uses theSDNStatsCollectionRep to both set the counters and read latest statistics
from those counters. A stat report consists of read time, counter specification, PN
label, and a list of traffic Data information, where each traffic Data element contains
the latest bytes and packet values for flow entries configured for
<protocol,port,direction> in the counter location.
The protocol can be {tcp,udp,icmp,otherip}, the port is any Layer 4 port, and
the direction can be {inbound, outbound}.
118
24. Define various functions and capabilities attached to virtual network
segments.
The main constructs are as follows:
• address: Specify a customer-visible custom address for a VM.
• group: Create a logical group of one or more VMs. Grouping VMs
with similar functions makes it possible for modifications to apply
across the entire group without requiring changing the service attached
to individual VMs.
• Middle box: Name and initialize a new virtual middlebox by
specifying its type and a configuration file. The list of available
middleboxes and their configuration syntax is supplied by the cloud
provider. Examples include intrusion detection and audit compliance
systems.
• Network service: Specify capabilities to attach to a virtual network
segment, such as Layer 2 broadcast domain, link QoS, and list of
middleboxes that must be traversed.
• Virtual net: Virtual network segments connect groups of VMs and are
associated with network services.
25. Write Down the Various Steps in the Cloud NaaS Framework.
• Specify User Requirements
• Convert Requirements into communication matrix
• Translate matrix entries into network level Rules
• Install rules and Configure paths
PART –B
1. Explain about Network Services Abstraction Layer.
2. Explain the details about Traffic Engineering.
3. Explain the details about the Security Open Day light DDoS
Application.
4. Explain the details about the Data Center Networking.
5. Explain about Measurement and Monitoring

119
***************

120
 UNIT IV
NETWORK FUNCTION VIRTUALIZATION

Network Virtualization - Virtual LANs – OpenFlow VLAN Support - NFV

Concepts – Benefits and Requirements – Reference Architecture
4.1. Network Virtualization:
Mechanisms for defining virtual networks have been in use for many years.
Virtual networks have two important benefits:
• They enable the user to construct and manage networks independent of the
underlying physical network and with assurance of isolation from other
virtual networks using the same physical network.
• They enable network providers to efficiently use network resources to
support a wide range of user requirements.

The chapter begins with a discussion of two well-established and widely used virtual
network techniques: virtual LANs (VLANs) and virtual private networks (VPNs).
The chapter then introduces the more general and broader concept of network
virtualization. After exploring a simple example, you will learn about the network
virtualization architecture and the benefits of this approach. The chapter also looks
at OpenDaylight’s Virtual Tenant Network, which is a VLAN-based capability, but
which exhibits many of the features of network virtualization. Finally, the chapter
introduces the concept of software-defined infrastructure, which encompasses many
of the concepts of software-defined network (SDN), network functions
virtualization (NFV), and network virtualization.
This section looks at the important area of network virtualization. One
immediate difficulty is that this term is defined differently in a number of academic
and industry publications. So we begin by defining some terms, based on definitions
in ITU-T Y.3011 (Framework of Network Virtualization for Future Networks,
January 2012):
• Physical resource: In the context of networking, physical resources include
the following: network devices, such as routers, switches, and firewalls; and
communication links, including wire and wireless. Hosts such as cloud
servers may also be considered as physical network resources.
• Logical resource: An independently manageable partition of a physical
resource, which inherits the same characteristics as the physical resource and
whose capability is bound to the capability of the physical resource. An
example is a named partition of disk memory.

121
 • Virtual resource: An abstraction of a physical or logical resource, which
may have different characteristics from the physical or logical resource and
whose capability may be not bound to the capability of the physical or
logical resource. As examples, virtual machines (VMs)may be moved
dynamically, VPN topologies can be altered dynamically, and access control
restrictions may be imposed on a resource.
• Virtual network: A network composed of multiple virtual resources (that
is, a collection of virtual nodes and virtual links) that is logically isolated
from other virtual networks. Y.3011 refers to a virtual network as a logically
isolated network partition (LINP).
• Network virtualization (NV): A technology that enables the creation of
logically isolated virtual networks over shared physical networks so that
heterogeneous collections of multiple virtual networks can simultaneously
coexist over the shared physical networks. This includes the aggregation of
multiple resources in a provider and appearing as a single resource.
NV is a far broader concept than VPNs, which only provide traffic isolation, or
VLANs, which provide a basic form of topology management. NV implies full
administrative control for customizing virtual networks both in terms of the physical
resources used and the functionalities provided by the virtual networks. The virtual
network presents an abstracted network view whose virtual resources provide users
with services similar to those provided by physical networks. Because the virtual
resources are software defined, the manager or administrator of a virtual network
potentially has a great deal of flexibility in altering topologies, moving resources,
and changing the properties and service of various resources. In addition, virtual
network users can include not only users of services or applications but also service
providers. For example, a cloud service provider can quickly add new services or
expanded coverage by leasing virtual networks as needed.
[Link] Virtualization Architecture :
An excellent overview of the many elements that contribute to an NV environment
is provided by the conceptual architecture defined in Y.3011and shown in Figure
4.1. The architecture depicts NV as consisting of four levels:

122
Figure 4.1 Conceptual Architecture of Network Virtualization (Y.3011)
• Physical resources
• Virtual resources
• Virtual networks
• Services
A single physical resource can be shared among multiple virtual resources. In turn,
each LINP (virtual network) consists of multiple virtual resources and provides a
set of services to users. Various management and control functions are performed at
each level, not necessarily by the same provider. There are management functions
associated with each physical network and its associated resources. A virtual
resource manager (VRM) manages a pool of virtual resources created from the
physical resources. A VRM interacts with physical network managers (PNMs) to
obtain resource commitments. The VRM constructs LINPs, and an LINP manager
is allocated to each LINP. Figure 4.2 provides another view of the NV architectural
elements. Physical resource management manages physical resources and may
create multiple logical resources that have the same characteristics as physical
resources. Physical and logical resources are available to the virtual resource
management at the interface between physical and virtual layers.

123
 The virtual resource management abstracts from the physical and logical
resources to create virtual resources. It can also construct a virtual resource that
combines other virtual resources. Virtual network management can build VNs on
multiple virtual resources that are provided by the virtual resource management.
Once a VN is created, the VN management starts to manage its own VN.

FIGURE 4.2Network Virtualization Resource Hierarchical Model

4.1.2. Types of Network Virtualization:
Network virtualization assumes different forms, each targeting a specific application or
occasion. Here are the main types of network virtualization:
• Software-Defined Networking (SDN): SDN is the form of network
virtualization which is a separation of the control and data plane (control plane
makes decisions as to where to send traffic, and data plane sends the traffic).
This division creates a viable opportunity for more centralized and
programmable network administration.
• Virtual LANs (VLANs): VLANs (Virtual Local Area Networks) represent
a way to provide virtualization of a network, which separates a physical network
to different logical ones. This segmentation process facilitates blocking and
translation and boosts network performance through division of the devices into
different broadcast domains.

124
• Virtual Routing and Forwarding (VRF): VRF creates an environment
wherein multiple instances of a routing table can be created within a single
router, which allows the router to host multiple virtual routers as required. This
is, for example, used for network isolation in service provider environments.
• Network Function Virtualization (NFV): NFV is about virtualizing network
services that we have always used in hardware dedicated to them, such as
firewalls, load balancers, and intrusion detection units. NFV, instead of relying
on hardware to operate the functions, utilizes software executed on virtualized
infrastructure to achieve flexibility and hardware independence.
• Overlay Networks: The virtual networks which are overlayed on the physical
infrastructure, are the logical networks that are created, which provide the
functionality to develop independent virtual networks that are not inter-
dependent with hardware. The technologies such as VXLAN Virtual Extensible
LAN or GRE Generic Routing Encapsulation are widely used as a overlay
virtualization.
• Virtual Private Networks (VPNs): VPNs is a way to secure users or networks
connecting through the internet. Encryption and tunneling protocols give an
ability to make virtual the network, thus creating networks of private and secure
communication channels.
• Multiprotocol Label Switching (MPLS): MPLS is a protocol applied in
telecommunications networks to make the data directed from one network node
to the next on the basis the labels which are not IP addresses. This promotes the
productivity of data transmission and provides the possibility of logical
switching paths within the network.
4.1.3. Benefits of Network Virtualization:
A 2014 survey [SDNC14] by SDxCentral of 220 organizations, including
network service providers, small and medium-size businesses (SMB), large
enterprises, and cloud service providers, reported the following benefits of NV
• Flexibility: NV enables the network to be quickly moved, provisioned, and
scaled to meet the ever-changing needs of virtualized compute and storage
infrastructures.
• Operational cost savings: Virtualization of the infrastructure streamlines the
operational processes and equipment used to manage the network.
• Similarly, base software can be unified and more easily supported, with a single
unified infrastructure to manage services. This unified infrastructure also allows
for automation and orchestration within and between different services and
components.
•

125
• From a single set of management components, administrators can coordinate
resource availability and automate the procedures necessary to make services
available, reducing the need for human operators to manage the process and
reducing the potential for error.
• Agility: Modifications to the network ‘s topology or how traffic is handled can
be tried in different ways, without needing to modify the existing physical
networks.
• Scalability: A virtual network can be rapidly scaled to respond to shifting
demands by adding or removing physical resources from the pool of available
resources.
• Capital cost savings: A virtualized deployment can reduce the number of
devices needed, providing capital as well as operational costs savings.
• Rapid service provisioning/time to market: Physical resources can be
allocated to virtual networks on demand, so that within an enterprise resource
can be quickly shifted as demand by different users or applications changes.
From a user perspective, resources can be acquired and released to minimize
utilization demand on the system. New services require minimal training and
can be deployed with minimal disruption to the network infrastructure.
• Equipment consolidation: NV enables the more efficient use of network
resources, thus allowing for consolidating equipment purchases to fewer, more
off-the-shelf products.
4.1.4. Network Virtualization Example :
VMware NSX: VMware NSX is a leading network virtualization platform which
allows building virtual networks, switches and routers. It is hardware independent and
due to this fact; it enables flexibility and security.
• Microsoft Hyper-V Network Virtualization: The Network
Virtualization feature of Microsoft's Hyper-V platform allows for the creation of
private virtual networks, making multi-tenancy and migrations of virtual
machines much easier across different physical networks.
• Cisco ACI (Application Centric Infrastructure): Cisco ACI uses the
principles of network virtualization and a policy-driven networking approach.
It provides an automatic setting up and managing of network resources that
eventually leads to better performance and less manual setups.
• OpenStack Neutron: Neutron is an open-source networking project which
abstracts the network as a service. It provides users with a capability to create
and manage virtualized networks in a virtual environment with support for both
conventional and software-defined networking.

126
• Juniper Contrail Networking: Juniper Contrail Networking is a solution that
uses network virtualization and SDN. It automates service provisioning and
networking on a scalable basis for cloud environments.
• Docker Networking: Docker (a container platform) deploys network
virtualization to create isolated networking environments for the containerized
applications. Docker networking facilitates convenient communication between
containers.
4. 2. Virtual LANs :
Figure 4.3 shows a relatively common type of hierarchical LAN configuration. In
this example, the devices on the LAN are organized into four segments, each served
by a LAN switch. The LAN switch is a store and- forward packet-forwarding device
used to interconnect a number of end systems to form a LAN segment.
• The switch can forward a media access control (MAC) frame from a source-
attached device to a destination attached device. It can also broadcast a frame
from a source-attached device to all other attached devices. Multiples switches
can be interconnected so that multiple LAN segments form a larger LAN. A
LAN switch can also connect to a transmission link or a router or other network
device to provide connectivity to the Internet or other WANs.

Figure 4.3 A LAN Configuration

127
• Traditionally, a LAN switch operated exclusively at the MAC level.
Contemporary LAN switches generally provide greater functionality, including
multilayer awareness (Layers 3, 4, application), quality of service (QoS)
support, and turning for wide-area networking.
• The three lower groups in Figure 4.3 might correspond to different
departments, which are physically separated, and the upper group could
correspond to a centralized server farm that is used by all the departments.
Consider the transmission of a single MAC frame from workstation X. Suppose
the destination MAC address in the frame is workstation Y. This frame is
transmitted from X to the local switch, which then directs the frame along the
link to Y.
If X transmits a frame addressed to Z or W, its local switch forwards the MAC
frame through the appropriate switches to the intended destination. All these are
examples of unicast addressing, in which the destination address in the MAC
frame designates a unique destination.
• A MAC frame may also contain a broadcast address, in which case the
destination MAC address indicates that all devices on the LAN should receive
a copy of the frame. Thus, if X transmits a frame with a broadcast destination
address, all the devices on all the switches in Figure 4.3receive a copy of the
frame. The total collection of devices that receive broadcast frames from each
other is referred to as a broadcast domain.
• In many situations, a broadcast frame is used for a purpose, such as network
management or the transmission of some type of alert, with a relatively local
significance. Thus, in Figure 4.3, if a broadcast frame has information that is
useful only to a particular department, transmission capacity is wasted on the
other portions of the LAN and on the other switches.
• One simple approach to improving efficiency is to physically partition the LAN
into separate broadcast domains, as shown in Figure 4.3. We now have four
separate LANs connected by a router. In this case, a broadcast frame from X is
transmitted only to the other devices directly connected to the same switch as
X. An IP packet from X intended for Z is handled as follows.
• The IP layer at X determines that the next hop to the destination is via router V.
This information is handed down to X’s MAC layer, which prepares a MAC
frame with a destination MAC address of router V. When V receives the frame,
it strips off the MAC header, determines the destination, and encapsulates the
IP packet in a MAC frame with a destination MAC address of Z. This frame is
then sent to the appropriate Ethernet switch for delivery.

128
 • The drawback to this approach is that the traffic pattern may not correspond to
the physical distribution of devices. For example, some departmental
workstations may generate a lot of traffic with one of the central servers.
• Further, as the networks expand, more routers are needed to separate users into
broadcast domains and provide connectivity among broadcast domains.
Routers introduce more latency than switches because the router must process
more of the packet to determine destinations and route the data tothe appropriate
end node.

Figure 4.4 A Partitioned LAN

4.2.1. The Use of Virtual LANs:

• A more effective alternative is the creation of VLANs. In essence, a virtual
local-area network (VLAN) is a logical subgroup within a LAN that is created
by software rather than by physically moving and separating devices.
It combines user stations and network devices into a single broadcast domain
regardless of the physical LAN segment they are attached to and allows traffic
to flow more efficiently within populations of mutual interest. The VLAN
logic is implemented in LAN switches and functions at the MAC layer.
129
• Because the objective is to isolate traffic within the VLAN, a router isrequired
to link from one VLAN to another. Routers can be implemented as separate
devices, so that traffic from one VLAN to another is directed to a router, or the
router logic can be implemented as part of the LAN switch, as shown in Figure
4.4.

Figure 4.5 A VLAN Configuration

• VLANs enable any organization to be physically dispersed throughout the
company while maintaining its group identity.
For example, accounting personnel can be located on the shop floor,
in the research and development center, in the cash disbursement
office, and in the corporate offices, while all members reside on the
same virtual network, sharing traffic only with each other.
• Figure 4.5 shows five defined VLANs. A transmission from workstation Xto
server Z is within the same VLAN, so it is efficiently switched at the MAC
level. A broadcast MAC frame from X is transmitted to all devices in all
portions of the same VLAN.

130
 • But a transmission from X to printer Y goes from one VLAN to another.
Accordingly, router logic at the IP level isrequired to move the IP packet from
X to Y.
• Figure 4.5 shows that logic integrated into the switch, so that the switch
determines whether the incoming MAC frame is destined for another
device on the same VLAN. If not, the switch routes the enclosed IP
packet at the IP level.
4.2.2. Defining VLANs:
A VLAN is a broadcast domain consisting of a group of end stations, perhaps on
multiple physical LAN segments, that are not constrained by their physical location
and can communicate as if they were on a common LAN. Some means is therefore
needed for defining VLAN membership. A number of different approaches have been
used for defining membership, including the following:
Membership by MAC address: Because MAC layer addresses are hardwired into
the workstation’s network interface card (NIC), VLANs based on MAC addresses
enable network managers to move a workstation to a different physical location on
the network and have that workstation automatically retain its VLAN membership.
• The main problem with this method is that VLAN membership must
be assigned initially. In networks with thousands of users, this is no
easy task. Also, in environments where notebook PCs are used, the
MA notebook PC. Consequently, when a notebook PC is moved to a
different docking station, its VLAN membership must be
reconfigured.
• Membership based on protocol information: VLAN membership
can be assigned based on IP address, transport protocol information,
or even higher-layer protocol information. This is a quite flexible
approach, but it does require switches to examine portions of the
MAC frame above the MAC layer, which may have a performance
impact.

4.2.3. Communicating VLAN Membership:

Switches must have a way of understanding VLAN membership (that
is, which stations belong to which VLAN) when network traffic arrives from
other switches; otherwise, VLANs would be limited to a single switch. One
possibility is to configure the information manually or with some type of
network management signaling protocol, so that switches can associate
incoming frames with the appropriate VLAN.

131
 A more common approach is frame tagging, in which a header is
typically inserted into each frame on inters witch trunks to uniquely identify
to which LAN a particular MAC-layer frame belongs.
4.3. OpenFlow VLAN Support:
OpenFlow is a protocol used in software-defined networking (SDN) that
allows for the direct control and management of network traffic flows by
separating the control plane (decision-making) from the data plane (traffic
forwarding). It provides a standardized way for network controllers to
communicate with network devices (like switches and routers).
When it comes to VLAN support in OpenFlow, it is essential to understand
how VLANs are used in networking and how OpenFlow handles them.
4.3.1. VLAN in Networking:
A VLAN (Virtual Local Area Network) is a logical grouping of devices in a
network, regardless of their physical location.
VLANs are used to segment network traffic, improve security, and manage
broadcast domains more effectively. Each VLAN is typically identified by a
unique ID (VLAN ID) that ranges from 1 to 4095.
4.3.2. OpenFlow and VLANs:
In OpenFlow, the VLAN ID is an important parameter that can be used to
direct traffic in a specific way. OpenFlow allows the controller to configure
switches to handle VLANs dynamically by setting rules for forwarding
traffic based on the VLAN tag. Here's how VLAN support works in
OpenFlow:
1. VLAN Matching:
OpenFlow switches can match VLAN tags in packet headers to apply rules.
The switch can inspect the Ethernet frame's VLAN ID and take appropriate
actions based on flow table entries configured by the SDN controller.
• The VLAN ID can be used as a field for matching packets. This means
that OpenFlow can filter and forward traffic based on which VLAN the
traffic belongs to.
• If a packet has a VLAN tag, the OpenFlow switch will match it to the
flow entries that include the VLAN ID field.
2. VLAN Actions:
Once a match is made, OpenFlow switches can apply actions such as:
• Forwarding the packet to specific ports or queues based on VLAN
rules.
• Modifying the VLAN tag in a packet (this is known as VLAN
translation), for example, changing the VLAN ID to direct traffic to a
different logical network.
132
 • Pushing or popping VLAN tags. OpenFlow can add (push) a VLAN
tag to a packet or remove (pop) an existing VLAN tag, allowing
dynamic adjustment of VLAN membership as packets traverse the
network.
3. VLAN Tagging in OpenFlow Rules:
OpenFlow flow rules that deal with VLANs can specify actions such as:
• Set-VLAN-ID: Modify the VLAN ID of a packet.
• Push-VLAN: Add a new VLAN tag to the packet.
• Pop-VLAN: Remove the VLAN tag from a packet.
For example, a rule could be set to push a VLAN tag of 100 to incoming traffic
that matches certain criteria, like specific MAC addresses or IP addresses.
4. VLAN Aware Switching:
OpenFlow switches can be configured to be VLAN aware, which means
they will inspect the VLAN tags of incoming traffic and make forwarding
decisions based on those tags. VLAN aware switching is important in cases
where multiple VLANs are configured on a network.
VLAN and OpenFlow Versions:
Support for VLANs in OpenFlow has evolved over the different versions:
• OpenFlow 1.0: Initial support for matching VLAN IDs in flow rules,
though limited in functionality.
• OpenFlow 1.1 and beyond: Enhanced support for VLAN handling,
such as VLAN stacking (Q-in-Q), VLAN translation, and additional
flow actions.
5. VLAN Tagging in SDN:
In an SDN environment, the SDN controller can dynamically program the
OpenFlow switch to tag or untag traffic based on policies. This allows the
network to adapt and change its VLAN configuration dynamically based on
real-time conditions, without requiring manual configuration of each
individual network device. 4.3.3. Practical Use Cases
• Multi-tenancy: In data centers, SDN with OpenFlow can segregate
traffic from different tenants by using VLANs. The SDN controller can
ensure that traffic from one tenant (VLAN) does not interfere with
traffic from another.
• Dynamic VLAN Assignment: OpenFlow allows for dynamic VLAN
assignment based on user identity, location, or network conditions. For
example, a user connecting to the network might automatically be
assigned to a specific VLAN based on their credentials or the switch
port they connect to.

133
 • Inter-VLAN Routing: While OpenFlow itself does not perform routing
(it's a layer 2 protocol), it can be used to configure switches to direct
traffic between different VLANs or to forward it to external routers for
inter-VLAN routing.
[Link] Concept :
“Requirements and Technology,” defined network functions virtualization (NFV) as
the virtualization of network functions by implementing these functions in software
and running them on VMs. NFV isa significant departure from traditional approaches
to the design, deployment, and management of networking services.

• NFV decouples network functions, such as Network Address

Translation (NAT), firewalling, intrusion detection, Domain Name
Service (DNS), and caching, from proprietary hardware appliances
so that they can run in software on VMs.
• NFV builds on standard VM technologies, extending their use into
the networking domain. Virtual machine technology, as discussed in
enables migration of dedicated application and database servers to
commercial off-the-shelf (COTS) x86 servers.
The same technology can be applied to network-based devices, including the
following:
• Network function devices: Such as switches, routers, network
access points, customer premises equipment (CPE), and deep packet
inspectors (for deep packet inspection).
• Network-related compute devices: Such as firewalls, intrusion
detection systems, and network management systems.
• Network-attached storage: File and database servers attached to the
network.
In traditional networks, all devices are deployed on proprietary/closed
platforms.
All network elements are enclosed boxes, and hardware cannot be shared. Each
device requires additional hardware for increased capacity, but this hardware is idle
when the system is running below capacity. With NFV, however, network elements
are independent applications that are flexibly deployed on a unified platform
comprising standard servers, storage devices, and switches. In this way, software and
hardware are decoupled, and capacity for each application is increased or decreased
by adding or reducing virtual resources (see Figure 4.6).

134
• By broad consensus, the Network Functions Virtualization Industry
Standards Group (ISG NFV), created as part of the European
Telecommunications Standards Institute (ETSI), has the lead and
indeed almost the sole role in creating NFV standards.
• ISG NFV was established in2012 by seven major
telecommunications network operators. Its membership has since
grown to include network equipment vendors, network technology
companies, other IT companies, and service providers such as cloud
service providers.
• ISG NFV published the first batch of specifications in October 2013,
and subsequently updated most of those in late 2014 and early 2015.
Table 4.1shows the complete list of specifications as of early 2015.
Table 4.2 provides definitions for a number of terms that are used in
the ISG NFV documents and the NFV literature in general.

Figure 4.6 Vision for Network Functions Visualization

135
TABLE 4.1 ISG NFV Specifications

136
TABLE 4.2 NFV Terminology

137
4.4.1. Simple Example of the Use of NFV :

• This section considers a simple example from the NFV Architectural

Framework document. Part a of Figure 7.6 shows a physical
realization of a network service. At a top level, the network service
consists of endpoints connected by a forwarding graph of network
functional blocks, callednetwork functions (NFs).
• Examples of NFs are firewalls, load balancers, and wireless network
access points. In the Architectural Framework, NFs are viewed as
distinct physical nodes. The endpoints are beyond the scope of the
NFV specifications and include all customer-owned devices. So, in
the figure, endpoint A could be a smartphone and endpoint B a
content delivery network (CDN) server.

Figure 4.7 A Simple NFV Configuration Example

138
 • Part a of Figure 4.7 highlights the network functions that are relevant
to the service provider and customer. The interconnections among the
NFs and endpoints are depicted by dashed lines, representing logical
links.
• These logical links are supported by physical paths through
infrastructure networks (wired or wireless).Part b of Figure 4.7
illustrates a virtualized network service configuration that could be
implemented on the physical configuration of part a of Figure7.6.
VNF1 provides network access for endpoint A, and VNF-2 provides
network access for B.
• The figure also depicts the case of a nested Onforwarding graph
(VNFFG-2) constructed from other VNFs (that is, VNF-2A, VNF-2B
and VNF-2C). All of these VNFs run as VMs on physical machines,
called points of presence (PoPs). This configuration illustrates
several important points. First, VNF-FG-2 consists of three VNFs
even though ultimately all the traffic transiting VNF-FG-2 is between
VNF-1 andVNF-3.
• The reason for this is that three separate and distinct network
functions are being performed. For example, it may be that some
traffic flows need to be subjected to a traffic policing or shaping
function, which could be performed by VNF-2C. So, some flows
would be routed throughVNF2C, while others would bypass this
network function.

A second observation is that two of the VMs in VNF-FG-2 are hosted

on the same physical machine. Because these two VMs perform different
functions, they need to be distinct at the virtual resource level but can be
supported by the same physical machine. But this is not required, and a
network management function may at some point decide to migrate one of
the VMsto another physical machine, for reasons of performance. This
movement is transparent at the virtual resource level.

[Link] Principles:

As suggested by Figure 4.7, the VNFs are the building blocks used
to create end-to-end network services. Three key NFV principles are
involved increasing practical network services:
• Service chaining: VNFs are modular and each VNF provides limited
functionality on its own.
139
 • For a given traffic flow within a given application, the service
provider steers the flow through multiplanes to achieve the desired
network functionality. This is referred toas service chaining.
• Management and orchestration (MANO): This involve deploying
and managing the lifecycle of VNF instances. Examples include
Insistence creation, VNF service chaining, monitoring, relocation,
shutdown, and billing. MANO also manages the NFV infrastructure
elements.
• Distributed architecture: A VNF may be made up of one or more
VNF components (VNFC), each of which implements a subset of the
VNF’s functionality. Each VNFC may be deployed in one or multiple
instances. These instances may be deployed on separate, distributed
hosts to provide scalability and redundancy.
• High-Level NFV Framework
Figure 4.9 shows a high-level view of the NFV framework defined
by ISGNFV. This framework supports the implementation of
network functions as software-only VNFs.

Figure [Link]-Level NFV Framework

The NFV framework consists of three domains of operation:

140
 • Virtualized network functions: The collection of VNFs,
implemented in software, that run over the NFVI.
• NFV infrastructure (NFVI): The NFVI performs a virtualization
function on the three main categories of devices in the network
service environment: computer devices, storage devices, and
network devices.
• NFV management and orchestration: Encompasses the
orchestration and lifecycle management of physical/software
resources that support the infrastructure virtualization, and the
lifecycle management of VNFs. NFV management and orchestration
focuses on all virtualizationspecific management tasks necessary
inthe NFV framework.

The ISG NFV Architectural Framework document specifies that in the

deployment, operation, management and orchestration of VNFs, two types
of relations between VNFs are supported:

• VNF forwarding graph (VNF FG): Covers the case where network
connectivity between VNFs is specified, such as a chain of VNFs on
the path to a web server tier (for example, firewall, network address
translator, load balancer).
• VNF set: Covers the case where the connectivity between VNFs is
not specified, such as a web server pool.

4.4.3. Need of NFV:

With the help of NFV, it becomes possible to separate communication
services from specialized hardware like routers and firewalls. This
eliminates the need for buying new hardware and network operations can
offer new services on demand. With this, it is possible to deploy network
components in a matter of hours as opposed to months as with conventional
networking. Furthermore, the virtualized services can run on less expensive
generic servers.
4.4.4. Advantages:
• Lower expenses as it follows Pay as you go which implies companies
only pay for what they require.
• Less equipment as it works on virtual machines rather than actual
machines which leads to fewer appliances, which lowers operating
expenses as well.

141
 • Scalability of network architecture is quite quick and simple using
virtual functions in NFV. As a result, it does not call for the purchase
of more hardware.
[Link] Benefits and Requirements:
Having considered on overview of NFV concepts, we can now
summarize key benefits of NFV and requirements for successful
implementation.
4.5.1. [Link] Benefits :
If NFV is implemented efficiently and effectively, it can provide a number
of benefits compared to traditional networking approaches. The following
are the most important potential benefits:
• Reduced CapEx, by using commodity servers and switches,
consolidating equipment, exploiting economies of scale, and
supporting pay-as-you grow models to eliminate wasteful
overprovisioning. This is perhaps the main driver for NFV.
• Reduced OpEx, in terms of power consumption and space usage, by
using commodity servers and switches, consolidating equipment, and
exploiting economies of scale, and reduced network management and
control expenses. Reduced CapeX and OpEx are perhaps the main
drivers for NFV.
• The ability to innovate and roll out services quickly, reducing the time
to deploy new networking services to support changing business
requirements, seize new market opportunities, and improve return on
investment of new services. Also lowers the risks associated with
rolling out new services, allowing providers to easily trial and evolve
services to determine what best meets the needs of customers.
• Ease of interoperability because of standardized and open interfaces.
• Use of a single platform for different applications, users and tenants.
This allows network operators to share resources across services and
across different customer bases.
• Provided agility and flexibility, by quickly scaling up or down
services to address changing demands.
• Targeted service introduction based on geography or customer sets is
possible. Services can be rapidly scaled up/down as required.
• A wide variety of ecosystems and encourages openness. It opens the
virtual appliance market to pure software entrants, small players and
academia, encouraging more innovation to bring new services and
new revenue streams quickly at much lower risk.

142
[Link] Requirements :
To deliver these benefits, NFV must be designed and implemented to meet a
number of requirements and technical challenges, including the following
[ISGN12]:
• Portability/interoperability: The capability to load and executants
provided by different vendors on a variety of standardized hardware
platforms. The challenge is to define a unified interface that clearly
decouples the software instances from the underlying hardware, as
represented by VMs and their hypervisors.
• Performance trade-off: Because the NFV approach is based on
industry standard hardware (that is, avoiding any proprietary
hardware such as acceleration engines), a probable decrease in
performance has to be taken into account. The challenge is how
tokeep the performance degradation as small as possible by using
appropriate hypervisors and modern software technologies, so that
the effects on latency, throughput, and processing overhead are
minimized.
• Migration and coexistence with respect to legacy equipment: The
NFV architecture must support a migration path from today’s
proprietary physical network appliance-based solutions to more open
standards-based virtual network appliance solutions. In other words,
NFV must work in a hybrid network composed of classical physical
network appliances and virtual network appliances. Virtual
appliances must therefore use existing northbound Interfaces (for
management and control) and interwork with physical appliances
implementing the same functions.
• Management and orchestration: A consistent management and
orchestration architecture is required. NFV presents an opportunity,
through the flexibility afforded by software network appliances
operating in an open and standardized infrastructure, to rapidly align
management and orchestration northbound interfaces to well defined
standards and abstract specifications.
• Automation: NFV will scale only if all the functions can be
automated. Automation of process is paramount to success.
• Security and resilience: The security, resilience, and availability of
their networks should not be impaired when VNFs are introduced.
• Network stability: Ensuring stability of the network is not impacted
when managing and orchestrating a large number of virtual
appliances between different hardware vendors and hypervisors.
143
 • This is particularly important when, for example, virtual functions are
relocated, or during reconfiguration events (for example, because of
hardware and software failures) or because of cyber-attack.
• Simplicity: Ensuring that virtualized network platforms will be
simpler to operate than those that exist today. A significant focus for
network operators is simplification of the plethora of complex
network platforms and support systems that have evolved over
decades of network technology evolution, while maintaining
continuity to support important revenue generating services.
• Integration: Network operators need to be able to “mix and match
“servers from different vendors, hypervisors from different vendors,
and virtual appliances from different vendors without incurring
significant integration costs and avoiding lock-in. The ecosystem
must offer integration services and maintenance and third-party
support; it must be possible to resolve integration issues between
several parties. The ecosystem will require mechanisms to validate
new NFV products.
[Link] Reference Architecture:
Figure 4.9 provided a high-level view of the NFV framework.
Figure 4.10shows a more detailed look at the ISG NFV reference
architectural framework. You can view this architecture as consisting of four
major blocks:

144
 Figure [Link] Reference Architectural Framework
• NFV infrastructure (NFVI): Comprises the hardware and software
resources that create the environment in which VNFs are deployed.
NFVI virtualizes physical computing, storage, and networking and
places them into resource pools.
• VNF/EMS: The collection of VNFs implemented in software to run
on virtual computing, storage, and networking resources, together
with a collection of element management systems (EMS) that
manage the VNFs.
• NFV management and orchestration (NFV-MANO): Framework
for the management and orchestration of all resources in the NFV
environment. This includes computing, networking, storage, and VM
resources.
• OSS/BSS: Operational and business support systems implemented
by the VNF service provider.
It is also useful to view the architecture as consisting of three layers. The
NFVI together with the virtualized infrastructure manager provide and
manage the virtual resource environment and its underlying physical
resources.
The VNF layer provides the software implementation of network functions,
together with element management systems and one or more VNF managers.
145
Finally, there is a management, orchestration, and control layer consisting of
OSS/BSS and the NFV orchestrator.
[Link] Management and Orchestration :
The NFV management and orchestration facility includes the following
functional blocks:
• NFV orchestrator: Responsible for installing and configuring new
network services (NS) and virtual network function (VNF) packages,
NS lifecycle management, global resource management, and
validation and authorization of NFVI resource requests.
• VNF manager: Oversees lifecycle management of VNF instances.
• Virtualized infrastructure manager: Controls and manages the
interaction of a VNF with computing, storage, and network resources
under its authority, in addition to their virtualization.
4.6.2Reference Points :
Figure 4.9 also defines a number of reference points that constitute
interfaces between functional blocks. The main (named) reference points and
execution reference points are shown by solid lines and are in the scope of
NFV. These are potential targets for standardization. The dashed line
reference points are available in present deployments but might need
extensions for handling network function virtualization. The dotted reference
points are not a focus of NFV at present.
The main reference points include the following considerations:
• Vi-Ha: Marks interfaces to the physical hardware. A well-defined
interface specification will facilitate for operators sharing physical
resources for different purposes, reassigning resources for different
purposes, evolving software and hardware independently, and obtaining
software and hardware component from different vendors.
• Vn-Nf: These interfaces are APIs used by VNFs to execute on the
virtual infrastructure. Application developers, whether migrating
existing network functions or developing new VNFs, require a
consistent interface the provides functionality and the ability to specify
performance, reliability, and scalability requirements.
• Nf-Vi: Marks interfaces between the NFVI and the virtualized
infrastructure manager (VIM). This interface can facilitate specification
of the capabilities that the NFVI provides for the VIM. The VIM must
be able to manage all the NFVI virtual resources, including allocation,
monitoring of system utilization, and fault management.

146
 • Or-Vnfm: This reference point is used for sending configuration
information to the VNF manager and collecting state information of the
VNFs necessary for network service lifecycle management.
• Vi-Vnfm: Used for resource allocation requests by the VNF manager
and the exchange of resource configuration and state information.
• Or-Vi: Used for resource allocation requests by the NFV orchestrator
and the exchange of resource configuration and state information.
• Os-Ma: Used for interaction between the orchestrator and the OSS/BSS
systems.
• Ve-Vnfm: Used for requests for VNF lifecycle management and
exchange of configuration and state information.
• Se-Ma: Interface between the orchestrator and a data set that provides
information regarding the VNF deployment template, VNF forwarding
graph, service-related information, and NFV infrastructure information
models.
4.6.3. Implementation:
As with SDN, success for NFV requires standards at appropriate
interface reference points and open-source software for commonly used
functions. For several years, ISG NFV is working on standards for the
various interfaces and components of NFV. In September of 2014, the Linux
Foundation announced the Open Platform for NFV (OPNFV) project.
OPNFV aims to be a carrier-grade, integrated platform that introduces new
products and services to the industry more quickly. The key objectives of
OPNFV are as follows:
• Develop an integrated and tested open-source platform that can be used
to investigate and demonstrate core NFV functionality.
• Secure proactive participation of leading end users to validate that
OPNFV releases address participating operators’ needs.
• Influence and contribute to the relevant open-source projects that will
be adopted in the OPNFV reference platform.
• Establish an open ecosystem for NFV solutions based on open standards
and open-source software.
• Promote OPNFV as the preferred open reference platform to avoid
unnecessary and costly duplication of effort.
OPNFV and ISG NFV are independent initiatives but it is likely that they
will work closely together to assure that OPNFV implementations remain
within the standardized environment defined by ISG NFV.

147
 The initial scope of OPNFV will be on building NFVI, VIM, and
including application programmable interfaces (APIs) to other NFV
elements, which together form the basic infrastructure required for VNFs and
MANO components. This scope is highlighted in Figure 4.10as consisting
of NFVI and VMI. With this platform as a common base, vendors can add
value by developing VNF software packages and associated VNF manager
and orchestrator software.

Figure 4.10 NFV Implementation

PART A
[Link] do you mean by network virtualization?
Network Virtualization (NV) refers to abstracting network resources
that were traditionally delivered in hardware to software.
NV can combine multiple physical networks to one virtual, software
based network, or it can divide one physical network into separate,
independent virtual networks.
2. What are the methods of network virtualization?
Two types of virtual networks exist: external and internal. External
network virtualization leverages physical systems located on the
same LAN into separate VLANs. External networks can also divide
individual LANs onto the same VLAN.
148
3. Which is a SDN network virtualization technology for VMware?
NSX software-defined networking, or SDN, is part of VMware's
software-defined data center, or SDDC, concept, which offers cloud
computing on VMware virtualization technologies.
4. What is the difference between SDN and network virtualization?
SDN attempts to isolate network control operations from network
forwarding services. In contrast, NV attempts to abstract network
forwarding and other networking functions from the hardware on
which they execute.
As a result, both rely on virtualization to abstract network
architecture and infrastructure in software.
6. What are the examples of network Virtualization?
One example of network virtualization is virtual LAN (VLAN). A
VLAN is a subsection of a local area network (LAN) created with
software that combines network devices into one group, regardless of
physical location.
7. What are the classification of network virtualization?
There are two broad categories of network virtualization: External
and internal network virtualization.
The goal of the external network virtualization is to allow for
seamless interoperation of physical networks and thus allow for
better administration and management.
8. What are two advantages to using virtualization on a network?
Virtualization offers benefits such as improved resource utilization,
cost savings, efficient scalability, easier management, and the ability
to create isolated environments for testing and development.
9. List out the Framework of Network Virtualization for Future Networks.
• Physical resource
• Logical resource
• Virtual resource
• Virtual network
• Network virtualization (NV)
10. Write down the benefits of Network Virtualization.
• Flexibility
• Operational cost savings
• Agility • Scalability.
• Capital cost savings
• Rapid service provisioning/time to market

149
 • Equipment consolidation
11. Defining VLANs
A VLAN is a broadcast domain consisting of a group of end stations,
perhaps on multiple physical LAN segments, that are not constrained
by their physical location and can communicate as if they were on a
common LAN.
Some means is therefore needed for defining VLAN membership.

12. What are the different approaches have been used for defining membership
in VLANs?
• Membership by port group
• Membership by MAC address
• Membership based on protocol information

13. What is a virtual LAN and why it is used?

A virtual local area network (VLAN) is a virtualized connection that
connects multiple devices and network nodes from different LANs
into one logical network.
VLAN stands for Virtual LAN. A VLAN is a way of logically
separating a group of computers into a separate network.
This means they will only communicate with each other and not with
any other devices connected to the same physical network. It's like
having a private wireless network at home.
14. What is VLAN example?
VLANs break up broadcast domains, reducing the number of other
hosts from which any given device sees broadcasts.
For example, if all desktop voice over IP phones are on one VLAN
and all workstations are on another, phones won't see any workstation
generated broadcast traffic and vice versa.
15. What are the 3 types of VLAN?
There are five main types of VLANs depending on their purpose:
• Management VLAN
• Data VLAN
• Voice VLAN
• Default VLAN
• Native VLAN

150
16. What are the two modes of VLAN?
The term VLAN stands for Virtual Local Area Network and every
Ethernet port in an Opti go Connect system can be configured with
one of three different VLAN modes: Access, Trunk, or Local.
Typically, VLAN Access mode is used for ports connected to end
devices (e.g.
cameras, BAS controllers, etc).
17. How can 2 VLANs communicate?
• VLANs can communicate with other VLANs when they both using
the same trunk link to connect to the same layer 2 switch. ...
• VLANs with the same default gateway can communicate with other
VLANs under the same layer 2 switch native VLAN can access other
VLANs under the same layer 2 switch.
18. How many devices can be connected in VLAN?
Entirely depends on what the devices are, what they are doing, how
good the switch is at processing the packets and pushing them out,
the port speed, the client lan adapter, how much broadcast traffic goes
on, etc.... Our main client vlan has ~600 devices on it, but not
concurrent and 80% are thin clients simply.
19. Why is VLAN trucking used?
Why is trucking important to VLAN configuration? With VLAN
trunking, it's possible to extend a VLAN across the network.
When you implement multiple VLANs across a network, trunk links
are necessary to ensure that VLAN signals remain properly
segregated for each to reach their intended destination.
20. What are the limitations of OpenFlow protocol?
OpenFlow was one of the first widely used protocols for enabling
SDN. However, OpenFlow also has disadvantages, for example:
i) Internet service providers cannot choose specific functions,
although not all functions are always needed, and thus costs
are high;
ii) each new OpenFlow version requires new hardware.
[Link] is OpenFlow specification used in SDN?
As the first standard communication interface between the control
plane and the data plane in SDN, the OpenFlow specification defines
the communication method between the controller and the switch and
the operation flow of the switch to the packets, implementing the idea
of a programmable network.

151
22. What is the difference between OpenFlow and SNMP?
SDN manages data flows and switching using the OpenFlow protocol
[11] whereas, SNMP has been widely used in TCP/IP-based networks
for the monitoring of network elements and hosts. However, the
monitored devices are represented as managed objects and defined as
a MIB.
[Link] are the advantages of OpenFlow in SDN?
OpenFlow plays a crucial role in enhancing network performance in
SDN environments.
By enabling centralized control, real-time traffic optimization,
scalability, improved security, and seamless integration, OpenFlow
empowers network administrators to efficiently manage and optimize
network traffic.
[Link] are the disadvantages of OpenFlow?
The malicious switches can exploit the OpenFlow handshake for
covert communication because security mechanisms on the data
plane are bypassed when forwarding traffic to a destination network
based on the control plane logic.
25. What is the purpose of OpenFlow?
ONF defines OpenFlow as the first standard communications
interface defined between the control and forwarding layers of an
SDN architecture.
OpenFlow allows direct access to and manipulation of the forwarding
plane of network devices such as switches and routers, both physical
and virtual (hypervisor-based).
[Link] protocol is used in SDN?
The OpenFlow protocol can be used in SDN technologies. The SDN
architecture is: Directly programmable: Network control is directly
programmable because it is decoupled from forwarding functions.
27. What is the concept of NFV?
Network Function Virtualization, or NFV, is a way to reduce cost and
accelerate service deployment for network operators by decoupling
functions like a firewall or encryption from dedicated hardware and
moving them to virtual servers.
28. What are the technology can be applied to network-based device?
• Network function devices: Such as switches, routers, network access
points, customer premises equipment (CPE), and deep packet inspectors
(for deep packet inspection).

152
 • Network-related compute devices: Such as firewalls, intrusion
detection systems, and network management systems.
• Network-attached storage: File and database servers attached to the
network.
29. What is Example of the Use of NFV?
At a top level, the network service consists of endpoints connected
by a forwarding graph of network functional blocks, callednetwork
functions (NFs).
Examples of NFs are firewalls, load balancers, and wireless network
access points. In the Architectural Framework, NFs are viewed as
distinct physical nodes.
The endpoints are beyond the scope of the NFV specifications and
include all customer-owned devices. So, in the figure, endpoint A
could be a smartphone and endpoint B a content delivery network
(CDN) server.
30. What is the difference between NFV and VNF?
The relationship between NFV and VNF is similar to that between SDN
and SD-WAN: NFV is an architecture guiding management and
orchestration activities, whereas a VNF is the technology providing
virtual (that is, hardware-independent) network functions such as
routing or firewalling.
31. What are the Three key NFV principles are involved in creating practical
network services?
• Service chaining: Management and orchestration (MANO): This
involves deploying and managing the lifecycle of VNF instances.
• Distributed architecture: A VNF may be made up of one or more VNF
components (VNFC), each of which implements a subset of the VNF’s
functionality.
• High-Level NFV Framework
This framework supports the implementation of network functions as
software-only VNFs.
32. List out the operation in NFV Framework.
• Virtualized network functions: The collection of VNFs, implemented
in software, that run over the NFVI.
• NFV infrastructure (NFVI): The NFVI performs a virtualization
function on the three main categories of devices in the network service
environment computer devices, storage devices, and network devices.

153
 • NFV management and orchestration: Encompasses the orchestration
and lifecycle management of physical/software resources that support
the infrastructure virtualization, and the lifecycle management of VNFs.
NFV management and orchestration focuses on all
virtualizationspecific management tasks necessary int he NFV
framework.
33. Write Down the two types of relations between VNFs are supported in NFV.
• VNF forwarding graph (VNF FG): Covers the case where network
connectivity between VNFs is specified, such as a chain of VNFs on the
path to a web server tier (for example, firewall, network address
translator, load balancer).
• VNF set: Covers the case where the connectivity between VNFs is not
specified, such as a web server pool.
34. What are the benefits of NFV?
• Reduced CapEx, by using commodity servers and switches,
consolidating equipment, exploiting economies of scale, and supporting
pay-as-you grow models to eliminate wasteful over provisioning. This
is perhaps the main driver for NFV.
• Reduced OpEx, in terms of power consumption and space usage, by
using commodity servers and switches, consolidating equipment, and
exploiting economies of scale, and reduced network management and
control expenses. Reduced CapeX and OpEx are perhaps the main
drivers for NFV.
• The ability to innovate and roll out services quickly, reducing the time
to deploy new networking services to support changing business
requirements, seize new market opportunities, and improve return on
investment of new services.
35. What are the Requirements of NFV?
• Portability/interoperability
• Performance trade-off Migration and coexistence with respect to legacy
equipment
• Management and orchestration.
• Automation Security and resilience Network stability
• Simplicity Integration
36. Define NFV infrastructure (NFVI).
Comprises the hardware and software resources that create the
environment in which VNFs are deployed. NFVI virtualizes physical
computing, storage, and networking and places them into resource
pools.
154
37. Define VNF/EMS.
The collection of VNFs implemented in software to run on virtual
computing, storage, and networking resources, together with a
collection of element management systems (EMS) that manage the
VNFs.
38. Define NFV management and orchestration (NFV-MANO) and OSS/BSS.
• NFV management and orchestration (NFV-MANO) Framework for
the management and orchestration of all resources in the NFV
environment. This includes computing, networking, storage, and VM
resources.
• OSS/BSS: Operational and business support systems implemented by
the VNF service provider.
39. What are the key objectives of OPNFV?
• Develop an integrated and tested open-source platform that can be used
to investigate and demonstrate core NFV functionality.
• Secure proactive participation of leading end users to validate that
OPNFV releases address participating operators’ needs.
• Influence and contribute to the relevant open-source projects that will
be adopted in the OPNFV reference platform.
• Establish an open ecosystem for NFV solutions based on open standards
and open-source software.
• Promote OPNFV as the preferred open reference platform to avoid
unnecessary and costly duplication of effort.
40. What are the main reference points include in NFV.
• Vi-Ha
• Vn-Nf
• Nf-Vi
• Or-Vnfm
• Vi-VnfmOr-ViOs-MaVe-VnfmSe-Ma
PART –B
1. Explain the details about the Network Virtualization. Or Explain about
the Network Virtualization Architecture.
2. Explain about the Virtual LANs and its concept.
3. Explain the details about the OpenFlow VLAN Support
4. Explain the details about the NFV Benefits and Requirements
5. Explain the details about the NFV Reference Architecture.
6. Explain the Virtualized Network Functions

155
156
 UNIT –V
NFV FUNCTIONALITY

NFV Infrastructure – Virtualized Network Functions – NFV

Management and Orchestration – NFV Use cases – SDN and
NFV.
5.1. NFV Infrastructure:
The heart of the NFV architecture is a collection of resources and functions
known as the NFV infrastructure (NFVI). The NFVI encompasses three
domains, as illustrated in Figure 5.1 and described in the list that follows.

Figure 5.1 NFV Domains

o Compute domain: Provides commercial off-the-shelf (COTS)
highvolume servers and storage.
o Hypervisor domain: Mediates the resources of the compute
domain to the VMs of the software appliances, providing an
abstraction of the hardware.
o Infrastructure network domain (IND): Comprises all the
generic high volume switches interconnected into a network that
can be configured to supply infrastructure network services.

157
5.1.1 Container Interface
• Before proceeding with a discussion of NFVI, we need to clarify the
concept of container interface as used in the Network Functions
Virtualization Industry Standards Group (ISG NFV) documents.
Unfortunately, the European Telecommunications Standards Institute
(ETSI) documents use the term container in a different sense than that
of container virtualization.
• The NFV Infrastructure document states that container interface
should not be confused with container as used in the context of
container virtualization as an alternative to full VMs. Further, the
Infrastructure document states that some virtual network functions
(VNFs) may be designed for hypervisor virtualization and other VNFs
may be designed for container virtualization. With this clarification,
the following examines the container interface concept.
• The ETSI documents make a distinction between a functional block
interface and a container interface, as follows:
o Functional block interface: An interface between two
blocks of software that perform separate (perhaps identical)
functions. The interface allows communication between the
two blocks. The two functional blocks may or may not be on
the same physical host.

o Container interface: An execution environment on a host

system within which a functional block executes. The
functional block is on the same physical host as the container
that provides the container interface.

• The concept of container interface is important because, in discussing

VMs and VNFs within the NFV architecture, and how these functional
blocks interact, it is easy to lose sight of the fact that all of these
virtualized functions must execute on actual physical hosts.
• Figure 5.2 relates container and functional block interfaces to the
domain structure of NFVI.
• The ETSI NFVI Architecture Overview document makes the
following points concerning this figure:
o The architecture of the VNFs is separated from the architecture
hosting the VNFs (that is, the NFVI).
o The architecture of the VNFs may be divided into a number of
domains with consequences for the NFVI and vice versa.
158
 FIGURE 5.2 General Domain Architecture and Associated
Interfaces

o Given the current technology and industrial structure,

compute (including storage), hypervisors, and infrastructure
networking are already largely separate domains and are
maintained as separate domains within the NFVI.
o Management and orchestration tend to be sufficiently distinct
from the NFVI as to warrant being defined as its own domain;
however, the boundary between the two is often only loosely
defined with functions such as element management
functions in an area of overlap.
o The interface between the VNF domains and the NFVI is a
container interface and not a functional block interface.
o The management and orchestration functions are also likely
to be hosted in the NFVI (as VMs) and therefore also likely
to sit on a container interface.
• Figure 5.2 gives insight into the deployment of NFV. The user view
of a network of interconnected VNFs is of a virtualized network in
which the physical and lower-level logical details are transparent.

159
• But the VNFs and logical links between VNFs are hosted on an NFVI
container, which in turn is hosted on VM and VM containers running
on physical hosts.
• Therefore, if we view the VNF architecture as having three layers
(physical resource, virtualization, application), all three layers are
present on a single physical host. Of course, functionality may be
distributed across multiple computer and switch hosts, but all
application software ultimately runs on the same physical host as the
virtualization software.
• This is in contrast to software defined networking (SDN), where by
design the data plane functions and the control plane functions are on
separate physical hosts. Application plane SDN functions may
execute on the same host as the control plane functions but may also
execute remotely on another host.
• Table 5.1 describes the interfaces labeled in Figure 5.2; the numbers
in the second column of the table correspond to the numbered arrows
in the figure.
• Interfaces 4, 6, 7, and 12 are container interfaces, so that components
on both side of the interface are executing on the same host.
Interfaces 3, 8, 9, 10, 11, and 14 are functional block interfaces and,
in most cases, the functional blocks on the two sides of the interface
execute on different hosts. However, in some cases, some of the
management and orchestration software may be hosted on a system
that also hosts other NFVI components.
• Figure 5.2 also shows interfaces 1, 2, 5, and 13 to existing networks
that have not implemented NFV. The NFV documents anticipate that
typically NFV will be introduced over time into an enterprise facility,
so that interaction with non-NFV network is necessary.

160
 TABLE 5.1 Inter-Domain Interfaces Arising from Domain Architecture

5.1.2. Deployment of NFVI Containers:

• A single compute or network host can host multiple virtual machines
(VMs), each of which can host a single VNF. The single VNF hosted
on a VM is referred to as a VNF component (VNFC).
• A network function may be virtualized by a single VNFC, or multiple
VNFCs may be combined to form a single VNF.

161
• Part a of Figure 5.3 shows the organization of VNFCs on a single
compute node. The compute container interface hosts a hypervisor,
which in turn can host multiple VMs, each hosting a VNFC. When a
VNF is composed of multiple VNFCs, it is not necessary that all the
VNFCs execute in the same host. As shown in part b of Figure 5.3,
the VNFCs can be distributed across multiple compute nodes
interconnected by network hosts forming the infrastructure network
domain.

Figure 5.3 Deployment of NVFI Containers

162
5.1.3. Logical Structure of NFVI Domains:
• The ISG NFV standards documents lay out the logical structure of
the NFVI domains and their interconnections. The specifics of the
actual implementation of the elements of this architecture will evolve
in both open source and proprietary implementation efforts.
• The NFVI domain logical structure provides a framework for such
development and identifies the interfaces between the main
components, as shown in Figure 5.4.

Figure 5.4 Logical Structures of NFVI Domains

5.1.4. Compute Domain:
The principal elements in a typical compute domain may include the following:
o CPU/memory: A COTS processor, with main memory, that executes
the code of the VNFC.
o Internal storage: Nonvolatile storage housed in the same physical
structure as the processor, such as flash memory.
o Accelerator: Accelerator functions for security, networking, and
packet processing may also be included.
163
 o External storage with storage controller: Access to secondary
memory devices. o Network interface card (NIC): Provides the
physical interconnection with the infrastructure network domain,
which is labeled Ha/CSr-Ha/Nr and corresponds to interface 14 of
Figure 5.2.
o Control and admin agent: Connects to the virtualized infrastructure
manager (VIM “Network Functions Virtualization: Concepts and
Architecture.” o Eswitch: Server embedded switch. The eswitch
function, described in the following section, is implemented in the
compute domain. However, functionally it forms an integral part of
the infrastructure network domain.
o Compute/storage execution environment: This is the execution
environment presented to the hypervisor software by the server or
storage device ([VI-Ha]/CSr, interface 12 of Figure 5.2).
Eswitch :
To understand the functionality of the eswitch, first note that, broadly
speaking, VNFs deal with two different kinds of workloads:
o Control plane workloads: Concerned with signaling and control
plane protocols such as BGP. Typically, these workloads are more
processor rather than I/O intensive and do not place a significant
burden on the I/O system.
o Data plane workloads: Concerned with the routing, switching,
relaying or processing of network traffic payloads. Such workloads
can require high I/O throughput.
• In a virtualized environment such as NFV, all VNF network traffic
would go through a virtual switch in the hypervisor domain, which
invokes a layer of software between virtualized VNF software and
host networking hardware.
• This can create a significant performance penalty. The purpose of the
eswitch is to bypass the virtualization software and provide the VNF
with a direct memory access (DMA) path to the NIC. The eswitch
approach accelerates packet processing without any processor
overhead.
NFVI Implementation Using Compute Domain Nodes :
• As suggested by Figure 5.3, a VNF consists of one or more logically
connected VNFCs. The VNFCs run as software on hypervisor
domain containers that in turn run on hardware in the compute
domain.

164
• Although virtual links and networks are defined through the
infrastructure network domain, the actual implementation of network
functions at the VNF level consists of software on compute domain
nodes. The IND interfaces with the compute domain and not directly
with the hypervisor domain or the VNFs. Again, this latter point is
illustrated in Figure5.3.
• Before proceeding, we need to define the term node, which is used
often in the ISG NFV documents. The documents define an NFVI-
Node as collection of physical devices deployed and managed as a
single entity, providing the NFVI functions required to support the
execution environment for VNFs.
• NFVI nodes are in the compute domain and encompass the
following types of compute domain nodes:
▪ Compute node: A functional entity which is capable
of executing a generic computational instruction set
(each instruction be being fully atomic and
deterministic) in such a way that the execution cycle
time is of the order of units to tens of nanoseconds
irrespective of what specific state is required for cycle
execution.
▪ In practical terms, this defines a compute node in
terms of memory access time. A distributed system
cannot meet this requirement as the time taken to
access state stored in remote memory cannot meet this
requirement.
▪ Gateway node: A single identifiable, addressable,
and manageable element within an NFVI-Node that
implements gateway functions. Gateway functions
provide the interconnection between NFVI-PoPs and
the transport networks. They also connect virtual
networks to existing network components.
▪ A gateway may process packets going between
different networks, such as removing headers and
adding headers. A gateway may operate at the
transport level, dealing with IP and data-link packets,
or at the application level.

165
 ▪ Storage node: A single identifiable, addressable, and
manageable element within an NFVI-Node that
provides storage resource using compute, storage, and
networking functions. Storage may be physically
implemented in a variety of ways.
▪ It could, for example be implemented as a component
within a compute node. An alternative approach is to
implement storage nodes independent of the compute
nodes as physical nodes within the NFVI-Node. An
example of such a storage node may be a physical
device accessible via a remote storage technology,
such as Network File System (NFS) and Fibre
Channel.
▪ Network node: A single identifiable, addressable,
and manageable element within an NFVI-Node that
provides networking (switching/routing) resources
using compute, storage, and network forwarding
functions.
• A compute domain within an NFVI node will often be deployed as a
number of interconnected physical devices. Physical compute
domain nodes may include a number of physical resources, such as a
multicore processor, memory subsystems, and NICs. An
interconnected set of these nodes comprise one NFVI-Node and
constitutes one NFVI point of presence (NFVI-PoP). An NFV
provider might maintain a number of NFVI-PoPs at distributed
locations, providing service to a variety of users, each of whom could
implement their VNF software on compute domain nodes at various
NFVI-PoP locations.
• Table 5.2 lists some deployment scenarios suggested in the ISG NFV
Compute Domain document. The scenarios include the following:

166
TABLE 5.2 Some Realistic Deployment Scenarios
o Monolithic operator: One organization owns and houses
the hardware equipment and deploys and operates the VNFs
and the hypervisors they run on. A private cloud or a data
center are examples of this deployment model.
o Network operator hosting virtual network operators:
Based on the monolithic operator scenario, with the
addition that the monolithic operator host other virtual
network operators within the same facility. A hybrid cloud
is an example of this deployment model.
o Hosted network operator: An IT services organization
(for example, HP, Fujitsu) operates the computer hardware,
infrastructure network, and hypervisors on which a separate
network operator (for example, BT, Verizon) runs VNFs.
These are physically secured by the IT services organization.
o Hosted communications providers: Similar to the hosted
network operator scenario, but in this case multiple
communications providers are hosted. A community cloud
is an example of this deployment model.
o Hosted communications and application providers:
Similar to the previous scenario. In addition to host network
and communications providers, servers in a data center
facility are offered to the public for deploying virtualized
applications. A public cloud is an example of this deployment
model.

Managed network service on customer premises: Similar

to the monolithic operator scenario. In this case, the NFV
provider’s equipment is housed on the customer’s premises.
167
 One example of this model is a remotely managed gateway in
a residential or enterprise location. Another example is
remotely managed networking equipment such as firewalls or
virtual private network gateways.
Managed network service on customer equipment:Similar
to the monolithic operator scenario. In this case, the
equipment is housed on the customer’s premises on customer
equipment. This scenario could be used for managing an
enterprise network. A private cloud could also be deployed in
this fashion.

Note
• The different letters represent different companies
or organizations, and are chosen to represent
different roles (for example, H = hosting provider,
N = network operator, P = public, C = customer).
The numbered network operators (N1, N2, and so
on) represent multiple individual hosted network
operators.

5.1.5. Hypervisor Domain :

• The hypervisor domain is a software environment
that abstracts hardware and implements services,
such as starting a VM, terminating a VM, acting on
policies, scaling, live migration, and high
availability.
The principal elements in the hypervisor domain are the following o
Compute/storage resource sharing/management: Manages
these resources and provides virtualized resource access for
VMs. Network resource sharing/management: Manages these
resources and provides virtualized resource access for VMs.
o Virtual machine management and API: This provides the
execution environment of a single VNFC instance
([VnNf]/VM, interface 7 of Figure 5.2). Control and admin
agent: Connects to the virtualized infrastructure manager
(VIM).

168
 o Vswitch: The vswitch function, described in the next
paragraph, is implemented in the hypervisor domain.
However, functionally it forms an integral part of the
infrastructure network domain.
• The vswitch is an Ethernet switch implemented by the hypervisor that
interconnects virtual NICs of VMs with each other and with the NIC
of the compute node. If two VNFs are on the same physical server,
they would be connected through the same vswitch.
• If two VNFs are on different servers, the connection passes through
the first vswitch to the NIC and then to an external switch. This
switch forwards the connection to the NIC of the desired server.
Finally, this NIC forwards it to its internal vswitch and then to the
destination VNF.
5.1.6. Infrastructure Network Domain :
• The infrastructure network domain (IND) performs a number of
roles. It provides
o The communication channel between the VNFCs of a
distributed VNF
o The communications channel between different VNFs
o The communication channel between VNFs and their
orchestration and management
o The communication channel between components of the NFVI
and their orchestration and management
o The means of remote deployment of VNFCs The means of
interconnection with the existing carrier network
• Figure 5.2 illustrates key reference points defined for the IND. As
already mentioned, Ha/CSr-Ha/Nr defines the interface between the
IND and the servers/storage of the compute domain, connecting the
NIC in the compute domain to a network resource in the
infrastructure network domain.
• Ex-Nf is the reference point between any existing/nonvirtualized
network (interface 13 of Figure 5.2). Reference point [VI-HA]/Nr is
the interface between the hardware network resources of the IND and
the virtualization layer.
• The virtualization layer provides container interfaces for virtual
network entities. The [Vn-Nf]/N reference point (interface 7 of
Figure 5.2) is the virtual network (VN) container interface (for
example, a link or a LAN) for carrying communication between
VNFC instances.
169
 • Note that a single VN can support communication between more than
a single pairing of VNFC instances (for example, a LAN).
• There is an important distinction to be made between the
virtualization function provided by the hypervisor domain and that
provided by the infrastructure network domain. Virtualization in the
hypervisor domain uses VM technology to create an execution
environment for individual VNFCs.
• Virtualization in IND creates virtual networks for interconnecting
VNFCs with each other and with network nodes outside the NFV
ecosystem. These latter types of nodes are called physical network
functions (PNFs).
Virtual Networks :
• Before proceeding, we need to clarify how the term virtual network
is used in the ISG NFV documents. In general terms, a virtual
network is an abstraction of physical network resources as seen by
some upper software layer.
• Virtual network technology enables a network provider to support
multiple virtual networks that are isolated from one another. Users of
a single virtual network are not aware of the details of the underlying
physical network or of the other virtual network traffic sharing the
physical network resources.
• Two common approaches for creating virtual networks are (1)
protocol based methods that define virtual networks based on fields
in protocol headers, and (2) virtual-machine-based methods, in which
networks are created among a set of VMs by the hypervisor. The
NFVI network virtualization combines both these forms.
L2 Versus L3 Virtual Networks :
• Protocol-based virtual networks can be classified by whether they are
defined at protocol Layer 2 (L2), which is typically the LAN media
access control (MAC) layer, or Layer 3 (L3), which is typically the
Internet Protocol (IP). With an L2 VN, a virtual LAN is identified by
a field in the MAC header, such as the MAC address or a virtual LAN
ID field inserted into the header.
• So, for example, within a data center, all the servers and end systems
connected to a single Ethernet switch could support virtual LANs
among the connected devices. Now suppose there are IP routers
connecting segments of the data center, as illustrated in Figure 5.5.
Normally, an IP router will strip off the MAC header of incoming

170
 Ethernet frames and insert a new MAC header when forwarding the
packet to the next network.
• The L2 VN could be extended across this router only if the router had
additional capability to support the L2 VN, such as being able to
reinsert the virtual LAN ID field in the outgoing MAC frame.
Similarly, if an enterprise had two data centers connected by a router
and a dedicated line, that router would need the L2 VN capability to
extend a VN.

Figure 5.5 Levels of Network Virtualization

• An L3 VN makes use of one or more fields in the IP header. A good
example of this is the virtual private network (VPN) defined using
IPsec. Packets traveling on a VPN are encapsulated in a new outer IP
header and the data are encrypted so that VPN traffic is isolated and
protected as it transits third-party network such as the Internet.
NFVI Virtual Network Alternatives:
• ISG NFV defines a virtual network as the network construct that
provides network connectivity to one or more VNFs that are hosted
on the NFVI. Therefore, the concept of a virtual network that extends
beyond the NFV infrastructure is not currently addressed. In NFV, a
virtual network is a network among VNFs.
• The Network Domain document indicates that three approaches are
envisioned for providing a virtual network service: o Infrastructure-
based VNs o Layered VNs using virtual overlays o Layered VNs
using virtual partitioning
• The infrastructure-Based VN uses the native networking
functions of the NFVI compute and networking components.

171
 The address space is partitioned so that VNF membership in a VN is
defined by IP address. The IND document gives the following
example of an L3 infrastructurebased VN:
o Each VNF is assigned its own unique IP address that does not
overlap with any other address of elements within the NFVI.
o Logical partitioning of the VNFs into their VNs is achieved
by managing access control lists in the L3 forwarding
function in each compute node. o The L3 forwarding between
VNFs and the physical fabric can then be handled by the L3
forwarding information base running on the hosting compute
node.
o Control plane solutions, such as Border Gateway Protocol
(BGP), can be used to advertise reachability of the VNFs to
other compute hosts.
• The other two approaches are referred to as layered virtual network
approaches. These approaches allow overlapping address spaces.
• The virtual overlay VN uses the concept of an overlay network.
5.2. Virtualized Network Functions:
A VNF is a virtualized implementation of a traditional network function. Table
5.3 contains examples of functions that could be virtualized.

172
 TABLE 5.3 Potential Network Functions to Be Virtualized

[Link] Interfaces :
• A VNF consists of one or more VNF components (VNFCs). The
VNFCs of a single VNF are connected internal to the VNF.
• This internal structure is not visible to other VNFs or to the VNF user.
Figure 5.6 shows the interfaces relevant to a discussion of VNFs as
described in the list that follows.

Figure 5.6 VNF Functional View

o SWA-1: This interface enables communication between a VNF and
other VNFs, PNFs, and endpoints. Note that the interface is to the
VNF as a whole and not to individual VNFCs. SWA-1 interfaces are
logical interfaces that primarily make use of the network connectivity
services available at the SWA-5 interface.
o SWA-2: This interface enables communications between VNFCs
within a VNF. This interface is vendor specific and therefore not a
subject for standardization. This interface may also make use of the
network connectivity services available at the SWA-5 interface.
However, if two VNFCs within a VNF are deployed on the same host,
other technologies may be used to minimize latency and enhance
throughput, as described below.
o SWA-3: This is the interface to the VNF manager within the NFV
management and orchestration module. The VNF manager is
responsible for lifecycle management (creation, scaling, termination,
and so on). The interface typically is implemented as a network
connection using IP.
o SWA-4: This is the interface for runtime management of the VNF by
the element manager. o SWA-5:

173
 o This interface describes the execution environment for a deployable
instance of a VNF. Each VNFC maps to a virtualized container
interface to a VM.
5.2.2. VNFC to VNFC Communication:
• As mentioned earlier, the internal structure of a VNF, in terms of
multiple VNFCs, is not exposed externally. The VNF appears as a
single functional system in the network it supports. However, internal
connectivity between VNFCs within the same VNF or across co-
located VNFs needs to be specified by the VNF provider, supported
by the NFVI, and managed by the VNF manager.
• The VNF Architecture document describes a number of architecture
design models that are intended to provide desired performance and
quality of service (QoS), such as access to storage or compute
resources. One of the most important of these design models relates
to communication between VNFCs.
Figure 5.7, from the ETSI VNF Architecture document, illustrates six
scenarios using different network technologies to support communication
between VNFCs:
Communication through a hardware switch. In this case, the VMs
supporting the VNFCs bypass the hypervisor to directly access the
physical NIC. This provides enhanced performance for VNFCs on
different physical hosts.
Communication through the vswitch in the hypervisor. This is the basic
method of communication between co-located VNFCs but does not
provide the QoS or performance that may be required for some VNFs.
Greater performance can be achieved by using appropriate data
processing acceleration libraries and drivers compatible with the CPU
being used. The library is called from the vswitch. An example of a
suitable commercial product is the Data Plane Development Kit (DPDK),
which is a set of data plane libraries and network interface controller
drivers for fast packet processing on Intel architecture platforms.
Communication through an embedded switch (eswitch) deployed in the
NIC with Single Root I/O Virtualization (SRIOV). SR-IOV is a PCI-SIG
specification that defines a method to split a device into multiple PCI
express requester IDs (virtual functions) in a fashion that allows an I/O
memory management unit (MMU) to distinguish different traffic streams
and apply memory and interrupt translations so that these traffic streams
can be delivered directly to the appropriate VM, and in a way that
prevents no privileged traffic flows from impacting other VMs.
174
 1. Embedded switch deployed in the NIC hardware with SR-
IOV, and with data plane acceleration software deployed in
the VNFC.
2. A serial bus connects directly two VNFCs that have extreme
workloads or very low-latency requirements. This is
essentially an I/O channel means of communication rather
than a NIC means.

Figure 5.7 VNFC to VNFC Communication

[Link] Scaling :
• An important property of VNFs is referred to as elasticity, which
simply means the ability to scale up/down or scale out/in. Every
VNF has associated with it an elasticity parameter of no elasticity,
scale up/down only, scale out/in only, or both scale up/down and
scale out/in.
• A VNF is scaled by scaling one or more of its constituents VNFCs.
Scale out/in is implemented by adding/removing VNFC instances
that belong to the VNF being scaled. Scale up/down is implemented
by adding/removing resources from existing VNFC instances that
belong to the VNF being scaled.
175
5.3. NFV Management:
• The NFV management and orchestration (MANO) component of
NFV has as its primary function the management and orchestration
of an NFV environment. This task, by itself, is complex.
• Further complicating MANO functionality is its need to interoperate
with and cooperate with existing operations support systems (OSS)
and business support systems (BSS) in providing management
functionality for customers whose networking environment consists
of a mixture of physical and virtual elements.
• Figure 5.8, from the ETSI MANO document, shows the basic
structure of NFV-MANO and its key interfaces. As can be seen, there
are five management blocks: three within NFV-MANO, EMS
associated with VNFs, and OSS/BSS.
• These two latter blocks are not part of MANO but do exchange
information with MANO for the purpose of the overall management
of a customer’s networking environment.

Figure 5.8 The NFV-MANO Architectural Framework with

Reference Points
5.3.1. Virtualized Infrastructure Manager:
• Virtualized infrastructure management (VIM) comprises the
functions 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 virtualization.

176
 • A single instance of a VIM is responsible for controlling and
managing the NFVI compute, storage, and network resources,
usually within one operator’s infrastructure domain. This domain
could consist of all resources within an NFVI-PoP, resources across
multiple NFVI-PoPs, or a subset of resources within an NFVI-PoP.
To deal with the overall networking environment, multiple VIMs
within a single MANO may be needed.
• A VIM performs the following:
• Resource management, in charge of the o Inventory of software
(for example, hypervisors), computing, storage and network
resources dedicated to NFV infrastructure.
o Allocation of virtualization enablers, for example, VMs onto
hypervisors, compute resources, storage, and relevant
network connectivity.
o Management of infrastructure resource and allocation, for
example, increase resources to VMs, improve energy
efficiency, and resource reclamation
• Operations, for
o Visibility into and management of the NFV infrastructure
o Root cause analysis of performance issues from the NFV
infrastructure perspective
o Collection of infrastructure fault information
o Collection of information for capacity planning, monitoring,
and optimization.
5.3.2. Virtual Network Function Manager :
• A VNF manager (VNFM) is responsible for VNFs. Multiple VNFMs
may be deployed; a VNFM may be deployed for each VNF, or a
VNFM may serve multiple VNFs. Among the functions that a
VNFM performs are the following:
o VNF instantiation, including VNF configuration if required by
the VNF deployment template (for example, VNF initial
configuration with IP addresses before completion of the VNF
instantiation operation)
o VNF instantiation feasibility checking, if required
o VNF instance software update/upgrade
o VNF instance modification o VNF instance scaling out/in and
up/down

177
 o VNF instance-related collection of NFVI performance
measurement results and faults/events information, and
correlation to VNF instance-related events/faults
o VNF instance assisted or automated healing
o VNF instance termination
o VNF lifecycle management change notification
o Management of the integrity of the VNF instance through its
lifecycle
o Overall coordination and adaptation role for configuration and
event reporting between the VIM and the EM.
5.4. NFV Orchestrator :
• The NFV orchestrator (NFVO) is responsible for resource
orchestration and network service orchestration.
• Resource orchestration manages and coordinates the resources under
the management of different VIMs. NFVO coordinates, authorizes,
releases and engages NFVI resources among different PoPs or
within one PoP. This does so by engaging with the VIMs directly
through their northbound APIs instead of engaging with the NFVI
resources directly.
• Network services orchestration manages/coordinates the creation of
an endto-end service that involves VNFs from different VNFMs
domains.
• Service orchestration does this in the following way o It creates
end-to-end service between different VNFs. It achieves this by
coordinating with the respective VNFMs so that it does not need to
talk to VNFs directly. An example is creating a service between the
base station VNFs of one vendor and core node VNFs of another
vendor.
o It cans instantiate VNFMs, where applicable.
o It does the topology management of the network services
instances (also called VNF forwarding graphs).
5.4.1. Repositories:
• Associated with NFVO are four repositories of information needed
for the management and orchestration functions:
o Network services catalog: List of the usable network
services. A deployment template for a network service in
terms of VNFs and description of their connectivity through
virtual links is stored in NS catalog for future use.

178
 o VNF catalog: Database of all usable VNF descriptors. A VNF
descriptor (VNFD) describes a VNF in terms of its
deployment and operational behavior requirements. It is
primarily used by VNFM in the process of VNF instantiation
and lifecycle management of a VNF instance. The
information provided in the VNFD is also used by the NFVO
to manage and orchestrate network services and virtualized
resources on NFVI.
o NFV instances: List containing details about network
services instances and related VNF instances. o NFVI
resources: List of NFVI resources utilized for the purpose of
establishing NFV services.

5.4.2. Element Management :

• The element management is responsible for fault, configuration,

accounting, performance, and security (FCAPS) management
functionality for a VNF. These management functions are also the
responsibility of the VNFM. But EM can do it through a proprietary
interface with the VNF in contrast to VNFM.
• However, EM needs to make sure that it exchanges information with
VNFM through open reference point (VeEm-Vnfm). The EM may
be aware of virtualization and collaborate with VNFM to perform
those functions that require exchange of information regarding the
NFVI resources associated with VNF.
• EM functions include the following:
• Configuration for the network functions provided by the VNF o Fault
management for the network functions provided by the VNF
• Accounting for the usage of VNF functions
• Collecting performance measurement results for the functions provided
by the VNF
• Security management for the VNF functions

5.4.3. OSS/BSS:The OSS/BSS are the combination of the operator’s other operations
and business support functions that are not otherwise explicitly captured in the
present architectural framework, but are expected to have information exchanges
with functional blocks in the NFV-MANO architectural framework.

179
 • OSS/BSS functions may provide management and orchestration of
legacy systems and may have full end-to-end visibility of services
provided by legacy network functions in an operator’s network.
• In principle, it would be possible to extend the functionalities of
existing OSS/BSS to manage VNFs and NFVI directly, but that may
be a proprietary implementation of a vendor.
• Because NFV is an open platform, managing NFV entities through
open interfaces (as that in MANO) makes more sense. The existing
OSS/BBS, however, can add value to the NFV MANO by offering
additional functions if they are not supported by a certain
implementation of NFV MANO. This is done through an open
reference point (Os-Ma) between NFV MANO and existing
OSS/BSS.

5.5. NFV Use cases:

• ISG NFV has developed a representative set of service models

and highlevel use cases that may be addressed by NFV. These
use cases are intended to drive further development of standards
and products for network-wide implementation. The Use Cases
document identifies and describes a first set of service models
and high-level use cases that represent, in the view of NFV ISG
member companies, important service models and initial fields
of application for NFV, and that span the scope of technical
challenges being addressed by the NFV ISG. There are currently
nine use cases, which can be divided into the categories of
architectural use cases and service-oriented use cases, as
described in Table 5.4.

180
 TABLE 5.4 ETSI NFV Use Cases
5.5.1. Architectural Use Cases:
• The four architectural use cases focus on providing general-purpose
services and applications based on the NFVI architecture.
NFVI as a Service:
• NFVIaaS is a scenario in which a service provider implements and
deploys an NFVI that may be used to support VNFs both by the
NFVIaaS provider and by other network service providers. For the
NFVIaaS provider, this service provides for economies of scale. •
The infrastructure is sized to support the provider’s own needs for
deploying VNFs and extra capacity that can be sold to other
providers. The NFVIaaS customer can offer services using the NFVI
of another service provider.
• The NFVIaaS customer has flexibility in rapidly deploying VNFs,
either for new services or to scale out existing services. Cloud
computing providers may find this service particularly attractive.

181
 • Figure 5.9 provides an example [ONF14]. Service provider X offers
a virtualized load balancing service. Some of carrier X’s customers
need load balancing services at locations where X does not maintain
NFVI, but where service provider Z does.
• NFVIaaS offers a means for carrier Z to lease NFV infrastructure
(computer, network, hypervisors, and so on) to service provider X,
which gives the latter access to infrastructure that would otherwise
be prohibitively expensive to obtain. Through leasing, such capacity
is available on demand, and can be scaled as needed.

Figure 5.9 NFVIaaS Example

VNF as a Service:
• Whereas NFVIaaS is similar to the cloud model of Infrastructure as
a Service (IaaS), VNFaaS corresponds to the cloud model of
Software as a Service (SaaS).
• NFVIaaS provides the virtualization infrastructure to enable a
network service provider to develop and deploy VNFs with reduced
cost and time compared to implementing the NFVI and the VNFs.
With VNFaaS, a provider develops VNFs that are then available off
the shelf to customers. This model is well suited to virtualizing
customer premises equipment such as routers and firewalls.
Virtual Network Platform as a Service:
• VNPaaS is similar to an NFVIaaS that includes VNFs as components
of the virtual network infrastructure.
• The primary differences are the programmability and development
tools of the VNPaaS that allow the subscriber to create and configure
custom ETSI NFV-compliant VNFs to augment the catalog of VNFs
offered by the service provider.
• This allows all the third-party and custom VNFs to be orchestrated
via the VNF FG.

182
VNF Forwarding Graphs :
• VNF FG allows virtual appliances to be chained together in a flexible
manner. This technique is called service chaining.
• For example, a flow may pass through a network monitoring VNF, a
load-balancing VNF, and finally a firewall VNF in passing from one
endpoint to another. The VNF FG use case is based on an information
model that describes the VNFs and physical entities to the
appropriate management/orchestration systems used by the service
provider.
• The model describes the characteristics of the entities including the
NFV infrastructure requirements of each VNF and all the required
connections among VNFs and between VNFs and the physical
network included in the IaaS service.
• To ensure the required performance and resiliency of the end-to-end
service, the information model must be able to specify the capacity,
performance and resiliency requirements of each VNF in the graph.
To meet SLAs, the management and orchestration system will need
to monitor the nodes and linkages included in the service graph. In
theory, a VNF FG can span the facilities of multiple network service
providers.
5.5.2. Service-Oriented Use Cases:
• These use cases focus on the provision of services to end customers,
in which the underlying infrastructure is transparent.
Virtualization of Mobile Core Network and IP Multimedia Subsystem:
• Mobile cellular networks have evolved to contain a variety of
interconnected network function elements, typically involving a
large variety of proprietary hardware appliances.
• NFV aims at reducing the network complexity and related
operational issues by leveraging standard IT virtualization
technologies to consolidate different types of network equipment
onto industry standard high-volume servers, switches, and storage,
located in NFVI-PoPs.
Virtualization of Mobile Base Station :
• The focus of this use case is radio access network (RAN) equipment
in mobile networks. RAN is the part of a telecommunications system
that implements a wireless technology to access the core network of
the mobile network service provider.

183
 • At minimum, it involves hardware on the customer premises or in the
mobile device and equipment forming a base station for access to the
mobile network. There is the possibility that a number of RAN
functions can be virtualized as VNFs running on industry standard
infrastructure.
Virtualization of the Home Environment:
• This use case deals with network provider equipment located as
customer premises equipment (CPE) in a residential location. These
CPE devices mark the operator/service provider presence at the
customer premises and usually include a residential gateway (RGW)
for Internet and Voice over IP (VoIP) services (for example, a
modem/router for digital subscriber line [DSL] or cable), and a set-
top box (STB) for media services normally supporting local storage
for personal video recording (PVR) services.
• NFV technologies become ideal candidates to support this
concentration of computation workload from formerly dispersed
functions with minimal cost and improved time to market, while new
services can be introduced as required on a grow-as-you-need basis.
Further, the VNFs can reside on services in the network service
provider’s PoP. This greatly simplifies the electronics environment
of the home, reducing end user and operator capital expenditure
(CapEx).
Virtualization of CDNs:
• Delivery of content, especially of video, is one of the major
challenges of all operator networks because of the massive growing
amount of traffic to be delivered to end customers of the network.
The growth of video traffic is driven by the shift from broadcast to
unicast delivery via IP, by the variety of devices used for video
consumption and by increasing quality of video delivered via IP
networks in resolution and frame rate.
• Complementary to the growth of today’s video traffic, the
requirements on quality are also evolving: Internet actors are more
and more in position to provide both live and on-demand content
services to Internet end users, with similar quality constraints as for
traditional TV service of network operators. Some Internet service
providers (ISPs) are deploying proprietary Content Delivery
Network (CDN) cache nodes in their networks to improve delivery
of video and other high-bandwidth services to their customers.

184
 • Cache nodes typically run on dedicated appliances running on
custom or industry standard server platforms. Both CDN cache nodes
and CDN control nodes can potentially be virtualized. The benefits
of CDN virtualization are similar to those gained in other NFV use
cases, such as VNFaaS.
Fixed Access Network Functions Virtualization :
• NFV offers the potential to virtualized remote functions in the hybrid
fiber/copper access network and passive optical network (PON) fiber
to the home and hybrid fiber/wireless access networks.
• This use case has the potential for cost savings by moving complex
processing closer to the network. An additional benefit is that
virtualization supports multiple tenancy, in which more than one
organizational entity can either be allocated, or given direct control
of, a dedicated partition of a virtual access node.
• Finally, virtualizing broadband access nodes can enable synergies to
be exploited by the co-location of wireless access nodes in a common
NFV platform framework (that is, common NFVI-PoPs), thereby
improving the deployment economics and reducing the overall
energy consumption of the combined solution.
The data in Table 5.5 indicates that although IT organizations have interest
in a number of the ETSI-defined use cases, by a wide margin they are most
interested in the NFVIaaS use case.

TABLE 5.5 Interests in ETSI NFV Use Cases

5.6. SDN and NFV:
• Over the past few years, the hottest topics in networking have been
SDN and NFV. Separate standards bodies are pursuing the two
technologies, and a large, growing number of providers have
announced or are working on products in the two fields.
185
• Each technology can be implemented and deployed separately, but
there is clearly a potential for added value by the coordinated use of
both technologies.
• It is likely that over time, SDN and NFV will tightly interoperate to
provide a broad, unified software-based networking approach to
abstract and programmatically control network equipment and
network-based resources.
• The relationship between SDN and NFV is perhaps viewed as SDN
functioning as an enabler of NFV. A major challenge with NFV is to
best enable the user to configure a network so that VNFs running on
servers are connected to the network at the appropriate place, with
the appropriate connectivity to other VNFs, and with desired QoS.
• With SDN, users and orchestration software can dynamically
configure the network and the distribution and connectivity of VNFs.
Without SDN, NFV requires much more manual intervention,
especially when resources beyond the scope of NFVI are part of the
environment.
• The Kemp Technologies Blog [MCMU14] gives the example of load
balancing where load balancer services are implemented as VNF
entities. If demand for load-balancing capacity increases, a network
orchestration layer can rapidly spin up new load-balancing instances
and also adjust the network switching infrastructure to accommodate
the changed traffic patterns. In turn, the load-balancing VNF entity
can interact with the SDN controller to assess network performance
and capacity and use this additional information to balance traffic
better, or even to request provisioning of additional VNF resources.
Some of the ways that ETSI believes that NFV and SDN complement each
other include the following:
o The SDN controller fits well into the broader concept of a network
controller in an NFVI network domain. o SDN can play a significant
role in the orchestration of the NFVI resources, both physical and
virtual, enabling functionality such as provisioning, configuration of
network connectivity, bandwidth allocation, automation of operations,
monitoring, security, and policy control.
o SDN can provide the network virtualization required to support
multitenant NFVIs.
o Forwarding graphs can be implemented using the SDN controller to
provide automated provisioning of service chains, while ensuring
strong and consistent implementation of security and other policies.
186
 o The SDN controller can be run as a VNF, possibly as part of a service
chain including other VNFs. For example, applications and services
originally developed to run on the SDN controller could also be
implemented as separate VNFs.
Figure 5.10, from the ETSI VNF Architecture document, indicates the
potential relationship between SDN and NFV. The arrows can be described
as follows:
o SDN enabled switch/NEs include physical switches, hypervisor virtual
switches, and embedded switches on the NICs. o Virtual networks
created using an infrastructure network SDN controller provide
connectivity services between VNFC instances. o SDN controller can
be virtualized, running as a VNF with its EM and VNF manager. Note
that there may be SDN controllers for the physical infrastructure, the
virtual infrastructure, and the virtual and physical network functions.
As such, some of these SDN controllers may reside in the NFVI or
management and orchestration (MANO) functional blocks (not shown
in figure).
o SDN enabled VNF includes any VNF that may be under the control of
an SDN controller (for example, virtual router, virtual firewall).
o SDN applications, for example service chaining applications, can be
VNF themselves.
o Nf-Vi interface allows management of the SDN enabled infrastructure.
o Ve-Vnfm interface is used between the SDN VNF (SDN controller
VNF, SDN network functions VNF, SDN applications VNF) and their
respective VNF Manager for lifecycle management.
o Vn-Nf allows SDN VNFs to access connectivity services between
VNFC interfaces.

187
 FIGURE 5.10 Mapping of SDN Components with NFV Architecture

5.6.1. Difference between SDN and NFV:

SDN NFV

SDN architecture mainly focuses

NFV is targeted at service providers or operators.
on data centers.

NFV helps service providers or operators to

SDN separates control plane and
virtualize functions like load balancing, routing,
data forwarding plane by
and policy management by transferring network
centralizing control and
functions from dedicated appliances to virtual
programmability of network.
servers.

SDN uses OpenFlow as a

There is no protocol determined yet for NFV.
communication protocol.

188
 SDN NFV

SDN supports Open Networking

NFV is driven by ETSI NFV Working group.
Foundation.

Various enterprise networking

Telecom service providers or operators are prime
software and hardware vendors are
initiative supporters of NFV.
initiative supporters of SDN.

Corporate IT act as a Business Service providers or operators act as a Business

initiator for SDN. initiator for NFV.

SDN applications run on

industrystandard servers or NFV applications run on industry-standard servers.
switches.

NFV increases scalability and agility as well as

SDN reduces cost of network
speed up time-to-market as it dynamically allot
because now there is no need of
hardware a level of capacity to network functions
expensive switches & routers.
needed at a particular time.

Application of NFV:
• Routers, firewalls, gateways
Application of SDN:
• WAN accelerators
• Networking
• SLA assurance
• Cloud orchestration
• Video Servers
• Content Delivery Networks (CDN)

PART- A
1. What is the functionality of NFV?
NFV allows virtual network function to run on a standard generic server,
controlled by a hypervisor, which is far less expensive than purchasing
proprietary hardware devices. Network configuration and management is
much simpler with a virtualized network.

189
 2. What is a VNF network function?
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.
3. What is the function of network virtualization?
Network virtualization helps organizations achieve major advances in speed,
agility, and security by automating and simplifying many of the processes
that go into running a data center network and managing networking and
security in the cloud.
4. What is difference between VNF and CNF?
CNFs encapsulate your physical network functions (PNF) and virtual
network functions (VNF) into containers. You get many VNF benefits but
VM (Virtual Machine) software overhead is no longer a concern. Containers
do not need a guest operating system or hypervisor, and container CNFs may
be spun up and down as required.
5. What is an example of NFV?
Examples include firewalls, software-defined WAN (SD-WAN), routing,
and Quality of Service (QoS). Management, Automation and Network
Orchestration (MANO): NFV MANO performs management and
orchestration of VNFs within the NVFI.
6. What is difference between NFV and SDN?
Takeaway. NFV and SDN both utilize software components, but the two are
fundamentally different. NFV converts network processes themselves into
software applications, while SDN virtualizes the management of networks
so you can gain from features like application-based traffic prioritization.
7. What is VNF vs NFV?
The relationship between NFV and VNF is similar to that between SDN and
SD-WAN: NFV is an architecture guiding management and orchestration
activities, whereas a VNF is the technology providing virtual (that is,
hardwareindependent) network functions such as routing or firewalling.
8. What is the full form of NFV?
Overview. Network functions virtualization (NFV) is a way to virtualized
network services, such as routers, firewalls, and load balancers, that have
traditionally been run on proprietary hardware.

190
9. What is the main function of the VNF manager?
VNFMs are necessary for scaling, changing operations, adding new
resources, and communicating the states of VNFs to the NFVO. The NFVO
coordinates with the VNFM to instantiate VNFs and manages the
deployment of network services, which are made up of VNFs.
10. Where is NFV used?
NFV allows for the separation of communication services from dedicated
hardware, such as routers and firewalls. This separation means network
operations can provide new services dynamically and without installing new
hardware.
11. What is NFV in 5G?
Network functions virtualization (NFV) is when hardware-based networking
functions are turned into software that can run on commodity hardware. NFV
is used in 5G networks because 5G must have the advantages of software to
meet the expectations that the industry and standards bodies have
established.
12. What are the different types of virtualizations?
a Server virtualization. Server virtualization is a process that
partitions a physical server into multiple virtual servers. ...
b Storage virtualization. ...
c Network virtualization. ...
d Data virtualization. ...
e Application virtualization. ...
f Desktop virtualization.
13. What is the NFV infrastructure?
Network Functions Virtualization (NFV) is a framework built upon the
European Telecommunications Standards Institute (ETSI) NFV architectural
model to virtualized networking infrastructure and platform resources such
as compute, storage, and networking.
14. What are the components of NFV architecture?
The major components of an NFV architecture include the VNFs, the NFV
infrastructure (NFVI) and the NFV management and network orchestration
(MANO).
15. What is the advantage of NFV?
NFV reduces the need for dedicated hardware to deploy and manage
networks by offloading network functions into software that can run on
industry-standard hardware and can be managed from anywhere within the
operator's network.

191
16. What is management and orchestration?
NFV MANO (Management and Orchestration) is the framework for the
management and orchestration of all network resources in the cloud. This
includes computing, networking, storage and virtual machine (VM)
resources.
17. What is VNF orchestration?
Network functions virtualization (NFV) Orchestration (NFVO) coordinates the
resources and networks needed to set up cloud-based services and applications. This
process uses a variety of virtualization software and industry-standard hardware.
18. What is the network function virtualization orchestrator?
The NFV orchestrator (NFVO) is a key component of the NFV MANO (network
functions virtualization management and network orchestration) architectural
framework, which helps standardize the functions of virtual networking to increase
interoperability of software-defined networking (SDN) elements.
19. Which kind of orchestration is NFVO?
The NFVO is a functional element of MANO (Management and
Orchestration), providing a critical role in the on-boarding and instantiation
of VNFs (Virtualized Network Functions) and Network Services. The NFVO
will also be involved in scale up/down of resources.
20. What is the difference between network management and orchestration?
Network management refers to functions for administering and operating
networks. A central network management system, usually the network
controller, uses its automation and orchestration capabilities to perform these
functions. In other words, network orchestration is a subset of network
management.
21. Where is orchestration used?
Container orchestration can be used in any computing environment that
supports containers, from traditional on-premises servers to public, private,
hybrid, and multicloud computing environments.
22. Which two are roles of network orchestration?
Network orchestration is a way of bringing automation and virtualization to
the network functions and services. This helps service providers in delivering
secure and quick services to their customers while making their business
models more agile and efficient.
23. What are the benefits of network orchestration?
• Reduce human error. ...
• Instant, secure connectivity. ...
• Efficient issue resolution. ...
• Greater scalability with APIs. ...

192
 • Enhance tooling opportunities. ...
• Easier data management.
23. Which are the two main types of network management protocol?
The most common types of network management protocols include Internet
Control Message Protocol (ICMP) and Simple Network Management
Protocol (SNMP).
24. What is SDN and NFV?
SDN allows networks to be centrally controlled via software applications
that use open APIs. While NFV divides the network functions from the
hardware components so that they can run in software.
25. Which is better SDN or NFV?
Although SDN is typically used at a much smaller enterprise scale, NFV
tends to be more beneficial for service providers, like telecom companies
that offer their services to hundreds or thousands of customers.
PART -B
1. Explain the NFV Infrastructure
2. Explain the NFV Management and Orchestration
3. Explain the detail about NFV Use cases
4. Describe the SDN and NFV
5. Explain the Virtualized Network Functions

193
*************

194