This document provides an overview of software defined networks (SDN) and OpenFlow protocol. It discusses the limitations of traditional networks and how SDN addresses these issues by decoupling the control plane from the data plane. The key components of the SDN architecture are described, including the control layer with SDN controllers, the infrastructure layer with OpenFlow switches, and the application layer. The document also covers the OpenFlow protocol for communication between controllers and switches, including message types. Examples of SDN controllers like NOX and POX are also mentioned.

1. Software Defined Network(SDN)
- Trupti Lotlikar
Fr. Conceicao Rodrigues Institute of
Technology
Vashi _NaviMumbaiJ.

2. Contents to be covered
• Limitations of Traditional Networks
• SDN
• Architecture of SDN
• Building Blocks of SDN
• Open Flow Protocol
• Open Flow Messages
• Open Flow Controllers
• Open Flow in Cloud Computing
• Lab Implementations

3. © 2007 Cisco Systems, Inc. All rights reserved. DESGN v2.0—1-3
IT Evolution—
From Connectivity to Intelligent Systems

4. ©
What is Enterprise Network?
An enterprise network is an enterprise's communications backbone that helps
connect computers and related devices across departments and workgroup networks,
facilitating insight and data accessibility with intelligence

5. LIMITATIONS OF EXISTING NETWORKS
• •Enterprise networks are difficult to manage
• Difficult to perform real world experiments on large scale production
networks.
• • Research stagnation-huge costly equipment to be procured and
networks to be setup by each team for research
• • Rate of innovation in networks is slower as protocols are defined in
isolation-lack of high level abstraction.
• • Closed systems
• • Hard to collaborate meaningfully due to lack of standard open
interfaces.
• • Vendors starting to open-up but not meaningfully.
• • Innovation is limited to vendor/vendor partners
• • Huge barriers for new ideas in networking.

6. Limitations of Traditional networks
• The characteristics of the traditional
approach are as follows:
• Complex Architecture.
• Variable Policies
• Scalability Issue
• Vendor Dependence

10. Difference Between Traditional Network And
SDN
• The control and data planes are combined
• in a network node.
• The control plane logic is decoupled from
the forwarding plane and has the ability to
control, change and manage network
behavior dynamically through software, via
open Application Program interface (API).

11. Limitations of Current Networks
11
Million of lines
of source code
Billions of gates
Many complex functions baked
into infrastructure
OSPF, BGP, multicast,
differentiated services,
Traffic Engineering, NAT,
firewalls, …
Specialized Packet
Forwarding Hardware
Operating
System
Feature Feature
• Cannot dynamically change according to network conditions.
• In this traditional methodology, once the flow management (forwarding policy)
has been defined, the best way to make an adjustment to the policy is by means
of changes to the configuration of the devices

12. Limitations of Current Networks
• Old ways to configure a network
12
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
Operating
System
Operating
System
Operating
System
Operating
System
Operating
System
App App App
. The control plane is responsible for configuration
of the node and programming the paths to be used
for data flows. Once these paths have been
determined, they are pushed down to the data plane.

13. Idea: An OS for Networks
13
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
App App App
Specialized Packet
Forwarding Hardware
Operating
System
Operating
System
Operating
System
Operating
System
Operating
System
App App App
Network Operating System
Control Programs

14. Idea: An OS for Networks
14
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware Simple Packet
Forwarding
Hardware
Network Operating System
Control Programs
•The key is to have a standardized control interface that
speaks directly to hardware
•Control is moved out of the individual network nodes
and into the separate, centralized controller. SDN
switches are controlled by a network operating system
(NOS) that collects information using the API

15. Difference between traditional
networks and SDN

20. NEED FOR SDN
• • Facilitate innovation in network.
• • Layered architecture with standard Open interfaces.
• • Experiment and research using non-bulky, non-
expensive equipment.
• • More accessibility since software can be easily
developed by more vendors.
• • More flexibility with programmability.
• • Ease of customization and integration with other
software Applications
• Program a network vs. configure a network

