Changes between Version 4 and Version 5 of Internal/OpenFlow/Controllers/MultiCtl/FLInternals
- Timestamp:
- Sep 7, 2012, 7:09:26 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/OpenFlow/Controllers/MultiCtl/FLInternals
v4 v5 7 7 Docs: http://www.openflowhub.org/display/floodlightcontroller/Module+loading+system 8 8 9 Floodlight 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 threemain steps:9 Floodlight 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 four main steps: 10 10 1. Read in configurations 11 11 1. Load modules … … 29 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`). 30 30 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 using the add/remove methods for each type of listener provided by `IFloodlightProviderService` when their ''startUp()'' method is called.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` . 32 32 33 33 For example, taking a look at the `Hub` module: … … 49 49 * the mapping between the service and its class is in terms of the interface that the class implements 50 50 * `Hub` initializes a reference to an implementation of `IFloodlightProviderService` called ''floodlightProvider'' in `init()` 51 * `Hub` is interested in receiving !PacketIns whenever `Controller` receives them from a switch, so it registers itself as a IOFMessageListener in `startUp()`51 * `Hub` is interested in receiving !PacketIns from switches, so it registers itself as a IOFMessageListener in `startUp()` 52 52 53 53 ''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()''. … … 57 57 58 58 == Handling switches == 59 `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. 60 61 Another 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. This only occurs after the switch state is designated ''READY''. 62 63 === The !OpenFlow Handshake === 64 The !OpenFlow handshake can be outlined as below: 65 66 1. Exchange of HELLO messages 67 2. Controller: send FEATURES_REQUEST 68 3. switch: send FEATURES_REPLY 69 4. Controller: send GET_CONFIG_REQUEST 70 5. Switch: send GET_CONFIG_REPLY 71 72 Stage 5 is the point where the switch is deemed ''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.
