Control Center

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 [1]. 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 [2] 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). For optimum utilization of resources, Floodlight relies on multi-threading and can handle several million new flows per second.

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

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.