Openflow Switch

Specifications and Working

SDN: Centralized Programming of
Forwarding Tables
 What is OpenFlow?
 OpenFlow protocol designed for network traffic
management between network devices of different
model and from different vendors.
 OpenFlow is a communications protocol that gives
access to the forwarding plane of a network switch or
router over the network (interface)
 Earlier, each switch or networking device had its own
intelligence (programmable but role was fixed).
 Openflow allows direct access to and manipulation of
the forwarding plane of network devices such as
switches and routers, both physical and virtual.
Basic OpenFlow: How Does it
Work? …  Controller manages the traffic (network
flows) by manipulating the flow table at
switches.
 Instructions are stored in flow tables.
 When packet arrives at switch, match
the header fields with flow entries in a
flow table.
 If any entry matches, performs indicated
actions and update the counters.
 If Does not match, Switch asks controller
by sending a message with the packet
Control Plane : header.

Flow Table (has 3 sections)

Communicate
via secure
Channel
Flow table

Data Plane

Match the packet

OpenFlow Table: Basic
Stats
• Provide
counter for
incoming
flows or
packets.
• Information
on counter
can be
retrieved to
control plane.
• Can be used
to monitor
network
traffic.
 BIRTH OF OPENFLOW

Arrival of OpenFlow is the point at which SDN
was actually born.

The term SDN came into use only a year
after OpenFlow made its appearance in 2008,
but the existence and adoption of OpenFlow
by research communities and networking
vendors marked a sea change in networking.
How to propose commercially viable
solution?

OpenFlow was developed and designed to
allow researchers to experiment and innovate
with new protocols in everyday networks.

The OpenFlow specification encouraged
vendors to implement and enable OpenFlow
in their switching products for deployment.

Many network vendors have implemented
OpenFlow in their products.
 Openflow.org

The nonprofit Internet organization, openflow.org
was created in 2008 to promote and support
OpenFlow.

While openflow.org existed formally on the Internet,
in the early years the physical organization was a
group of people at Stanford University.

From its inception OpenFlow was intended to
belong to the research community to serve as a
platform for open network switching
experimentation, with an eye on commercial use
through commercial implementations of this public
specification.
 ONF

The first release Version 1.0.0 appeared in
December 31, 2009, though numerous
prereleases existed before for experimental
purposes and then the specifications evolved.

Development and management of the
specification was performed under the
auspices of openflow.org (1.1.0).

On 21.3.2011 Open Network Foundation
(ONF) was created for the purpose of
accelerating delivery & commercialization of
SDN.
 ONF

So, OpenFlow began with the publication of the
original proposal in 2008.

ONF was established by Deutsche Telekom,
Facebook, Google, Microsoft, Verizon, and Yahoo!.

ONF is now the guardian of OpenFlow standard,
and consists of a number of councils, areas and
working groups.

ONF board is composed of CTOs, Technical
Directors, Professors from Stanford and Princeton,
and Fellows from companies such as Google,
Yahoo!, Facebook, Deutsche Telekom, Verizon,
Microsoft, NTT, and Goldman Sachs among others.
Simple Architecture of an
OpenFlow Solution
Data Plane Network Device

From Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud by William Stallings (0134175395)
Copyright © 2016 Pearson Education, Inc. All rights reserved.
 Principle Functions of 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
devices and forwards them along the data
forwarding paths established according to
the rules defined by the SDN applications.
 OpenFlow Switch Context

From Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud by William Stallings (0134175395)
Copyright © 2016 Pearson Education, Inc. All rights reserved.
 Types

A given OpenFlow switch implementation is
either OpenFlow-only or OpenFlow-hybrid.

An OpenFlow-only switch is one that forwards
packets only according to the OpenFlow logic
described above.

An OpenFlow hybrid is a switch that can also
switch packets in its legacy mode as an
Ethernet Switch or IP router.

