17 OpenFlow Protocol and Flow Tables

reference-architectures

sdn

openflow

17.1 Start With a Packet Event

OpenFlow is easiest to read as a packet event that changes switch state. A packet misses, the controller evaluates intent, a rule is installed, counters move, and later packets follow the programmed path.

Start simple: trace one packet from match to action to evidence. The protocol details matter because they decide whether that trace is correct, timely, and reversible.

In 60 Seconds

OpenFlow is a southbound protocol pattern for letting an SDN controller manage switch behavior with explicit messages and flow-table entries. A switch reports events such as packet misses and port changes. The controller checks state and policy, then installs, modifies, or removes match-action rules. The switch forwards matching packets locally and reports acknowledgements, counters, and errors back to the controller.

17.2 Learning Objectives

By the end of this chapter, you will be able to:

Explain the OpenFlow control-channel boundary between controller decisions and switch forwarding.
Trace packet-in, flow-mod, packet-out, barrier, stats, and error message roles without mixing them with user traffic.
Inspect a flow entry through match fields, priority, instructions, actions, counters, timeout, owner, and cleanup state.
Evaluate table-miss behavior, multi-table pipelines, group-style outputs, and meter-style rate controls.
Build a proof record for an OpenFlow-style rule change in an IoT gateway path.

17.3 Quick Check: Gateway Update Rule Proof

17.4 Minimum Viable Understanding

OpenFlow is useful when every rule change can be traced from event to proof.

Check route from switch event through controller decision, flow modification, acknowledgement, local forwarding, counter proof, and cleanup record. — OpenFlow protocol check route

Use this route:

Observe the event: packet miss, port change, counter update, error, or operator request.
Check controller state: topology, host group, existing rules, policy, protected exceptions, and rollback.
Build the message: choose flow-mod, packet-out, stats request, barrier, or no-action response.
Install narrowly: set match, priority, instruction, action, table, timeout, owner, and cleanup trigger.
Confirm behavior: inspect acknowledgement, errors, counters, receiver result, and protected-path proof.

The protocol is not just a message vocabulary. It is a way to make forwarding changes traceable.

17.5 Prerequisites

Revisit these chapters as needed:

SDN Core Concepts: control/data-plane separation and match-action rules.
SDN Three-Layer Architecture: controller and infrastructure responsibilities.
SDN Controller Hands-On Lab: proof-based lab practice.
SDN OpenFlow Challenges: operational risks and rule-state pressure.

17.6 Protocol Boundary

OpenFlow messages travel on a control channel between controller and switch. They are not the same as the data packets that the switch forwards for applications.

OpenFlow boundary showing controller messages on a control channel, switch flow tables in the data plane, user packets on forwarding ports, and proof reports back to the controller. — OpenFlow control-channel boundary

Boundary rules:

Controller messages: change, query, or confirm switch state through the control channel.
User packets: enter and leave forwarding ports according to local rules.
Switch state: includes tables, ports, buffers, counters, meters, groups, errors, and connection state.
Proof: acknowledgements, counters, errors, and receiver observations prove whether the change worked.

Keeping this boundary clear prevents a controller-side plan from being mistaken for a data-plane result.

17.7 Message Roles

The protocol uses different messages for different check questions.

Packet-in

Switch reports an unmatched packet or configured exception to the controller with enough context for a decision.

Flow-mod

Controller adds, changes, or removes a flow entry in a target table with match, priority, action, and cleanup fields.

Packet-out

Controller asks the switch to emit a specific packet when the first packet or a control workflow needs explicit handling.

Stats

Controller asks for counters and state so a decision or audit is based on observed behavior rather than intent alone.

Barrier

Controller asks the switch to confirm earlier messages have been processed before the next step depends on them.

Error and status

Switch reports rejected messages, table pressure, port changes, and other conditions that affect forwarding proof.

17.8 Reactive Message Loop

A reactive loop handles a new or exceptional packet by involving the controller once, then keeping later matching packets local.

Reactive message loop showing packet miss, packet-in, controller policy decision, flow-mod, optional packet-out, local forwarding, counters, and cleanup. — Reactive OpenFlow message loop

Trace the loop:

Packet arrives: the switch checks its tables in the configured order.
No local match: table-miss behavior reports the event, drops it, or follows another configured fallback.
Controller decides: state, policy, protected paths, and existing rules are checked.
Rule is installed: the switch accepts, rejects, times out, or replaces the flow-mod.
Later packets match locally: counters move and receiver behavior provides service proof.

