This document provides an overview and introduction to the OpenFlow protocol and SDN. It discusses the key concepts including: - OpenFlow enables SDN by providing an interface between controllers and switches via protocols like OpenFlow and POF. - An OpenFlow switch uses flow tables to match packets and apply actions. OpenFlow 1.3 supports multiple tables and table miss flow entries. - The tutorial aims to help readers understand OpenFlow 1.0 vs 1.3 basics and differences, and use a virtualized OpenFlow environment to test applications.

1. The OpenFlow Tutorial
Table of Contents
Chapter 1 ­ OpenFlow and SDN
Chapter 2 ­ The OpenFlow Switch
Chapter 3 ­ The OpenFlow Controller
Chapter 4 ­ Hands On
References
Preface
Welcome to the OpenFlow tutorial. This is the first version (also called 0.1 or Beta), of a
simple document which has the intention of being an introduction to the basics of the
OpenFlow protocol driving the user to a familiar experience when looking to the OpenFlow
specification for the first time.
The tutorial is composed by 4 chapters. The first three have the basics and are more
theoretical, going through an OpenFlow intro and his relationship with SDN at chapter 1,
passing by more specific details about the OpenFlow switch and protocol on chapter 2,
ending with a short discussion about controller fundamentals at 3. The fourth and last
chapter is the tutorial practical part. On future versions, a FAQ section will be added with
the most common questions that may arise from future readers.
At the end of this tutorial you should:
● Understand the OpenFlow 1.0 and 1.3 basics and differences.
● Feel comfortable to explore the specifications.
● Be able to use a virtualized OpenFlow environment to create and test applications.
1

2. Chapter 1 - OpenFlow and SDN
OpenFlow and Software Defined Networks (SDN) are among the most used buzzwords on
Computer Networks these days. These hot topics have brought a lot of expectation, hype
and confusion to network operators and companies. It can be explained by the proposal of
significant changes to the current model of the networks. The separation between the
network control plane from the forwarding plane is not a new idea, but it has gained much
more traction from the emergence of OpenFlow and the term SDN.
The idea of the OpenFlow protocol was born on a research project called Ethane at
Stanford University, in Silicon Valley, California. The idea was to allow the user to enforce
network policies on a network with centralized control and flow­based switches.
The idea has evolved to OpenFlow, which is the protocol that allows the network to be
controlled by an external controller. Specifications were then released under Stanford’s
arms until the version 1.1. From 1.2 OpenFlow was embraced by the Open Network
Foundation (ONF), an organization with the objective to promote the adoption of SDN.
ONF analyzes SDN need and evolves OpenFlow accordingly.
A common question by new OpenFlow user is: Is SDN OpenFlow?
Short answer is: no.
OpenFlow is a technology that enables SDN and is the most known interface between
controllers and switches, but it is not the only element of an SDN solution and will not solve
all of the problems of your networks automagically!
The figure 1, taken from the ONF site illustrates an SDN architecture. Look that OpenFlow
is just the control data plane interface and is just one example. Other example of interface
is the Protocol Oblivious Forwarding (POF), designed by Huawei.
The basic idea behind these common network equipment control interfaces is to give a
programmable interface with allow direct access and manipulation of the forwarding plane.
This could be a simple API that can be compared to the instruction set of a CPU, giving
flexibility to change the devices behavior, developing network services and applications. A
good analogy is the computer Operating System, in which the control of resources enable
for a wide number of programs running over it.
2

3. Figure 1. SDN Architecture
Chapter 2 - The OpenFlow Switch
An OpenFlow switch is composed by tables where packets are processed and an
OpenFlow Channel. OpenFlow 1.0 featured only on table, called Flow Table, but more
tables were added, as new specification were being released, giving more forwarding
options and enabling per­flow QoS.
Flow Table
The Flow Table is the main table of the OpenFlow pipeline. It contains flow entries that
matches packets and apply actions that may include actions as forwarding, packet
modification and others.
Flow entries differ from OpenFlow 1.0 and 1.3, as we can see in the figure 2 and 3, taken
from the respective specifications.
Figure 2. OpenFlow 1.0 Flow Entry
3

