Flow Control

Several leading Internet companies founded the Open Networking Foundation (ONF) [1] to promote the adoption of software-defined networking through open standard development. According to the ONF, their "signature accomplishment" is fostering and maintaining the OpenFlow standard [2], which defines a protocol for communicating with software-defined network (SDN)-ready network devices (Figure 1). A striking number of proprietary and free SDN projects now implement the OpenFlow standard.

Figure 1: An OpenFlow-capable switch connected to the controller.

OpenFlow has gained some momentum since it first appeared in 2008. Between the test suite 0.8.1 from June 2008 and version 1.0 of the specification from December 2009, the developers released seven updates. Since then, eight further iterations have appeared; the current version is numbered 1.4.

In this article, I describe how OpenFlow implements the principles of SDN and take a brief tour of OpenFlow configuration and management using the Mininet simulation tool. See the article on Mininet elsewhere in this issue for more on installing and using Mininet.

OpenFlow at Work

As you learned in the previous article in this issue, the basic idea of software-defined networking is to centralize control of network devices such as routers and switches in a way that allows the network to behave more intelligently. Processing power on the network device is therefore kept to a minimum: the hardware just forwards packets and does not need to execute complex logic to make individual forwarding decisions. The controller maintains an overview of the network, passing simple instructions to the networking devices in the form of a flow table, which the device will use as a roadmap for forwarding packets (see the "OpenFlow Controllers" box).

This separation of data and control reduces the unit cost significantly, because the software-side implementation of the various protocols for operating a device in a Layer 2 domain (bridged/switched network) is expensive. Also, the admin does not have to pre-configure the devices individually. Since all the intelligence is in the controller, you don't need to leave your desk; instead, you can manage the network from a central point.

OpenFlow uses a flow-based routing concept. By considering the network as a whole, the controller can set up end-to-end connections across multiple switches for certain types of packets. OpenFlow maps the packet type to the transport protocol.

As soon as the controller detects the signature, it instructs the participating switches in the network to set their forwarding entries accordingly. The admin thus no longer needs to train the local switches but can use the controller to develop granular rules for the entire adaptive network.

The OpenFlow forwarding logic basically consists of a flow table, which in turn contains various flow entries (Figure 2). Included with the entries is a header, which collects an identification pattern in several fields; this identifier information will play a role in packet detection (matching patterns). The flow entries define actions applicable to the pattern or packet type.

Figure 2: The flow table regulates the data flow by reference to the flow entries.

The specifications are sometimes very extensive, because they provide detailed explanations of the flow entry structures, the structure of the flow tables, the possible actions, and the counter fields. If you're interested in the details, you'll find the OpenFlow specifications at the website for the Open Networking Foundation.

When a packet in an OpenFlow network arrives at one of the ports reserved for OpenFlow, the switch examines the header field (Figure 3). The switch compares the bits with the entries in its flow table, which may use wildcards as entries. In case of a match, the switch performs the actions defined in the flow entries and updates the counter.

Figure 3: Schematic of the header field from the OpenFlow 1.0 specification.

The action can be, for example, forwarding the packet to a port, modifying its header field, or forwarding it to another flow table. If the switch fails to find the entry in the header field in a flow table, it encapsulates the packet and sends it to the controller, which then decides how to proceed. The controller either forwards the packet directly or instructs the switches to add the flow entry to their flow tables so that they can handle packets with this pattern in the future.

The controller has two types of flow entries: proactive and reactive. Proactive means the controller instructs the switch to set a flow record for a given flow table without the switch first asking for permission. Reactive tells the switch to encapsulate an unknown packet and send it to the controller; in response, the controller generates a matching flow record for the unknown packet.

Once a switch has set a flow entry, it waves through the packets that belong to the flow. This approach reduces the response time because it saves the detour via the controller.

Hardware

OpenFlow has evolved into production use as an SDN concept; the dedicated switches that support OpenFlow are described by their vendors as OpenFlow enabled. These are hybrid switches that, in addition to their legacy switch functionality and the associated protocols, such as the Link Local Discovery Protocol (LLDP), offer an OpenFlow configuration. To use them, network managers need, depending on the vendor and model, to complete various configurations of the OpenFlow instance on the switch. This usually means switching the appropriate ports or VLANs to OpenFlow mode so that an external controller can manage the switch.

Examples with Mininet

I'll describe three practical examples that illustrate how to use OpenFlow. To cook up these simulations, I'll use Mininet [6], a tool designed for testing and simulating network configurations. (See the article on Mininet elsewhere in this issue.)

