Deployment Guide

33
4.4.1 DNOS-OF flow tables
DNOS-OF flow tables accommodate specific types of flow entries with associated semantic rules,
including constraints such as which match fields are available, which instructions and actions are
supported, how priorities can be assigned to flow entries, which next table(s) flow entries can go to, and
so forth. The flow tables conform to the OpenFlow 1.3.4 specification. In addition to normal flows, two
types of special flow entries are supported as follows:
- Built-in: Built-in flow entries come preinstalled in specific tables. They are visible to the controller but
cannot be modified or deleted. Built-in entries have preassigned match fields, priority, and cookie values.
They are typically used for default entries.
- Automatic: Automatic flow entries are added by the switch as a side effect of the controller adding a flow
entry. They are visible to the controller but cannot be directly modified or deleted except by modifying or
deleting the rule that caused the automatic entry to be added. Match fields and priority are predetermined,
and the switch assigns the same cookie value as the initiating rule.
In addition to flow tables, DNOS-OF defines a set of group table entry types. The OpenFlow 1.3.4
specification defines four types of groups: indirect, all, select, and fast failover. DNOS-OF further types
group entries according to how they can be used in packet flows. This is done using specific naming
conventions, properties, and supported action buckets. All DNOS-OF group table entry types can be
programmed using OpenFlow 1.3.4 as long as group mods respect the typing conventions.
One motivation for group typing is supporting fundamental differences in use-case requirements. For
example, in order to support “one-arm” routing using group table entries, there needed to be a way to
override OpenFlow’s default source removal and allow routing back to the IN_PORT. This was
accomplished by defining L3 group entry types with different properties from L2 groups. Group entry
typing is also useful to enforce constraints on group entry chains and for Virtual Local Area Network
(VLAN) configuration on physical ports.
Remember that DNOS-OF tables are programming abstractions and do not necessary directly correspond
one-to-one with hardware tables. However, they are designed to faithfully capture both use-case
requirements and the hardware packet flow semantics, while being straightforward to program from
standard controllers.
Users must program flow tables and group entries according to the allowed entry types. The DNOS-OF
validates calls and returns errors if constraints and/or conventions are violated. This includes the
requirement that objects must exist before they can be referenced from other objects. The OpenFlow
agent that interfaces to OF-DPA may also do some argument validation and execute local iterative
procedures.
Many forwarding and editing actions for encapsulation/push and field modify are programmed using one
or more action buckets in group table entries. This not only proves to be a very efficient and modular
programming approach, in that the controller can optimize hardware resources better than the switch, but
the controller intrinsically has more CPU power and memory than the control processor on a typical
switch for this task. The controller also understands what the application is trying to do, especially when
programming requires updating multiple tables. However, when compared with OpenFlow 1.0
programming, it may require more messages between the controller and switches, since more objects
need to be programmed. It also potentially requires the controller to keep track of more switch state,
although this state can be interrogated as needed.
4.4.2 DNOS-OF L2 Interface Group Entries
L2 Interface Group entries are of OpenFlow indirect type, with a single action bucket.
DNOS-OF L2 Interface group entries are used for egress VLAN filtering and tagging. The identifier
convention is shown in Table 94. If a specific set of VLANs is allowed on a port, appropriate group entries
must be defined for the VLAN and port combinations.