Cloud, SDN & Production Architectures · Study deck

SDN Controllers: Rule Strategies

Known sensor paths need rules, the instructions that direct traffic, before traffic starts.

Cloud Clara is your guide for this deck.

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

After studying this chapter

Learning objectives

You will be able to:

  • Test rule installation strategy with a concrete scenario and pass criteria.
  • Validate state freshness breaks automation with a concrete scenario and pass criteria.
  • Explain: Known sensor paths need rules, the instructions that direct traffic, before traffic starts.
  • Explain: IoT deployments add physical, gateway, and local-control constraints that a controller design must respect.
iotclass.org

Major section

Start With the Decision · Rule Installation Strategy

Known sensor paths need rules, the instructions that direct traffic, before traffic starts.

  • A flow is traffic whose packets match the same chosen fields.
  • New or suspect flows, whose safety is not yet clear, may wait for the software-defined networking (SDN) controller to decide.
  • That controller sets the network rules.

Why it matters

Reactive handling suits discovery, exceptions, suspicious traffic, and maintenance windows because policy can be checked first, yet known routine traffic should not create repeated controller load.

SDN controller rule installation strategy
SDN controller rule installation strategy
iotclass.org

Major section

IoT Controller Placement Fit · Build Gateway Policy Changes

IoT deployments add physical, gateway, and local-control constraints that a controller design must respect.

  • A fast local loop must also work when the controller cannot be reached.
  • The record should link the choice, rule install, result at the receiver, owner, and rollback.
  • Door-access alerts must continue.
  • Receiver still sees door-access alerts.
SDN controller placement fit for IoT networks
SDN controller placement fit for IoT networks
iotclass.org

Major section

Proof Loop · Common Pitfalls

The controller's internal decision record is necessary, but not sufficient.

  • Proof must connect the decision to switch behavior and service outcome.
  • The red cross rejects a safety switch that waits for a remote answer.
  • The broken link is the failure test; the green local path lets the interlock stop the pump.
iotclass.org

Major section

Controller as Decision System · Controller Decision Record

In a course project, that means the controller diagram should name one real decision path, not just boxes for applications, control logic, and switches.

  • An SDN controller is not just a central brain.
  • This record also separates authority from convenience.
  • The rule manager then computes match fields, priority, timeout, counter attachment, and affected devices.

Key terms

Device acceptance
Device acceptance is paired with receiver proof that the intended service still works.
iotclass.org

Major section

State Freshness Breaks Automation

Controller automation fails when it treats all state as equally trustworthy.

  • Policy ownership and active rules may need strong coordination.
  • Topology and device capability need freshness checks.
  • Telemetry may be delayed.
  • Switch local state and receiver behavior must be verified outside the controller's own record.

Why it matters

For IoT, this matters because gateways often sit at site boundaries where one mistaken rule can cut telemetry, firmware updates, alarms, and rollback access at the same time.

iotclass.org

Major section

State Freshness Breaks Automation (continued)

Under the hood, each service has a different failure mode.

  • A topology service can keep a stale view after a link flap or gateway move.
  • A device manager can overestimate switch capability if firmware changes table size, meter support, or OpenFlow version behavior.
  • A policy resolver can approve two incompatible writes unless ownership is explicit.
iotclass.org

Major section

State Freshness Breaks Automation (continued)

Sequence numbers, bundle support, role negotiation, and idempotent rule identifiers keep recovery predictable enough to debug.

  • A rule manager can produce a valid-looking rule that is rejected by one switch, shadowed by a higher-priority rule, or installed without the counter needed for evidence.
  • The telemetry collector can arrive seconds late, and a receiver log can prove a service failure even when the switch accepted the update.
  • A southbound acknowledgement is not service proof.
iotclass.org

Major section

State Freshness Breaks Automation (continued)

A sound design names which state can be stale, which state blocks writes, and which external proof closes the loop.

  • A standby controller should not replay old intent against a newer switch table, and a primary controller should not assume every acknowledged OpenFlow message reached every device in the same order.
  • The practical risk in state freshness breaks automation needs a diagram. The linked figure in Part 1 summarizes it: Different controller records need different ownership and freshness rules before automation can be trusted.
  • Sampled state marks a different decision point, while Check: did it work? Prevents an early stop in state freshness breaks automation.
iotclass.org

Major section

State Freshness Breaks Automation (continued)