4. Figure 3. OpenFlow 1.3 Flow entry
The Header Fields and Match fields meaning are equivalent on both versions, they are the
fields which the packets will match. The difference from 1.0 and 1.3 is that 1.3 adopts a
TLV structure to describe the match fields and supports 40 fields against the 12 from 1.0.
There are a good number of protocols supported, since layer 2 Ethernet, layer 3 IPv4 and
IPv6, from less usual as the transport protocol SCTP. Check the specifications for all
supported fields.
Priority is not present on Figure 2, but it is not exclusive from OpenFlow 1.3. Flow lookup is
made from highest to lowest priority.
The counters are useful for statistics, counting the number of matched packets and the total
bytes. As counters are a costly operation for hardware, OpenFlow 1.3 allows to disable
these counters.
The timeouts, similar to Priority are present on both versions, and they are the time which a
flow keeps live. There are two type of timeouts: idle timeout, the time one flow lives without
any packet match; and hard timeout, which is the time a flow will independently of any
activity.
The OpenFlow pipeline differs from OpenFlow 1.0 and 1.3. The most recent version
supports multiple tables, while the prior version exposes only one table. On 1.0 the packets
are parsed and matched against the table flow entries and, if it matches any, the actions
are applied to the packet. On OpenFlow 1.3 the packets are processed against every
table, in order and at every table the associated action set may be written. In the end the
action set is applied to the packet.
Do not Forget!
Another difference from OpenFlow 1.0 and 1.3 Flow Table are the behavior on a table
miss. On OpenFlow 1.0 the default behavior is to send the packet to the controller in a
Packet­In message. OpenFlow 1.3 changes this introducing the table­miss flow entry. If
a packet does not match a flow entry it is discarded, so a table­miss flow entry should be
installed to avoid to lose the packets. This special flow entry have the lowest priority and
matches every packet. The typical action of this flow is to send the packet to the controller,
but you can specify any of the available instructions and actions to be applied.
4

5. It is very common users switching from OpenFlow 1.0 to 1.3 wondering why his
applications do not work. The mistake: forget to install the table­miss flow entry.
Actions
The Actions from the figure 2 are executed in case of a packet match. In OpenFlow 1.0
they are a list of actions executed in sequential order. In OpenFlow 1.3 actions are part of
two instructions, explained below, called apply­actions and write­actions.
The most common action is output the packet into a determined port, but there are also
options to modify packet fields, like Set VLAN ID on OpenFlow 1.0 or Set Field on
OpenFlow 1.3, and actions that push or pop some protocol header from the packet, like
Strip VLAN from 1.0 and Push MPLS from the version 1.3.
Instructions
OpenFlow 1.3 has a set of instructions executed when the packet matches the flow entry.
The instructions may be to apply the actions directly after a flow match and not in the end of
the pipeline; write actions to the action set executed at the end of the pipeline; write
metadata that will be passed along the tables; go to an specific table, clear the action set
and send the packet to the meter table.
A common point of confusion is the difference between apply­actions and write­actions
instructions. The main differences is that the apply action executes the instructions just like
on OpenFlow 1.0, just after the flow match and the actions are executed in the list order.
The actions passed to write actions are always executed at the end of the pipeline, cannot
have repeated actions and there is an specify order for the execution. For example, the
output port action should be the last action executed.
Group Table
The group table was introduce by OpenFlow 1.1 and offers new forwarding options. The
figure 4 show how a group entry is defined.
Figure 4. OpenFlow 1.3 Group entry
The Group Identifier is a unique number that will be used in the group action to direct
packets from the flow table to the Group Table.
5

