Today’s communication networks are designed around the original mechanisms of Ethernet and TCP/IP. Because of the success of these early technologies, networks grew bigger and more complex, which led to a need for more complex control options, such as VLANs, ACLs, and firewalls.

A variety of heterogeneous network appliances known as middleboxes (firewalls, load balancers, IDS, optimizers, and so on) each implement their own proprietary control stack and provide a vendor-dependent management interface in the form of a CLI, a web interface, or a management protocol. Reciprocal communication is handled by other complex protocols such as Spanning Tree, Shortest Path Bridging, Border Gateway, or similar. Each additional component thus increases the complexity and complicates integrated network management. The consequences are often low network utilization, poor manageability, lack of control options in cross-network configurations, and vendor lock-in.

One way out of this dilemma is Software Defined Networks (SDNs) and OpenFlow. OpenFlow is an Open Networking Foundation (ONF) standard protocol that abstracts the complex details of a fast and efficient switching architecture. Today, OpenFlow offers an open control interface that is now implemented in hardware by all major network component manufacturers. Several vendors even offer software switches that support virtualized datacenters.

OpenFlow also supports the concept of separating the data and control paths, which lets a central control point oversee a variety of OpenFlow-enabled network components. The SDN controller could even be a distributed application to provide additional security, fault-tolerance, or load balancing.

The OpenFlow protocol allows for uniform, direct control of the infrastructure, thus removing the need for complex and sophisticated network management. Added flexibility and freedom from the proprietary protocols of a single hardware vendor are pleasant side effects.

OpenFlow integrates easily with homegrown network applications, and you can look forward to significant reductions in cost. Figure 1 shows the differences between a legacy network and an SDN.

Figure 1: The difference between a legacy network with distributed, heterogeneous, and vertically integrated network components and an SDN using OpenFlow.

Rules Control

The OpenFlow API uses simple primitives for handling network packets, as well as querying and analyzing statistics. On the basis of matching rules for detecting identical header information, OpenFlow allows packages to be grouped into flows. These flows are assigned a priority and an action. A simple OpenFlow rule looks like this:

match="dl_type=ip, nw_type=tcp,tp_dst_port=80", action="output=2",priority="10"

This rule states that all IP packets with a destination TCP port of 80 are forwarded to port 2. If several rules apply for a packet, the priority determines which rules take precedence.

The simple primitives of the OpenFlow protocol itself show its flexibility. At the same time, they represent a challenge. Although OpenFlow allows programming of the SDN, it does not necessarily make it easy. Managing a network using OpenFlow primitives would be like developing your software in machine code. The need for an easier and more intuitive interface has led to the development of the SDN controller.

An SDN controller assumes the central role of communicating with the OpenFlow switches and abstracting the OpenFlow API. Instead of using complicated OpenFlow primitives, SDNs can thus be managed using higher-level commands of the type “Install a data path from A to B” or “Reject all packets to Host X.” The controller resolves any conflicts that occur, translates the commands into OpenFlow primitives, and then installs them on the corresponding switches.

On the basis of these abstractions, the actual network applications, such as MAC learning, Spanning Tree, and routing protocols, can then be implemented. Completely new ideas, such as multipath switching, BYOD applications, or a central ACL configuration, are implemented relatively quickly.

The development of SDN controllers and the search for the right OpenFlow abstractions are still at an early stage – and are the subject of intensive research activities. If you can live with some limitations, the Floodlight OpenFlow SDN controller is a promising open source solution that is available now.

Floodlight OpenFlow Controller

Floodlight, which is written in Java, is a high-performance, open source OpenFlow controller. Floodlight was developed on the basis of Beacon, an experimental OpenFlow controller from Stanford University, and it is now supported by a large developer community. BigSwitch Networks backs Floodlight as a company that primarily offers solutions for commercial datacenters.

Currently, Floodlight implements OpenFlow version 1.0 and works with any switches, routers, virtual switches, and access points that also support this version. Floodlight is released under the Apache license and provides a number of network applications, in addition to the control framework for controlling the OpenFlow-enabled network components.

Floodlight Architecture

Floodlight offers a number of features and abstractions for controlling an OpenFlow network. Supporting these features is a modular architecture, as well as a series of basic applications (Figure 2).

Figure 2: Floodlight architecture and the relationships between each of the Floodlight Controller’s Java modules and the RESTful Northbound API.

For optimum utilization of resources, Floodlight relies on multi-threading and can handle several million new flows per second.

The Westbound Java API allows the development of custom modules in Java and quick interfacing with the core controller. The modules are loaded via a separate module system when the Floodlight controller starts. You can thus leverage the full functionality of the controller and OpenFlow API and promptly respond to events on the network, such as the emergence of new packets or new flows.

The northbound REST API allows the integration of external applications in any language through JSON. Compared to the Java API, however, the REST API is relatively slow. Reacting to events in real time is not possible. Instead, the REST API supports querying service and status information, for example, the a priori installation of OpenFlow rules by external applications.

