Changes between Version 7 and Version 8 of Internal/OpenFlow/FloodlightFVPort/Architecture
- Timestamp:
- Aug 20, 2012, 5:28:12 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/OpenFlow/FloodlightFVPort/Architecture
v7 v8 1 1 = Architecture = 2 2 3 Much of the architecture draws heavily from !FlowVisor, but does so in a way to fit back into Floodlight's modular model. Many components are named after the components that they are analogous to in !FlowVisor.3 The design of this project draws heavily from !FlowVisor, but does so in a way to fit back into Floodlight's modular model. Many components are named after the !FlowVisor components on which their functions are based. 4 4 5 5 === Internal links === … … 22 22 * Configuration files - one for !FlowVisor policies and another for module configurations 23 23 24 * A module providing the core event handler (FVProxyProvider)24 * FVProxyProvider - A module providing the core event handler 25 25 26 * The main event handler (the !FlowVisor service)26 * The !FlowVisor service - The main event handler 27 27 28 28 * Message handler components: … … 43 43 === Containers === #i 44 44 45 The JSON-formatted configuration file used by this implementation is nearly identical to that used by !FlowVisor, save the "modules" field specifying which modules should be kept in what slice. While !FlowVisor would store the contents of the config file in a database, this project assumes that there is no persistent storage. Instead of a database, a few classes are used to keep this information available: 45 The JSON-formatted configuration file used by this implementation is nearly identical to the one used by !FlowVisor. The Floodlight version of this file has a "modules" field specifying which modules should be kept in what slice. By default, Floodlight will search for a file named 'config.json' in src/main/resources/ . 46 47 Although !FlowVisor would store the contents of the config file in a database at startup, this project assumes that there is no persistent storage. Instead of a database, a few classes are used to keep this information available: 46 48 47 49 * Slice : configurations of individual slices … … 64 66 65 67 ---- 66 === !FlowVisor service === #iii68 === The !FlowVisor service === #iii 67 69 68 !FlowVisor is derived from Floodlight's Controller class, the main implementation of the service that handles connections and events. The !FlowVisor service initializes switch-side message handlers (FVClassifiers) for each switch connection, and dispatches messages as events to subscribing modules according to message type (as Controller does)and slice policy.70 The !FlowVisor service is derived from Floodlight's Controller class, the main implementation of the service that handles connections and events. The !FlowVisor service initializes switch-side message handlers (FVClassifiers) for each switch connection, and dispatches messages as events to subscribing modules according to message type and slice policy. 69 71 70 72 '''Implementation :''' net.floodlightcontroller.core.internal.!FlowVisor.java … … 77 79 '''Initializes :''' FVClassifier (per switch connection) 78 80 79 Because of their same logical purpose the !FlowVisor/FVProxyProvider pair are interchangeable with the Controller/!FloodlightProvider pair, allowing this version of Floodlight to be easily switched between "!FlowVisor" and "normal" modes of operation through the module loading system's configuration file.81 Because of their same logical roles, the !FlowVisor/FVProxyProvider pair are interchangeable with the Controller/!FloodlightProvider pair, allowing this version of Floodlight to be easily switched between "!FlowVisor" and "normal" modes of operation through the [http://www.openflowhub.org/display/floodlightcontroller/Module+loading+system module loading system]'s configuration file. 80 82 81 83 ----