The first event may need controller involvement. The continuing service should not require a live controller decision for every matching packet.

17.9 Switch Components

An OpenFlow-style switch has more than one table of rules.

OpenFlow switch components showing an SDN controller connected over OpenFlow and TLS to a switch secure channel, a pipeline of flow tables that match header fields and apply actions, a group table for multi-path output, a meter table for rate limiting and QoS, a packet buffer, and physical ingress and egress ports, with the ingress, lookup, and action packet flow. — OpenFlow switch components: flow tables, meters, and ports

Check these components:

Flow tables: ordered match-action entries, often arranged as a pipeline.
Group-style outputs: reusable output behavior for replication, selection, or fallback paths.
Meter-style controls: rate or policy controls that can mark, limit, or redirect a traffic class.
Packet buffer: temporary packet storage used when the controller must respond to an event.
Ports and queues: data-plane interfaces and scheduling behavior.
Counters and status: rule, table, port, and error proof used by operations.

The switch is not a passive wire. It executes checked local behavior and reports proof.

17.10 Flow Entry Anatomy

A flow entry is traceable only when both behavior and proof fields are explicit.

Anatomy of an OpenFlow flow-table entry: match fields, an action set, and metadata including priority, packet and byte counters, idle and hard timeouts, and a controller cookie. — An OpenFlow flow entry pairs match fields and an action set with metadata - priority, counters, timeouts, and a controller cookie - that make the rule auditable.

Minimum fields:

Match: the packet fields, ingress context, metadata, or traffic class that define scope.
Priority: which rule wins when multiple rules could match.
Table: where the entry belongs in the processing pipeline.
Instruction: whether to apply actions, write actions, jump to another table, meter, or stop.
Action: forward, drop, mirror, modify, queue, meter, group, or send an event.
Timeout: idle cleanup and hard cleanup behavior for temporary or bounded rules.
Owner: application, policy, incident, maintenance window, or operator that requested it.
Counters: matched packets, bytes, duration, errors, and final values at cleanup.

Avoid broad entries that cannot name their owner, timeout, and protected exceptions.

17.11 Table-Miss Behavior

Every table should have defined miss behavior.

Table-miss behavior showing packet with no matching rule, explicit miss action, controller event, drop, default path, and proof record. — OpenFlow table-miss behavior

Miss behavior choices:

Report

Send a packet-in event when the controller must classify or approve the traffic before it is allowed.

Drop

Discard traffic that should not leave the table without an explicit approved match.

Default path

Forward limited traffic to a safe path when the design needs continuity for known low-risk classes.

The unsafe choice is an implicit miss that nobody checked. Make the miss action visible and test it.

17.12 Pipeline Check

Multi-table pipelines make rule ownership easier to check when each table has a narrow purpose.

OpenFlow pipeline check showing classification, policy, traffic treatment, forwarding, miss behavior, and proof tracepoints across tables. — OpenFlow multi-table pipeline

Example table purposes:

Classification: identify traffic class, host group, or ingress context.
Policy: apply allowed, denied, protected, or approval-required decisions.
Treatment: set queue, meter, mirror, rewrite, or group behavior.
Forwarding: choose egress port, tunnel, gateway, or receiver path.
Proof: counters and events that prove each stage was reached.

The pipeline should make conflicts easier to inspect, not harder.

17.13 Counters and Statistics

Counters are useful proof, but they are not the full service result by themselves.

OpenFlow statistics collection: a controller polls switches at intervals for five statistics types - flow, port, table, queue, and meter stats - feeding traffic engineering and anomaly detection. — OpenFlow exposes five statistics types - flow, port, table, queue, and meter - that a controller polls to prove behavior and detect anomalies.

Use counters to answer:

Which rule matched the traffic?
Did the expected table stage see the packet?
Did the egress port counter move?
Did a drop, meter, or error counter change?
Did the receiver observe the expected traffic?
Did protected traffic remain unaffected?

Counters support the conclusion; receiver proof and protected-path checks complete it.

17.14 Security and Failure Boundaries

OpenFlow centralizes decision authority, so control-channel safety and failure behavior must be part of the check.

Security and failure boundary map showing controller identity, protected control channel, role permissions, rule validation, switch connection loss, stale rules, and recovery proof. — OpenFlow security and failure boundaries

Check:

