How OpenFlow Evolved: From v1.0 to v1.8 and What Comes Next

OpenFlow SDN Protocol Evolution

OpenFlow is an SDN protocol, officially called the OpenFlow Switch Specification, developed and maintained by the Open Networking Foundation (ONF).

The evolution of OpenFlow has focused on two core aspects:

Control‑plane enhancements : making the SDN controller richer and more flexible.

Data‑plane enhancements : allowing switches to match more packet fields, perform more actions, and use more efficient matching strategies.

Each subsequent OpenFlow version builds on the previous one with incremental improvements.

OpenFlow v1.0 (December 2009)

Introduced a single Flow Table per switch, composed of Flow Entries that contain a Header Domain, Action set, and Counter. Communication is limited to a single controller.

Matches fields such as srcMAC, dstMAC, srcIP, dstIP, TCP/UDP ports.

Supports Flow Classify, multiple Flow Entries per table.

Provides an Action Set (forward, drop, modify header, etc.).

Offers basic statistics (packet and byte counters per flow).

OpenFlow v1.1 (February 2011)

Added support for multi‑level Flow Tables (up to 256 levels) and a Multi‑Table Pipeline, enabling better use of ASIC pipelines and avoiding single‑table bloat.

Matches VLAN ID, IPv4 DSCP, MPLS labels.

Introduces Group Table for logical grouping of flows.

Provides richer statistics (latency, loss rate, etc.).

OpenFlow v1.2 (December 2011)

Replaced the fixed‑length flow rule encoding with a TLV‑based OXM format, allowing more flexible field definitions and supporting multiple controllers.

Matches IPv6 and IPv6 Flow Label.

Introduces Metadata Table and IP subnet aggregation.

Supports programmable tunnels.

OpenFlow v1.3 (June 2012)

A long‑term supported stable release that expands matching fields to 40, introduces Meter Table, Flow Priority, and flow migration.

Matches IPv6 Extension Header.

Provides rate‑metering via Meter Table.

Allows flow priority assignment and flow migration between switches.

OpenFlow v1.4 (April 2013)

Focuses on data‑plane synchronization, allowing multiple Flow Tables to share matching fields while defining distinct actions.

Matches ICMPv6 and SCTP fields.

Supports multi‑path flows and multiple actions per packet.

Normalizes multiple Meter Tables.

OpenFlow v1.5 (August 2014)

Matches IPv6 ND and ARP fields.

Supports multi‑level flow classification and dynamic table size changes.

Enables virtualization of multiple virtual networks on a single physical network.

OpenFlow v1.6 (April 2016)

Matches GRE protocol fields.

Allows programmable data‑plane logic.

Introduces controller access control and flow replication.

OpenFlow v1.7 (March 2017)

Matches IPv6 fragment and TCP flag fields.

Supports hybrid tables, IP address mobility, and controller traffic shaping.

OpenFlow v1.8 (November 2017)

Matches PBB tags.

Provides multi‑path coordination for load balancing and high availability.

Offers controller topology discovery, load balancing, failover, and data‑plane security evaluation.

After v1.5, OpenFlow development slowed due to limitations such as limited functionality coverage and hardware dependence, prompting the industry to explore more flexible, programmable data‑plane alternatives like P4 and eBPF.

Nevertheless, OpenFlow remains a fundamental skill for SDN developers.

OpenFlow v1.5.1 Specification

This article uses OpenFlow v1.5.1 as a reference.

Specification: openflow-switch-v1.5.1.pdf

The specification focuses on seven major parts:

OpenFlow Switch system architecture

OpenFlow Port types

OpenFlow Flow Table definition

OpenFlow Group Table definition

OpenFlow Meter Table definition

OpenFlow Channel

OpenFlow protocol message types

OpenFlow Switch System Architecture

OpenFlow Controller : The control‑plane component that remotely manages switches via the OpenFlow protocol (add, delete, modify flow tables and entries).

OpenFlow Switch : Implements the OpenFlow protocol in hardware or software, forwards packets based on multiple Flow Tables and a Group Table, and communicates with the controller via an OpenFlow Channel. Two types exist:

OpenFlow‑only Switch : All traffic is processed by the OpenFlow pipeline.

OpenFlow‑hybrid Switch : Supports both traditional networking and the OpenFlow pipeline.

OpenFlow Channel : The interface through which a switch receives commands from a remote controller.

OpenFlow Protocol : The communication protocol used between controller and switch.

Flow Table : Holds multiple Flow Entries that dictate packet forwarding.

Group Table : Provides higher‑level forwarding features such as flooding, multipath, fast reroute, and link aggregation.

