The material in this presentation belongs to St. Francis Institute of Technology and is solely for educational purposes.

Distribution and modifications of the content is prohibited.

Enterprise Network Design

Module 6
Software Defined Networking (SDN)
Lecture 1

Ref: Software Defined Networking with Open Flow : PACKT Publishing Siamak Azodolmolky, Chapter 1: Introducing
OpenFlow

Enterprise Network Design

Gigi Joseph 1
Content

Understanding SDN and Open Flow

SDN – SDN Building Blocks
Open Flow messages
Controller to Switch
symmetric and Asynchronous messages
Implementing Open Flow Switch
Open Flow controllers
POX and NOX
Open Flow in Cloud Computing
 Understanding SDN and Open Flow

■ SDN is a new network technology where the control plane logic is

decoupled from forwarding plane in all networking devices.
■ The control plane has ability to control, change and manage the
network behavior through the software via open interfaces.
■ SDN is becoming popular because of its flexible approach in network
designing and management.
■ The conventional networking approach is static. Even a small change
in networking conditions extract a high cost of reconfiguring large
number of switches, routers and other networking resources.
Understanding SDN and Open Flow
Understanding SDN and Open
Flow

■ Conventional Networking:
■ The networking protocols are distributed among the devices (routers, switches,
firewalls etc)
■ The control and data planes are tightly coupled
■ No common view of the network
■ New networking features are commonly introduced via expensive, specialized
and hard to configure equipments
■ Hard to implement new features and protocols as this means changing the
control plane of all devices which are part of the topology
■ Each device has to be configured separately which is prone to errors. Many
configurations changes are done manually
 Understanding SDN and Open Flow

■ SDN Key Features:

■ SDN is a revolutionary networking paradigm, in which the forwarding
hardware (for example, specialized packet forwarding engines) is
decoupled from the control decisions (for example, the protocols and
control software).
■ The migration of control logic, which used to be tightly integrated in the
networking devices (for example, Ethernet switches) into accessible and
logically centralized controllers, enables the underlying networking
infrastructure to be abstracted from the application's point of view.
■ This separation provides a more flexible, programmable, vendor-
agnostic, cost efficient, and innovative network architecture.
 Understanding SDN and Open Flow

■ SDN Key Features:

■ Besides the network abstraction, the SDN architecture provide a set of
Application Programing Interfaces (APIs) that simplifies the implementation
of common network services (for example, routing, multicast, security, access
control, bandwidth management, traffic engineering, QoS, energy efficiency,
policy management).
■ In SDN, the network intelligence is logically centralized in software-based
controllers (at the control plane), and network devices become the simple
packet forwarding devices (the data plane) that can be programmed via an
open interface. One of the early implementations of this open interface is
called OpenFlow.
Networking the SDN way
SDN Architecture
 SDN Architecture

■ Three Layers/Planes:
■ Application - Layer/Plane
■ Control - Layer/Plane
■ Infrastructure/ Forwarding/Data - Layer/ Plane
■ Application Layer:
■ Includes different applications that interact with SDN controller
■ Programs that communicate behaviors and needed resources to the
controller via APIs.
■ Applications can build an abstract view of network by collecting information
from controller for decision making.
■ Application examples: network management, QoS incorporation, data
analysis, business applications etc.
 SDN Architecture
■ Control Layer/Plane :
■ It’s a logical entity that receives instructions or requirements from SDN
application layer
■ Relays them to networking components in the infrastructure layer
■ It extracts information about network (such as traffic statistic, network events)
from hardware devices and communicates it to application layer
■ Data Plane:
■ SDN data plane consist of physical switches and virtual switches
■ They are responsible for data processing and forwarding packets for a network
based on instructions from control plane
SDN Architecture

■ Data Plane (contd….) : The forwarding hardware (data plane) consists of the
following:
■ A flow table containing flow entries consisting of match rules and actions that needs
to be taken on active flows.
■ A transport layer protocol that securely communicates with a controller about new
entries that are not currently in the flow table.
SDN Functional Architecture

