SDN Series Part Five: Floodlight, an OpenFlow Controller
Beacon is an open-source SDN controller developed by David Erickson at Stanford, which we will not be covering in this series. Instead, in this part, we will discuss Floodlight SDN Controller that used Beacon controller as its foundation. However, there is no doubt that Floodlight, in comparison to Beacon, has grown leaps and bounds to be one the most popular open source SDN controllers with more than 15,000 downloads. Floodlight is also recongized as better with respect to features and performance.
Floodlight Controller, an Apache licensed, Java-based OpenFlow controller, is one of the significant contributions from Big Switch Networks to the open source community. Floodlight’s architecture is based on Big Network Controller (BNC), the company’s commercial offering. Applications written for Floodlight Controller by any developer can be made available for certification and qualification with BNC. Hence, as Floodlight is one of the core elements of the Big-Switch’s product(s), it would be fair to assume that the company will support it.
Before we dig deep into Floodlight Controller, I would like to clarify the term ‘Floodlight’ as it is used by the Big Switch’s opensource program. The term ‘Project Floodlight’ is used as an umbrella-term to cover multiple projects such as Floodlight Controller, Indigo, LoxiGen, and OFTest. In this article, Floodlight is used only to refer to the SDN controller.
Just like many other controllers, when you run Floodlight, both northbound and southbound operations of the controller become active. That is, when you run the Floodlight, the controller and the set of configured module applications will run, too. The northbound REST APIs exposed by all the running modules becomes available via the specified REST port. Any application can interact (retrieve information and invoke services) with the controller by sending http REST commands. On the other hand, at the southbound, the provider module of Floodlight will start listening on the OpenFlow-specified TCP-port for connections from the OpenFlow switches.
Floodlight, currently supports OpenFlow 1.0. Versions of 1.3 and 1.4 are in the pipeline. With an extensible Java development environment, and enterprise-grade core engine, Floodlight is both an easy to use and robust SDN controller. In the next section we’ll discuss the architecture and follow it with discussions about writing applications on top of the Floodlight Controller.
Floodlight Architecture
The term ‘modular architecture’ is used to describe the architecture of the Floodlight Controller, which is shown in the figure below. The core architecture includes various modules, such as topology management, device/end-station management, path/route computation, infrastructure for web access (management), counter store (OpenFlow counters), and a state storage system, that are well stitched a by module-management system. Below we will describe some of the important components of the controller architecture.
Figure-1 Floodlight Architecture
Rest-API Based Applications
Floodlight comes with few applications that use the exposed REST APIs. Circuit Pusher utilizes floodlight rest APIs to establish a path between any two IP-addressable devices by adding flow-entries in all the switches that constitutes the path. In addition to circuit-pusher, Floodlight can be run as the network backend for OpenStack using a Neutron plugin. There are two main components to this solution:
A RestProxy to realize the connectivity between floodlight controller and OpenStack Neutron.
VirtualNetworkFIlter to realize the Neutron APIs. The VirtualNetworkFilter module, which implements L2-address based network isolation, is not dependent on OpenStack-Neutron, and can be activated via configuration file. However, the RestProxy plugin was designed to run as part of OpenStack’s Neutron service.
Built-In Module Applications
Floodlight includes multiple applications in its distribution, and below I’ll summarize a few. Typically, these applications are great place for a developer to understand the usage of APIs if he/she is interested in developing SDN-applications. This is true for all SDN controllers, and not just Floodlight.
The forwarding application, as name suggests, can forward packets between any two devices that may be connected via OpenFlow (or non-OpenFlow) switches. The learning-switch is same as what we had seen in NOX/RYU/Trema, whereas the hub application just floods any incoming packet to all other active ports. The static-flow entry pusher just adds a OpenFlow flow entry (Match+Action) in any specified switch, using the flow-mod message of OpenFlow. The VirtualNetworkFilter, as described above is a MAC-Address based network slicing application. Finally, there is a firewall application to apply ACL (access control list) rules, which are nothing but set of conditions, to control (allow or deny) the traffic flow based certain set of policies.
Core, Internal and Utility Services
An important point we need note about any SDN controller is that – the in-built services defines the capability of the controller, and these services are the ones that are used by the northbound-applications. Accordingly, Floodlight includes services ranging from discovering network states and events to enabling switch-communication support to utilities like storage, threads and web-UI. Below we will summarize some of the services
| Service Name | Description |
| Floodlight-Provider | Manages the secure-connections to switches. FloodlightProvider is the module that is responsible for translating received OpenFlow messages into events, which may be processed by other modules. In addition, it also ensures the ordering of the received messages before passing it to the interested modules. [IOFMessageListener]. |
| Device-Manager | The Device Manager keeps track of the devices or end-stations via PacketIn requests, rather the information (MAC, VLAN, etc) present in the PacketIn, With this, it can also learn to which port of which switch a particular device is connected. |
| Link Discovery Manager | As in other SDN controllers, the link discovery also uses LLDPs to detect links. In simple terms, a link is set to be established between two switches if an LLDP is sent out of a port of one switch, and the same LLDP is received on a of port of another switch. |
| Topology-Service | The Topology Service computes topologies based on link information from the Link-Discovery-Manager. Here, a term o OpenFlow island is used to indicate a group of connected OpenFlow-switches that are managed by the same instance of an SDN-controller (floodlight). In-addition the Islands can be interconnected using non-OpenFlow switches on the same layer 2 domain. |
| Flow Cache | This module exists to encourage application developers to implement solutions according to their needs by handling a range of events from then network in their own way. The freedom is provided to decide what all events to handle and how to handle the same. |
| Packet Streamer: | Packet streamer can forward OpenFlow packets to any connected monitoring device in the network. It provides an interface to specify (in terms of one or multiple fields in the packet) the interested OpenFlow messages, typically termed as a filter. |
| Memory Storage Source | The MemoryStorageSource is an ‘in-memory’ storage source – storage of shared data. Floodlight modules that depend upon this can create/delete/modify data in the memory storage source. In addition, modules can also register for changes to data, by indicating the tables and rows. |
| ThreadPool | ThreadPool is a Floodlight module wrapper for a Java’s ScheduledExecutorService. It can be used to create threads that can run at specific times or periodically. |
As mentioned earlier, Floodlight Controller is part of the Floodlight-project by BigSwitch network. Big Switch also provides an open source agent, named Indigo, that has been incorporated into commercial products. In addition, Big Switch has also provided Loxi, an open source OpenFlow library generator, with multiple language support to address the problems of multi-version support in OpenFlow.
As a development environment, Floodlight is fully Java-based. Build and debugging tools are available. In the next two sections, we will discuss Floodlight from the developer point of view.
Floodlight Controller RestAPIs
Floodlight includes a RestAPI server, which uses the Restlets library. With the restlets, any module developed can expose additional REST APIs through an IRestAPI service – typically, the modules that depend on REST server, expose APIs by implementing RestletRoutable in a class. The controller itself presents a set of extensible REST APIs, to get and set various types of information. The REST API is the recommended interface to develop applications utilizing Floodlight supported features.
Once the floodlight is up and running, one can use the APIs that are already supported in the controller. The Figure-3 summarizes various functions that are supported by the Floodlight. For example, the below curl command gets the switches that are connected to the controller with IP as 10.0.0.1.
|
1 |
curl http://10.0.0.1:8080/wm/core/controller/switches/json |
Figure-2 Floodlight REST API Structure.
How to Write a Module in Floodlight:
In our previous articles, while describing the process of writing applications on top of SDN controller, we had taken a case-study and described it as a step-by-step process. However, for Floodlight, there exists considerable amount of documentation for writing modules and adding services. Hence, in this article, we will just summarize the whole process in one simple figure. The readers can go through a specific example at [5,6,7].
Fl Figure Process For Writing Modules In Floodlight.
As summarized in the figure above, the process involves scoping the module functionalities, followed by translating those requirements into specific events, messages and utilities. Once the requirements are enlisted, a class matching those functionalities are declared and implemented – including handing messages, events, and implementing the exposed APIs.
In summary, inspired from the Beacon, the OpenFlow-based FloodLight controller consists of rich set of modules, where each module provides a service that can be accessed through either a simple Java API or a REST API.
Sridhar received his Ph.D degree in computer science from National University of Singapore, in 2007, his M.Tech. degree in computer science from KREC, Suratkal, India, in 2000, and his B.E. degree in instrumentation and electronics from SIT, Tumkur, Bangalore University, India, in August 1997. He worked as Research lead at SRM Research Institute, India, Post-doctoral fellow at Microsoft Innovation Center, Politecnico Di Torino, Turin, Italy, and as a research fellow at Institute for Infocomm Research (I2R) Singapore. He has worked on various development and deployment projects involving ZigBee, WiFi and WiMax. Sridhar is currently working as Group Technical Specialist with NEC Technologies India Limited. Sridhar’s research interests are mainly in the domain of next-generation wired and wireless networking, such as OpenFlow, software defined networking, software defined radio based systems for cognitive networks, Hotspot 2.0 and the Internet of Things.
