Changes between Version 1 and Version 2 of Internal/OpenFlow/Controllers/MultiCtl/FLInternals


Ignore:
Timestamp:
Sep 7, 2012, 7:05:16 AM (12 years ago)
Author:
akoshibe
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • Internal/OpenFlow/Controllers/MultiCtl/FLInternals

    v1 v2  
    1 = Floodlight Controller Internals. =
    2 This is a quick recap/overview of the internal workings of !OpenFlowHub's Floodlight !OpenFlow controller. There is a good amount of official documentation at openflowhub.org; these are just side-notes written down based on some code reading done in 2012, and may contain errors.     
     1= Floodlight Controller Internals =
     2This is a quick recap/overview of the internal workings of !OpenFlowHub's Floodlight !OpenFlow controller. There is a good amount of official documentation at openflowhub.org; these are side-notes compiled based on some code reading done in 2012, and are not only pretty dense but also may contain errors.     
    33
    4 As a convention, classes and interfaces are shown in `terminal type`, and the methods in ''italics''.
     4As a convention, classes and interfaces are shown in `terminal type`, and methods and variables in ''italics''.
    55
    66== Loading and Initialization ==
    77Refs: http://www.openflowhub.org/display/floodlightcontroller/Module+loading+system
     8
     9Floodlight can be broken down into two main components: A module loader and all of the modules that implement Floodlight's services and functions. Initialization is therefore characterized by three main steps:
     10 1. Read in configurations
     11 1. Load modules
     12 1. Initialize core controller module/service
     13 1. Register modules with controller service 
    814
    915=== Loading ===
    … …  
    1420 1. floodlightdefault.properties: a list of service-providing modules and their configurations
    1521 
    16 The files are read by the module loading system to find and properly load all of the modules. Module interdependencies are found with a DFS search for dependencies of each module beginning with the service-providing ones listed in the second file. A module is anything that implements the `IFloodlightModule` interface, and this interface provides a method, ''getModuleDependencies()'', which facilitates the building of this dependency tree. the methods in the module loader that are responsible for this task are ''loadModulesFromContig()'' and ''loadModulesFromList()''. The procedure produces the smallest collection of modules to be loaded. Once the list is complete each module is activated by calling its ''startUp()'' method.   
     22The files are read by the module loading system to find and properly load all of the modules. Module interdependencies are found with a DFS search for dependencies of each module beginning with the service-providing ones listed in the second file. A module is anything that implements the `IFloodlightModule` interface, and this interface provides a method, ''getModuleDependencies()'', which facilitates the building of this dependency tree. the methods in the module loader that are responsible for this task are ''loadModulesFromContig()'' and ''loadModulesFromList()''. The procedure produces the smallest collection of modules to be loaded. Once the list is complete each module is activated by calling its ''init()'' and ''startUp()'' methods. ''init()'' typically initializes references to services that a module depends on, and other things that do not count on a module's dependencies being fully active; ''startUp()'' takes care of them after everyone's ''init()'' are called.     
    1723
    18 === Initialization ===
    19 The first module to always be activated (by the virtue of being first in floodlightdefault.properties) is the `FloodlightProvider`, which provides the key service that implements Floodlight's controller functions. The actual implementation at the heart of the controller service is the class `Controller`, implementing the `IFloodlightProviderService` interface. When people mention `IFloodlightProvider`, they are referring to a collection of methods that are part of this interface.   
     24=== Initialization and module registration ===
     25The first module to always be activated (by the virtue of being first in floodlightdefault.properties) is the `FloodlightProvider`, which provides the key service that implements Floodlight's controller functions (managing connections from switches, keepalives, event dispatch, etc). The actual implementation at the heart of the controller service is the class `Controller`, implementing the `IFloodlightProviderService` interface. When people mention `IFloodlightProvider`, they are referring to a collection of methods that are part of this interface, and when ''floodlightProvider'' is referenced it is usually an instantiation of `Controller` (or some other implementation of `IFloodlightProviderService`).    
    2026
    21 The module loader calls each module's ''startUp()'' method to register them with the controller service, typically either as an `IOFMessageListener` or an `IOFSwitchListener`.   
     27The module loader calls each module's ''startUp()'' method to register them with `Controller`, typically either as an `IOFMessageListener` or an `IOFSwitchListener`. The identification depends on what kind of event a service is interested in receiving from `Controller`. Services interested in new messages are the former, and those interested in the joining/leaving of switches are the latter. Services may belong to both categories. In `Controller`, the two groups are organized into two lists, ''messageListeners'' and ''switchListeners''. Each method essentially "adds itself" to either or both of these lists using the add/remove methods for each type of listener provided by `IFloodlightProviderService` when their ''startUp()'' method is called.
     28
     29For example, taking a look at the `Hub` module:
     30
     31 {{{
     32    public void init(FloodlightModuleContext context)                             
     33            throws FloodlightModuleException {
     34        floodlightProvider =                                                         
     35                context.getServiceImpl(IFloodlightProviderService.class);
     36    }
     37
     38    public void startUp(FloodlightModuleContext context) {
     39        floodlightProvider.addOFMessageListener(OFType.PACKET_IN, this);           
     40    }
     41 }}}   
     42
     43Several things should be mentioned here:
     44 * `FloodlightModuleContext` maintains a !HashMap called ''serviceMap'' that keeps a mapping between a service and its implementing class
     45 * the mapping between the service and its class is in terms of the interface that the class implements
     46 * `Hub` initializes a reference to an implementation of `IFloodlightProviderService` called ''floodlightProvider'' in `init()`
     47 * `Hub` is interested in receiving !PacketIns whenever `Controller` receives them from a switch, so it registers itself as a IOFMessageListener in `startUp()` 
     48
     49''startUp()'' is also where service-specific variables in floodlightdefault.properties will be used to do per-module configurations. A module accesses the contents of the file through `FloodlightModuleContext` via the method ''getConfigParams()''.