A hybrid switch requires a preprocessing
classification mechanism that directs packets
to either OpenFlow processing or the
traditional packet processing.
OpenFlow V.1.0 switch
 After a Match:
Fundamental Packet Paths

A match with a particular entry in that table,
the logic directs the now matched packet to
an action box on the right.

This action box has three fundamental
options for the disposition of this arriving
packet:
•
A: Forward the packet out a local port,
possibly modifying certain header fields first.
•
B: Drop the packet.
•
C: Pass the packet to the controller.
 Packet to Controller

In the case of path C, the packet is passed
to the controller over the secure channel
shown in the figure.

If the controller has either a control
message or a data packet to give to the
switch, the controller uses this same
secure channel in the reverse direction.
 Packet_Out

When the controller has a data packet to
forward out through the switch, it uses the
OpenFlow PACKET_OUT message.

Such a data packet coming from the
controller may take two different paths
through the OpenFlow logic, both denoted Y.

In the right side case, the controller directly
specifies the output port and the packet is
passed to port N.

In the left side path Y case, the controller
indicates that it wishes to defer the forwarding
decision to the packet matching logic.
 OpenFlow Switch

From Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud by William Stallings (0134175395)
Copyright © 2016 Pearson Education, Inc. All rights reserved.
 Basic Operation of An OpenFlow
Solution
1.The controller populates the switch with flow
table entries.
2.The switch evaluates the header(s) of
incoming packets and finds a matching flow,
then performs the associated action.
3.Depending on the match criteria, this
evaluation would begin with the layer two
header, and then potentially continue to the
layer three and even layer four headers in
some cases.
 Basic Operation of An OpenFlow
Solution
4.If no match is found, the switch forwards the
packet to the controller for instructions on how
to deal with the packet.
5.Typically the controller will update the switch
with new flow entries as new packet patterns
are received, so that the switch can deal with
them locally.
6.It is also possible that the controller will
program wildcard rules that will govern many
flows at once.
 IP Packet Header: Recap
0 4 8 16 19 24 31

Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

Source IP Address

Destination IP Address

Options Padding

Internet header length (IHL): length of the header in 32-bit words. Minimum 20
bytes, Up to 40 bytes in options fields
Type of service (TOS): traditionally priority of packet at each router. Recent
Differentiated Services redefines TOS field to include other services besides best
effort.
 Differentiated Services(DS)
• 8 bits to provide desired quality of service (QoS) to
packets depending upon traffic type.
• Leftmost 6 bit are used a codepoint (DSCP) to
select per-hop behavior (PHB), a packet
experience at each node.
• Remaining 2 bits on right are called explicit
congestion notification (ECN) field and are used to
indicate congestion in the network.
• 00: Non-ECN-capable transport-Non-ECT
• 10: ECN capable transport-ECT(0)
• 01: ECN capable transport-ECT(1)
• 11: Congestion encountered-CE
 Openflow Context
• An SDN controller communicates with
OpenFlow-compatible switches using the
OpenFlow protocol running over Transport
Layer Security (TLS).
• Each switch connects to other OpenFlow
switches and, possibly, to end-user devices
that are the sources and destinations of
packet flows.
 Openflow Context
• On the switch side, the interface is known as
an OpenFlow channel.
• These connections are via OpenFlow ports.
• An OpenFlow port also connects the switch
to the SDN controller.
 Openflow Ports
1)Physical port: Corresponds to a hardware
interface of the switch.
2)Logical port: Does not correspond directly to
a hardware interface of the switch.
Logical ports may include packet
encapsulation and may map to various
physical ports.
3)Reserved port: Defined by the OpenFlow
specification.
 Ports and Port Queues

Sophisticated switches support multiple
queues per physical port.

These queues are generally served by
scheduling algorithms that allow the
provisioning of different Quality of Service
(QoS) levels for different types of packets.

OpenFlow follows this concept and permits a
flow to be mapped to an already-defined
queue at an output port.
 Openflow Support for Multiple
