The FloodLight Controller.

FloodLight is an open-source, Java-based controller maintained by OpenFlowHub.

This page is comprised of many notes that may be transient. Anything referencing links will be repeated for completeness.

Quick Links

Installation
Features
Adding functionality
Architecture - the section most likely to change as I figure things out/discover my own misconceptions.
Floodlight/Mininet VM

Installation.

The following describes the installation of FloodLight on an Ubuntu 11.04 (natty) system. Installation is described on their ​website, but will be repeated here. If you are using SSH, You may want X11 forwarding to be able to launch Eclipse later on.

1. install the dependencies:

   apt-get install build-essential default-jdk ant python-dev git-core eclipse
   

2. pull sources from github, and build:

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

Running Floodlight

There are two ways to do this, both from the floodlight/ directory.

1. directly through java:

   java -jar target/floodlight.jar
   

If parameters e.g. OpenFlow port need to be modified, create a config file and point floodlight to it with the -cf flag:

cp src/main/resources/floodlightdefault.properties path_to_conffile/config.properties
<edit config.properties>
java -jar target/floodlight.jar -cf path_to_conffile/config.properties

For example, if you want floodlight to listen on port 6636 instead of 6633, modify '6633' to '6636' in the following line of your properties file:

net.floodlightcontroller.core.FloodlightProvider.openflowport = 6633

2. as an Eclipse project - first set up Eclipse:

   ant eclipse;
   

then import Floodlight as a project (verbatim from the website):

• Open eclipse and create a new workspace
• File → Import → General → Existing Projects into Workspace. Then click “Next”.
• From “Select root directory” click “Browse”. Select the parent directory where you placed floodlight earlier.
• Check the box for “Floodlight”. No other Projects should be present and none should be selected.
• Click Finish.

Once imported, the controller may be run by right-clicking on Controller.java (net.floodlightcontroller.core.internal.Controller.java, found under src/main/java) and doing the following:

• Click Run→Run Configurations
• Right Click Java Application→New
• For Name use 'FloodlightLaunch'
• For Project use Floodlight
• For Main use net.floodlightcontroller.core.Main
• Click Apply

This creates a handle for launching Controller.java as an application.

The learning switch is loaded by default. The controller listens on 0.0.0.0:6633 (host, all interfaces with an IP address).

Features

Floodlight comes with several tools/features:

• ​RESTful API
• ​static flow pusher
• ​web UI

The REST API takes the same syntax as the BSN controller. The web UI is already incorporated into the latest version so there is no downloading/git checkout required.

Adding functionality.

A base tutorial can be found ​here. The steps assume that you are using Eclipse. The rough steps are the following:

1. Create a new class under src/main/java, with the proper interfaces.
2. Export services if it interacts with other services e.g. the REST API.
3. Register the module so that it is loaded at startup. This involves adding the fully qualified module name to two files:
   • net.floodlight.core.module.IFloodlightModule - list of modules recognized by the loader
   • floodlightdefault.properties - list of modules to be loaded at startup.

Some module components

• IFloodlightProviderService : Needed for listening to OpenFlow messages by registering with the FloodlightProvider.
• getModuleDependencies() : in a module, the function to indicate dependencies to the module loader e.g the IFloodlightProviderService above. This is probably the function that is called by the loader when it searches for loadable modules and tries to discern its dependencies.
• getModuleServices() : in a module, the function to indicate services exported by the module.
• getServiceImpls() :
• init() : in a module, the function where contexts are defined for services that the module is dependent on. It seems to be similar to a constructor.
• isCallbackOrderingPrereq(), isCallbackOrderingPostreq() : where the module should be in the message processing chain.
• startUp() : in a module, defines external initializations associated with other modules to which it is dependent on.
• receive() : defines what a module does when it receives an event e.g. the one specified in startUp().

Exporting services

1. create a interface for the service
2. Add interface to the module
3. add classes used by the service e.g. the REST API

Architecture and Implementation

This section describes the architecture and some of the implementations of the various parts of the controller. These are largely references to source code and their Javadocs.

• ref: ​http://www.openflowhub.org/display/floodlightcontroller/Advanced+Tutorial

The controller has two main components:

• the core, which listens to OpenFlow messages and dispatches events, and
• secondary modules which handle the events e.g PACKET_INs.

The secondary modules register with the core module when the controller is starting up. They do everything from recording certain aspects of flows to providing a RESTful API to modifying the flow tables within switches. They may also export services to leverage other modules, such as the REST API.

Startup

The following steps describe the startup process of the Floodlight controller. The reference is the source code in Main.java.

1. The FloodlightModuleLoader reads in the list of modules, and loads them, returning an IFloodlightModuleContext instance.

The FloodlightModuleLoader basically coordinates calls to the functions provided by the IFloodlightModule interface for each module in the config file (floodlightdefault.properties) and the modules that they depend on. Some key points are:

• IFloodlightModule is the interface that lets you define Floodlight module behavior in a uniform way.
• The function loadModulesFromList finds all of the modules that it needs to load via a DFS beginning with the modules listed in the config file. The search is facilitated by IFloodlightModule functions such as getModuleDependencies.
• The structure moduleSet will ultimately contain the minimum number of modules that need to be loaded at startup.

2. The IFloodlightModuleContext instance fetches copies of the IRestApiService and IFloodlightProviderService modules.

IFloodlightModuleContext provides a clean mechanism for retrieving references to the loaded modules/services, and their configuration parameters. FloodlightModuleContext implements this interface.

• IRestApiService provides REST API functions.
• IFloodlightProviderService provides the core controller functions and then some.

3. Run the REST API and core controller.

At this point, Floodlight is up and running. The TCP server functions are implemented with ​Netty. The controller's run routine does two things:

1. create a server-side channel on port 6633 (or where specified)
2. handle updates.

Updates include switches joining and departing, controller role change, and controller IP change.

IFloodlightProviderService

This interface lies at the core of Floodlight's functions (literally in net.floodlightcontroller.core). The class Controller implements this interface and defines Floodlight's corre controller functionalities.

OpenFlow message processing chain

The manner in which a control message is processed is defined in the modules themselves through the IOFMessageListener interface's receive function.

In Controller:

1. injectOfMessage(sw, msg) calls overloaded injectOfMessage with null context
2. injectOfMessage (sw, msg, context) calls handleMessage(sw, msg, context)
3. handleMessage(…) calls receive for each listener subscribed to the particular type of message received from a switch (types are defined in OFType)
   • messageListener maintains mappings between control message type and listeners.
   • This is also where IListener's Command enumeration (return value for IOFMessageListener::receive) is used to decide if a message continues down the processing chain.

The Floodlight VM

This is a VM image geared towards VirtualBox containing a running floodlight instance, mininet, and wireshark.
It can easily be run on qemu/kvm after conversion to qcow2 with qemu-img convert -O and with the parameters used to run mininet.

temporary mininet info

Using with vnc: requires:

kvm-pxe ssvnc tightvncserver