21. 21
Global Network View
Protocols Protocols
Control via
forwarding
interface
Network Operating System
Control Programs
Software-Defined Networking (SDN)
A remote controller has control of a switch’s forwarding decisions

22. WHAT IS SDN?
What is SDN?
SDN(Software Defined
Network) decouples the
control and data planes,
wherein a logically
centralized controller
performs forwarding
decisions on behalf of
switches.

25. ARCHITECTURE OF SDN
• In the SDN architecture, the control and data planes are
decoupled, network intelligence and state centralized, and the
underlying network infrastructure is abstracted from the
applications.

26. SDN LAYERS
• Infrastructure layer/Data Plane
• Consists of both physical and virtual network devices such as
switches and routers.
• The SDN networking devices control the forwarding and data
processing capabilities for the network.
• All the network devices will implement OpenFlow protocol to
implement traffic forwarding rules.
• Processing and delivery of packets is based on state in routers and
endpoints

27. • Control layer:
• This layer consists of a centralized control plane that is decoupled from
the physical infrastructure to provide centralized global view to entire
network .
• The SDN controller is a logical entity that receives instructions or
requirements from the SDN application layer and relays them to the
networking components and viceversa.
• Determines how and where packets are forwarded e.g Routing, traffic
engineering, firewall state, …
• The layer will use OpenFlow protocol to communicate with below
layer i.e. infrastructure layer.
• Application layer:
• It consists of network services, application and orchestration tools that
are used to interact with control layer.
• It provide an open interface to communicate with other layers in the
architecture.

28. SDN Building blocks

29. Building blocks
• The SDN controller,
• SDN Switch (i.e OpenFlow switch),
• The interfaces present on the controller for communication with forwarding
devices, i.e southbound interface (OpenFlow)
• Network applications interface (northbound interface)
• SDN Applications and Interfaces:
• SDN applications are programs that communicate behaviors and needed
resources with the SDN controller via application programming interfaces
(APIs).
• The SDN architecture APIs are often referred to as the northbound and the
southbound interfaces, defining the communication amongst the applications,
the controllers, and the networking systems.
• The northbound interface is defined as the connection between the
controller and the applications, whereas the Southbound interface is the
connection between the controller and the physical networking hardware

30. Building Blocks
• SDN Controller:
• The SDN controller is a logical entity that receives instructions or
requirements from the application layer and relays them to the
networking components.
• The controller also extracts information about the network from the
hardware devices and communicates back to the SDN applications with
an abstract view of the network.
• SDN Networking Devices (Openflow Switch):
• The SDN networking devices control the forwarding and data
processing capabilities for the network

31. Open Flow protocol
•The switch and controller
communicate by means of the
OpenFlow protocol.
•OpenFlow is a protocol that
allows a server to
tell network switches where to
send packets.
•OpenFlow allows switches from
different vendors to be managed
remotely using a single, open
protocol, hence can consider
OpenFlow as an enabler
of software defined
networking (SDN).

32. OPENFLOW PROTOCOL
• OPENFLOW is an open API that provides a standard interface for
programming the data plane switches. OpenFlow is a protocol that allows
a server to tell network switches where to send packets.
•In a conventional network, each switch has proprietary software that tells
it what to do.
• With OpenFlow, the packet-moving decisions are centralised, so that the
network can be programmed independently of the individual switches .
• An OpenFlow protocol enables network controllers to determine the
path of network packets across a network of switches
• • OpenFlow protocol can instruct switches and routers to direct the
traffic by providing software-based access to flow tables that can be
used to quickly change the network layout and traffic flows as per users
requirements

33. OpenFlow
33
Data Path (Hardware)
Control Path OpenFlow
OpenFlow Controller
OpenFlow Protocol (SSL/TCP)

34. Open-Flow Switch
• An OpenFlow Switch contain one or more flow tables that implement
packet lookups and forwarding, and an OpenFlow channel to link to an
external controller .
The switch interconnects with the controller and the controller directs the
switch using the OpenFlow protocol

