Changes between Version 2 and Version 3 of Internal/OpenFlow/FloodlightFVModule
- Timestamp:
- Jun 12, 2012, 5:44:58 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/OpenFlow/FloodlightFVModule
v2 v3 4 4 This is an on-going process - therefore this page will be updated frequently. 5 5 6 == Overview. == 6 == Quick links == 7 [#o Overview] [[BR]] 8 [#s Setup] [[BR]] 9 [#bg Background] [[BR]] 10 [#a Approach] - a diary-style log of the implementation 11 12 == Overview. == #o 7 13 ''Slicing'' is the SDN (in our case referring to !OpenFlow) term for network virtualization. Specifically, A slice is a SDN controller and the network resources allocated to it by a hypervisor-like entity such as !FlowVisor. With proper resource isolation and allocation, multiple controllers can coexist on a single physical network. 8 14 … … 16 22 The key point here is that Floodlight's modular structure allows for multiple different handlers to coexist, with various (groups of) modules imposing different capabilities on the switches. If these modules controlled different groups of switches e.g. had their own bit of resource, each <module:resource> set can be viewed as a slice. Floodlight does not currently have this capability, so the objective of the process described here is to try to realize this feature. 17 23 18 == Setup == 24 == Setup == #s 19 25 Development is done on two VMs, one for Flowvisor and Floodlight source, and the other, Mininet for testing our code. 20 26 … … 46 52 The REST API port is changed from 8080 to prevent conflict with Flowvisor's services. 47 53 48 == Approach == 49 The general flow of operation needed is the following: 50 1. The Acceptor (OFSwitchAcceptor) listens for all OFTypes (!OpenFlow message types) and all switch join/leave events. 54 == Background. == #bg 55 The general flow of operation with respect to Flowvisor (in terms of components) is the following: 56 57 1. The Acceptor (OFSwitchAcceptor) listens for all !OpenFlow message types (OFTypes) and all switch join/leave events. 51 58 2. When a new switch joins, the Acceptor hands the switch's connection to a Classifier (FVClassifier). 52 59 3. The Classifier fetches all slices associated with the switch and launches a Slicer (FVSlicer) per module. … … 55 62 4. Each Slicer sets up event dispatching for the modules associated with a slice. 56 63 57 Event handling would (probably) look like the following. For switch-to-slice: 64 Where the messages go once Flowvisor receives a message are determined by the !FlowMap. the origin of a message can be determined several ways, one being checking the OFType (as some messages are sent by switches but never controllers, and vice versa). 58 65 66 Flowvisor implements all of the needed controller functions, so a good chunk of it is life-support (event handling mechanism, timers, !OpenFlow signaling, etc.). Therefore, we need to be aware of what Floodlight already provides, and what can/needs-to be pulled in from Flowvisor. 67 68 A Floodlight module, in general: 69 * can subscribe to switch join/leave events. They are notified of joins after the switch sends a features reply. 70 * can subscribe to all OFTypes, and once processed, can choose to pass it down the processing chain to other modules or drop it. 71 * the modules themselves cannot control which modules receive the messages if it choses to pass them downstream. 72 73 == Approach (and implementation). == #a 74 (6/12): 75 [[BR]] 76 [[BR]] 77 We generally believe that the following parts will need to be implemented: 78 1. A broker module to register with the core module for all events - the core module can notify this module of !OpenFlow messages and new switches. 79 2. A component that provides the IFloodlightProviderService interface to the rest of the modules. To the rest of the modules, the broker module will appear to be the core controller module. 80 3. Flow-mapping mechanism - it is possible that the components needed for a working !FlowMap can be taken directly from Flowvisor, since it is relatively independent from the rest of the code base (according to Ali). 81 82 Therefore, the module is both a module in Floodlight's usual sense as a subscriber to the controller core, but also a controller that services the rest of the modules. 83 The rough parallels are: 84 * the main broker module's behavior as a listener roughly corresponds to the OFSwitchAcceptor 85 * the new IFloodlightProviderService interface (call it "FVController"?) and receive() functions correspond to the FVSlicers and FVClassifiers 86 * the modules correspond to the multiple controllers 87 88 The FVController interface should be responsible for keeping track of which modules are associated with which slice, and which messages reach what (with help from the !FlowMap). This means that the modules must register with it, as opposed to the core controller defined in Controller.java. 89 90 So, for the meanwhile, the next steps include: 91 * isolating out the !FlowMap code in Flowvisor 92 * mapping out the module registration mechanisms in Floodlight 93 * finding a "nice" way to make the modules register with FVController.
