Module 6

Software Defined Networks

SDN
• What is SDN? Explain the concept of control plane and data plane
with respect to SDN
• What is SDN? Explain SDN architecture along with Operations of
control and data planes
Software-defined networking (SDN)

• It is an approach to network management that enables dynamic, programmatically

efficient network configuration to improve network performance and monitoring.

• 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).
Components of Software Defining
Networking (SDN)
The three main components that make the SDN are:

• SDN Applications: SDN Applications relay(transmits) requests or

networks through SDN Controller using API.

• SDN Controller: SDN Controller collects network information from

hardware and sends this information to applications.

• SDN Networking Devices: SDN Network devices help in forwarding

and data processing tasks.
How is SDN different from Traditional Networking?
SDN is software-based, while traditional networking is hardware-based.
Because the control plane is software-based, SDN is much more flexible
than traditional networking. It allows administrators to control the network,
change configuration settings, provision resources, and increase network
capacity—all from a centralized user interface, without adding more
hardware.
security differences between SDN and traditional networking. SDN offers
better security in many ways. However, because SDN use a centralized
controller, securing the controller is crucial to maintaining a secure network,
A typical SDN architecture consists of three layers.
• Application Layer: The application layer is the top layer of the SDN
architecture and is responsible for providing network services and applications
to end-users. This layer consists of various network applications that interact
with the control layer to manage the network. It contains the typical network
applications like intrusion detection, firewall, and load balancing

• Infrastructure Layer: This layer is the bottom layer of the SDN architecture,
also known as the data plane. It consists of physical and virtual network devices
such as switches, routers, and firewalls that are responsible for forwarding
network traffic based on the instructions received from the control plane.
• Control Layer: It consists of the SDN controller which acts as the brain of the
network. It also allows hardware abstraction to the applications written on top of
it. The control layer is the middle layer of the SDN architecture, also known as the
control plane. It consists of a centralized controller that communicates with the
infrastructure layer devices and is responsible for managing and configuring the
network.

• The controller interacts with the devices in the infrastructure layer using protocols
such as Open Flow to program the forwarding behaviour of the switches and
routers. The controller uses network policies and rules to make decisions about
how traffic should be forwarded based on factors such as network topology, traffic
 Data Plane
• It is the part of a network device responsible for forwarding data packets from one
interface to another based on the destination address contained in the packet
header.
• It is also referred to as the forwarding plane or the user plane.
• Encapsulate and decapsulate packets
• Adding or removing headers
• Segmentation and reassembly of data.
• Replication of packets for multicasting.
Some examples of data planes include:
• Ethernet networks
• Wi-Fi networks
• Cellular networks
• Satellite communications
 control plane
• The control plane is a crucial network component,brain of the network,
making decisions on how data should be managed, routed, and processed.
It acts as a supervisor of data, coordinating communication between
different components and collecting data from the data plane.

The activities of the control plane include:

• Making routing tables.
• Setting packet handling policies.
Control planes utilize various protocols, such as:
• Routing protocols (like BGP, OSPF, and IS-IS)
• Network management protocols (SNMP)
• Application layer protocols (HTTP and FTP)
• These protocols often employ software-defined networking (SDN) to create
virtual networks and manage their traffic. Virtual networks, facilitated by
SDN, are instrumental in managing data traffic at an enterprise level. They
enable organizations to:

• Segment traffic

• Prioritize important data flows

• Isolate traffic from different parts of the network

 Elaborate the architecture of Nox and Pox
controller of SDN with their comparison.
• POX

• Definition: POX is an open-source SDN controller written in Python. It is used

for managing and controlling networks created in Mininet.
• Mininet is used as a learning tool to test, experiment, and learn about software-
defined networks.
• Functionality: POX communicates with the switches( the switch is the data plane that forwards packets based on
instructions from a centralized control plane) in a Mininet topology using the OpenFlow protocol. It

allows developers to implement custom networking applications and protocols.

• Use Case: POX is typically used in educational settings and for prototyping
because of its simplicity and ease of use.
• NOX is the original OpenFlow controller. It serves as a network control
platform, that provides a high level programmatic interface for management
and the development of network control applications. Its system-wide
abstractions turn networking into a software problem.
• initially developed by Nicira Networks and now owned by VMware, along
with OpenFlow — was first introduced to the community in 2009. This was
later divided into multiple different lines of development:

• NOX classic: This is the version that has been available under the GPL since
2009.
• NOX: The “new NOX.” Only contains support for C++ and has lesser
applications than the classic; however, this version is faster and has better
codebase.
• POX: Typically termed as NOX’s sibling. Provides Python support.
NOX Architecture
NOX is a Software-Defined Networking (SDN) controller with a modular architecture that acts as
an operating system for networks, separating the control plane from the data plane.
Its components include a Northbound API for applications to communicate with the controller, a
Controller Core that processes network events and makes forwarding decisions, and a
Southbound Interface (typically using the OpenFlow protocol) to manage network devices.
Applications running on top of NOX can program the network's behavior by installing flow rules
into the switches

