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.
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 flowbased 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 perflow 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
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
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.
$ ryumanager
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.
$ ryumanager
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?
Ovsofctl 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 ovsofctl commands, see the output and look mininet to see what OpenFlow
messages are sent.
$ sudo ovsofctl show s1
$ sudo ovsofctl dumpdesc s1
15