Overview of OpenFlow v1.3.0

An OpenFlow switch maintains one or more flow tables, which are used for packet processing. The switch performs the actions listed in the table entry corresponding to the matched flow.

The OpenFlow Controller manages the OpenFlow switch using OpenFlow. The OpenFlow Controller can add, delete, or modify flows by getting statistics for ports and flows and other information using the OpenFlow protocol.

OpenFlow v1.3.0 Architecture

Each flow table maintained in a switch consists of flow entries sorted by the flow priority. The highest priority flows are at the top of the flow table. Incoming packets are matched against the flow entries starting from the highest priority flow. If there is a match, then flow matching stops, and the set of actions for that flow entry are performed. The packets that do not match any flow entry are either dropped or sent to the controller.

OpenFlow v1.3.0 defines three types of tables:

  • Flow table
  • Group table
  • Meter table

OpenFlow 1.3.0 Flow Table Entries

The incoming packets are matched against the multiple tables in the pipeline.

Note: The ICX switches do not support matching or manipulating MPLS label information in a flow. Flows with MPLS EtherType are considered failures.

Pipeline Processing

Note: The ICX switches do not support multiple table lookup.

In this section:

  1. Flow Table Entries
    Each flow table entry contains the fields described in the following table.
  2. OpenFlow v1.3.0 Instructions
    Each flow entry has a set of instructions that are executed when the packet matches the entry.
  3. OpenFlow v1.3.0 Actions
    Each flow has a set of instructions that are executed when the packet matches the flow according to OpenFlow v1.3.0 specifications. Each flow can have only one instruction of each type.
  4. Scaling Considerations
    These are the scaling considerations and limitations for the flows and CAM partitions.
  5. Multiple Controller Connections
    An OpenFlow switch may be connected to multiple controllers for reliability, allowing the switch to continue to operate in OpenFlow mode if a controller or controller connection fails. The controllers coordinate the management of the switch amongst themselves to help synchronize controller handoffs.
  6. Asynchronous Configuration
    Asynchronous messages may need to be sent to multiple controllers. An asynchronous message is duplicated for each eligible OpenFlow channel, and each message is sent when the respective controller connection allows it.
  7. Supported OpenFlow Messages
    The OpenFlow messages listed in the following table are supported on ICX devices.
  8. Output Port Normal Action
    Output port Normal is a reserved action. Normal action represents the traditional non-OpenFlow pipeline of the device. Normal is a special type of output port included in the actions associated with a flow. When a flow is received from the controller with an output port as Normal, the switch processes the matched incoming packet using the local switching or routing.
  9. Supporting Untagged Traffic on OpenFlow Hybrid Ports on Protected and Unprotected VLANs
    Untagged traffic is supported on protected VLANs or configured unprotected VLANs supporting IP traffic on an OpenFlow hybrid port. You can configure an untagged VLAN as a protected VLAN or an unprotected VLAN.
  10. Idle and Hard Timeout Support for OpenFlow
    Each flow entry may have an idle timeout and a hard timeout associated with it.
  11. Layer 2 Support for OpenFlow Hybrid Mode
    The following Layer 2 features are supported in the OpenFlow hybrid mode on protected VLANs and unprotected VLANs:
Parent topic: OpenFlow v1.3.0