Application
Load Traffic/ Security ----------
Monitoring Layer
Balancing

Application – Control Interface

Control
POX OpenDayLight ---------
Layer

Control - Data Interface

Data
Routers Switches --------- Layer
 Advantages of SDN

■ The separation of the forwarding hardware from the control logic allows
easier deployment of new protocols and applications
■ Straightforward network visualization and management, and consolidation
of various network functions into software control is possible
■ Instead of enforcing policies and running protocols on a convolution of
scattered devices, the network is reduced to simple forwarding hardware
and the decision-making network controller(s).
SDN Building Blocks
SDN Building Blocks

■ The fundamental building blocks of SDN are,

1. SDN Switches, also called as “Open flow switches”
2. SDN Controller
3. The interfaces present on controller,
1. Interfaces used for communication with forwarding devices is called “South
bound“ Interface or “openflow” interface
2. Interface used for communication with network applications is called
“Northbound Interface”
 SDN Building Blocks

■ Switches in an SDN are often represented as basic forwarding

hardware accessible via an open interface
■ The control logic and algorithms are offloaded to a controller
■ OpenFlow switches come in two varieties:
■ Pure (OpenFlow-only)
■ Pure OpenFlow switches have no legacy features or on-board control
■ they completely rely on a controller for forwarding decisions
■ Hybrid (OpenFlow-enabled)
■ Hybrid switches support OpenFlow in addition to traditional operation and
protocols.
■ Most commercial switches available today are hybrids
Open Flow Protocol
 Open Flow Protocol
■ An OpenFlow switch consists of a flow table, which performs:
■ packet lookup and forwarding
■ Each flow table in the switch holds a set of flow entries that consists of:
1. Header fields or match fields, with information found in packet header,
used to match incoming packets
2. Counters, used to collect statistics for the particular flow, such as number
of received packets, number of bytes, and duration of the flow
3. A set of instructions or actions to be applied after a match that dictates
how to handle matching packets. For instance, the action might be to
forward a packet out to a specified port
Open Flow Protocol Implementation
Open Flow Protocol Implementation

Image Source: https://slideplayer.com/slide/5722212/

Open Flow Protocol Implementation
 Open Flow Protocol Implementation

■ Counters are used to collect statistics for the particular flow, such as number of
received packets, number of bytes, and duration of the flow
■ They are maintained per table, per flow, per port and per queue
■ Counters wrap around with no overflow indicator
Open flow Counters
Open flow Actions

■ Each flow entry is associated with zero or more actions that instruct the
OpenFlow switch how to handle matching packets.
■ If no forward actions are present, the packet is dropped.
■ Action lists must be processed in the specified order.
■ Pure OpenFlow switches only support the Required Actions, while hybrid
OpenFlow switches may also support the NORMAL Action.
Open flow Actions
■ The Required Actions :
■ Forward: OpenFlow switches must support forwarding the packet to physical
ports and the following virtual ones:
■ ALL: Send the packet on to all interfaces, excluding the incoming port
■ CONTROLLER: Encapsulate and send the packet to the controller
■ LOCAL: Send the packet to the local networking stack of the switch
■ TABLE (Only for packet-out message): Perform action in the flow table
■ IN_PORT: Send the packet out through the input port
■ Drop: This indicates that all the matching packets should be dropped. A flow
entry with no specified action is considered as a Drop action.
Open flow Actions
■ The Optional Actions :
■ NORMAL: Process the packet using the traditional
forwarding path supported by the switch (that is
traditional L2, VLAN, and/or L3 processing)
■ FLOOD: Flood the packet along the minimum spanning
tree, not including the incoming interface.
■ Enqueue: This forwards a packet through a queue
attached to a port. Forwarding behaviour is dictated by
the configuration of the queue and is used to provide the
basic QoS support.
Open flow Actions
■ Modify field: supports following modification actions,
■ Setting VLAN ID
■ Setting VLAN priority
■ Striping the VLAN header
■ Modifying the Ethernet source/destination MAC address
■ Modifying the IPv4 source/destination address
■ Modifying the IPv4 ToS bits
■ Modifying the transport source/destination port
Open Flow Table Examples

