Changes between Version 1 and Version 2 of Internal/OpenFlow/FloodlightFVModule

Timestamp:

Jun 11, 2012, 8:44:39 PM (13 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/FloodlightFVModule

@@ -16 +16 @@
 The key point here is that Floodlight's modular structure allows for multiple different handlers to coexist, with various (groups of) modules imposing different capabilities on the switches. If these modules controlled different groups of switches e.g. had their own bit of resource, each <module:resource> set can be viewed as a slice. Floodlight does not currently have this capability, so the objective of the process described here is to try to realize this feature.
 
-== Approach. ==  
-Development is done on two VMs, one hosting Flowvisor and Floodlight source, and the other, Mininet for testing our code. 
+== Setup == 
+Development is done on two VMs, one for Flowvisor and Floodlight source, and the other, Mininet for testing our code. 
+
+ * '''VM1(10.50.250.2):''' 3-switch, 3-host Mininet topology pointed to external controller in VM2:
+
+ Topology:
+ {{{
+ h4   h5   h6
+  |    |    | 
+ s1---s2---s3 
+ }}}
+ Mininet config:
+ {{{
+ # mn --topo=linear,3 --controller=remote --ip=10.50.250.17 --port=6633
+ }}}   
+ * '''VM2(10.50.250.17):''' Flowvisor on port 6633, with a slice to point two switches to Floodlight instance on 6634
+
+ !FlowVisor configuration:
+ {{{
+# fvctl createSlice fl-1 tcp:localhost:6634 foo@sampledomain.org
+# fvctl addFlowSpace 00:00:00:00:00:00:00:02 1000 any "Slice:fl-1=7"
+# fvctl addFlowSpace 00:00:00:00:00:00:00:01 1000 any "Slice:fl-1=7"
+ }}} 
+ Floodlight config alteration (in src/main/resources/config.properties):
+ {{{
+net.floodlightcontroller.restserver.RestApiServer.port = 8088
+net.floodlightcontroller.core.FloodlightProvider.openflowport = 6634
+ }}}
+ The REST API port is changed from 8080 to prevent conflict with Flowvisor's services.
+ 
+== Approach == 
+The general flow of operation needed is the following:
+ 1. The Acceptor (OFSwitchAcceptor) listens for all OFTypes (!OpenFlow message types) and all switch join/leave events.
+ 2. When a new switch joins, the Acceptor hands the switch's connection to a Classifier (FVClassifier). 
+ 3. The Classifier fetches all slices associated with the switch and launches a Slicer (FVSlicer) per module.
+  * mappings of DPID to slices are found through configurations (the Flowmap)
+  * modules associated with the control module (the primary module defining the behavior of a switch for that slice) may be grouped together in a slice.     
+ 4. Each Slicer sets up event dispatching for the modules associated with a slice. 
+   
+Event handling would (probably) look like the following. For switch-to-slice:
+