Controller identity: switches should accept commands only from approved controller endpoints.
Protected control channel: message integrity and confidentiality matter because flow-mods change forwarding behavior.
Role and request checks: applications should not install rules outside their scope.
Rule validation: broad matches, unsafe drops, and missing timeouts must be checked before installation.
Connection loss: existing local rules and new unmatched traffic need defined behavior when the controller is unavailable.
Recovery: after reconnection, controller state must reconcile with real switch tables and counters.

17.15 Build Gateway Update Paths

A building gateway carries telemetry, door-control events, camera traffic, management access, and update downloads. During a maintenance window, the controller needs to steer update traffic while preserving door-control and management paths.

Request

The application requests a temporary update path for a defined device group.

OpenFlow-style trace

Packet event or operator request identifies update traffic and ingress context.
Controller checks host group, topology, existing rules, protected exceptions, and rollback.
Controller sends a scoped flow-mod for update traffic only.
Switch acknowledges the change or reports an error.
Later matching update traffic increments the expected rule and port counters.
Door-control and management receiver checks remain clean.
Cleanup removes or expires the temporary update rule and records final counters.

Proof record

Service intent: steer update traffic during a maintenance window
Protected exceptions: door-control events, telemetry, management access
Message path: packet event or operator request, controller state check, flow-mod
Rule fields: match, priority, table, instruction, action, timeout, owner
Switch proof: acknowledgement or error, rule counter, port counter
Outcome proof: update receiver result and protected-path checks
Cleanup: expiry or removal, rollback result, final table state

17.16 Proof Loop

The chapter’s protocol knowledge should end in a traceable proof loop.

Proof loop showing event, controller state, protocol message, switch acknowledgement, local forwarding, counters, receiver result, cleanup, and operations record. — OpenFlow proof loop

Capture:

Event source, reason, ingress context, and traffic class.
Controller state used for the decision.
Message type and target switch or table.
Flow entry fields and owner.
Acknowledgement, error, or barrier result.
Rule, table, and port counter movement.
Receiver result and protected-path checks.
Cleanup, rollback, and next check trigger.

17.17 Knowledge Check

17.18 Check the Protocol Proof

17.19 Match the Message to Its Check Role

17.20 Order an OpenFlow-Style Rule Change

17.21 Common Pitfalls

Confusing control messages with user traffic: packet-in and flow-mod travel on the control channel; application packets still use the forwarding plane.
Leaving table-miss behavior implicit: every table needs a checked miss action so unknown traffic does not drift into unsafe behavior.
Using broad rules without exceptions: wide matches can capture protected management, command, or safety traffic.
Ignoring priority and table order: correct actions can fail when another rule wins first or a packet never reaches the expected table.
Treating counters as complete proof: counters show matching behavior, but receiver outcomes and protected-path checks still matter.
Skipping reconnection check: after controller or channel recovery, switch tables and controller state must be reconciled.

17.22 The Protocol Changes State

OpenFlow matters because it turns a controller decision into switch state. The protocol message is only the start of the story; the learner should always ask what state changed, which packets now match it, and how the system proves the change stayed inside its intended boundary.

A safe OpenFlow explanation therefore connects the controller request, the switch acknowledgement or error, the local forwarding result, the receiver outcome, and the cleanup record. Without that chain, a flow rule can look correct in the controller and still be wrong in the network.

For example, a warehouse gateway group might need a short-lived rule that steers firmware downloads away from the same uplink used by fire-door status events and operator management. The OpenFlow protocol part is the controller sending a flow-mod with explicit match fields, table, priority, action, timeout, and owner. The service part is proving that download packets matched the intended rule while fire-door and management traffic kept their protected paths.

The key distinction is state versus intent. A controller log can show that an application asked for a rule. A switch acknowledgement can show that the request was processed. Counters can show whether packets matched. Receiver proof can show whether the update service and protected services behaved correctly. The chapter’s mental model should keep all four facts separate.

A useful beginner check is to read a rule as a sentence: traffic from wh-gw-17 to the update server, in table 10, at priority 420, is sent through the metered update path for 30 minutes, while door-control and management packets keep their normal rules. If that sentence cannot name the match, action, timeout, exception, and proof, the rule is not ready to release.

This sentence also gives reviewers a compact way to compare controller intent against switch state, receiver logs, and the final cleanup record.

17.23 Rule Release Record

