Cloud, SDN & Production Architectures · Study deck

SDN Architecture Fundamentals

Imagine a new camera sends a packet and the network must decide where that packet may go.

Cloud Clara is your guide for this deck.

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

After studying this chapter

Learning objectives

You will be able to:

Separate SDN application intent, controller decision-making, and data-plane forwarding as distinct architectural responsibilities
Explain why SDN's value is coordinated, auditable policy rather than routing every packet through the controller
Build a rule and interface review record spanning northbound, controller, southbound, and operations boundaries
Choose proactive, reactive, hybrid, or fallback rule placement for a given traffic class

Major section

A Clear First Route · Start With One Forwarding Decision

The team must separate the rule choice from the act of moving the packet.

This page starts with one job.
Last, choose allow, block, steer, rate-limit, or inspect the flow.
A central controller can set intent.
This first route is a guide to the main choice.

Major section

SDN Policy vs Packet Forwarding

Software-defined networking is an architecture pattern for coordinating network behavior.

Applications express intent, a controller translates that intent into network state, and forwarding devices apply local match-action rules to packets.
The value is not that every packet passes through a controller.
That separation is the practical SDN claim.

An SDN review follows service intent all the way to packet behavior and evidence.

Major section

SDN Policy vs Packet Forwarding (continued)

The data plane then forwards or drops packets locally; ordinary packets do not wait for the controller.

The value is that policy can be coordinated, reviewed, changed, and measured from a clear control point.
When a switch is attacked, overloaded, or misconfigured, the network may need an alternate path, a policy change, or a service-chain decision that local routing alone cannot review globally.
Operations must preserve evidence at both APIs and at the receiving service.

Major section

SDN Policy vs Packet Forwarding (continued)

For IoT, SDN is useful when gateways, sites, device classes, or service traffic need coordinated isolation, quality treatment, telemetry, or rollback.

The controller translates that request into concrete match-action rules, checks conflicts with safety and operations policies, and records the selected switches, priorities, and timeouts.
A quick way to test the claim is to ask what changes when a rule is wrong.
It should not depend on the controller for every ordinary packet.

Major section

SDN Policy vs Packet Forwarding (continued)

The route begins with Intent, but the learner should not accept that request as implemented policy until the application, controller, and switch stages all expose their own decision record.

For the warehouse example, that means recording that gw-17 is isolated while alarm traffic still reaches the broker, together with the rule owner, timeout, and rollback trigger.
Enterprise SDN Architecture separates orchestration and policy from: Clustered SDN Controllers, so application intent does not collapse into device-specific commands.
The arrows make the ownership split explicit: management names intent, the control plane resolves and checks it, and the data plane applies bounded match-action state.

Major section

Rule and Interface Review

A practical SDN design record should explain who is allowed to request a network change, what the controller is allowed to compute, how forwarding devices receive rules, and which evidence proves the receiver or service outcome.

Without that record, SDN automation becomes a fast way to distribute unreviewed policy.
Authorized request, intent record, scope limit, and rollback condition.

Interfaces are authority boundaries. Each one needs scope, ownership, and evidence.

Major section

Rule and Interface Review (continued)

A useful record is concrete enough for another operator to replay the decision.

For example, a greenhouse monitoring site might allow the maintenance application to quarantine one irrigation gateway, but not the LoRaWAN join server or the safety-alert topic.
The controller record names the topology snapshot, rule priority, match fields, timeout, and conflict checks.
The southbound record names the switch or gateway target and whether the rule was accepted.

Major section

Rule and Interface Review (continued)

That record makes the interface boundaries reviewable instead of merely automated.

The emulator result is still pre-deployment evidence: field switches, links, traffic, failover, and receiver outcomes must be verified again on the real network.
Unowned automation can change broad traffic classes without review.
Conflicting or stale rules remain installed without a clear owner.

Major section

Rule and Interface Review (continued)