Queues Per Port

OpenFlow embraces this
concept and permits a
flow to be mapped to an
already-defined queue at
an output port.

Action box specifies how
to enqueue the packet
being processed a
particular queue on to a
port.
OpenFlow Table Entry Formats

From Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud by William Stallings (0134175395)
Copyright © 2016 Pearson Education, Inc. All rights reserved.
 What is a flow?

A flow is a set of packets transferred from one
network endpoint (or set of endpoints) to
another endpoint (or set of endpoints).

The endpoints may be defined as IP address
TCP/UDP port pairs, VLAN endpoints, layer
three tunnel endpoints, and input port among
other things.
 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.
• Flow 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.
 Flow Table: First Four Entries
• Match fields: Used to select packets that
match the values in the fields. Used as match
• criteria to determine if an incoming packet
matches this entry.
• Priority: Relative priority of table entries. 16-
bit field with 0 corresponding to the lowest
priority. In principle, there could be 216
priority levels.
• Counters: Updated for matching packets.
• Instructions: Instructions to be performed if a
match occurs.
 Flow Table Entry: Timeout
• 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.
 Flow Table Entry: Cookie
• Cookie: 64-bit opaque data value chosen by
the controller. It 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, the flag
OFPFF_SEND_FLOW_REM triggers flow
removed messages for that flow entry
Required OpenFlow Counters
 Instructions Component
• The instructions component of a table entry
consists of a set of instructions that are
executed if the packet matches the entry.
• Actions describe packet forwarding, packet
modification, and group table processing
operations.
 Openflow Actions
• 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.
 Openflow Actions
• 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.
 OpenFlow Actions
• Group: Process packet through specified
group.
• Push-Tag/Pop-Tag: Push or pop a tag field for
a VLAN or Multiprotocol Label Switching
(MPLS) packet.
• Set-Field: The various Set-Field actions are
identified by their field type and modify the
values of respective header fields in the
packet.
 OpenFlow Actions
• Change-TTL: The various Change-TTL
actions modify the values of the IPv4 TTL,
IPv6 hop limit, or MPLS TTL in the packet.
• Drop: Packets whose action sets have no
output action should be dropped.
/* * Overridden IOFMessageListener's receive() function. */
@Override
public Command receive(IOFSwitch sw, OFMessage msg, FloodlightContext
cntx) {
switch (msg.getType()) {
case PACKET_IN: /* Retrieve the deserialized packet in message */
Ethernet eth = IFloodlightProviderService.bcStore.get(cntx,
IFloodlightProviderService.CONTEXT_PI_PAYLOAD);

/* Various getters and setters are exposed in Ethernet */

MacAddress srcMac = eth.getSourceMACAddress();
VlanVid vlanId = VlanVid.ofVlan(eth.getVlanID());

/** Check the ethertype of the Ethernet frame and retrieve the
appropriate payload. EthType caches and reuses instances for valid
types. */
if (eth.getEtherType() == EthType.IPv4) {
/* We got an IPv4 packet; get the payload from Ethernet */
IPv4 ipv4 = (IPv4) eth.getPayload();

/* More to come here */

} else if (eth.getEtherType() == EthType.ARP) {
/* We got an ARP packet; get the payload from Ethernet */
ARP arp = (ARP) eth.getPayload();
/* More to come here */
} else { /* Unhandled ethertype */ }
break;
default: break; }
return Command.CONTINUE;}
OpenFlow Switch
 Flow Table Pipeline
• An OpenFlow switch is composed of one or
more flow tables and a group table and uses
the OpenFlow protocol to communicate with
the SDN controller.
• If there is more than one flow table, they are
organized as a pipeline, with the tables
labeled with increasing numbers starting with
zero.
• This provides flexibility to SDN Controllers.
Working of OpenFlow Switch
 Stages of Packets Processing