Image Source: https://www.slideshare.net/TaeAmCHOI/sdn-37556531

Open Flow Switch (OF Switch) Architecture
Open Flow Operation
OpenFlow Messaging Process

Image Source: http://www.sharetechnote.com/html/IP_Network_SDN_OpenFlow.html

OpenFlow Messaging Process

■ The communication between the controller and switch happens using the
OpenFlow protocol, where a set of defined messages can be exchanged
between these entities over a secure channel.
■ The secure channel is the interface that connects each OpenFlow switch to
a controller.
■ The Transport Layer Security (TLS) connection to the user-defined
(otherwise fixed) controller is initiated by the switch on its power on.
■ The controller's default TCP port is 6633.
■ The switch and controller mutually authenticate by exchanging certificates
signed by a site-specific private key.
■ Each switch must be user-configurable with one certificate for
authenticating the controller (controller certificate) and the other for
authenticating to the controller (switch certificate).
OpenFlow Messaging Process

■ Traffic to and from the secure channel is not checked against the flow table and
therefore the switch must identify incoming traffic as local before checking it against
the flow table.
■ In the case that a switch loses contact with the controller, as a result of an echo
request timeout, TLS session timeout, or other disconnection, it should attempt to
contact one or more backup controllers.
■ If some number of attempts to contact a controller fail, the switch must enter
emergency mode and immediately reset the current TCP connection.
■ Then the matching process is dictated by the emergency flow table entries (marked
with the emergency bit set).
OpenFlow Messages

■ The OpenFlow protocol defines three message types, each with multiple
subtypes:
■ Controller-to-switch
■ Symmetric
■ Asynchronous
OpenFlow Messages - Controller-to-switch

■ Controller-to-switch messages are initiated by the controller

■ Used to manage or inspect the state of the switch
■ This messages may or may not require a response from the switch
■ categorized in the following subtypes:
■ Features
■ Configuration
■ Modify-State
■ Read-State
■ Send-Packet
■ Barrier
OpenFlow Messages - Controller-to-switch

■ Features
■ Upon establishment of the TLS session, the controller sends a feature request
message to the switch.
■ The switch must reply with a features reply message that specifies the features
and capabilities that are supported by the switch.
■ Configuration
■ The controller is able to set and query configuration parameters in the switch.
■ The switch only responds to a query from the controller.
OpenFlow Messages - Controller-to-switch

■ Modify-State
■ These messages are sent by the controller to manage the state of the switches.
■ They are used to add/delete or modify flow table entries or to set switch port
priorities.
■ Flow table modification messages can have the following types:
■ ADD
■ MODIFY
■ DELETE
■ MODIFY and DELETE
OpenFlow Messages - Controller-to-switch

■ Read-State
■ These messages collect statistics from the switch flow tables, ports, and the
individual flow entries.
■ Send-Packet
■ These are used by the controller to send packets out of a specified port on the
switch.
■ Barrier
■ Barrier request/reply messages are used by the controller to ensure message
dependencies have been met or to receive notifications for completed operations.
OpenFlow Messages - Symmetric messages

■ Symmetric messages are initiated by either the switch or the controller and sent
without solicitation.
■ Three subtypes are:
■ Hello

■ Hello messages are exchanged between the switch and controller upon connection
setup.
■ Echo
■ Echo request/reply messages can be sent from either the switch or the controller,
and must return an echo reply.
■ These messages can be used to indicate the latency, bandwidth, and/or liveliness of a
controller-switch connection
■ Vendor
■ These messages offer additional functionality within the OpenFlow message type
space for future revisions of OpenFlow
 OpenFlow Messages - Asynchronous messages
