= The !FloodLight Controller. =
!FloodLight is an open-source, Java-based controller maintained by !OpenFlowHub. [[BR]][[BR]]
This page is comprised of many notes that may be transient. Anything referencing links will be repeated for completeness.  
== Quick Links ==
 [#install Installation][[BR]]
 [#features Features][[BR]]
 [#modding Adding functionality][[BR]]
 [#arch Architecture] - the section most likely to change as I figure things out/discover my own misconceptions. [[BR]]
 [#vm Floodlight/Mininet VM][[BR]] 
== Installation. == #install
The following describes the installation of !FloodLight on an Ubuntu 11.04 (natty) system. Installation is described on their [http://floodlight.openflowhub.org/getting-started/ website], but will be repeated here. If you are using SSH, You may want X11 forwarding to be able to launch Eclipse later on.[[BR]]

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.  
[[BR]][[BR]]
The learning switch is loaded by default. The controller listens on 0.0.0.0:6633 (host, all interfaces with an IP address).

== Features == #features
Floodlight comes with several tools/features: 

 * [http://www.openflowhub.org/display/floodlightcontroller/REST+API RESTful API]
 * [http://www.openflowhub.org/display/floodlightcontroller/Static+Flow+Pusher static flow pusher]
 * [https://github.com/thewmf/floodlight 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. == #modding
A base tutorial can be found [http://floodlight.openflowhub.org/developing-floodlight/ 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. 
 1. Export services if it interacts with other services e.g. the REST API. 
 1. 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
 1. Add interface to the module
 1. add classes used by the service e.g. the REST API

== Architecture and Implementation == #arch
This section describes the architecture and some of the implementations of the various parts of the controller, with focus on the controller core functions (net.floodlightcontroller.core* area of source code). This section is fairly dense, and is best referenced alongside the source code.   

To start, here are some references:  
 * Floodlight wiki: http://www.openflowhub.org/display/floodlightcontroller/Floodlight+Controller+Wiki
 * javadocs: http://floodlight.openflowhub.org/files/javadoc/
You can also generate the docs yourself with `ant javadoc` in your working directory. You may also want to join the [http://groups.google.com/a/openflowhub.org/group/floodlight-dev/subscribe floodlight-dev mailing list].  

=== Overview ===

The controller has two main components:
 1. the core, which listens to !OpenFlow messages and dispatches events, and
 2. various modules which handle the events 
In general, events encompass a range of things, including a switch joining/leaving the network, the reception of a !OpenFlow message e.g. a PACKET_IN, and the controller's role changing. 

=== Listeners, Modules, and registration ===

In general, modules are implementations of several interfaces, including, but not limited to:  

 * `IFloodlightModule` - defines interfaces uniform across modules
 * `IOFSwitchListener` - lets a module be notified of switches joining and leaving
 * `IOFMessageListener` - lets a module be notified of various types of !OpenFlow messages

A module always implements the first interface, but may implement one or both of the latter two as ''listeners''. For example, The REST API module (interested in everything under the sun) implements both, while the Hub module (interested in just PACKET_INs) only implements `IOFMessageListener`.

Class `Controller`, Floodlight's core controller implementation, dispatches events to the modules by calling the modules' event handling functions, namely ''receive()''. The controller keeps mappings of which modules implement which listener in two map structures, ''switchListeners'' and ''messageListeners''. These maps are used by the controller to dispatch the events to the proper listeners. `IFloodLightProviderService`, the interface that `Controller` implements, in turn provides two functions, ''addOFSwitchListener()'' and ''addOFMessageListener()'', which the modules can call in their initialization functions to add themselves to the appropriate map. The controller's listener maps are populated at startup, when the module loader initializes each required module.  

=== Startup ===
The following steps describe the startup process of the Floodlight controller. The reference is the source code in Main.java. 
[[BR]]
[[BR]]
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: [[BR]] 
  * 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()'' (e.g. the modules themselves specify their dependencies).
  * 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. [[BR]]
  * `IRestApiService` provides REST API functions.
  * `IFloodlightProviderService` as mentioned prior, 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 [http://netty.io/ Netty]. The controller's ''run()'' routine does two things:
 1. create a server-side channel on port 6633 
 1. handle updates. 
Updates include switches joining and departing, controller role change, and controller IP change. The definitions are found as inner classes implementing `IUpdate`, within class `Controller`.

==== !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 = #vm
This is a VM image geared towards !VirtualBox containing a running floodlight instance, mininet, and wireshark. [[BR]]
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
}}}