Changes between Version 34 and Version 35 of Internal/OpenFlow/FloodlightFVModule

Timestamp:

Jul 30, 2012, 4:16:36 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/FloodlightFVModule

@@ -370 +370 @@
  * Each slicer in Floodlight would is a dispatch queue containing user-chosen services. 
 
- * Keep-alives and handshakes can be tracked by Controller (possibly). This gives us two main choices of architecture:
-   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.   
-   2. A relatively fully-featured IFloodlightProvider decides which messages go to which group of slicers, based on incoming DPID.   
-  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. 
+ * Keep-alives and handshakes can be tracked by Controller (possibly). 
+
+This gives us two main choices of architecture:
+
+ 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 and messaging to manage.   
+
+ 2. A relatively fully-featured IFloodlightProvider decides which messages go to which group of slicers, based on incoming DPID. The classifiers are just abstractions within the IFloodlightProvider. 
+
+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.