■ Initiated by the switch and used to update the controller of network events and
changes to the switch state.
■ Switches send asynchronous messages to the controller to denote a packet arrival,
switch state change, or an error.
■ Four asynchronous messages are:
■ Packet-in

■ For all packets that do not have a matching flow entry or if a packet matches an entry with a
send to controller action, a packet-in message is sent to the controller.
■ If the switch has sufficient memory to buffer packets that are sent to the controller, the
packet-in message contains some fraction of the packet header (by default, 128 bytes) and a
buffer ID to be used by the controller when it is ready for the switch to forward the packet.
■ Switches that do not support internal buffering (or have run out of internal buffer space)
must send the full packet to the controller as part of the message.
 OpenFlow Messages - Asynchronous messages

■ Flow-Removal
■ When a flow entry is added to the switch by a flow modify
message (the Modify State type message), an idle timeout value
indicates when the entry should be removed due to the lack of
activity as well as a hard timeout value.
■ The hard timeout value indicates when the entry should be
removed, regardless of activity.
■ The flow modify message also specifies whether the switch
should send a flow removal message to the controller when the
flow expires.
■ Flow modify messages, which delete flow entries may also cause
flow removal messages.
 OpenFlow Messages - Asynchronous messages

■ Port-status
■ The switch send port-status messages to the controller as the
port configuration state changes.
■ These events include changes in port status (for example,
disabled by the user) or a change in the port status as specified
by 802.1D (Spanning Tree).
■ Error
■ The switch is able to notify the controller of problems using error
messages.
SDN - Northbound interface
 OpenFlow Switch Implementation
■ ‘OpenFlow switch’ is a basic forwarding element, which is
accessible via OpenFlow protocol and interface.
■ In SDN, switches come in two flavours:
■ hybrid (OpenFlow enabled)
■ pure (OpenFlow only).
■ Hybrid switches support OpenFlow in addition to traditional
operation and protocols (L2/L3 switching).
■ Pure OpenFlow switches have no on-board control, and
completely rely on a controller for forwarding decisions.
■ Every ‘OF switch’ needs to maintain forwarding table entries,
buffer space, and statistical counters
■ Difficult to implement in traditional switches with
application specific Ics (ASICs).
 OpenFlow Switch Implementation
■ The reference implementation of the OpenFlow switch (from
Stanford University) includes
■ ofdatapath, which implements the flow table in user space;
■ ofprotocol, a program that implements the secure channel
component of the reference switch
■ dpctl, which is a tool for configuring the switch.
■ controller, a simple controller program that connects to any
number of OpenFlow switches and a Wireshark dissector that
can decode the OpenFlow protocol).
OpenFlow Switch Implementation
 OpenFlow Switch Implementation
■ Features:
■ Upon the establishment of the TLS session (using TCP, on port 6633/6653),
the controller sends an OFPT_FEATURES_REQUEST message to the switch
■ the OpenFlow switch reports back (via OFPT_FEATURES_REPLY message) the
features and capabilities that it has and supports.
■ The datapath identifier (datapath_id), number of supported flow tables by
data path (OpenFlow switch), switch capabilities, supported actions, and
definition of ports are the important features that are reported to the
controller.
■ The datapath_id field uniquely identifies an OpenFlow switch. It is a 64-bit
entity and the lower 48 bits are intended for the switch MAC address, while
the top 16 bits are up to the manufacturers.
OpenFlow Switch Implementation

■ Configuration:
■ The controller is able to set and query configuration
parameters in the switch with the OFPT_SET_CONFIG and
OFPT_GET_CONFIG_REPLY messages, respectively.
■ The switch responds to a configuration request with an
OFPT_GET_CONFIG_REPLY message; it does not reply to a
request to set the configuration.
OpenFlow Switch Implementation