35. OPENFLOW CONTROLLER
.
• The controller can delete, add or update flow entries in flow
tables existing in the switch, both reactively i.e. in response to
packets or proactively, using the OpenFlow protocol.
• Controller make this decision based on policies set by
administrator or depending on the conditions of the network
and the decision it makes is forwarded to flow table entries of all
the switches in the network.

36. Openflow protocol-message types
• OpenFlow protocol consists of a number of message types
that are used for communication between the switch and
the controller.
• These messages can be classified into three groups:
• 1) Controller to switch messages,
• 2) Asynchronous messages
• 3) Symmetric messages.

37. • Controller-to-switch messages: are initiated by the controller and used to
manage or inspect the state of the switch.
• Features: The controller may request the capabilities of the switch by sending a
features request
• Configuration: The controller is able to set and query configuration parameters
in the switch.
• Modify-State: The modify-state messages are sent by the controller to manage
state of the switches. Their primary purpose is to add, delete and modify the
flow/group entries in the OpenFlow tables and to set switch port properties.
• Read-State: The read-state messages are used by the controller to collect various
information from the switch, such as current configuration, statistics and
capabilities.

38. Packet-out: These are used by the controller to send packets out of a specified
port on the switch, and to forward packets received via packet-in messages.
Barrier: The barrier request/reply messages are used by the controller to ensure
message dependencies have been met or to receive notifications for completed
operations.
Role-Request: The role-request messages are used by the controller to set the
role of its OpenFlow channel, or query that role..
Asynchronous-Configuration: The asynchronous-configuration messages are
used by the controller to set an additional filter on the asynchronous messages
that it wants to receive on its OpenFlow channel, or to query that filter.

39. • B) Asynchronous messages are initiated by the switch and used to
update the controller of network events and changes to the state of the
switch i.e denote a packet arrival, change in switch state, or an error
• Packet-in: It transfers the control of a packet to the controller.
• Flow-Removed: It informs the controller about the removal of a flow
entry from a flow table. E.G when timeout of one of the flow is
exceeded .
• Port-status: It informs the controller of a change on a port. Eg.a port
configuration or change in a port state.
• C) The symmetric messages are initiated by either the switch or the
controller and sent without solicitation in any direction.
• Hello: The hello messages are exchanged between the switch and the
controller upon a connection start-up.
• Echo: The echo requests/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.
• Experimenter: The experimenter messages provides a standard way for
OpenFlow switches to offer additional functionality.

40. Structure of Flow-table
• 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. Each flow table consists of a number of rows, called
flow entries.
• A flow entry includes a header that identifies the individual flow that the
packets are matched against and a set of actions that are to be taken by
the switch for the matched packets. The matching is made on the packet
header fields.

42. OPEN FLOW TABLE ENTRY
•A flow entry includes a
header that identifies the
individual flow that the
packets are matched against
and a set of actions that are
to be taken by the switch for
the matched packets. The
matching is made on packet
header fields.
•The actions taken can vary
from packet forwarding,
drop, further lookups in
other flow tables, rewriting
of the header fields and etc.

43. Open flow operation
H
1
H
2
)

44. Flow Chart detailing packet flow in an Open
Flow

45. Openflow controllers
• The controllers are the focal point in the SDN networks and are also
known as the brain of the network.
• The controller is the core of a software-defined network. It resides in
the control plane, between network devices at one end of the network
and applications at the other end. Any communication between
applications and network devices must go through the controller.
• The SDN controller platform typically runs on a server and uses
protocols to tell switches where to send packets .
• The SDN controllers direct traffic according to forwarding policies that
a network operator puts in place, thereby minimising manual
configurations for individual network devices.
• The centralised controller facilitates automated network management
and makes it easier to integrate and administer business applications. In
effect, the SDN controller serves as a sort of operating system for the
network.

46. List of Controllers

