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).

 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, and this single point of failure represents a potential vulnerability of
SDN.
 SDN simplifies data communication in the network (IoT, Cloud, Computer
Networks, NFV etc).
 The Router has a Control Plane and a Data forwarding Plane.
 Control Plane does the computational task for routing and Data Forwarding Plane
does the transfer of data packets.
 SND simply removes the control plane task of the routers.
 Routing decisions are now taken care by the SDN controller in the SDN.
 SDN controllers maintain a unified view of the network & make configuration,
management, and provisioning simpler.
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 patterns, and quality of service requirements.
 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
 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

POX
 Definition: POX is an open-source SDN controller written in Python. It is used
for managing and controlling networks created in Mininet.
 Functionality: POX communicates with the switches 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 GPLsince

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.

 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 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 fordeveloping SDN applications.
 POX controller provides an efficient way to implement the OpenFlow protocol
which is the de facto 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
OpenFlow messages
 OpenFlow messages are sent and received between the controller and the
datapaths (OpenFlow instances or devices) it manages. These messages are byte
streams, the structure of which is documented in the OpenFlow Protocol
Specification documents published by the Open Networking Foundation (ONF).
 The controller handles the connections from OpenFlow switches and provides the
means for upper layers of software to interact with those switches via the
ControllerService interface,
 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

 Open Flow : three message types

 These messages are:

 • Controller to Switch
 • Asynronous
 • Symmetric

 Controller to Switch Messages are the massages that are initiated by the
controller used to 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.

 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
controllers.

 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.

Fi