Changes between Version 7 and Version 8 of Internal/OpenFlow/Controllers/MultiCtl/FLInternals


Ignore:
Timestamp:
Sep 9, 2012, 8:11:03 PM (12 years ago)
Author:
akoshibe
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • Internal/OpenFlow/Controllers/MultiCtl/FLInternals

    v7 v8  
    11= 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; the contents of this page are side-notes compiled based on some code reading done in 2012.
     2This is a (not-so) quick recap/overview of the internal workings of !OpenFlowHub's Floodlight !OpenFlow controller. There is a good amount of official documentation at openflowhub.org; the contents of this page are side-notes compiled based on some code reading done in 2012.
    33
    44As a convention, classes and interfaces are shown in `terminal type`, and methods and variables in ''italics''. Furthermore, "module" and "service" may be used interchangeably unless otherwise specified. 
    … …  
    2020 1. floodlightdefault.properties: a list of service-providing modules and their configurations
    2121 
    22 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 interdependencies 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 by returning a list of modules that a module depends on. the methods in the module loader that are responsible for building the dependency list are ''loadModulesFromContig()'' and ''loadModulesFromList()''. The procedure produces the smallest collection of modules to be loaded. 
     22The files are read by the module loading system to find and properly load all of the modules. Module interdependencies are found with DFS searches beginning with the service-providing modules 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 by returning a list of modules that a module depends on. the methods in the module loader that are responsible for building the dependency list are ''loadModulesFromContig()'' and ''loadModulesFromList()''. The procedure produces the smallest collection of modules to be loaded. 
    2323
    24 A list of modules that come with the base controller can be found [http://www.openflowhub.org/display/floodlightcontroller/Modules here].
    25 
    26 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 actions dependent on fully active services (e.g. callback registration) after everyone's ''init()'' are called. In addition to the ordering produced by the DFS process, the division of the module startup process into two steps guarantees that modules are able to properly register with necessary services without worrying about which ones are already initialized.         
     24Once 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 actions dependent on fully active services (e.g. callback registration) after everyone's ''init()'' are called. In addition to the ordering produced by the DFS process, the division of the module startup process into two steps guarantees that modules are able to properly register with necessary services without worrying about which ones are already initialized.
     25         
     26A description of the modules that come with the base v0.85 controller can be found [http://www.openflowhub.org/display/floodlightcontroller/Modules here].
    2727
    2828=== 1.2 Module initialization and registration ===
    29 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 (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`).   
     29The 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. The naming gets a bit confusing unless the following are kept in mind:
    3030
    31 The 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 when their ''startUp()'' method is called, using the add/remove methods for each type of listener provided by `IFloodlightProviderService` .
     31 * When people mention `IFloodlightProvider`, they are referring to a collection of methods that are part of this interface
     32 * ''floodlightProvider'' is a variable pointing to an instantiation of `Controller` (or some other implementation of `IFloodlightProviderService`).
     33 * `FloodlightProvider` is the module that provides `Controller` as a service 
     34 
     35When the module loader calls each module's ''startUp()'' method, one thing that happens is the module's registration 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''. The ''startUp()'' method basically causes a module to call one or both of `IFloodlightProviderService`'s ''addOF[Switch|Message]Listener()'' methods to add themselves to these lists.   
    3236
    3337For example, taking a look at the `Hub` module:
    … …  
    5458[[BR]] 
    5559
    56 modules are loaded and initialized, Floodlight will begin listening for incoming connections from switches and sending out LLDP messages to gather topology information.
     60Once modules are loaded and initialized, Floodlight will begin listening for incoming connections from switches and sending out LLDP messages to gather topology information.
    5761
    58 == Handling switches ==
     62== II. Event handling ==
     63`Controller`'s primary duties is the one of event handling and dispatch. 
     64
     65Switches can connect with Floodlight even if all of the modules except !FloodlightProvider are removed from floodlightdefault.properties. This is because `Controller` does just enough event handling to allow switches to associate and stay connected. Of course, without any modules to process !PacketIns, Floodlight cannot provide the switches with flow entries. This section focuses on event handling done by `Controller`, that is, the functions contained within !FloodlightProvider.     
     66
     67=== 2.1 Connections from switches ===
    5968`OFChannelHandler` is the inner class of `Controller` responsible for listening for incoming connections from switches. When a switch establishes a connection, a new instantiation of `OFSwitchImpl` is created for the switch. `OFSwitchImpl` is a representation of an individual switch, comprised of the channel, DPID, and information gleaned from the FEATURE_REPLY, among other bits and pieces. Changes are made to a switch through the manipulation of the `OFSwitchImpl` representing it.   
    6069
    6170Another thing that occurs upon a switch establishing contact (or disappearing) is the dispatch of a switch event. `SwitchUpdate` is the `Controller` inner class responsible for calling a registered `IOFSwitchListener`'s ''addedSwitch()'' or ''removedSwitch()'' methods.     
    6271
    63 === The !OpenFlow Handshake ===
     72=== 2.2 The !OpenFlow Handshake ===
    6473The switch event is not fired until the switch completes the !OpenFlow handshake. The handshake can be outlined as below:
    6574
    … …  
    7281Stage 5 is the point where ''checkSwitchReady()'' is called, the switch state is set to ''READY'', and listeners are notified of its arrival. The components that execute the handshake are implemented in `Controller` as a collection of methods that are called from ''processOFMessage()''. ''processOFMessage()'' is also responsible for keeping up with the ECHO_REQUEST/REPLY keepalive messages.     
    7382
    74 == Handling Messages ==
     83=== 2.3 Message dispatch ===
    7584Once the handshake is complete and interested parties aware of it, messages to/from the switch can be dispatched to registered `IOFMessageListeners`. The high-level view of the message processing chain is the following:
    7685