SDN Flow Rule Installation

Watch a first IoT packet miss the table, ask the controller, receive a Flow-Mod rule, and then forward later packets in the data plane

animation
sdn
openflow
flow-table
packet-in
flow-mod
networking
architecture
Interactive SDN/OpenFlow flow-rule installation workbench with Packet-In, Flow-Mod, Packet-Out, table-miss behavior, priorities, counters, timeouts, and IoT policy scenarios.
SDN OpenFlow Flow tables IoT policy

Install the rule once, then let the switch forward matching IoT packets locally.

A reactive SDN controller is involved when the switch has no matching rule. After a Flow-Mod installs a flow entry, later matching packets follow the table entry in the data plane without asking the controller again.

18 ms First packet teaching latency
Not installed Current rule state
0 packets Matched by installed rule
2 messages Controller messages for first flow

Core sequence

Packet arrives, lookup misses, Packet-In goes to the controller, Flow-Mod installs the entry, then later packets match.

Rule structure

A flow entry combines match fields, priority, counters, instructions or actions, timeouts, and controller metadata.

Policy choice

The controller can allow, drop, meter, mirror, or steer traffic based on the policy you select.

Accuracy guardrail

The timing values are teaching estimates. OpenFlow behavior and supported fields depend on version and switch table features.

Scenario

A temperature sensor sends MQTT telemetry through an access switch. The first packet misses; the controller installs an allow rule for this flow.

Rule builder

1 Lookup

Packet reaches switch Switch parses packet headers and starts table lookup.

2 Miss

No rule matches Table-miss entry decides whether to ask the controller.

3 Packet-In

Controller sees headers The switch sends metadata and possibly a buffered packet reference.

4 Decision

Policy becomes a rule Controller chooses match fields, priority, action, and timeouts.

5 Flow-Mod

Switch installs entry The flow table now has a match-action entry for this flow.

6 Table hit

Later packets stay local Counters update and the switch applies the rule in the data plane.

Animated control/data plane handoff

The first sensor packet is entering the access switch. No installed rule is available yet, so the switch begins with a table lookup.

Lookup Data plane
SDN flow-rule installation diagram A sensor, OpenFlow switch, SDN controller, monitor, and cloud service with an animated packet and control messages showing Packet-In and Flow-Mod. IoT device Temp sensor Switch Flow table 0 SDN controller Policy engine MQTT gateway Allowed service Monitor Mirror copy Drop path Table lookup match? not yet P
Packet movement Packet-In to controller Flow-Mod install Drop outcome

First packet

18 ms Controller round trip plus install teaching overhead.

Later packet

0.2 ms Representative local data-plane lookup after the rule is installed.

Controller work

Packet-In + Flow-Mod Packet-Out may be used for the buffered first packet.

Learning diagnosis

Reactive install Good for unknown flows; proactive rules reduce first-packet delay.

Current packet headers

Ingressedge-port 3
Source10.10.8.21 temp-sensor-17
Destination10.10.20.9 mqtt-gateway
ProtocolTCP dst port 1883

Rule being installed

Matchsrc=10.10.8.21, dst=10.10.20.9, tcp_dst=1883
Priority28000
ActionApply-Actions: output uplink
Timeoutsidle 30 s, hard 300 s

Flow table snapshot

Priority Match Instruction / action Counters Timeout Status

Before the controller installs a specific flow, only the table-miss behavior can decide what happens to unmatched traffic.

Message trace

    What is installed?

    A flow entry is not just a destination. It combines packet match fields, matching priority, counters, and instructions/actions such as output, drop, set-field, group, or meter.

    Why the first packet is slower

    In reactive mode, the switch has to ask the controller when the table has no matching entry. After the Flow-Mod, later matching packets do not need a controller round trip.

    Priority matters

    OpenFlow selects the highest-priority matching entry. Overlapping entries at the same highest priority are unsafe because the selected entry can be undefined.

    Timeouts clean state

    Idle timeout removes a rule after no matching packets for a period. Hard timeout removes it after a fixed lifetime, even if packets are still matching.

    Table-miss choice

    A table-miss entry can send unmatched packets to the controller, drop them, or continue pipeline processing. Without a table-miss entry, unmatched packets are dropped by default in OpenFlow 1.3 behavior.

    IoT design clue

    Use proactive rules for predictable, latency-sensitive telemetry. Use reactive installs when the controller needs to learn or authenticate new flows first.

    Technical accuracy notes

    • Modern OpenFlow describes instructions that may contain actions; this lab uses "action" as the learner-facing shortcut.
    • The first-packet latency is a teaching model, not a field benchmark.
    • Supported match fields and actions depend on OpenFlow version and switch table features.

    Common mistake

    Do not say "the controller forwards every packet." In this model, the controller makes the decision and installs the rule; the switch forwards matching packets afterward.

    Try it

    Choose Rogue drop, step to Flow-Mod, then explain why later rogue packets do not need another Packet-In.

    Compare

    Set the table-miss behavior to default drop. What information does the controller lose when the switch never sends Packet-In?

    Design

    For a factory alarm sensor, would you pre-install rules or wait for a reactive Packet-In? Justify the choice using latency and policy control.

    OpenFlow Lookup Trace priority-ordered matching inside the switch. SDN Planes Separate control-plane decisions from data-plane forwarding. SDN Network Slicing Apply controller policy to isolated IoT traffic groups. SDN Fundamentals Connect the animation to the architecture chapter.