Key components of NOX architecture

● Northbound API: This is the interface for applications to interact with the controller. It allows developers to create network
management applications, retrieve network state information, and influence the network's behavior.
● Controller Core: This is the central processing unit of the system. It handles network events, processes packets, and uses the
logic from applications to make forwarding decisions. The core provides helper functions for tasks like threading and input/output
operations.
● Southbound Interface (OpenFlow): This interface allows the NOX controller to communicate with network switches and routers.
It uses the OpenFlow protocol to install flow entries (which consist of matching header fields and corresponding actions) directly
into the forwarding tables of the switches.
● Applications: These are high-level programs that run on the controller and define how the network operates. They can be
network-wide management tools that decide how packets are routed.
● Internal components: Other components include an event dispatcher and a connection manager to handle communication, as
How it works
● Packet arrival: When a packet arrives at a switch, the switch checks its flow table for a matching entry.
● Forwarding decision:
● If a match is found, the switch performs the corresponding action (e.g., forward to a specific port,
drop the packet, or modify packet headers).

● If no match is found, the switch can be configured to send the packet to the NOX controller for a
decision.

● Controller logic: The NOX controller's application logic receives the packet, processes it, and
determines the appropriate action. This can involve looking at the network's state, which is maintained
by the controller.
● Rule installation: The controller then uses the OpenFlow southbound interface to install a new flow
entry into the switch's flow table. This new rule ensures that subsequent packets with the same header
will be handled correctly without needing to consult the controller again.
• Figure above depicts the architecture of NOX. The NOX core provides
helper methods, such as network packet process, threading and event engine,
in addition to OpenFlow APIs for interacting with OpenFlow switches, and
I/O operations support.

• At the top, we have applications: Core, Net and Web.

• However, with the current NOX version, there are only two core
applications: OpenFlow and switch, and both network and web applications
are missing.
• The middle layer shows the in-built components of NOX.
• The connection manager, event dispatcher and OpenFlow manager are self-
explanatory, whereas the dynamic shared object (DSO) deployer basically
scans the directory structure for any components being implemented as
DSOs.
• The event system is another important concept of the NOX controller.
• An event represents a low-level or high-level event in the network.
• Typically the event only provides the information, and processing of that
information is deferred to handlers.
• Many events roughly correlate to something which happens on the network
that may be of interest to a NOX component.
• These components, typically, consists a set of event handlers. In this sense,
events drive all execution in NOX.
• NOX events can be broadly classified as core events and application events.
• The core events map directly to OpenFlow messages received by controlled
switches, such as:
In addition to core events, components themselves may define and throw
higher level events which may be handled by any other events.
 POX
• POX is a Python based open source OpenFlow/Software Defined Networking (SDN)
Controller. POX is used for faster development and prototyping of new network
applications.
• POX is an open source controller for developing SDN applications.
• POX controller provides an efficient way to implement the OpenFlow protocol which is
the communication protocol between the controllers and the switches.
• Using POX controller you can run different applications like hub, switch, load balancer,
and firewall
• Tcpdump packet capture tool can be used to capture and see the packets flowing
between POX controller and OpenFlow devices.
• Communication between the controller and the switches is carried by communication
protocol such as OpenFlow , ForCES (Fig. 1).
• OpenFlow is the most popular standard protocol used in SDN. OpenFlow switches
behave as dumb forwarding devices.
• They are unable to perform any actions without programmed by the controller.
• When a switch is powered on, it will immediately connect to an OpenFlow
controller.
• Initially, the flow table of the switches is empty.
• When a packet arrives at a switch, it does not know, how this packet is to be
handled. Then it send packet-in message to the controller.
• To handle the packet, controller inserts a flow entries in flow table of switch.
• Flow entry in flow table contains three parts, rule(match field), action,
counters.
• For each packet, that has to pass through a switch, a flow entry will have to be
installed so that the switch can forward this traffic without further intervention
of the controller .
• Flow modification messages are sent to the switches to install the flow entries
in flow table (Fig. 2).
• Once these are installed, traffic belonging to this flow will be handled by the
switches themselves.
Fig 1: POX Architecture
 Open Flow Message
