Changes between Version 39 and Version 40 of Internal/OpenFlow/FloodlightFVModule

Timestamp:

Aug 16, 2012, 3:27:37 AM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/FloodlightFVModule

@@ -2 +2 @@
 This page documents the (attempted) process of developing a version of Floodlight with !FlowVisor-like slicing capabilities. 
 
-This is an on-going process - therefore this page will be updated frequently. 
+This is an on-going process - therefore this page will be updated frequently. At the end of the day it will be compiled into a neater document. 
 
 == Quick links ==
@@ -400 +400 @@
  * FlowVisor::FVChannelHandler.handleMessage()
  * FlowVisor::FVChannelHandler.classifyOFMessage()
- * FlowVisor.handleMessage()  
+ * !FlowVisor.handleMessage()  
  * FVClassifier.classifyFromSwitch()
  * FVSlicer.sendMsg() - sets writing Slicer to itself  
@@ -412 +412 @@
  * FVClassifier.write() - to Netty channel
 
-Where FlowVisor is derived from Controller, and FVClassifier from IOFSwitchImpl.   
+Where !FlowVisor is derived from Controller, and FVClassifier from IOFSwitchImpl.   
 
 ==== (8/10) ====
@@ -422 +422 @@
  
 /something/ needs to be done before the soft deadline of (8/13). 
+
+==== (8/15) ====
+An initial, very primitive implementation:
+
+'''The packet process chain:''' 
+ * two separate packet write paths - one for messages that never hit the modules, and the other, the one that gets processed. The former includes handshake messages and importantly, keepalives. Passing the keepalives (ECHO_REQUEST/REPLY messages) through the full process chain causes switches to disconnect periodically, probably due to them being dropped. 
+ 
+ * the separate write paths are achieved by "splitting" the FVClassifier (OFSwitchImpl) write() into two parts, one that implements the original write(), and another, which intercepts outgoing messages and either sends them back to a slice (to be handled by sliceFromController(), if it had come from a slice), or passes them to the first write to be sent out immediately.  
+ 
+ * a FVClassifier-local "writer" slice variable keeps track of which slice had sent a message to the particular classifier. The sending FVSlicer sets the 'writer' to itself before dispatching its modules.
+    
+'''Controlling access of slices to modules:''' 
+ * Each module has access to one specific module, as per its configurations. This is the module that it is always allowed to run. If the module depends on, or upon, another module, that module must also belong to the same slice, to honor the dependency tree, lest things break. 
+
+ * Each slice has a deny list associated with it. The deny list of a slice contains all of the other modules associated to other slices in the configs. 
+
+ * when handleMessage() is run, a dependency-ordered list of modules interested in that particular incoming message type is fetched by !FlowVisor (Controller). The modules in the deny list are skipped when time comes to dispatch the modules in order.   
+
+'''Issues''' - There are many. The biggest above is probably the way the writer is chosen, which can totally be destroyed by one slice setting it, then another coming along and setting it to something else mid-processing. The way the deny list is built and used also seems kludgy. 
+ 
 ===== --- =====
 [#top home] [[BR]]