6. The Counters works just like the Flow Table counters.
The Action Buckets is a list of buckets containing actions sets. The Group Type defines
the buckets that will be executed.
The Group Type defines how the group will handle the packet by choosing which buckets
will be executed. Below there is a simple description of the types available:
All
This group type will execute all buckets present on the group entry. It was introduced to add
multicast and broadcast to forwarding, missing on OpenFlow 1.0. The packet is cloned for
each bucket, so you can have multiple output actions in different buckets.
Select
The select type is used to execute only one group bucket, based on some algorithm not
defined by the OpenFlow specification. It could be a simple round robin or some more
complex type of selection. It is an optional type.
Indirect
Groups of the indirect type may have only one bucket. It is useful for having multiple flows or
groups pointing to a common group identifier. It is the same of an All group with only one
bucket.
Fast Failover
This optional group type will execute the first bucket live. Buckets can be associated with
an specific port or group. Buckets are live while the port or group are up. If a port or group
goes down, then the bucket is not live and the next live bucket will choosen
Meter Table
The Meter Table was introduced by OpenFlow 1.3 and allows simple per­flow QoS,
applying rate­limiting to matching flows. The figure 5 is how a meter entry looks like.
6

7. Figure 5. OpenFlow 1.3 Meter entry
The Meter Identifier is a unique number which the flow entry instruction meter will
reference.
The Meter Bands is a list of bands containing the allowed rate and the type of processing.
There are two optional meters defined by the specification:
Drop
Limits the rate simply dropping the packets.
DSCP Remark
This more elaborated rate limit mechanism changes the DSCP field of the IP header,
increasing the drop precedence.
OpenFlow Channel
It is the interface that connects the switch to the controller. The switch can connect using
TCP or an encrypted TLS connection. An official port number, 6653, was assigned by
Internet Assigned Number Authority (IANA) , so future implementations of OpenFlow
switches will connect using this port.
After the connection the switch and controller perform an initial handshake to establish the
OpenFlow connection.
The figure 6 shows how the handshake works. After the establishment of the TCP or TLS
connection the switch and the controller, without specified order, send a Hello message
with the higher OpenFlow version supported. If the switch does not have support for the
OpenFlow version sent by the controller it sends an Error message, with a version error.
Otherwise, the controller send a Features Request to the switch. The switch then reply
with the Features Reply, containing switch information as the datapath id, number of
tables, and others. After the receipt of the Features Reply, the OpenFlow connection is
established.
7

8. Figure 6. OpenFlow Handshake
Hello 1.0 vs Hello 1.3
The Hello message from OpenFlow 1.0 is a simple message, containing only the
OpenFlow header, present at the beginning of every message and is composed by the
fields version, message type, message length and xid.
OpenFlow 1.3 added one optional field after the header. This field can contain elements to
pass more information during the connection. Currently the only element defined is a
bitmap containing all the OpenFlow versions supported by the switch/controller, so a
common version can be negotiated by both sides.
Features Reply 1.0 vs Features Reply 1.3
The Features Reply message from OpenFlow 1.0 contains the description of all ports. It is
really common from people switching versions expect to retrieve all ports from a Features
Reply on OpenFlow 1.3.
8

9. Do not Forget!
If you want the port description on OpenFlow 1.3 you must use a Multipart Request of the
type port description (OFPMP_PORT_DESC).
OpenFlow Message types
There are three type of messages in OpenFlow.
Note: I will not enter in details here as the specification covers really well all OpenFlow
messages. It is just one introduction.
Controller to Switch
These messages are sent by the controller and may require or not an answer from the
switch. The Features Request is one type of controller to switch message. Other really
common messages are Flow Mod, to modify the Flow Table state, Packet Out, to send a
packet in the controller back to the forwarding plane.
The messages read state, know as Stats messages on OpenFlow 1.0, were renamed to
Multipart messages on 1.3, because it used both for statistics and capabilities. For
example, it is possible to change the switch table configuration with a Table Features
Request.
Asynchronous
These messages are sent by the controller without any requirement. The Packet In,
happens when a packet does not match any flow on OpenFlow 1.0 or by an output action
that explicitly directs the packet to the controller on both versions, is one of the most
common asynchronous messages.
Symmetric
Symmetric messages are sent without request by both sides. The Hello message used on
the handshake is one example. Another one is the Echo Request, to check for
switch/controller connectivity, the other side must reply with a Echo Reply, to confirm he
still there.
9

