| | 265 | ==== (7/7) ==== |
| | 266 | To tie back to the proxy module: |
| | 267 | * receive() gets all IO Events. |
| | 268 | * Added/!RemovedSwitch() gets all switch joinleave events. |
| | 269 | The actions that must occur at reception of an IO event include, as per Flowvisor documentations: |
| | 270 | * identification of origin - switch or a slice? |
| | 271 | * if from a switch, which slice(s) it belongs to |
| | 272 | * if from a slice, which switch(es) they apply to |
| | 273 | As of now, we assume that there is one module per slice (forwarding, switch, hub...). |
| | 274 | |
| | 275 | The flow of event handling for messages, compared to the components of Flowvisor, looks like the following in the modified version of Floodlight: |
| | 276 | {{{ |
| | 277 | OFSwitchAcceptor FVClassifier FVSlicer |
| | 278 | _______________/\_______________ ____________________________/\____________________________ |
| | 279 | / \/ \ |
| | 280 | FVAcceptor FVController Modules OFSwitchImpl FVController Modules |
| | 281 | receive() -> handleMesssage() -> receive() -> write() -> handleOutgoingMessage() -> receive() |
| | 282 | }}} |
| | 283 | receive() in the modules may be called twice, but since message handling varies with OFType, this does not loop as one may think. |
| | 284 | We can then use these functions to handle the functionalities of the Slicers and Classifiers in Flowvisor. |