|Version 3 (modified by 9 years ago) ( diff ),|
Floodlight is a modularized OpenFlow controller, in that its functional components can be split into two major parts, a core event dispatcher and the various event handlers, or modules, that process these events. The key point here is that Floodlight's modular structure allows for:
- Extensibility, in that new functionalities can be added as new modules, and
- Multiple functionalities to coexist as modules on the same controller.
Currently, 2) is only true for modules that depend on one another. Modules that have conflicting functions cannot be loaded together on one running Floodlight instance. For example, the learning switch and forwarding modules will conflict, as they both send a PACKET_OUT to a switch - The switch will respond with a buffer error when it receives the second PACKET_OUT, since it had already sent the packet out.
Without some form of management over control traffic, the same problem will still occur if two (or more) controllers on the same network are running conflicting modules. An entity such as FlowVisor can resolve this situation by intercepting control traffic and ensuring that each controller's messages do not interfere with the others. The re-writing of messages has the effect of controlled network resource allocation that enables multiple controllers to share a single physical network.
This project draws an analog between the individual modules and controllers, and attempts to implement a version of Floodlight applies FlowVisor's resource allocation to its modules.
The main goals of this project are the following:
- Implement a slicing scheme that prevents unwanted interaction between modules
- Allow control of slice behavior through a configuration file
- Avoid modification of existing Floodlight source code
- Provide an easy way to switch between normal Floodlight and "FlowVisor" modes of operation
In addition, the following assumptions were made as a consideration of the amount of time provided by GSoC :
- All modules to be run are loaded at startup, and remain subscribed to events as long as Floodlight is running
- Several modules such as link discovery and device manager need a global view of the network and so should not be restricted
- modules that depend on one another must be in the same slice
- The configurations are not persistent