249 | | Unlike the !FlowMap, a Slice does not seem to be a concrete object, but a collection of information shared amongst the Slicers and Classifiers. We create a new configuration option, "module_name," to replace the controller information stored in a "slice". For now we keep the old parameters for each Slice, but modified: |
| 249 | Unlike the !FlowMap, a Slice does not seem to be a concrete object, but a collection of information the Slicers and Classifiers access using !FlowSpaceUtil. We create a new configuration option, "module_name," to replace the controller information stored in a "slice". For now we keep the old parameters for each Slice, but modified: |
255 | | In any case, we need an easily manipulated mapping of DPIDs to slices, and slices to their modules, where modules are specified by the names returned by getName(). |
| 255 | Another way to do this would be to re-use the existing fields (e.g. "controller_hostname") to hold the module's name, but that might become rather confusing despite keeping the syntax compatible with that of Flowvisor's configuration file. In any case, we need an easily manipulated mapping of DPIDs to slices, and slices to their modules, where modules are specified by the names returned by getName(). |
| 256 | |
| 257 | ==== (7/3) ==== |
| 258 | Since we don't rely on storage (for now), the same class handling the initialization of the Flowvisor components may also provide the functions of FlowSpaceUtil e.g. supply the means for the proxy module to access slice configurations. |
| 259 | |
| 260 | * in FVAcceptor, switch DPIDs may be lifted when the switch joins. |
| 261 | * the origin of the message can be (mostlly) determined by OFP message type (OFType). |
| 262 | |
| 263 | For now, a sane goal is probably to have the proxy identify which slice a message belongs to based on the contents of the configuration file. |
| 264 | |