• Ingress processing: 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.
Packet Flow Through an OpenFlow
Switch - 1
Packet Flow Through an OpenFlow Switch:
Ingress Processing
 Egress Processing
• 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.
Packet Flow Through an OpenFlow
Switch (2)
• 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.
 Final Table
• 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
Packet Flow Through OpenFlow Switch:
Egress Processing
Messaging Between Controller and Switch

The messaging between the controller and switch
is transmitted over a secure channel.

This secure channel is implemented via an initial
TLS connection over TCP.

Subsequent versions of OpenFlow allow for
multiple connections within one secure channel.

If the switch knows the IP address of the controller,
then the switch will initiate this connection.

Each message between controller and switch starts
with the OpenFlow header.

This header specifies the OpenFlow version number,
the message type, the length of the message and the
transaction ID of the message.
 OpenFlow Messages
• 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:
– Controller-to-Switch: Messages initiated by the
controller and, in some cases, require a response
from the switch
– Asynchronous: Sent without solicitation from the
controller by Switch (like status or unmatched
packet)
– Symmetric: Sent without solicitation from either the
controller or the switch (Hello, Echo request/reply)
OFPT Message Types in OpenFlow 1.0
 Controller-to-Switch Messages
1. Features Request the capabilities of a switch.
Switch responds with a features reply that specifies
its capabilities.
2. Configuration: Set and query configuration
parameters. Switch responds with parameter
settings.
3. Modify-State: Add, delete, and modify flow/group
entries and set switch port properties.
4. Read-State: Collect information from switch, such
as current configuration, statistics, and capabilities.
 Controller-to-Switch Messages
5. Packet-out: Direct packet to a specified port on the
switch.
6. Barrier: Barrier request/reply messages used by
the controller to ensure message dependencies
have been met or to receive notifications for
completed operations.
7. Role-Request: Set or query role of the OpenFlow
channel. Useful when switch connects to multiple
controllers.
8. Asynchronous-Configuration: Set filter on
asynchronous messages or query that filter. Useful
when switch connects to multiple controllers.
 Symmetric Messages

These may be sent by either the controller or the switch,
without having been solicited by the other.

The HELLO messages are exchanged after the secure
channel has been established to determine the highest
OpenFlow version number supported by the peers.

The protocol specifies that the lower of the two versions is to be
used for Controller-Switch communication over this secure
channel instance.

ECHO messages are used by either side during the life of
the channel to ascertain that the connection is still alive and
to measure the current latency or bandwidth of the
connection.

The VENDOR messages are available for vendor-specific
experimentation or enhancements.
 Symmetric Messages
1. Hello: Exchanged between the switch and
controller upon connection startup.
2. Echo: Echo request/reply messages can be
sent from either the switch or the controller,
and they must return an echo reply.
3. Experimenter: For additional functions.
 Asynchronous Messages

Async messages are sent from the switch to the controller without having been
solicited by the controller.

PACKET_IN message is used by switch to pass data packets back to the controller
for exception handling.

Control plane traffic will usually be sent back to the controller via this
message.

The switch can inform the controller that a flow entry is removed from the flow
table via the FLOW_REMOVED message.

PORT_STATUS is used to communicate changes in port status whether by direct
user intervention or by a physical change in the communications medium itself.

Finally, the switch uses the ERROR message to notify the controller of problems
 Asynchronous Messages
1. Packet-in:Transfer packet to controller.
2. Flow-Removed: Inform the controller about
the removal of a flow entry from a flow
table.
3. Port-Status: Inform the controller of a
change on a port.
4. Error: Notify controller of error or problem
condition.
 Emergency Mode

In the event that the HELLO protocol detects
a loss of the connection between controller
and switch, the V.1.0 specification prescribes
that the switch should enter emergency mode
and reset the TCP connection.

All flows are to be deleted at this time except
special flows that are marked as being part of the
emergency flow cache.

The only packet matching that is allowed in this
mode is against those flows in that emergency
flow cache.