Level 1: There and Back Again

Imagine two hosts connected by a switch (Figure 4). Initially, I won't define a controller and set flow entries manually. To check whether the connection has been established, host 1 uses the CLI in Mininet to ping host 2 (Listing 1). I ping host 2 from host 1:

mininet h1 ping -c 4 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.From 10.0.0.1 icmp_seq=1 Destination Host Unreachable[...]

Figure 4: OpenFlow controllers often serve as a platform for networking applications.

The attempt fails because the switch initially does not forward packets without flow entries and without a controller. The absence of a controller and flow entries is revealed using the dpctl command, a utility shipped with OpenFlow that provides access to a switch's flow table:

~$ dpctl dump-flows tcp:127.0.0.1:6634
stats_reply (xid=0x6929ef28): flags=none type=1(flow)

dpctl then sets a flow entry that forwards the incoming packets arriving at port 1 of the switch to port 2:

~$ dpctl add-flowtcp:127.0.0.1:6634 in_port=1,actions=output:2

Again, nothing: The second ping fails because, although the switch forwards packets to host 2, host 2 is not responding.

If you now use dpctl to create another flow entry that forwards from port 2 to port 1, the results are positive: The two hosts communicate freely through the switch, as long as the idle timeout does not interfere (Listing 2).

Level 2: Where is Arp?

Scenario 2 uses a network structure identical to Scenario 1, but it sends the initial command to ensure that Open vSwitch enters the game as a built-in controller:

sudo mn --topo single,2 --switch ovsk --controller ovsc

The connection test with ping is immediately successful; the flow table shows three flow entries (Listing 3).

In addition to the Arp reply, two ICMP requests and replies appear in Listing 3; these requests originate from the flow entry generated by the ping. What happened to the Arp request, which usually comes as a broadcast over the network? If you sniff the control channel, which connects the switch and the controller, using tcpdump or Wireshark, you can determine that the controller has the Arp requests forwarded directly, which does not require a flow entry.

If you use Wireshark with the OpenFlow dissector, which is part of the Mininet image, you can see and analyze the OpenFlow controller's entire communication. Figure 5 shows an example of the handshake between the controller and the switch: The switch uses the Features Reply to signal to the controller which OpenFlow actions it supports.

Figure 5: With Wireshark, you can easily sniff communications between controllers and switches.

Level 3: Tree-Like

In the third and final scenario, Mininet generates a network with a tree topology (Figure 6), in which three hosts each are connected to switches S2 through S4. Mininet then plugs the three switches into an aggregation switch (S1). This topology is typical for networks in companies or data centers. This time, the admin defines a remote controller, assigns an IP address, and sets an OpenFlow standard controller port.

Figure 6: Floodlight recognizes the tree structure of the test network and automatically maps it graphically.

sudo mn --topo tree,depth=2,fanout=3 --mac --switch ovsk--controller=remote,ip=<Controller-IP>,port=6633

The admin can select any computer on the local network and launch a controller (e.g., Floodlight) in the basic configuration:

java -jar floodlight.jar

If Mininet is online, Floodlight detects both the connections to the switches as well as the topology from the console output. Now, you can enter

http://<Controller_IP>:8080/ui/index.html

to launch the Floodlight web user interface and view the switches and hosts that have been detected – the Topology tab presents a graphical display. The graph in Figure 6 might be more functional than pretty, but it is sufficient for an overview.

Summary

OpenFlow fixes many of the problems that networks have been lugging around since the first technical implementation of Ethernet. Thanks to OpenFlow, admins no longer consider their networks as a collection of various standalone devices that operate locally and each forward packets according to their own rules, but as a great whole, with the network devices acting as remotely controlled locks. This change in paradigm opens a door to new ideas. As probably the most common manifestation of SDN that is also used in commercial products, OpenFlow brings a breath of fresh air to the field of virtualization, adding flexibility to networks and fertile ground for many applications.

As so often happens, however, all that glitters is not gold. It still isn't clear whether OpenFlow is ready to serve as a replacement for conventional network infrastructure in large-scale, enterprise production environments.

One problem is that the rapid evolution of the OpenFlow specification means that hardware does not always support the full range of OpenFlow actions [7].

The Author

Marc Körner works as a research assistant at the CIT, Technical University of Berlin. He has been working with OpenFlow for more than three years and is currently finishing his thesis, which focuses on the integration of OpenFlow applications in data centers.