One of the standard applications that relies on the REST API is Floodlight’s own GUI (Figure 3). Additionally, a Python-based Circuit Pusher automatically installs persistent OpenFlow rules for the connection between two IP addresses.

Figure 3: The Floodlight GUI visualizes all the critical information for the OpenFlow network. You can view switch states, the network topology, and the connected devices.

Main Floodlight Modules

In traditional networks, Spanning Tree or routing protocols often take on the task of topology management, such as ensuring freedom from loops. Due to the distributed algorithms of these protocols, however, a number of difficulties arise, such as a complex configuration, a limited number of hops, or long convergence times for changes in the underlying network infrastructure. Exploiting multiple paths between the start and destination of a data flow involves considerable effort and the use of other protocols.

In contrast, SDN controllers have a central view of all network components and can therefore greatly simplify topology management.

To let this happen, Floodlight implements a sophisticated mechanism for automatically detecting the topology of an OpenFlow network. Using a link-discovery module, the controller generates both LLDP and broadcast packets (referred to as BDDPs) and sends them to all neighboring switches on a regular basis. Assuming all switches consume LLDP messages and forward broadcast packets, Floodlight can identify active connections by receiving its own messages and computing the network topology.

Floodlight makes a distinction between direct links and broadcast links; a direct connection is always assumed if it receives its own LLDP packets. In this case, two Open Flow switches are directly connected under the control of the same Floodlight instance.

Based on the information of the link discovery mechanism, the topology service computes a topology map in the form of a directed graph. The maps contains all the relevant information about interconnectivity between switches, and they can be used by other applications, for example, for computing a spanning tree.

Loop-Free Islands

Another interesting and important concept is the combination of directly interconnected OpenFlow switches to groups known as OpenFlow islands. Islands can connect to other islands via broadcast links. With certain restrictions, Floodlight thus supports the combination of OpenFlow equipment with standard network components.

Because of the broadcast packets, it is important to avoid loops in connections with non-open flow switches. For this reason, any OpenFlow island can only have exactly one connection to non-OpenFlow equipment. Furthermore, OpenFlow and non-OpenFlow islands must not form a loop themselves. Figure 4 shows a potential topology that allows for OpenFlow and non-OpenFlow equipment.

Figure 4: Example of a permissible topology in Floodlight, with OpenFlow devices and standard equipment. OpenFlow islands can have exactly one connection to non-OpenFlow islands.

Packet Forwarding

Floodlight currently provides two modules for automatic packet forwarding between endpoints. A relatively simple Forwarding module mainly serves as an exemplary introduction to Floodlight. The Forwarding module handles each packet individually, which severely limits performance.

The complex Learning Switch module implements behavior similar to standard switches: The Learning Switch detects and learns about new devices based on their MAC addresses.

Because of Floodlight’s global view, it also offers advanced functions. When Floodlight detects a new flow, the Learning Switch module identifies the input and the output switches, as well as all other switches on the shortest path between the start and endpoint. Once a path has been found, the module installs the appropriate OpenFlow rules for handling the new flows on all participating switches.

Compared to the simple Forwarding module, the performance of the Learning Switch module is several degrees of magnitude greater because, after you install the OpenFlow rules, packet forwarding is accomplished solely in the forwarding path of the switches and interaction with the controller is not necessary for each message.

One restriction applies to both modules: When OpenFlow coexists with standard equipment on the network, the algorithm identifies all OpenFlow islands and only forwards packets directly to the destination within the island. If the target is unknown, or located on a different island, the packets are flooded.

Even based on these modules, the advantages of SDN, OpenFlow, and Floodlight are clearly visible. Even relatively simple implementations offer significant advantages, and complex Spanning Tree Protocol configurations become unnecessary even for large meshed networks.

Additionally, multipath connections can be implemented within an OpenFlow island with very little effort. In the case of link failures, the controller can react immediately and intelligently to changes in the topology and redirect existing data flows. In an ideal case, this change is transparent and does not involve much delay. Long convergence times are thus a thing of the past.

Divide and Conquer

Another example of an advanced packet forwarding and manipulation application with OpenFlow is network-internal load distribution across multiple servers. Traditional server load balancers are typically individual systems that reside upstream of a server landscape and distribute the load to the available applications as a function of the service. One major drawback with this approach is that the classic load balancer is a significant and unavoidable bottleneck on the network.

In an SDN, however, this bottleneck can easily be avoided. Thanks to the extensive control options for data flows, the entire SDN, that is, every single switch, router, and network path, can act as a load balancer and forward data streams directly to different servers along distributed paths. This technique avoids overloading any single network appliance. Instead, server load balancing becomes a network service.

Floodlight already provides a rudimentary version of this approach. The Floodlight Load Balancer application is a simple application for the distribution of UDP, TCP, or ICMP flows to different servers. No single network component handles the task of load balancing; the task is instead distributed through the entire network.

The Floodlight load balancer can be managed via a REST API, which is based on the OpenStack Quantum Load Balancer as-a-service API (LBaaS). This means that virtual IP addresses can be created for the load balancer and flows directed to these addresses automatically redirected to physical servers on the network. Once configured, the OpenFlow switches automatically handle a large part of the work.

