Cloud, SDN & Production Architectures · Study deck

OpenFlow Protocol and Flow Tables

Picture a building sensor whose packets keep taking an old route after a maintenance change.

Cloud Clara is your guide for this deck.

openflowprotocol

Cloud Clara, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

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.

Major section

Start With a Packet Event

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.

Major section

Start With a Packet Event (continued)

The protocol details matter because they decide whether that trace is correct, timely, and reversible.

This runway does not prove that the whole software-defined network is correct.
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.

Major section

In 60 Seconds · Minimum Viable Understanding

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 protocol is not just a message vocabulary.

Major section

Protocol Boundary · Message Roles

The practical risk in protocol boundary needs a diagram. Summarizes it: OpenFlow control-channel boundary.

Proof: requested barrier replies, switch readback, counters, errors, and receiver observations help verify whether the change worked.
The protocol uses different messages for different check questions.
At message roles, Message Roles Answer Different Review Questions makes the architecture testable.

Major section

Reactive Message Loop · Switch Components

The panels begin with a packet that has no switch 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.
Later packets match locally: counters move and receiver behavior provides service proof.

Major section

Flow Entry Anatomy · Table-Miss Behavior

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

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.
Every table should have defined miss behavior.

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.

Major section

Pipeline Check · Counters and Statistics

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

This path preserves the chapter’s pipeline check argument: OpenFlow multi-table pipeline.
The pipeline should make conflicts easier to inspect, not harder.
Counters are useful proof, but they are not the full service result by themselves.

Major section

Security and Failure Boundaries · Build Gateway Update Paths

OpenFlow centralizes decision authority, so control-channel safety and failure behavior must be part of the 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.

OpenFlow security and failure boundaries

Major section

Proof Loop · Check the Protocol Proof

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

The chapter needs visual evidence for proof loop. Provides it: OpenFlow proof loop.
Controller state supplies policy and topology context before a flow-mod or statistics message is sent.
Cleanup then removes or expires the temporary rule and records the final state.

Major section

Common Pitfalls · The Protocol Changes State

Without that chain, a flow rule can look correct in the controller and still be wrong in the network.

Confusing control messages with user traffic: packet-in and flow-mod travel on the control channel; application packets still use the forwarding plane.
The key distinction is state versus intent.
Counters can show whether packets matched.

Major section

Rule Release Record

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.
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.
The exact tooling can vary, but the release record should still show intended state, processed state, observed traffic, receiver result, and cleanup.

OpenFlow exposes five statistics types - flow, port, table, queue, and meter - that a controller polls to prove behavior and detect anomalies.

Major section

Ordering Is Correctness

OpenFlow-style control is stateful.

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.
Timeouts are part of the same state comparison.

An OpenFlow entry matches packet fields, applies output, drop, or modify actions, and records priority, counters, timeouts, and a cookie.

Major section

Ordering Is Correctness (continued)

Otherwise a temporary OpenFlow action can become invisible production policy.

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.
When the controller reconnects, the same comparison should run again.

Major section

Ordering Is Correctness (continued)

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.

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.
The switch may still hold rules, counters, meters, or groups that the controller no longer expects.

Major section

Summary · Key Takeaway

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.
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.
OpenFlow protocol work should connect match-action rules, table behavior, counters, and controller interactions to concrete network policy.

OpenFlow switch components: flow tables, meters, and ports

Deck summary

Key takeaways

The team must show which rule remained, who installed it, and when it should have ended.

The protocol details matter because they decide whether that trace is correct, timely, and reversible.
OpenFlow is a southbound protocol pattern for letting an SDN controller manage switch behavior with explicit messages and flow-table entries.
The practical risk in protocol boundary needs a diagram. Summarizes it: OpenFlow control-channel boundary.
The panels begin with a packet that has no switch rule.

Retrieval practice

Recall check 1 of 4

Cloud Clara says: answer from memory, then check your reasoning.

Q1During a maintenance window, a controller must steer gateway update downloads without catching telemetry, door-control events, or management access. Which first check keeps the OpenFlow-style rule change traceable?

AName the update class, match fields, table, priority, action, timeout, owner, exceptions, counters, receiver proof, and cleanup path.

BInstall a broad update match first, then narrow it later if telemetry or door-control paths report trouble.

CTreat the flow-mod acknowledgement as proof that update receivers and protected paths stayed clean.

DUse the maintenance calendar's end time as the cleanup plan, letting the operator remove the rule when the window closes.

Show answer

Answer: A A safe OpenFlow-style maintenance rule names the update traffic scope, match fields, table, priority, action, owner, timeout, protected exceptions, counters, receiver result, cleanup path, and review condition before the controller sends the flow-mod.

Retrieval practice

Recall check 2 of 4

Cloud Clara says: answer from memory, then check your reasoning.

Q2A switch sees unknown traffic, while known alerts need a protected output and routine traffic needs a rate cap. Which pipeline review fits?

ADefine miss and policy; alert output or supported group, meter routine traffic, then check counters and receivers.

BLet unknown packets inherit a broad allow rule without classifying or checking receiver outcomes.

CMeter protected alerts while sending all routine flows to controller without rate policy.

DCheck switch rule acceptance alone, without counters, alert receiver, or routine meter proof.

Show answer

Answer: A Miss, treatment, and forwarding rules need explicit proof.

Retrieval practice

Recall check 3 of 4

Cloud Clara says: answer from memory, then check your reasoning.

Q3A controller sends a flow-mod to steer update traffic, and the switch accepts it. What proof is still needed before saying the service behavior worked?

ANo more proof is needed because a flow-mod acknowledgement proves the user service worked.

BCheck rule and port counters, receiver behavior, protected-path safety, and cleanup state.

CCompare the controller's requested and acknowledged rule records to confirm the change completed.

DCapture the next packet at the controller to verify the intended update classification.

Show answer

Answer: B An OpenFlow flow-mod has no mandatory success acknowledgement.

Retrieval practice

Recall check 4 of 4

Cloud Clara says: answer from memory, then check your reasoning.

Q4A controller sends two OpenFlow-style changes for a gateway maintenance window: remove an old broad update rule, then install a narrower rule with protected exceptions. Which proof closes the protocol boundary?

ACheck order, final table state, narrow-rule counters, receiver result, protected paths, and cleanup owner.

BTrust the controller log because it lists both requested changes in the intended order.

CCheck only that update traffic still reaches the receiver after the rule change.

DUse increasing narrow-rule counters as the completion check, since they show the new rule is forwarding traffic.

Show answer

Answer: A OpenFlow protocol proof closes only when requested intent, processed switch state, rule priority and ordering, counters, receiver behavior, protected paths, and cleanup all agree.

Print reference

Answers

Answer key.

A · A safe OpenFlow-style maintenance rule names the update traffic scope, match fields, table, priority, action, owner, timeout, protected exceptions, counters, receiver result, cleanup path, and review condition before the controller sends the flow-mod.
A · Miss, treatment, and forwarding rules need explicit proof.
B · An OpenFlow flow-mod has no mandatory success acknowledgement.
A · OpenFlow protocol proof closes only when requested intent, processed switch state, rule priority and ordering, counters, receiver behavior, protected paths, and cleanup all agree.