■ Modify state:
■ Modifications to the flow table from the controller are done with the
OFPT_FLOW_MOD message and the controller uses the OFPT_PORT_MOD
message to modify the behavior of the physical ports.
■ The flow modification commands are ADD, MODIFY, MODIFY_STRICT,
DELETE, and DELETE_STRICT.
■ The port configuration bits indicate whether a port has been
administratively brought down, options for handling 802.1D spanning tree
protocol (STP) packets, and how to handle incoming and outgoing packets.
■ The controller may set OFPPFL_NO_STP to 0 to enable STP on a port, or to 1
to disable STP on a port. ‘0’is a default value (enabling STP).
OpenFlow Switch Implementation

■ Read State (Statistics):

■ The controller can query the status of the switch using
OFPT_STAT_REQUEST message.
■ The switch responds with one or more OFPT_STATS_REPLY
messages.
■ There is a type field in these message exchanges.
■ Type field specifies the kind of information that is being
exchanged (OpenFlow switch description, individual flow
statistics, aggregate flow statistics, flow table statistics,
physical port statistics, queue statistics for a port, and
vendor-specific messages)
■ It also determines how the other fields should be
interpreted.
OpenFlow Switch Implementation
■ Queue query:
■ An OpenFlow switch provides limited Quality of Service
(QoS) support through a simple queuing mechanism.
■ One (or more) queue(s) can be attached to a port and could
be used to map flows on it (them).
■ The flows, which are mapped to a specific queue, will be
treated according to the configuration of that queue (for
example, minimum rate control).
■ Note that queue configuration takes place outside the
OpenFlow protocol (for example, through command-line
interface) or an external dedicated configuration protocol.
■ The controller can query the switch for configured queues
on a port using queue query message.
OpenFlow Switch Implementation
■ Send packet:
■ Using the message, OFPT_PACKET_OUT, the controller is
able to send packets out of a specified port of the OpenFlow
switch.
■ Barrier:
■ This message is sent whenever the controller wants to
receive notifications for completed operations.
■ The message is OFPT_BARRIER_REQUEST and has no
message body.
■ Upon receipt, the OpenFlow switch must finish processing
all previously-received messages before executing any
message beyond the barrier request.
■ When current processing is completed, the switch must
send an OFPT_BARRIER_REPLY message
OpenFlow Switch Implementation
■ Asynchronous messages
■ Asynchronous messages are initiated by the switch to
update the controller of network events, and changes to
the switch state.
■ Switches send asynchronous messages to the controller to
denote a packet arrival, flow removal, port status change,
or an error.
■ When packets are received by the switch, they are sent to
the controller using the OFPT_PACKET_IN message.
■ When a packet is buffered in the switch, some number of
bytes from the message will be included in the data
portion of the message.
OpenFlow Switch Implementation
■ Asynchronous messages
■ If the packet is sent because of a send-to-controller action,
then the max_len bytes are sent
■ if the packet is sent due to a flow table miss, then at least
the miss_send_len bytes are sent.
■ If the packet is not buffered inside the switch, then the
entire packet is included in the data portion of the
message.
■ An OpenFlow switch must gracefully handle the case
where a buffered packet_in message gets no response
from the controller.
■ When flows time out, the OpenFlow switch notifies the
controller with OFPT_FLOW_ REMOVED message.
OpenFlow Switch Implementation
■ Asynchronous messages
■ As physical ports are added, modified, and possibly
removed from the data path, the controller needs to be
informed with the OPFT_PORT_STATUS message.
■ There are cases where the OpenFlow switch needs to notify
the controller of a problem.
■ The message includes an error type, error code, and a
variable-length data that should be interpreted according
to the error type and code.
■ In most cases, the data part is the message that caused the
problem.
OpenFlow Switch Implementation
■ Asynchronous messages
■ There are six types of error.
■ OFPET_HELLO_FAILED indicates that Hello protocol failed.
■ OFPET_BAD_REQUEST refers to the case, where the request
was not understood.
■ Error in action description is indicated by
OFPET_BAD_ACTION.
■ If the FLOW_MOD or PORT_MOD requests are failed then
the error type is OFPET_FLOW_MOD_FAILED and
OFPET_PORT_MOD_FAILED, respectively.
■ Failure in port queue operations is classified with
OFPET_QUEUE_OP_FAILED.
OpenFlow Switch Implementation
■ Symmetric Messages
■ The hello message ( OFPT_HELLO), echo request/reply, and vendor
message are symmetric OpenFlow messages.
■ In the OpenFlow reference implementation that includes a user
space process and a kernel module, echo request/reply is
implemented in the kernel module.
■ This implementation consideration provides more accurate end-to-
end latency timing.
■ The vendor field in the OFPT_VENDOR message is a 32-bit value
that uniquely identifies the vendor.
■ If the most significant byte is zero, the next three bytes (24 bits) are
the vendor’s IEEE OUI.
■ If a switch does not understand a vendor extension, it must send an
OFPT_ERROR message with a OFPET_BAD_REQUEST error type,
and a OFPBRC_BAD_VENDOR error code.
OpenFlow Switch Implementation
OpenFlow Hardware Switches
OpenFlow Software Switches
■ Open vSwitch:
■ This is a multilayer and production quality virtual switch
licensed under the Apache 2.0 license.
■ It is designed to enable network automation through
programmatic extension, while still supporting standard
management interfaces and protocols (for example, NetFlow,
sFlow, OpenFlow, OVSDB, and so on).
■ Indigo:
■ This is an open source OpenFlow implementation that runs on
physical switches and uses the hardware features of Ethernet
switch ASICs to run OpenFlow at line rates.
■ It is based on the OpenFlow Reference Implementation from
Stanford University.
OpenFlow Software Switches
■ LINC:
■ This is an open source project led by FlowForwarding effort and
is an Apache 2 license implementation based on OpenFlow
1.2/1.3.1.
■ LINC is architected to use generally-available commodity x86
hardware and runs on a variety of platforms such as Linux,
Solaris, Windows, MacOS, and FreeBSD where Erlang runtime is
available.
OpenFlow Software Switches
■ Pantou (OpenWRT):
■ This turns a commercial wireless router/access point to an
OpenFlow-enabled switch.
■ OpenFlow is implemented as an application on top of OpenWrt.
■ Pantou is based on the BackFire OpenWrt release (Linux 2.6.32).
■ The OpenFlow module is based on the Stanford reference
implementation (userspace).
■ It supports generic Broadcom and some models of LinkSys and
TP-LINK access points with Broadcom and Atheros chipsets.
OpenFlow Software Switches
■ Of13softswtich:
■ This is an OpenFlow 1.3 compatible user-space software switch
implementation based on the Ericsson TrafficLab 1.1 softswitch.
■ The latest version of this software switch includes the switch
implementation (ofdatapath), a secure channel for connecting
the switch to the controller (ofprotocol), a library for conversion
from/to OpenFlow 1.3 (oflib), and a configuration tool (dpctl).
The OpenFlow Controllers

■ The OpenFlow controller provides the interfaces to the OpenFlow switches on

one side and provides the required API for the development of Net Apps.
■ Some of the existing implementations
■ NOX/POX
■ NodeFlow
■ Floodlight
■ FlowVisor
■ RouteFlow
The OpenFlow Controllers

■ NOX was the first OpenFlow controller written in Python and C++.
■ POX is a general, open-source SDN controller written in Python.
■ NodeFlow is an OpenFlow controller written in JavaScript for Node.js.
■ Floodlight is a Java-based OpenFlow controller, based on the Beacon
implementation, that works with physical and virtual OpenFlow switches.
■ FlowVisor and RouteFlow as special controllers which acts as a transparent
proxy between OpenFlow switches and multiple OpenFlow controllers.