10. Chapter 3 - The OpenFlow Controller
An OpenFlow switch without a switch can be seen as a dumb equipment. If it is not
one the hybrid options existent in the market, which features OpenFlow with the
traditional protocol stack, the switch will not be able to handle any type of packet.
The controller can be seen as the Network Operating System, where application will
run on top of it. For example, a controller can have applications that enable the
switch to act as a firewall for packets coming from some determined IP address or
program it to work as a load balancer.
The design of controllers is relatively new and the requisites are still being defined as new
demands and use cases arise. But some principles, taken from the Beacon article present
on SIGCOMM 2013 can be listed here.
● A controller should be able to launch and stop applications during runtime, as an
Operating System.
● It should improve the developer productivity. A controller API should be easy to used
and optimize the time spent to develop and application.
● It should have good performance for the scenario it has been designed.
These principles listed are more related to the development of an OpenFlow
controller, but for a complete SDN solution the controller should also have other
desirable characteristics that will not be discussed here.
Controller Architectures
There are three architectural models that may be possible to OpenFlow controllers.
Centralized
The traditional method, with a single controller controlling the entire network. It has the
visibility of all network switches and may operate all of them. Another controller may also be
incorporated for fast failover in case of the main controller goes down. The synchrony
between the controllers could be achieved using a centralized database, where the failover
10

11. controller would obtain the state of the main controller or they could talk directly to each
other, with the main controller updating the failover controller in determined events.
Distributed
The distributed architecture have multiple controllers looking to different switches at
the network. This has the advantage to have a better distribution of the load,
avoiding the possibility to overload the controller in a centralized model, but adds the
need a signaling protocol between the controllers.
Proactive vs Reactive Flows
There are two model to control the network state. They are simple and having a good
understatement of both will help you to think the best design for the solution you are looking.
In the proactive method, the controller install the flows without reacting to any packet. This
model is used when we already know the traffic we want to handle and want to avoid
Packet In messages going to the controller, eliminating the latency introduced by consulting
the controller. One example of application that could use this method is a packet monitor,
suppose we want to know the traffic statistics from determined MAC address. The flows
could be installed before any packet from the desired MAC arrives in the network.
The reactive model reacts to packets that do not match the entries on a flow table. The
controller can then inspect the packet header and install a flow entry to handle that kind of
traffic. An application example is the Learning Switch, which learns the MAC and port of
the elements linked to him after the receipt of packets coming from these elements.
A hybrid approach can be considered, allowing to keep the flexibility of the reactive flows
for some kinds of packet flows. This is probably the most reasonable model as the
limitations and requirements of some applications does not support an entirely reactive
model.
Controllers Everywhere!
There is a good number of Open Source controllers for OpenFlow. We will list some of
them here.
POX
Pox is an OpenFlow controller written in Python. It was originated from the NOX controller,
11

12. one the first OpenFlow controllers available. It is one of the most suited controllers for
beginners. There is plenty of documentation and the forum is always a good place to look
for answers. Also, the API is easy and intuitive. If you are looking for performance do not go
with POX. It is more for experimentation and prototyping. Another miss for POX is the lack
of OpenFlow versions other than 1.0.
Floodlight
Floodlight is the controller developed by Big Switch Networks, one of most promising
Startups on SDN. It is was forked from Beacon, designed at Stanford, due to licensing
issues. The code is written in Java and is running on some production environments. It
comes with built in applications as a Load Balancer and Firewall. Also, there is a REST
API to push OpenFlow commands to the switch. There is only support for OpenFlow 1.0.
Open DayLight
It is the most recent project on controllers. The purpose of the Open DayLight controller is
to be a general purpose SDN controller, supporting a wire range of SDN technologies, like
OpenFlow. The plugin to the OpenFlow 1.0 is already implemented and is written in Java.
The main advantage of Open DayLight is the case when we want to switch to another SDN
interface, as it will have support for other technologies that enable the new paradigm.
Ryu
Ryu is driven by NTT, the giant japanese telco. It is written in Python and has a really active
development. Ryu main features include easy integration with Open Stack, with
applications to control and isolate virtual networks. It also has support for OpenFlow 1.0,
1.2 and 1.3. The Python API is clean and easy to learn.
Trema
Trema is developed by NEC and is written in C++ and Ruby. Trema has a very clean code
and is well documented. The OpenFlow version supported is 1.0, but newer versions are
on the roadmap and a code under development can be found on trema­edge. Trema also
features his own frameworks to emulate an OpenFlow network and a wireshark plugin to
dissect messages, easing the test and debugging of your applications.
12