The final review should join those records with MQTT delivery and switch counters so a successful API response cannot conceal a failed service outcome.

Installed rule state matches the intended action and affected switch set.
Controller intent differs from switch behavior or unsupported capabilities are assumed.
Receiver evidence, incident signal, rollback action, support owner, and review condition.

Major section

Rule and Interface Review (continued)

A successful rule install is treated as proof even when the service outcome is unknown.

The acknowledgement proves only that a device accepted state; counters and receiver results establish whether the intended packets matched and the protected traffic survived.
At owner, priority, timeout, decide when the rule expires or is revised, and retain the rollback path.
That full loop prevents a temporary quarantine from becoming an unowned permanent policy.

Major section

SDN Data Plane Resilience · Summary

Under the hood, SDN is a control loop.

The controller observes topology and policy state, decides what rules should exist, installs those rules, then relies on counters, events, and receiver evidence to determine whether the rule is still valid.
The rule itself is usually more specific than the architecture diagram suggests.
Degradation planning is equally technical.

Availability planning starts by deciding which behaviour stays local during controller or control-channel degradation.

Deck summary

Key takeaways

The team must separate the rule choice from the act of moving the packet.

Software-defined networking is an architecture pattern for coordinating network behavior.
The data plane then forwards or drops packets locally; ordinary packets do not wait for the controller.
For IoT, SDN is useful when gateways, sites, device classes, or service traffic need coordinated isolation, quality treatment, telemetry, or rollback.
The route begins with Intent, but the learner should not accept that request as implemented policy until the application, controller, and switch stages all expose their own decision record.

Retrieval practice

Recall check 1 of 3

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

Q1Which statement best describes a defensible SDN architecture claim?

AThe controller is valuable mainly because each packet waits for central inspection before the switch forwards it.

BApplications express scoped intent, controllers compute auditable rules, switches enforce locally, and operations verify outcomes.

CAny network with an administrator API qualifies because automation matters more than plane separation or evidence.

DSDN is defensible when the controller replaces local fallback, device autonomy, and wireless constraint planning.

Show answer

Answer: B A defensible SDN claim identifies who can request intent, which controller rule was produced, which switch behavior enforced it, what fallback applies, and what receiver or service evidence proves the result.

Retrieval practice

Recall check 2 of 3

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

Q2An IoT security workflow asks the network to isolate one gateway while preserving protected alert traffic. Which review action is strongest?

AInstall a broad block across all switches because isolation is safer than preserving topic, device, and alert scope.

BAccept the controller API success response as approval, then skip receiver checks because the rule exists.

CApprove a scoped request, compute conflict-checked rules, enforce them locally, then verify alerts and rollback.

DLet access switches choose isolation independently because the data plane sees the packets before the controller.

Show answer

Answer: C A practical SDN review traces an authorized request through controller decisions, switch enforcement, receiver evidence, and rollback.

Retrieval practice

Recall check 3 of 3

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

Q3Which evidence best proves that an SDN rule is safe to keep after deployment?

AThe controller log shows that it sent the rule once, so installation and receiver behavior are assumed.

BThe rule is broad enough to match many traffic classes, which reduces future policy maintenance work.

CThe rule has no timeout because permanent rules are easier for operators to remember during incidents.

DThe rule has owner, scope, timeout, switch counters, receiver outcomes, review condition, and rollback path.

Show answer

Answer: D Under-the-hood SDN evidence must connect owner, scope, installed state, counters, receiver behavior, stale-state review, and rollback.

Print reference

Answers

Answer key.

B · A defensible SDN claim identifies who can request intent, which controller rule was produced, which switch behavior enforced it, what fallback applies, and what receiver or service evidence proves the result.
C · A practical SDN review traces an authorized request through controller decisions, switch enforcement, receiver evidence, and rollback.
D · Under-the-hood SDN evidence must connect owner, scope, installed state, counters, receiver behavior, stale-state review, and rollback.