Before a rule change is released, write a short record that separates intent, installed state, observed behavior, and closure. This makes the protocol usable in production instead of leaving it as a sequence of controller log lines.

A practical release record for wh-gw-update would name the gateway group, update destination, ingress port or VLAN, match fields, target table, priority, meter or output action, idle timeout, hard timeout, and rollback owner. It would also name protected exceptions such as door-status, mgmt-ssh, and broker telemetry so reviewers can see what the rule must not capture.

Record Field	What To Capture	Why It Matters
Intent	Traffic class, protected exceptions, target switch, table, priority, action, timeout, and owner.	Prevents broad rules from silently capturing management, command, or safety traffic.
Install proof	Flow-mod result, error result, barrier result where ordering matters, and final table entry.	Separates a sent request from a switch state that was actually processed.
Behavior proof	Rule counters, table counters, port counters, expected receiver result, and protected-path checks.	Shows that the right packets matched locally and that the service result stayed safe.
Closure proof	Expiry, explicit removal, rollback, final counters, and owner sign-off.	Stops temporary protocol state from becoming permanent hidden network behavior.

After installation, the record should be updated with the flow-mod result, any error code, barrier result when ordering matters, final table entry, and before/after counters. Closure should include receiver evidence from the update service, receiver evidence from protected paths, final counter values, and the cleanup action that removed or expired the temporary entry.

With Open vSwitch, that proof often means comparing the controller’s intended rule with a table dump such as ovs-ofctl dump-flows, then checking packet and byte counters before and after the maintenance window. The exact tooling can vary, but the release record should still show intended state, processed state, observed traffic, receiver result, and cleanup.

17.24 Ordering Is Correctness

OpenFlow-style control is stateful. A controller can send several requests, but the service depends on how the switch processes them, how tables are ordered, which priority wins, whether a previous entry still matches, and whether counters prove the expected path after the change.

That is why a barrier, acknowledgement, or error is not just administrative detail. It tells the operator where the proof chain is strong and where it is still missing. A flow-mod accepted before an old broad rule is removed may still fail if the old rule has higher priority or an earlier table sends the packet elsewhere.

An OpenFlow flow entry pairs match fields and an action set with metadata - priority, counters, timeouts, and a controller cookie - that make the rule auditable.

The under-the-hood check is a state comparison: controller intent before the change, switch table state after processing, packet path through the pipeline, receiver evidence, and final state after cleanup. Protocol knowledge is complete only when those states line up.

Suppose a controller removes an old ip_dst=update.example rule from table 10 and installs a narrower rule that also matches the gateway VLAN and update TCP port. If the removal is still pending, or if a table-0 jump bypasses table 10, the narrower rule can be technically present but operationally irrelevant. A barrier reply, final table dump, and matched counter movement help prove which state the switch actually used.

Timeouts are part of the same state comparison. An idle timeout cleans up entries that stop matching; a hard timeout removes an entry after a fixed interval even if traffic continues. A maintenance rule should record which timeout applies, what happens on expiry, and whether the controller reconciles switch state after reconnection. Otherwise a temporary OpenFlow action can become invisible production policy.

When the controller reconnects, the same comparison should run again. The switch may still hold rules, counters, meters, or groups that the controller no longer expects. Treat reconciliation as a protocol step, not just an operations chore.

17.25 Summary

OpenFlow-style protocols let a controller manage switch behavior through explicit control-channel messages and local match-action tables. Packet-in messages report events, flow-mod messages change rules, packet-out messages handle specific packets, stats messages return proof, and errors expose rejected requests. Strong designs define table-miss behavior, priority, pipeline stage, owner, timeout, and cleanup for each rule. The proof of success is not the message alone; it is acknowledgement, local forwarding proof, counters, receiver behavior, protected-path checks, and a recorded cleanup path.

17.26 Key Takeaway

OpenFlow protocol work should connect match-action rules, table behavior, counters, and controller interactions to concrete network policy.

17.27 See Also

SDN Core Concepts: match-action rules and SDN check route.
SDN Controller Hands-On Lab: hands-on proof practice.
SDN Three-Layer Architecture: application, controller, and infrastructure responsibilities.
SDN OpenFlow Challenges: operational risks and state pressure.
SDN OpenFlow Statistics: using counters for proof traces.

17.28 What’s Next

Continue to SDN OpenFlow Challenges to check failure modes, rule-state pressure, and operations risks around OpenFlow-style control.