The OpenFlow classes display shows the OpenFlow classes that applications have registered with the controller. For more information about OpenFlow classes, see “About OpenFlow classes”.
When multiple applications share the same resource—the flow tables of OpenFlow switches—how can their priorities relative to each other be determined and how can their actions be coordinated? If flow table modification priorities are directly coded into each application, applications can end up directly competing with other applications for the highest priorities, which can result in conflicts in general network traffic control and unintended results when you implement a solution that has multiple SDN applications attempting to act on the same packets. In addition, many environments make it difficult to trace the origin of flow modification requests installed in switches.
The HP VAN SDN Controller uses OpenFlow classes to dynamically manage the priorities of the OpenFlow rules being deployed to the network, thus enabling applications to execute their business logic in a more orderly fashion.
For each class of flow modification message the application can send, the application must register an OpenFlow class with the controller. The OpenFlow class must specify the types of match fields, types of actions, and (optionally) the relative position (higher than or lower than) for this class with respect to other flow classes.
The controller adds a unique base cookie to be used with each future flow modification to be validated against this OpenFlow class, and assigns an actual priority for the OpenFlow class. This actual priority is based on the logical priorities of all of the OpenFlow classes of all the applications that are registered with the controller.
When the application sends a flow modification message, it must set the match and action to be the same fields as specified in the OpenFlow class and, instead of providing an actual priority, the application sets the logical priority as assigned by the flow class, and a cookie that is derived from the base cookie of the OpenFlow class.
Before sending the flow table modification message to the switch, the controller evaluates the requested flow modification against the registered OpenFlow classes and replaces the logical priority provided by the application with an actual priority.
In addition to enabling the controller to manage priorities for multiple applications, OpenFlow classes enable the controller to validate flow modifications an application makes against a set of expected flow modification requests. This capability means that the behavior of an application must match the intent that the application disclosed when it registered with the controller:
The controller does not manage flow modification priorities or validate flow modification requests:
(Default) The controller manages flow modification priorities and validates flow modification requests for applications that register OpenFlow classes:
The controller manages all flow modification priorities and validates all flow modification requests:
Refreshes the list.
|Flow Class ID|
The symbolic name for the flow class. The prefix identifies the application that registered the class; the suffix uniquely identifies the class.
The actual priority the controller assigns to flows of this class.
The base value of the cookie assigned to this OpenFlow class. The application that registered this class must use this base cookie when constructing flows that belong to this class.
The types of match fields that are expected to be specified in flows that belong to this class.
The general category of the action or instruction a flow that belongs to this class is expected to include. For a list of categories, see “About OpenFlow classes”.
Short description of what the OpenFlow class does. The application describes the OpenFlow class when it registers the class with the controller.
To change the enforcement level the controller applies to applications sending flows to switches, change the value for the
flow.mod.enforcement key of the
com.hp.sdn.ctl.of.impl.ControllerManager configuration component.
For more information about configuration components, see “Configurations screen”.
For information about the enforcement levels the controller can apply, see “Controller enforcement levels for OpenFlow classes”.