Changes between Initial Version and Version 1 of Internal/OpenFlow/FloodlightFVPort

Timestamp:

Aug 19, 2012, 7:36:09 AM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/FloodlightFVPort

@@ +1 @@
+= Enabling !FlowVisor-like Slicing in Floodlight = 
+
+This GSoC 2012 project aims to incorporate !FlowVisor's network resource slicing features into Floodlight. 
+
+== Motivation and Overview ==
+
+Floodlight is a modularized !OpenFlow controller, in that its functional components can be split into two major parts, a core event dispatcher and the various event handlers, or modules, that process these events. The key point here is that Floodlight's modular structure allows for:
+
+ 1. Extensibility, in that new functionalities can be added as new modules, and 
+ 2. Multiple functionalities to coexist as modules on the same controller. 
+
+Currently, 2) is only partially true, as modules that have conflicting functions may not coexist on a running Floodlight instance. As an example, the learning switch and forwarding modules will conflict, as they both send a PACKET_OUT to a switch - The switch will respond with a buffer error when it receives the second PACKET_OUT, as it had already sent the packet out.   
+
+In the case that the conflicting modules are running on separate instances of Floodlight on the same network, this situation can be averted by network slicing. A slice can be thought of as an !OpenFlow controller and the network resources allocated to it by a hypervisor-like entity such as !FlowVisor. With proper resource allocation, which guarantees isolation, multiple controllers can coexist on the network without interfering with each other.
+
+This project draws an analog between the individual modules and controllers, and attempts to implement an isolation scheme within Floodlight to isolate conflicting modules, allowing them to run properly on the same controller. 
+
+=== Design Goals ===
+
+The goals of this project can be summarized as follows:
+
+ * Implement a slicing scheme that prevents unwanted interaction between modules 
+ * Allow control of slice behavior through a configuration file
+ * Avoid modification of existing Floodlight source code
+ * Provide an easy way to switch between normal Floodlight and "!FlowVisor" modes of operation
+ 
+=== Assumptions ===
+
+The following assumptions are made as a consideration of the amount of time provided by GSoC :  
+
+ * All modules to be run are loaded at startup, and remain subscribed to events as long as Floodlight is running
+ * Several modules such as link discovery and device manager need a global view of the network and so should not be restricted
+ * Each slice can isolate one module
+ * The configurations are not persistent 
+
+== Usage ==
+
+As of now this project is extremely rough around the edges. 
+
+==== Installation ====
+
+The source code can be fetched using git and built with `ant`:
+{{{
+git clone git://github.com/akoshibe/floodlight.git
+cd floodlight/
+git checkout -b flowvisor origin/flowvisor
+ant;
+}}}
+
+As with the regular Floodlight, `ant eclipse` allows it to work with eclipse and `ant javadoc` will produce javadocs for the code. 
+
+==== running in !FlowVisor mode ====
+
+To run:
+{{{
+java -jar target/floodlight.jar -cf src/main/resources/flowvisor.properties
+}}}
+
+This brings the controller up in "!FlowVisor mode," with two default slices containing the !LearningSwitch and Forwarding modules. The slice configurations are in config.json, found with the .properties file in [floodlight working directory]/src/main/resources/.  
+
+==== running as a regular controller ====
+
+Alternatively, since none of the original code base was modified, this version of Floodlight can be run as a normal v0.85 controller by replacing 
+{{{
+net.floodlightcontroller.core.FVProxyProvider
+}}}
+with
+{{{
+net.floodlightcontroller.core.FloodlightProvider
+}}}
+in `src/main/resources/META-INF/services/net.floodlight.core.module.IFloodlightModule` and launching it without the -cf option. 
+
+==== creating a custom configuration file ====
+As of now, !FlowVisor is required to create custom configuration files. This takes four steps:
+
+ 1. configure the desired policies using `dpctl` against a running !FlowVisor   
+ 1. dump the configurations to file using `dpctl dumpConfig <filename>`
+ 1. edit the configuration file: add each module to be isolated to a slice, with "modules" as the key and the fully qualified name of the module as the value. The value "none" may be used for a slice not associated with any modules. For example, the following isolates the Forwarding module in a slice named "fl-1":
+{{{
+   ...
+   
+   "Slice": [
+   ...      
+      {
+         "config_name": "default",
+         "flowmap_type": "federated",
+         "name": "fl-1",
+         "creator": "fvadmin",
+         "passwd_crypt": "a3b88aa4453124c025c39938fb89d3cb",
+         "passwd_salt": "-1847302276",
+         "controller_hostname": "localhost",
+         "controller_port": 6634,
+         "modules": "net.floodlightcontroller.forwarding.Forwarding",
+         "contact_email": "foo@sampledomain.org",
+         "drop_policy": "exact",
+         "lldp_spam": true
+      },
+   ...
+}}}
+ 4. edit flowvisor.properties to point FVProxyProvider to the new configuration file. The path should be relative to the Floodlight working directory: 
+{{{
+net.floodlightcontroller.core.FVProxyProvider.configfile = /src/main/resources/config.json
+}}}
+
+Unless already there, the modules added to the config file should also be added to flowvisor.properties.
+
+
+
+== Internal Links ==
+ 
+
+== External Links ==
+ * http://floodlight.openflowhub.org/ Floodlight Home Page
+ * https://openflow.stanford.edu/display/DOCS/Flowvisor !FlowVisor Wiki