Flow Cache (API only)

The flowCache has been deprecated in Floodlight v1.0. Future support is possible but will require a redesign to a scalable solution.

The flowCache API is defined with the need of the handling a range of different types of events in the network in mind, while the events to be handled and how to be handled are often decisions of different SDN applications that build on floodlight.   For example, handling flows in the event of switch/link failures is one typical need by most applications.

Floodlight defines a flow cache API and a set of skeleton methods as a common framework for application developers to implement such a solution tailored to their application needs.

We are working on the API writeup for posting on the floodlight website sometime later; in the mean time, succinct explanations of the API calls can be found in the flow cache source.

Switch/Link Down Event Example

For a high level explanation of the purpose of a flow cache, we can follow the switch/link down event's life cycle to walk through various involved modules.

1. Currently when LinkDiscoveryManager detects a link or a port is down, the event is handled by a "NewInstanceWorker" thread in TopologyManager.  Note that at the end of the thread it calls informListeners, which is the hook left to inform this event to any other modules that are interested in handling this event.
2. So, you would start with implementing a module that implements ITopologyListener interface with a topologyChanged() method, and add the module to the list of listeners by calling TopologyManager.addListener.
3. In your module, you can retrieve all the earlier discovered topology changes via Topology.getLastLinkUpdates(), and by sorting through the events to look for the event of interest.  A failed switch results in link down in adjacent switches, so you should be looking for ILinkDiscoery.UpdateOperation.LINK_REMOVED events (one event per affected switch).  The found entry will tell you the involved switch ports.
4. The next step is to query each affected switch all the flows they carry now that match the affected port.  The query should be an OFStatisticsRequest message, which will be sent to the switch sw by sw.sendStatsQuery().  
5. Once the query is sent out, you will expect later to receive the response.  In order to receive the response which is an OF packet, your module will also implement IOFMessageListener interface and expect OFType.STATS_REPLY messages.  Once you get the reply, you will see all the flows in it. Now you can decide if you want to create delete flowmods to cleanup the flows.

OK. This seems to have solved the problem. But we have not used a flow cache and its associated service interfaces yet.  

The concept of a flow cache is for the controller to keep a record of all active flows, and when events are observed by different modules of a controller or by querying the switches from time to time, the flow cache records are updated.  This consolidates in one place the updates and retrieval of flow records by different modules. 

The Flow Cache data structure is left for the implementor's decision, while the query and response (against the flow cache) format is shown in the API. Each query can also designate its handler.

The flow reconcile classes are for "cleaning up" the flows in the cache as well as in the switches. You can have multiple modules handling different events, each will implement the IFlowReconcileListener interface and a reconcileFlows method.  The method can either result in some immediate actions, or you can pass the decision to another module via an OFMatchReconcile object. There are also interfaces defined for keeping track of pending queries.