Meter Table : Enables QoS and metering for matched flows.

Pipeline : A chain of Flow Tables that processes packets step by step.

OpenFlow Port Types

An OpenFlow switch can configure up to 65,280 ports, divided into three major categories:

Physical Ports : Visible ports on the hardware.

Logical Ports : Abstracted ports such as tunnel or link‑aggregation ports.

Reserved Ports : Custom ports used for special actions like broadcast.

Reserved ports are further divided into eight types, three of which are optional and only valid on hybrid switches.

OpenFlow uses a 16‑bit field to encode these eight custom port types.

OpenFlow Flow Table Definition

Multi‑level Flow Tables

Since v1.1, a switch can host up to 256 hierarchical Flow Tables, numbered from 0 upward.

These tables split the matching process into multiple steps, forming a Multi‑Table Pipeline that leverages ASIC capabilities while avoiding single‑table bloat.

Flow Entries

A Flow Table consists of Flow Entries, each containing a Match Domain, Action set, and Counter.

Controllers exchange Flow Entries with switches in two modes:

Proactive : The controller pre‑installs entries using Packet‑Out messages.

Reactive : When a packet misses all entries, the switch sends a Packet‑In to the controller for decision.

A Flow Entry is composed of:

MatchFields : Packet fields to match.

Priority : Determines matching order (higher value matches first).

Counters : Packet and byte statistics.

Instructions : Actions to execute, such as apply-actions, write-actions, clear-actions, write-metadata, goto-table.

Timeouts : hard_timeout (absolute) and idle_timeout (idle).

Cookie : Controller‑defined identifier.

Flags : Entry management flags.

MatchFields

Partial list of match fields (full list in the specification):

Actions

Key actions in the Action Set include:

output {port_no} : Forward packet to a specific port.

drop : Discard the packet.

set-field {field_type} {value} : Modify packet header fields.

push-tag / pop-tag {ether_type} : Add or remove Ethernet tags.

group {group_id} : Apply a Group Table entry.

…other actions.

Set‑field actions support various field types (e.g., Ethernet, IP, TCP).

Examples

Flow Entries can match any combination of L2, L3, or L4 header fields:

Layer 1 : Tunnel ID, In Port, QoS priority, skb mark, etc.

Layer 2 : MAC address, VLAN ID, Ethernet type.

Layer 3 : IPv4/IPv6 fields, ARP.

Layer 4 : TCP/UDP, ICMP, ND.

Pipeline Processing

Packets enter the switch at Flow Table 0 and are matched sequentially. Within a table, entries are evaluated by descending priority. On a match, the entry’s counters are updated and its instructions/actions are executed (e.g., goto another table, modify packet, output, drop).

If no entry matches and a Table‑miss entry exists, the switch follows that entry’s instructions (typically forward to controller, drop, or continue). Without a Table‑miss entry, the packet is dropped.

Entries may use goto-table to jump forward but cannot jump backward.

Pipeline processing is split into Ingress and Egress stages, handling packet reception and transmission respectively.

A complete pipeline diagram is shown below:

OpenFlow Group Table Definition

Group Tables allow multiple Flow Entries to reference a common Group Entry, simplifying management.

A Group Entry consists of:

Group Identifier (unique ID)

Group Type (determines processing behavior)

Counters

Action Buckets (ordered sets of actions)

Group Types include:

all : Execute all buckets (used for multicast/broadcast).

select : Choose one bucket based on an algorithm (load balancing).

indirect : Force execution of a single bucket.

fast‑failover : Execute the first live bucket for high availability.

OpenFlow Meter Table Definition

Introduced in v1.3 to support QoS and metering.

A Meter Entry includes:

Meter identifier (unique)

Meter Bands (unordered set defining rate and actions, e.g., drop or DSCP remark)

Counters

Type‑specific arguments

OpenFlow Channel

The channel is the communication link between controller and switch, supporting TLS encryption and multiple connections (primary and auxiliary). Switches initiate the channel on TCP port 6633, and controllers can use LLDP to discover topology.

OpenFlow Message Types

The final part of the specification defines the various OpenFlow message types and data structures used for communication.

Message categories include:

Controller‑to‑Switch messages (features, configuration, flow/mod, statistics, packet‑out, barrier, role‑request, asynchronous configuration).

Asynchronous messages (packet‑in, flow‑removed, port status, error) sent from switch to controller.

Symmetric messages (hello, echo, experimenter) used bidirectionally for connection management.

A typical message exchange between controller and switch is illustrated below:

OpenFlow Message Header

OpenFlow Message Types