Views
OpenFlow 0.9 release notes
From OpenFlow Wiki
Overview
This document contains the release notes for the 0.9 release of OpenFlow. The release includes updated versions of the OpenFlow Switch Specification, the Reference Implementation and related tools. A a more in-depth discussion of the changes in this release, please see the 0.9 wiki page on the OpenFlow Wiki.
Contributors to this release include (in alphabetical order) David Erickson, Glen Gibb, Brandon Heller, Mikio Hara, Bob Lantz, Justin Pettit, Ben Pfaff, Jean Tourrilhes and David Underhill, Tatsuya Yabe, Yiannis Yiakoumis as well as many other members of the OpenFlow community that provided valuable suggestions, feedback and testing.
Known Issues
- As of the time of release, NOX does not yet support OpenFlow 0.9. A patch to NOX providing compatibility is expected in the near future.
- This release has not yet been tested on Big Endian architectures. A patch providing better support for Big Endian architecture is expected in the near future.
- This release has not yet been tested on architectures which do not allow unaligned memory access, such as MIPS and ARM.
- This release initially does not support NetFPGA. A patch providing full NetFPGA support is planned for 2H2009.
New Features
Failover
The reference implementation now includes a simple failover mechanism. A switch can be configured with a list of controllers. If the first controller fails, it will automatically switch over to the second controller on the list.
Emergency Flow Cache
The protocol and reference implementation have been extended to allow insertion and management of emergency flow entries.
Emergency-specific flow entries are inactive until a switch loses connectivity from the controller. If this happens, the switch invalidates all normal flow table entries and copies all emergency flows into the normal flow table.
Upon connecting to a controller again, all entries in the flow cache stay active. The controller then has the option of resetting the flow cache if needed.
Barrier Command
The Barrier Command is a mechanism to get notified when an OpenFlow message has finished executing on the switch. When a switch receives a Barrier message it must first complete all commands sent before the Barrier message before executing any commands after it. When all commands before the Barrier message have completed, it must send a Barrier Reply message back to the controller.
Match on VLAN Priority Bits
There is an optional new feature that allows matching on priority VLAN fields. Pre 0.9, the VLAN id is a field used in identifying a flow, but the priority bits in the VLAN tag are not. In this release we include the priority bits as a separate field to identify flows. Matching is possible as either an exact match on the 3 priority bits, or as a wildcard for the entire 3 bits.
Selective Flow Expirations
Flow expiration messages can now be requested on a per-flow, rather than per-switch granularity.
Flow Mod Behavior
There now is a CHECK_OVERLAP flag to flow mods which requires the switch to do the (potentially more costly) check that there doesn't already exist a conflicting flow with the same priority. If there is one, the mod fails and an error code is returned. Support for this flag is required in an OpenFlow switch.
Flow Expiration Duration
The meaning of the "duration" field in the Flow Expiration message has been changed slightly. Previously there were conflicting definitions of this in the spec. In 0.9 the value returned will be the time that the flow was active and not include the timeout period.
Notification for Flow Deletes
If a controller deletes a flow it now receives a notification if the notification bit is set. In previous releases only flow expirations but not delete actions would trigger notifications.
Rewrite DSCP in IP ToS header
There is now an added Flow action to rewrite the DiffServ CodePoint bits part of the IP ToS field in the IP header. This enables basic support for basic QoS with OpenFlow in in some switches. A more complete QoS framework is planned for a future OpenFlow release.
Port Enumeration now starts at 1
Previous releases of OpenFlow had port numbers start at 0, release 0.9 changes them to start at 1.
Protocol Statistics Gathering in the Reference Implementation
Added a protocol stats collector and PRIVATE_EXTENSION messages to communicate between OpenFlow control plane process and user interface process. This does not affect the spec, only the reference implementation.
New Features in 0.9 rev1
Hardware Support
OpenFlow with NetFPGA is available as 0.9 release (wire protocol 0x98).
Bugfixes in 0.9 rev1
- userspace datapath: Memory leak in mod_flow handler was fixed
- userspace datapath: Insufficiently wildcards look up regarding VLAN PCP was fixed
Changes to the Specification
- 6633/TCP is now the recommended default OpenFlow Port. Long term the goal is to get a IANA approved port for OpenFlow.
- The use of "Type 1" and "Type 0" has been depreciated and references to it have been removed.
- Clarified Matching Behavior for Flow Modification and Stats
- Made explicit that packets received on ports that are disabled by spanning tree must follow the normal flow table processing path.
- Clarified that transaction ID in header should match offending message for OFPET_BAD_REQUEST, OFPET_BAD_ACTION, OFPET_FLOW_MOD_FAILED.
- Clarified the format for the Strip VLAN Action
- Clarify behavior for packets that are buffered on the switch while switch is waiting for a reply from controller
- Added the new EPERM Error Type
- Fixed Flow Table Matching Diagram
- Clarified datapath ID 64 bits, up from 48 bits
- Clarified miss-send-len and max-len of output action