Like many other Floodlight applications, the load balancer is currently still in development and thus far offers only basic functionality. For example, flow distribution is based on a round-robin method and does not take into account the server load or the actual data traffic. Nevertheless, it is already possible to implement a simple but powerful server load balancer with the existing components if you adapt the existing software to meet your own needs.

More Security

SDN and OpenFlow are also breaking new ground in the field of security by simplifying traditional approaches. The congruent installation of Access Control Lists (ACLs) on a large number of network switches is quite complex, and, even in professional systems, discrepancies arise between requirements, documentation, and the actual configuration. Therefore, a system that automatically sets ACLs on all network components is desirable.

Again, Floodlight offers an elegant and standardized solution: The Floodlight stateless firewall application is a reactive Floodlight module that centrally stores network-wide ACL configurations for all OpenFlow switches. The firewall rules (ALLOW or DENY) can be configured relatively conveniently for arbitrary OpenFlow matches and sorted by priority thanks to a REST API.

Each packet-in event generated by the first packet in a new flow is compared with the existing firewall ruleset until either the set is empty or a matching rule is found. If matching rules are found, the highest priority rule determines whether the packet is forwarded or the flow is blocked. If no rule is found, or the rule states that the flow is allowed, the packet-in event passes through the firewall and is processed and forwarded by subsequent Floodlight modules. However, if a rule that blocks the flow is found, the firewall installs an OpenFlow rule on the OpenFlow input switch to discard all further packets in the same flow.

The Floodlight firewall thus allows centrally configured network-wide ACL rules that are automatically enforced at all (or selected) switches. The following simple example illustrates the configuration options. The rules exclusively allow connections in the subnet 192.168.1.0/24 to TCP port 80.

TCP | 192.168.1.0/24 | 80 | ALLOW | 1 TCP | 192.168.1.0/24 | * | DENY | 2

Initial Steps

As a Java application, Floodlight runs on a Java VM and is therefore available on virtually all operating systems. Many popular Linux distributions, including Ubuntu, actually have a release in their repositories. Additionally, a preconfigured virtual machine image is available from the project website.

Because of the rapid development of Floodlight, you should install the latest version from GitHub or nightly builds, which have proved to be extremely stable in the past. Floodlight is easiest to install on Linux (e.g., Ubuntu). For this purpose, a Git client, Python, and Apache Ant must be in place in addition to a Java environment. To load Floodlight Linux from GitHub and compile, you can do the following:

$ git clone git://github.com/floodlight/floodlight.git
$ cd floodlight
$ git checkout stable
$ ant

Floodlight can be configured via Java properties files. The directory

./src/main/resources/floodlightdefault.properties

contains the default settings, such as port settings, and the application modules, which are loaded automatically.

Before initial tests, it makes sense to replace the simple net.floodlightcontroller.forwarding.Forwarding module with the higher performance net.floodlightcontroller.learningswitch.LearningSwitch module. You can then launch Floodlight by typing

$ java -jar target/floodlight.jar

Floodlight will now wait for connections from OpenFlow switches. If you do not have any OpenFlow-enabled hardware right now, you can simulate an OpenFlow network with the free MiniNet software. Again, installing from GitHub is recommended:

$ git clone git://github.com/mininet/mininet
$ mininet/util/install.sh -a

The procedure takes about five minutes and installs all MiniNet components, including the Open vSwitch OpenFlow software switch, a Wireshark dissector for analyzing OpenFlow messages with Wireshark, and POX. (POX is another OpenFlow controller written in Python.)

The following command will start MiniNet with a minimal topology that connects two hosts over an OpenFlow Switch and establishes a connection to an external Floodlight controller:

$ sudo mn --topo=minimal --controller=remote --ip= --port=

MiniNet immediately connects with Floodlight, giving you a miniature SDN for testing purposes.

For further help or information about Floodlight, take a look at the project website. The Floodlight project has a mailing list, and you will find a great developer community that is always willing to help.

Conclusions

The Floodlight OpenFlow SDN controller already offers impressive performance and many applications, and the Floodlight developers are working on some interesting improvements, such as a more efficient handover in wireless networks, multipath and in-network load balancing, and application-aware traffic engineering.

Software Defined Networking provides a fast, cross-hardware, and above all, inexpensive option for implementing your own network management solutions. The Floodlight project demonstrates the potential of SDN; however, Floodlight will need a few critical new features before is truly useful in a production environment. Thus far, Floodlight offers only very limited configuration management. Virtually all of the configuration information is kept in memory only and is lost when you reboot the controller.

Additionally, Floodlight lacks a high availability mechanism. A controller failure can quickly paralyze the entire network, especially if you primarily use reactive applications. The currently available applications are still relatively young and offer only limited functionality.

Despite these issues, Floodlight is ideal for your first contact with Software Defined Networking. In combination with the MiniNet Software and Open vSwitch, which are also available for free, Floodlight makes it easy to take your first steps and develop some expertise in SDNs.

OpenFlow controllers like Floodlight are currently still in their infancy, but you can look forward to their changing the future of communication networks.