13. Chapter 4 - Hands On
And finally we are here! If you are tired of all of this introductory talk, this is what you are
looking for.
We will use a prepared Virtual Machine for this tutorial. The VM can be downloaded at
https://mega.co.nz/#!DU1wiaKb!TL46wmSnp1uwSRWBo8_tzhK02TYOw41hpef1aK_Kwq
g.
The file downloaded is Virtual Box appliance. To import the VM open Virtual Box, go to File
­> Import Appliance. Then open the downloaded file. After the import the VM should appear
at the Virtual Box VM Manager.
The virtual machine have ubuntu server 12.4 installed, i.e no graphical interface. If you are
not very used to text interfaces do not worry, the tutorial will show all the steps you need to
go through the tutorial.
Login into the VM via ssh with ­Y option to enable X11 forwarding. The last part of the IP
address should vary, so check the eth1 interface IP with ifconfig.
$ ssh oftutorial@<ip from VM eth1 interface> ­Y
The software installed has all tools needed for this tutorial and they are:
● Mininet ­ The network emulation tool.
● Open vSwitch ­ the most used OpenFlow software switch, It has great performance
with his kernel module and is used even for productions environments.
● Wireshark and OpenFlow plugins ­ To dissect OpenFlow messages.
● Ofsoftswitch13 ­ CPqD/Ericsson OpenFlow 1.3 software switch based on
Stanford’s reference switch.
● Ryu controller ­ The OpenFlow controller of our choice due to his support for
OpenFlow 1.0 and 1.3 and the Python language.
The figure 7 is an illustration of the simple topology that will be used for this tutorial. The
13

14. topology has an unique OpenFlow switch S1 connecting two hosts H1 and H2. This will be
sufficient to demonstrate how OpenFlow works on OpenFlow 1.0 and 1.3, using a
Learning Switch application.
Figure 7. Tutorial topology
First contact with OpenFlow 1.0
1 - To start this topology, with OpenFlow 1.0, on mininet type the following
command at the terminal
$ sudo mn ­­mac ­­switch ovsk ­­ controller remote
2 ­ Now start wireshark, type of on the filter box and choose the interface lo to capture.
$ wireshark
3 ­ Start the Ryu controller without any applications.
$ ryu­manager
4 ­ Run to wireshark to see what is happening!
● Which messages are you seeing?
5 ­ Now go to mininet and try to perform a ping between h1 and h2.
mininet> h1 ping h2
6 ­ Go to Wireshark again.
● A new type of message should appear going to the controller. What
message?
14

15. First contact with OpenFlow 1.3
Now we will do the same exercise from above, but with OpenFlow 1.3. Quit all application
that were running before.
1 ­ Start mininet with the OpenFlow 1.3 switch
$ sudo mn ­­mac ­­switch user ­­ controller remote
2 ­ Execute the script /wire_of_version.sh. Choose 2 to change the OpenFlow plugin and
reinit wireshark. Type of13.ofp_header on the filter box to see only OpenFlow packets and
then start the capture on lo.
$. /wire_of_version.sh
$ wireshark
3 ­ Start Ryu again.
$ ryu­manager
Go to wireshark and look the messages. They are similar from the OpenFlow 1.0? What is
the difference? Try to take a look at the message body.
Now try to ping again between H1 and H2 on mininet. What happens? Are you seeing
Packet In messages? Why?
Ovs­ofctl and Dpctl
Now let’s try some switch tools that enable us to send messages directly to the Switch.
1 ­ Start mininet again with Open vSwitch
$ sudo mn ­­mac ­­switch ovsk ­­ controller remote
2 ­ Change again the wireshark OpenFlow plugin version to 1.0, open it, filter by of and
start the capture on lo.
$. /wire_of_version.sh
$ wireshark
2 ­ Try some ovs­ofctl commands, see the output and look mininet to see what OpenFlow
messages are sent.
$ sudo ovs­ofctl show s1
$ sudo ovs­ofctl dump­desc s1
15

