24 OpenFlow Protocol and Flow Tables

24.1 Start With a Packet Event

This section: Start With a Packet Event — Picture a building sensor whose packets keep taking an old route after a maintenance change.

Trace One Rule From Request to Removal

Picture a building sensor whose packets keep taking an old route after a maintenance change. The team must show which rule remained, who installed it, and when it should have ended.

A gateway means the boundary system that connects local devices to another network or service. A protocol means shared rules for exchanging messages. OpenFlow carries control messages between a controller and switches.

Send one test packet that misses a rule, install the intended path, change it, then remove it. Keep packet events, rule owner, match, action, priority, counters, time, and errors.

This runway does not prove that the whole software-defined network is correct. The deeper sections explain message roles, flow tables, pipelines, timeouts, barriers, counters, and cleanup evidence.

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.

24.2 Learning Objectives

This section: 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.

24.3 Quick Check: Gateway Update Rule Proof

This section: Quick Check: Gateway Update Rule Proof

24.4 Minimum Viable Understanding

This section: Minimum Viable Understanding — OpenFlow is useful when every rule change can be traced from event to proof.

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

The route in Figure 24.1 follows a switch event through controller policy to flow-mod, local match, and proof cleanup; notice where the installed rule is checked.

+

Locate Event in the diagram Figure 24.1, then compare flow-mod with proof cleanup. The three labels prevent a one-box minimum viable understanding reading. Their relevance to flow-mod is: OpenFlow protocol check route.

Use this route:

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

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

24.5 Prerequisites

This section: 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.

24.6 Protocol Boundary

This section: Protocol Boundary — OpenFlow messages travel on a control channel between controller and switch.

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.

The practical risk in protocol boundary needs a diagram. Figure 24.2 summarizes it: OpenFlow control-channel boundary. Look at Controller beside control messages.

+

For protocol boundary, the diagram Figure 24.2 uses Controller as the entry and control messages as a later checkpoint. Finish at service outcome. The full reading conveys: 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: requested barrier replies, switch readback, counters, errors, and receiver observations help verify whether the change worked.

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

24.7 Message Roles

This section: Message Roles — The protocol uses different messages for different check questions.

The protocol uses different messages for different check questions.

At message roles, Message Roles Answer Different Review Questions makes the architecture testable. In Figure 24.3, Barrier frames this claim: OpenFlow message role map. Read it against Message Roles Answer Different Review Questions.

+

The OpenFlow message role map in Figure 24.3 includes Barrier and the review question “what changed?”.

24.8 Reactive Message Loop

This section: Reactive Message Loop — A reactive loop handles a new or exceptional packet by involving the controller once, then keeping later matching packets local.

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

Start at Packet Arrives in Figure 24.4. Follow the table miss to packet-in, the controller check, flow-mod, and the accepted-or-error branch. Then use the six panels below to watch that rule reach the switch and the packets move.

+

The panels begin with a packet that has no switch rule. The miss goes to the controller, which checks policy and protected traffic before installing a narrow rule. The first packet is released; later matches stay on the switch path. In the SVG, counters and cleanup close the loop: rule acceptance alone does not prove forwarding, and temporary state needs an end. The steps below name each message in that path.

Trace the loop:

1. Packet arrives: the switch checks its tables in the configured order.
2. No local match: table-miss behavior reports the event, drops it, or follows another configured fallback.
3. Controller decides: state, policy, protected paths, and existing rules are checked.
4. Rule is installed: the switch accepts, rejects, times out, or replaces the flow-mod.
5. 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.

24.9 Switch Components

This section: Switch Components — An OpenFlow switch has one or more flow tables; multiple tables can form a pipeline.

An OpenFlow switch has one or more flow tables; multiple tables can form a pipeline.

For switch components, inspect Figure 24.5 at OpenFlow switch: controller programs, data plane forwards. Its visible premise is: OpenFlow switch components: flow tables, meters, and ports. Then compare Action.

+

Locate OpenFlow switch: controller programs, data plane forwards in the diagram Figure 24.5, then compare Action with Ingress / egress. The three labels prevent a one-box switch components reading. Their relevance to Action is: 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 controls that can drop excess packets or remark DSCP when supported; separate forwarding actions can redirect traffic.
• 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.

24.10 Flow Entry Anatomy

This section: Flow Entry Anatomy — A flow entry is traceable only when both behavior and proof fields are explicit.

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

Use Figure 24.6 to separate the fields that select a rule, the instructions that act on a packet, and the metadata that proves what happened.

+

Read Figure 24.6 from table, match, and priority into the instruction and action block. The first group selects which entry wins when several rules could match; the second decides whether to drop, mirror, modify, queue, meter, forward, or continue into another table. Finish with the proof fields and owner. Counters, timeouts, errors, final values, and the controller cookie make the rule traceable to an application, policy, incident, operator, or maintenance window. A packet action without that evidence may work, yet remain impossible to audit or clean up safely.

Practitioner Knowledge Check

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 or mirror via output/group actions, modify fields, select a queue, or send to the controller; an empty action set drops. Metering is an instruction.
• 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.

24.11 Table-Miss Behavior

This section: Table-Miss Behavior — Every table should have defined miss behavior.

Every table should have defined miss behavior.

A checklist alone cannot settle table-miss behavior. Inspect Figure 24.7 for this relationship: OpenFlow table-miss behavior. Compare No Match with packet-in event.

+

