| 351 | | == . ==#end |
| | 352 | |
| | 353 | ==== (7/30) [Comparisons] ==== #cmp |
| | 354 | It seems to be a good time to step back and look at the forest, as things were getting stalled due to confusion. |
| | 355 | |
| | 356 | * Flowvisor keeps track of switches based on incoming TCP source port. This is a pretty obvious but important point^1^, which allows Flowvisor to differentiate message sources and have them go to the right classifier/slicer early on, even before having to check the !OpenFlow information (e.g. DPID). |
| | 357 | |
| | 358 | * Floodlight's channel handler (OFChannelHandler), a subclass of Controller, accepts all incoming connections, much like Flowvisor's OFSwitchAcceptor. |
| | 359 | |
| | 360 | * Controller also handles (as its name suggests) many controller-related functions, such as taking care of the initial handshake and keep-alives (ECHO_REQUEST/REPLY). In Flowvisor, each FVClassifier and Slicer handle both of these tasks individually, with the former doing so for switches, and the latter, for each controller. |
| | 361 | |
| | 362 | * Flowvisor does not allow the virtualization of controllers e.g. allow two slices to associate with the same controller (See !DuplicateControllerException, thrown by !SliceImpl when creating slices). |
| | 363 | |
| | 364 | Gathering these points together, we can try to come up with processing scheme that should be used. |
| | 365 | |
| | 366 | * As connections come into OFChannelHandler, a "classifier" can be spawned to track each incoming TCP connection. |
| | 367 | |
| | 368 | * a check can be done at the slice creation stage (when configurations are being read) to avoid slices associating with the same modules. |
| | 369 | |
| | 370 | * Each slicer in Floodlight would is a dispatch queue containing user-chosen services. |
| | 371 | |
| | 372 | * Keep-alives and handshakes can be tracked by Controller (possibly). This gives us two main choices of architecture: |
| | 373 | 1. A bare-bones IFloodlightProvider (almost just OFCHannelHandler) catches incoming connections, and passes it on to instances of more fully implemented IFloodlightProviders (Classifiers). Each have their own group of slicers to manage. |
| | 374 | 2. A relatively fully-featured IFloodlightProvider decides which messages go to which group of slicers, based on incoming DPID. |
| | 375 | The first case allows each IFloodlightProvider to be simpler in slice management, but guarantees that if n switches are present, n IFloodlightProviders are needed, which may get messy. The second case guarantees a complicated IFloodlightProvider, but probably less overall modifications. Both probably suffer scalability issues if done carelessly: for 1 this is the number of IFloodlightProviders and for 2 the large hashMap of DPID to slicers. |
| | 376 | |
| | 377 | |
| | 378 | |
| | 379 | |
| | 380 | ===== --- ===== |
| | 381 | [#top home] [[BR]] |
| | 382 | ===== --- =====#end |
| | 383 | ^1. It wasn't for me until I realized it.^ |
