Changes between Version 1 and Version 2 of Internal/OpenFlow/FloodlightFVPort/Architecture
- Timestamp:
- Aug 20, 2012, 2:09:56 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/OpenFlow/FloodlightFVPort/Architecture
v1 v2 3 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. 4 4 5 == Goals == 5 === Internal links === 6 [#goals Goals][[BR]] 7 [#comp Components][[BR]] 8 [#i Containers][[BR]] 9 [#ii FVProxyProvider][[BR]] 10 [#iii FlowVisor service][[BR]] 11 [#iv Message Handlers][[BR]] 12 13 == Goals == #goals 6 14 7 15 The main goals of this project's designs are the following: … … 19 27 * The configurations are not persistent 20 28 21 = Components =29 == Components == #comp 22 30 23 31 The main components are: … … 36 44 * the FVSlicer, which handles messages to/from modules 37 45 38 == Containers ==46 === Containers === #i 39 47 40 48 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: … … 43 51 * FVConfUtil : !FlowSpace contents, !FlowMap 44 52 45 == FVProxyProvider ==53 === FVProxyProvider === #ii 46 54 47 55 This module is analogous to the [http://www.openflowhub.org/display/floodlightcontroller/FloodlightProvider FloodlightProvider], and provides similar main functionalities of handling switch connections, turning messages into events that modules can subscribe to, and dealing with the details of dispatching messages to the modules. In addition to these functions, FVProxyProvider also reads in the !FlowVisor configurations from file, and initializes the container structures necessary for the message handlers to determine how messages should be processed. … … 51 59 '''Dependencies''' 52 60 53 * FVConfUtil : reading !FlowVisor configs, initialization/access ofcontainer structures61 * FVConfUtil : reading !FlowVisor configs, initialization/access to container structures 54 62 * !FlowVisor : connection and event handling/dispatch 55 63 * config.json : !FlowVisor slice policies, flow rules … … 57 65 '''Initializes :''' The !FlowVisor service 58 66 59 == !FlowVisor service ==67 === !FlowVisor service === #iii 60 68 61 69 !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. … … 68 76 * FVSlicer : per-message slice policy information 69 77 70 '''Initializes :''' FVClassifier 78 '''Initializes :''' FVClassifier (per switch connection) 71 79 72 80 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. 73 81 74 == Message handlers ==82 === Message handlers === #iv 75 83 76 The message handlers prevent conflicting messages from being sent out to the switches by modifying !OpenFlow messages and controlling how the !FlowVisor service dispatches messages to the modules. The classes and logic responsible for processing the messages are taken from !FlowVisor and are found in org.flowvisor.message* . The !FlowMap interface used by the message processing class is a modified version of !FlowVisor's linear !FlowMap, and is located in net.floodlightcontroller.flowspace.84 The message handlers prevent conflicting messages from being sent out to the switches by modifying !OpenFlow messages and controlling how the !FlowVisor service dispatches messages to the modules. The classes and logic responsible for processing the messages are taken from !FlowVisor, hence there are many analogues between this implementation and !FlowVisor's message processing chain. 77 85 78 ==== FVClassifier ==== 86 Two major packages are largely borrowed from !FlowVisor: 87 88 * org.flowvisor.message* : Implementations of class and action specific message processing for OFMessages 89 * net.floodlightcontroller.flowspace* : !FlowMap and !FlowSpace manipulation 90 91 === FVClassifier === 79 92 80 93 FVClassifier is derived from Floodlight's OFSwitchImpl class. A FVClassifier instance is associated with one switch, and is responsible for initializing one FVSlicer per slice that the switch is part of, processing messages to/from the switch according to policies in the !FlowMap, and sending out messages for the modules and the !FlowVisor service. … … 88 101 * FVMessageConverter : translation of messages between OFMessage and !FlowVisor equivalents in org.flowvisor.message* 89 102 90 '''Initializes :''' FVSlicer 103 '''Initializes :''' FVSlicer (per slice) 91 104 92 === = FVSlicer ====105 === FVSlicer === 93 106 94 107 Each FVSlicer enforces slice policies for one slice onto messages to/from the modules. The two main functions of FVSlicer are the processing of outbound messages and providing the !FlowVisor service with the slice policy that is used to restrict the list of modules that a given message can be dispatched to. The current implementation supplies a list of 'blacklisted' modules that should be ignored during message dispatch. … … 101 114 * FVMessageConverter : translation of messages between OFMessage and !FlowVisor equivalents in org.flowvisor.message* 102 115 103