• OpenFlow messages are the communication units between a controller and a switch in a
network, used for configuring network behavior.
• Open Flow messages are sent and received between the controller and the data
paths (Open Flow instances or devices) it manages. These messages are byte
streams, the structure of which is documented in the Open Flow Protocol
• There are five main parts in Open Flow Messages.
• Version
• Type
• Message Lenght
• Transaction ID (A unique value section used to match requests for response)
• Payload
OpenFlow messages
Open Flow : three message types
These messages fall into three main categories: controller-to-switch ( asynchronous , and
symmetric . These messages are:

• Controller to Switch(for managing and configuring the switch),

• Asynronous(from the switch to inform the controller of events)
• Symmetric(sent by either party for tasks like diagnostics)

Key examples include FLOW_MOD for modifying flow tables, PORT_MOD for port control, and
PACKET_OUT for sending packets.

• Controller to Switch Messages are the massages that are initiated by the
controller used to examine the status and state of the flow table of the
switches . They managed the Flow Tables. Switch capability exchange is also
done with these messages.
● Message categories
● Controller-to-Switch: Initiated by the controller to manage the
switch, these messages are used for configuration and direct
management.
● FLOW_MOD: Modifies flow table entries, allowing the controller
to define, add, remove, or change how the switch handles
specific types of packets.
● PORT_MOD: Changes port properties, such as enabling or
disabling a port.
● PACKET_OUT: Tells the switch to send a specific packet out of a
port.
● FEATURES_REQUEST: The controller asks the switch for
● Asynchronous: Initiated by the switch to inform the controller about events or changes.

● Packet-in: T he switch sends a packet to the controller if it has no

matching flow rule.
● Port status messages: Notify the controller when a port is
added, removed, or goes up/down.
● Symmetric: These messages can be initiated by either the
controller or the switch, often used for diagnostics.
● HELLO: A handshake message used at the start of the connection
to exchange supported OpenFlow versions.
● ECHO_REQUEST / ECHO_REPLY: Used to check the status of the
connection between the switch and controller
How they work
● Communication channel: OpenFlow messages travel over a secure
channel, typically encrypted with TLS, and run on top of TCP.
● Dynamic configuration: The controller uses these messages to program
the switch's flow tables, which are a set of rules for handling network traffic.
This allows for fine-grained control over how packets are forwarded,
dropped, or sent to the controller.
● Connection setup: During initialization, a switch might send a HELLO
message to the controller, and the controller might respond with a
FEATURES_REQUEST to discover the switch's capabilities, with the switch
 Controller-to-switch messages
• Controller-to-switch messages are initiated by the controller and used to directly
manage or inspect the state of the switch. Controller-to-switch messages might or
might not require a response from the switch.
The controller-to-switch messages include the following subtypes:
• Features—The controller requests the basic capabilities of a switch by sending a
features request. The switch must respond with a features reply that specifies the
basic capabilities of the switch.
• Configuration—The controller sets and queries configuration parameters in the
switch. The switch only responds to a query from the controller.
• Modify-State—The controller sends Modify-State messages to manage state on
the switches. Their primary purpose is to add, delete, and modify flow or group
entries in the OpenFlow tables and to set switch port properties.
• Read-State—The controller sends Read-State messages to collect various
information from the switch, such as current configuration and statistics.
• Packet-out—These are used by the controller to send packets out of the specified
port on the switch, or to forward packets received through packet-in messages.
Packet-out messages must contain a full packet or a buffer ID representing a
packet stored in the switch. The message must also contain a list of actions to be
applied in the order they are specified. An empty action list drops the packet.
• Barrier—Barrier messages are used to confirm the completion of the previous
operations. The controller send s Barrier request. The switch must send a Barrier
reply when all the previous operations are complete.
• Role-Request—Role-Request messages are used by the controller to set the role
of its OpenFlow channel, or query that role. It is typically used when the switch
connects to multiple controllers.
• Asynchronous-Configuration—These are used by the controller to set an
additional filter on the asynchronous messages that it wants to receive, or to
query that filter. It is typically used when the switch connects to multiple
 Asynchronous messages
• Switches send asynchronous messages to controllers to inform a packet arrival or
switch state change. For example, when a flow entry is removed due to timeout,
the switch sends a flow-removed message to inform the controller.
The asynchronous messages include the following subtypes:
• Packet-In— For all packets forwarded to the Controller reserved port using a
flow entry or the table-miss flow entry, a packet-in event is always sent to
controllers. It transfers the control of the packets to the controller. Flow-
Removed—Inform the controller about the removal of a flow entry from a flow
table. These are generated due to a controller flow delete request or the switch
flow expiry process when one of the flow timeouts is exceeded.
• Port-status—Inform the controller of a state or setting change on a port.
• Error—Inform the controller of a problem or error.
 Symmetric messages
• Symmetric messages are sent without solicitation, in either direction.
• Symmetric Messages are used to diagnose any problems between Controller
and Switches. and can be sent both from Contoller and Switches.
The symmetric messages contain the following subtypes:
• Hello—Hello messages are exchanged between the switch and controller upon
connection startup.
• Echo—Echo request or reply messages can be sent from either the switch or
the controller, and must return an echo reply. They are mainly used to verify
the liveness of a controller-switch connection, and might also be used to
measure its latency or bandwidth.