The no-match case in Figure 24.7 forces an explicit action. A packet may create a packet-in report for controller review, be dropped by default, or use a limited default path. Those are different policy choices; none should be an accidental consequence of an empty table. Reporting is useful when a controller must classify an exception, but repeated misses can overload that controller. A default path needs a narrow traffic scope, while a drop needs evidence for diagnosis. Record the chosen miss action and the observed counter or event so the fallback can be tested rather than inferred from a successful rule install.

Miss behavior choices:

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

24.12 Pipeline Check

This section: Pipeline Check — Multi-table pipelines make rule ownership easier to check when each table has a narrow purpose.

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

Make the pipeline check premise visible in the diagram Figure 24.8: OpenFlow multi-table pipeline. Begin by distinguishing Pipeline Tables Should Have Narrow Jobs from Treatment.

+

Begin the diagram Figure 24.8 with Pipeline Tables Should Have Narrow Jobs. Continue through Treatment before checking Checkpoints: miss, winning rule, counters, receiver, cleanup. This path preserves the chapter’s pipeline check argument: 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.

24.13 Counters and Statistics

This section: Counters and Statistics — Counters are useful proof, but they are not the full service result by themselves.

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

Inspect Figure 24.9 to match each OpenFlow statistic with the operational question it can answer.

+

Follow the polling arrow in Figure 24.9 from the controller to five statistic families. Flow counters show which rule matched; port counters expose received, transmitted, and dropped traffic. Table statistics reveal whether the expected pipeline stage saw a packet, while queue and meter statistics describe scheduling and rate-policy behaviour. These counters support traffic engineering and anomaly review, but they do not prove that a protected message arrived fresh and usable. Pair the chosen counter movement with receiver evidence and a protected-path check before closing a service claim.

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.

24.14 Security and Failure Boundaries

This section: Security and Failure Boundaries — OpenFlow centralizes decision authority, so control-channel safety and failure behavior must be part of the check.

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

Before approving security and failure boundaries, test the depicted proposition in Figure 24.10: OpenFlow security and failure boundaries. Read from Review the Boundary Before Installing Rules toward broad or stale.

+

For security and failure boundaries, the diagram Figure 24.10 uses Review the Boundary Before Installing Rules as the entry and broad or stale as a later checkpoint. Finish at Review every flow-mod before install. The full reading conveys: 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.

24.15 Build Gateway Update Paths

This section: Build Gateway Update Paths — A building gateway carries telemetry, door-control events, camera traffic, management access, and update downloads.

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.
• A switch can report an error; a requested barrier reply confirms processing order, and readback verifies installed state.
• 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: requested barrier reply and readback or error, rule counter, port counter
Outcome proof: update receiver result and protected-path checks
Cleanup: expiry or removal, rollback result, final table state

24.16 Proof Loop

This section: Proof Loop — The chapter’s protocol knowledge should end in a traceable proof loop.

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

The chapter needs visual evidence for proof loop. Figure 24.11 provides it: OpenFlow proof loop. Examine Event together with Message.

+

The proof loop in Figure 24.11 begins with a miss or service request. Controller state supplies policy and topology context before a flow-mod or statistics message is sent. An acknowledgement alone proves only that a protocol step occurred; counters and the receiver outcome show whether the service took the intended path. Capture a rejection or partial change with the same request identity. Cleanup then removes or expires the temporary rule and records the final state. This closes the operational loop: the next operator can compare the event, decision, switch response, forwarding result, and cleanup instead of trusting an isolated controller log entry.

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.
• Requested barrier reply and switch readback, or an error.
• Rule, table, and port counter movement.
• Receiver result and protected-path checks.
• Cleanup, rollback, and next check trigger.

24.17 Knowledge Check

This section: Knowledge Check

24.18 Check the Protocol Proof

This section: Check the Protocol Proof

24.19 Match the Message to Its Check Role

This section: Match the Message to Its Check Role

24.20 Order an OpenFlow-Style Rule Change

This section: Order an OpenFlow-Style Rule Change

24.21 Common Pitfalls

This section: 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.

24.22 The Protocol Changes State

This section: The Protocol Changes State — OpenFlow matters because it turns a controller decision into switch 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, a requested barrier reply and switch readback or an 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 requested barrier reply can show that prior messages were processed; switch readback shows the installed state. 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.

24.23 Rule Release Record

This section: Rule Release Record — Before a rule change is released, write a short record that separates intent, installed state, observed behavior, and closure.

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.

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.

24.24 Ordering Is Correctness

This section: Ordering Is Correctness — OpenFlow-style control is stateful.

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 reply, switch readback, 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.

+

Read @embed-flowentry-modern-20260222 from match and priority into instructions and actions, then finish at counters, timeouts, errors, and ownership. During an ordered update, compare those fields with controller intent before the change and the table state after the switch processes it. Next follow the packet through the selected tables and check receiver evidence alongside a requested barrier reply and switch readback. The final cleanup state matters too: an expired or removed maintenance rule should no longer match traffic. The change is complete only when intended rule, installed state, observed path, receiver result, and cleanup agree.

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.

24.25 Summary

This section: Summary — OpenFlow-style protocols let a controller manage switch behavior through explicit control-channel messages and local match-action tables.

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 a requested barrier reply and switch readback, local forwarding proof, counters, receiver behavior, protected-path checks, and a recorded cleanup path.

24.26 Key Takeaway

This section: Key Takeaway — OpenFlow protocol work should connect match-action rules, table behavior, counters, and controller interactions to concrete network policy.

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

24.27 See Also

This section: 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.

24.28 What’s Next

This section: What’s Next — Continue to SDN OpenFlow Challenges to check failure modes, rule-state pressure, and operations risks around OpenFlow-style control.

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