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

Timestamp:

Aug 11, 2012, 7:54:49 AM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/FloodlightFVModule

@@ -394 +394 @@
 Wiring in the Classifier and Slicer components involve modification of how events will be dispatched to the modules.    
 
-
+==== (8/9) ====
+Bullet points for record keeping. [[BR]]
+The packet processing chain has taken the following form:
+ 
+ * FlowVisor::FVChannelHandler.handleMessage()
+ * FlowVisor::FVChannelHandler.classifyOFMessage()
+ * FlowVisor.handleMessage()  
+ * FVClassifier.classifyFromSwitch()
+ * FVSlicer.sendMsg() - sets writing Slicer to itself  
+Within a Module
+ * IFloodlightModule.receive()
+ * FVClassifier.write()
+
+ * FVSlicer.write()
+ * FVSlicer.sliceFromController()
+ * FVClassifier.sendMsg()
+ * FVClassifier.write() - to Netty channel
+
+Where FlowVisor is derived from Controller, and FVClassifier from IOFSwitchImpl.   
+
+==== (8/10) ====
+The dispatch of modules from slices is a fairly complicated task, since Floodlight "just" produces a list of modules to run based on OFType, while we need to dispatch not only based on original concerns such as the way Floodlight produces the list of modules, but also on slice rules. Not only this, a slice cannot simply call its module and be done with it; modules might be dependent on others, e.g. must get results from other modules in order to work. An example of this case is the topology module, which needs the information collected by the link discovery module. 
+ 
+ * The full list of services that floodlight uses to quickly find the modules to run is also organized by OFType.
+ * The slices cannot directly get access to this list.
+ * even if we want to pass the list to the slices, we don't know which slice to hand it to before a classifier does its job. 
+ 
+/something/ needs to be done before the soft deadline of (8/13). 
 ===== --- =====
 [#top home] [[BR]]