Reference Guide

Table Of Contents
The flow class is assigned a unique “base cookie” (top 16 bits of the 64 bit field) which must be
“OR”ed with any cookie value that you wish to include in the flow (bottom 48 bits of the 64 bit
field).
The flow class “priority” is a private, logical key to be stored in the FlowMod “priority” field. It is
used by the controller to look up the pre-registered flow class record, so that the match fields and
actions of the FlowMod can be validated against the list of intended matches/actions.
When your application gets uninstalled, be sure to unregister any flow classes you created:
private void cleanup() {
controller.unregisterFlowClass(l2Class, PASSWORD);
}
Flow Contributors
When a datapath first connects to the controller, an initial handshaking sequence is employed.
In brief...
1. Datapath connects
2. OpenFlow handshake (Hello/Hello, FeaturesRequest/Reply)
3. Extended handshake (MP-Request: Description, Ports, TableFeatures)
4. Device type determined
5. “Delete ALL Flows” command sent to datapath
6. Core “initial flows” generated
7. Contributed “initial flows” collated
8. Flows validated (via pre-registered flow classes)
9. Flows adjusted (via device driver subsystem)
10. Flows (and barrier request) sent to datapath
11. DATAPATH_READY event emitted
A component may implement InitialFlowContributor and register itself with the controller service.
During step (7) above, the provideInitialFlows(...) callback method will be invoked on every
registered contributor, requesting any flows to be included in the set of initial flows to be laid down
on the newly-connected datapath.
A possible implementation might look like this:
@Override
public List<OfmFlowMod> provideInitialFlows(DataPathInfo info,
boolean isHybrid) {
List<OfmFlowMod> result = new ArrayList<>(1);
if (isHybrid)
result.add(buildFlowMod(info));
return result;
}
45