Two controller paths must not make incompatible decisions for the same scope without a defined owner and conflict rule.

  • Topology, device capability, active rules, and controller role need age or version checks before risky rule changes.
  • Switches and gateways must have safe behavior when controller contact is degraded or a rule update is rejected.
  • Receiver logs, protected traffic, application acknowledgements, and operations records close the loop beyond switch acceptance.
iotclass.org

Deck summary

Key takeaways

Known sensor paths need rules, the instructions that direct traffic, before traffic starts.

  • IoT deployments add physical, gateway, and local-control constraints that a controller design must respect.
  • The controller's internal decision record is necessary, but not sufficient.
  • In a course project, that means the controller diagram should name one real decision path, not just boxes for applications, control logic, and switches.
  • Controller automation fails when it treats all state as equally trustworthy.
iotclass.org

Retrieval practice

Recall check 1 of 5

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

Q1Routine pump telemetry must keep flowing when the controller is unreachable; unknown debug traffic may wait for a policy decision. Which rule plan and test fit?

APreinstall routine flow, react to debug exceptions, cut controller and verify receiver.
BAsk controller to install routine rules only after first packet when it may be offline.
CPreinstall broad debug allows because temporary diagnostic traffic needs a route before the policy review.
DChoose a hybrid label but inspect switch ACKs rather than telemetry delivery.
Show answer

Answer: A Stable traffic stays local, while exceptions use controller review and the receiver proves the fallback.

iotclass.org

Retrieval practice

Recall check 2 of 5

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

Q2A controller receives a request to restrict maintenance traffic from one IoT gateway while preserving door-access alerts. Which decision path is strongest?

AInstall a broad block for the gateway because security events should override all maintenance and alert traffic.
BValidate scope, protected paths, scoped rules, receiver proof, and rollback.
CLet the security app write switch rules directly because it already knows which gateway looks suspicious.
DWait for traffic counters to prove the problem, then decide whether topology checks are needed.
Show answer

Answer: B A controller decision is trustworthy when request, state, policy, rule result, switch proof, receiver outcome, and rollback condition are connected.

iotclass.org

Retrieval practice

Recall check 3 of 5

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

Q3A controller architecture diagram lists topology, policy, rule, telemetry, and device services. What added record best makes the design operationally reviewable?

AA note that the controller has a global view, so individual service records are unnecessary after installation.
BA list of switch models, because controller architecture depends mainly on forwarding hardware.
CRecord intent, state version, owner, computed rule, device ack, proof, and rollback.
DA dashboard screenshot after one rule update appears in the controller UI and looks healthy.
Show answer

Answer: C Controller architecture needs records that connect service intent, state, policy, rule installation, receiver proof, and rollback.

iotclass.org

Retrieval practice

Recall check 4 of 5

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

Q4A controller plans a gateway isolation rule from an old topology view after a link move. What pass gate should stop the write?

ARequire fresh topology and recent protected-path proof before writing the rule.
BInstall from the old global view because its topology remains valid after the link path changes.
CTrust a switch ACK on the former path instead of current receivers.
DTurn off topology checks to make controller writes faster.
Show answer

Answer: A Stale topology can steer or cut traffic; current path evidence must pass first.

iotclass.org

Retrieval practice

Recall check 5 of 5

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

Q5Two controller applications can update rules for the same gateway: one isolates suspicious traffic and one preserves maintenance access. Which architecture control prevents conflicting automation?

ALet whichever application sends the rule last win because the controller has the latest observed state.
BDisable telemetry collection so controller state cannot disagree with switch counters or receiver logs.
CForward all packets through the controller until operators decide which application owns the gateway.
DDefine owner, conflict rule, idempotency, freshness gate, rollback, and proof.
Show answer

Answer: D Controller automation needs explicit ownership, conflict handling, freshness gates, rollback, and receiver proof when multiple paths can affect the same forwarding scope.

iotclass.org

Print reference

Answers 1 of 2

Answer key.

  1. A · Stable traffic stays local, while exceptions use controller review and the receiver proves the fallback.
  2. B · A controller decision is trustworthy when request, state, policy, rule result, switch proof, receiver outcome, and rollback condition are connected.
  3. C · Controller architecture needs records that connect service intent, state, policy, rule installation, receiver proof, and rollback.
  4. A · Stale topology can steer or cut traffic; current path evidence must pass first.
iotclass.org

Print reference

Answers 2 of 2

Answer key.

  1. D · Controller automation needs explicit ownership, conflict handling, freshness gates, rollback, and receiver proof when multiple paths can affect the same forwarding scope.
iotclass.org