16. $ sudo ovs­ofctl add­flow s1 priority=100,in_port=1,actions=output:2
$ sudo ovs­ofctl add­flow s1 priority=100,in_port=2,actions=output:1
$ sudo ovs­ofctl dump­flows s1
3 ­ Try to ping between H1 and H2 on mininet. What happens now?
Now switch to OpenFlow 1.3 again.
1 ­ Start mininet again with the OpenFlow 13 software switch
$ sudo mn ­­mac ­­switch user ­­ controller remote
2 ­ Change again the wireshark OpenFlow plugin version to 1.3, open it, filter by of and
start the capture on lo.
$. /wire_of_version.sh
$ wireshark
2 ­ Try some ovs­ofctl commands, see the output and look mininet to see what OpenFlow
messages are sent.
$ sudo dpctl unix:/tmp/s1 features
$ sudo dpctl unix:/tmp/s1 stats­desc
$ sudo dpctl unix:/tmp/s1 flow­mod cmd=add,table=0 in_port=1 apply:output=2
$ sudo dpctl unix:/tmp/s1 flow­mod cmd=add,table=0 in_port=2 apply:output=1
$ sudo dpctl unix:/tmp/s1 stats­flow
3 ­ Try to ping between H1 and H2 on mininet. What happens now?
Learning Switch
Now, finally let’s implement the Learning Switch for OpenFlow 1.0 and 1.3. The learning
switch forwards packets based on MAC learning, if it does not know the destiny it floods
the packet to all interfaces, else if it knows the MAC associated with the port it forwards the
packet directly to the right interface.
Translating to OpenFlow:
The OpenFlow application will receive the packet from an unknown destination, learn the
packet src MAC and map it to the packet in port and install a flow with this MAC on the
ethernet dst field and with the output action to the in port. Then it should send the packet
back to the switch and flood it.
OpenFlow 1.0
16

17. Open the file ~/ryu/ryu/app/stub_switch.py. This is an OpenFlow 1.0 Learning Switch
application, with some missing parts. Try to complete the TODO parts. Once you are
finished try you application.
1 ­ Start mininet again with Open vSwitch
$ sudo mn ­­mac ­­switch ovsk ­­ controller remote
2 ­ Run ryu with the stub switch
$ ryu­manager ryu/ryu/app/stub_switch.py
Try to ping between H1 and H2 on mininet. What happens? What is
the time of the first ping?
Note: The Answer is in the file ~/ryu/ryu/app/simple_switch.py
OpenFlow 1.3
Open the file ~/ryu/ryu/app/stub_switch_13.py. This is an OpenFlow 1.3 Learning Switch
application, with some missing parts. Try to complete the TODO parts. Once you are
finished try you application.
1 ­ Start mininet again with OpenFlow 1.3 switch
$ sudo mn ­­mac ­­switch user ­­ controller remote
2 ­ Run ryu with the stub_switch_13
$ ryu­manager ryu/ryu/app/stub_switch_13.py
Try to ping between H1 and H2 on mininet. What happens? What is
the time of the first ping?
Note: The Answer is in the file ~/ryu/ryu/app/simple_switch_13.py
17

18. References
Open Network Foundation:
https://www.opennetworking.org/
OpenFlow White Paper:
http://archive.openflow.org/documents/openflow­wp­latest.pdf
OpenFlow switch 1.0 specification:
http://archive.openflow.org/documents/openflow­spec­v1.0.0.pdf
OpenFlow 1.3.1 specification:
https://www.opennetworking.org/images/stories/downloads/sdn­resources/onf­specifications/op
enflow/openflow­spec­v1.3.1.pdf
Brent Salisbury’s blog
http://networkstatic.net/openflow­proactive­vs­reactive­flows/
The Beacon OpenFlow Controller
http://conferences.sigcomm.org/sigcomm/2013/papers/hotsdn/p13.pdf
POX
http://www.noxrepo.org/pox/about­pox/
Trema
https://github.com/trema/trema
Open DayLight
www.opendaylight.org
Floodlight
http://www.projectfloodlight.org/
Ryu
https://github.com/osrg/ryu
18