47. NOX
• NOX is an open source development platform
for C++based software-defined networking control
applications. NOX is the original OpenFlow controller
• 1.NOX classic: This is the version that has been available
under the GPL since 2009.
• 2.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.
• 3.POX: It is typically termed as NOX’s sibling that
provides Python support.

48. NOX ARCHITECTURE
At the upper layer, 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.

49. • POX is a lightweight OpenFlow controller that is a suitable
platform for SDN research, academic work, education, and
experimentation.
• POX is a networking software platform that is written in Python.
• POX started life as an OpenFlow controller, but now it can also
function as an OpenFlow switch.
• POX officially requires Python 2.7 (though much of it will work
fine with Python 2.6), and should run under Linux, Mac OS, and
Windows.
• POX currently communicates with OpenFlow 1.0 switches and
includes special support for the Open vSwitch/Nicira extensions.
It also provides a web-based graphical user interface (GUI).

50. Mininet@SDN lab experimentation

51. • Create a custom network topology using MiniEdit
• First add some hosts to network scenario. Then click on the Host
icon and, move the pointer to the location on the MiniEdit.
Finally add controller, switch and, links.

52. Sample Topology For Experimentation

53. Before the DoS Attack

54. Effect after DoS Attack

55. Flow Effect at the Switch after the Attack

56. Attack detection using Sflow-rt

57. Openflow in cloud computing
• OpenStack and Neutron
• SDN and OpenFlow are used for the facilitation of data centers
and a cloud computing infrastructure .Hence, it is important to
understand the usage of OpenFlow in data centers and in
particular OpenStack ,since it is used as control and management
software for cloud computing.
• OpenStack is a cloud operating system that controls large pools
of compute, storage, and networking resources throughout a
datacenter, all managed and provisioned through APIs with
common authentication mechanisms

59. Components of Open stack
• OpenStack Compute (Nova): OpenStack compute (codename: Nova) is the
component which allows the user to create and manage virtual servers using the
machine images. It is the brain of the cloud.
• Block Storage (Cinder); This component provides persistent block storage to running
instances.
• Object Storage (Swift): This component stores and retrieves unstructured data
objects through the HTTP based APIs.
• OpenStack Networking (Neutron): It is a pluggable, scalable and API-driven system
for managing networks. OpenStack networking is useful for VLAN management,
management of IP addresses to different VMs and management of firewalls
• Identity Service (Keystone):This provides a central directory of users mapped to the
OpenStack services. It is used to provide an authentication and an authorisation service
for other OpenStack services.

60. • OpenStack Image Service (Glance): This provides the discovery, registration
and delivery services for the disk and server images. It stores and retrieves the
virtual machine disk image.
• OpenStack Telemetry Service (Ceilometer): It monitors the usage of the
cloud services and decides the billing accordingly.
• Dashboard (Horizon):This component provides a web-based portal to
interact with all the underlying OpenStack services, such as NOVA, Neutron,
etc.
• Orchestration Heat: This component manages multiple cloud applications
through an OpenStack-native REST API and a CloudFormation-compatible
Query API.
• Database as a Service (Trove): Trove is database as a service for OpenStack.
It is designed to run entirely on Open Stack, with the goal of allowing users to
quickly and easily utilise the features of a relational database without the burden
of handling complex administrative tasks.
• Messaging as a Service (Marconi): Marconi is a cloud messaging and
notification service for developers building applications on top of OpenStack.

61. OpenStack Process Workflow
• The workflow diagrams which describe the flow of process in
OpenStack of a user who wants to host SUSE Linux. are as
follows:
• Step 1)User requests a VM running SUSE Linux
OpenStack Dashboard
Step 2) The Dashboard(horizon ) passes the request to the Compute
Component(NOVA)

62. • Step3)The request goes to Identity Component (Keystone) for
the authentication
Step 4) NOVA requests the Networking Component(Neutron)for an IP Address

63. • Finally after getting the image, Nova mounts it on a
VM host. During the boot process of the VM, it
requests Neutron (DHCP component) for an IP
address.
•
Step 5) Nova requests the image component(Glance) for an image of
SUSE linux