Architecture

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.

Goals

The main goals of this project's designs are the following:

• 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

In addition, the following assumptions were 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
• modules that depend on one another must be in the same slice
• The configurations are not persistent

Components

The main components are:

• Containers for configurations:
  • Slices
  • The FlowMap
  • Configuration files - one for FlowVisor policies and another for module configurations

• A module providing the core event handler (FVProxyProvider)

• The main event handler (the FlowVisor service)

• Message handler components:
  • the FVClassifier, which handles messages to/from switches
  • the FVSlicer, which handles messages to/from modules

Containers

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:

• Slice : configurations of individual slices
• FVConfUtil : FlowSpace contents, FlowMap

FVProxyProvider

This module is analogous to the ​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.

Implementation : net.floodlightcontroller.core.FVProxyProvider.java

Dependencies

• FVConfUtil : reading FlowVisor configs, initialization/access of container structures
• FlowVisor : connection and event handling/dispatch
• config.json : FlowVisor slice policies, flow rules

Initializes : The FlowVisor service

FlowVisor service

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.

Implementation : net.floodlightcontroller.core.internal.FlowVisor.java

Dependencies

• Controller : base class
• FVSlicer : per-message slice policy information

Initializes : FVClassifier

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.

Message handlers

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.

FVClassifier

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.

Implementation : org.flowvisor.classifier.FVClassifier.java

Dependencies

• OFSwitchImpl : base class
• org.flowvisor.message* : Extended versions of OFMessage classes with interfaces for message processing
• FVMessageConverter : translation of messages between OFMessage and FlowVisor equivalents in org.flowvisor.message*

Initializes : FVSlicer

FVSlicer

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.

Implementation : org.flowvisor.slicer.FVSlicer.java

Dependencies

• Slice : slice configuration information
• org.flowvisor.message* : Extended versions of OFMessage classes with interfaces for message processing
• FVMessageConverter : translation of messages between OFMessage and FlowVisor equivalents in org.flowvisor.message*