Published on March 8, 2014
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
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
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
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 PacketIn message. OpenFlow 1.3 changes this introducing the tablemiss flow entry. If a packet does not match a flow entry it is discarded, so a tablemiss 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
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 tablemiss 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 applyactions and writeactions. 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 applyactions and writeactions 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
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 perflow QoS, applying ratelimiting to matching flows. The figure 5 is how a meter entry looks like. 6
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
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
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
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
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
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 tremaedge. 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
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
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
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
$ sudo ovsofctl addflow s1 priority=100,in_port=1,actions=output:2 $ sudo ovsofctl addflow s1 priority=100,in_port=2,actions=output:1 $ sudo ovsofctl dumpflows 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 ovsofctl 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 statsdesc $ sudo dpctl unix:/tmp/s1 flowmod cmd=add,table=0 in_port=1 apply:output=2 $ sudo dpctl unix:/tmp/s1 flowmod cmd=add,table=0 in_port=2 apply:output=1 $ sudo dpctl unix:/tmp/s1 statsflow 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
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 $ ryumanager 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 $ ryumanager 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
References Open Network Foundation: https://www.opennetworking.org/ OpenFlow White Paper: http://archive.openflow.org/documents/openflowwplatest.pdf OpenFlow switch 1.0 specification: http://archive.openflow.org/documents/openflowspecv1.0.0.pdf OpenFlow 1.3.1 specification: https://www.opennetworking.org/images/stories/downloads/sdnresources/onfspecifications/op enflow/openflowspecv1.3.1.pdf Brent Salisbury’s blog http://networkstatic.net/openflowproactivevsreactiveflows/ The Beacon OpenFlow Controller http://conferences.sigcomm.org/sigcomm/2013/papers/hotsdn/p13.pdf POX http://www.noxrepo.org/pox/aboutpox/ Trema https://github.com/trema/trema Open DayLight www.opendaylight.org Floodlight http://www.projectfloodlight.org/ Ryu https://github.com/osrg/ryu 18
Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...
In this presentation we will describe our experience developing with a highly dyna...
Presentation to the LITA Forum 7th November 2014 Albuquerque, NM
Un recorrido por los cambios que nos generará el wearabletech en el futuro
Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...
Getting Started OpenFlow OpenvSwitch Tutorial Lab : Setup This is a starter to get an initial lab setup that can build about any SDN use case.
About OpenFOAM. OpenFOAM is a free, open source CFD software package developed by OpenCFD Ltd at ESI Group and distributed by the OpenFOAM ...
OpenFlow Tutorial Theophilus Benson Outline Components in an OpenFlow testbed Setting up a testbed Writing a new component C++ components version Python ...
A graphical network simulator to design and configure virtual networks 7-Zip. A free file archiver for extremely high ...
Hi, I'm currently trying to perform a simple open channel flow simulation using Fluent 6.3.26 and having absolutely no luck. I've tried looking for
Simulating open channel flow in ANSYS Fluent #1: openchannelflow. New Member . Anonymous van Munster. Join Date: May 2012. Posts: 2 Rep Power: 0. Hi all
Trouble with Open flow tutorial-xterm display error and not in the sudoers file error 882 Views 8 Replies Latest reply: May 18, 2013 11:04 AM by ...
Openflow & OpenvSwitch Tutorial Part 1 OpenvSwitch ... Open vSwitch - the good, the bad and the ugly - Jerry Chu, Google, Inc. - Duration: ...