Cloud, SDN & Production Architectures · Study deck

SDN Production Case Studies

Picture a factory network carrying safety alarms, camera files, and maintenance checks over the same narrow path.

Cloud Clara is your guide for this deck.

prodcasestudies

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

After studying this chapter

Learning objectives

You will be able to:

Compare production SDN case studies by problem pattern instead of copied deployment results.
Identify when traffic-engineering, service-slicing, or scheduled-forwarding patterns fit an IoT network.
Check baseline proof and post-change proof before accepting a case-study lesson.
Separate transferable architecture lessons from environment-specific implementation details.

SDN network slicing in Barcelona's smart-city network

Major section

Start With the Case Proof

A published case says central rule changes improved service, but the factory owner needs proof that local switches and staff can handle the same change and its failure modes.

A valid alarm must keep its protected route.
An unapproved path must stay closed.
Software-defined networking, or SDN, separates rule control from packet forwarding.

Major section

Start With the Case Proof (continued)

A result from another site is only a clue until local proof matches its conditions.

Under the Hood explains rule order, table limits, observation gaps, safe local behavior, and the races hidden by a simple before-and-after chart.
An SDN case study is useful only when it proves how a pattern behaves under local constraints.
Traffic engineering, slicing, and scheduled forwarding all sound promising until the gateway, controller, and receiver evidence are checked.

SDN baseline validation for case-study transfer

Major section

Minimum Viable Understanding · Case-Study Lenses

A case study is proof, not a recipe.

Its value depends on whether the operating conditions match your network.
Traffic engineering, service slicing, and scheduled forwarding identify the control pattern; baseline proof and operational guardrails test whether it is safe locally; the transfer decision records which assumptions survive the move into the target network.

Major section

Pattern 1: Traffic Engineering · Pattern 2: Service Slicing

A traffic-engineering case study starts with uneven path use or congestion risk across shared links.

Congestion counters and receiver outcomes must improve while protected traffic remains inside its boundary; the rollback record identifies the measurement that restores the old path choice.
The traffic-engineering diagram in @fig-sdn-prod-case-studies-traffic-engineering keeps protected traffic and rollback beside the optimized path.
That placement matters: lower congestion is not an acceptable result if the moved class violates a protected service boundary or if operators cannot restore the previous assignment.

Major section

Pattern 3: Scheduled Forwarding

A scheduled-forwarding case study starts with a control loop or industrial workflow that cannot tolerate unpredictable queuing.

Late packets take an exception path, while protected-service proof and the transfer decision determine whether the schedule is acceptable.
Transfer the lesson only if the timing requirement is real, documented, and supported by the switching environment.
The scheduled-forwarding diagram in @fig-sdn-prod-case-studies-scheduled-forwarding keeps the late-packet exception beside normal windows.
Reviewers should trace an on-time control packet and a late diagnostic packet separately, then use protected-service proof to show the schedule improves predictability without silently starving maintenance traffic.

Major section

Cross-Case Proof Comparison · Baseline Validation

A blank field is visible uncertainty; it cannot be hidden by a larger throughput or latency headline from a different environment.

Baseline proof: what was measured before SDN was introduced.
The most common case-study mistake is accepting a pattern before proving the local problem.
Policy delay is a separate observation.

Major section

Migration Risk Boundaries · Operations Handoff

Operations training and monitoring evidence support the acceptance decision; a stop trigger blocks expansion, while a written expansion rule makes broader rollout conditional on the pilot evidence rather than enthusiasm.

A stop trigger holds or reverses the pilot; only a satisfied expansion rule widens scope.
The hybrid boundary and rollback proof remain authoritative throughout both outcomes.
A case study is incomplete unless it shows who runs the system after launch.
Those links turn a technically successful pilot into work that an operations team can safely inherit.

Major section

Walkthrough: Choosing a Case Pattern · Case-Study Proof Loop

Baseline: gather pre-change proof for each pattern instead of assuming one case study solves every problem.

The local baseline selects or rejects the SDN pattern; pilot proof and the operations handoff constrain the transfer decision; and the next check feeds new evidence back into the baseline instead of treating acceptance as permanent.
In @fig-sdn-prod-case-studies-proof-loop, the external lesson is only the entry point.

Major section

Campus IoT OpenFlow Case

A campus wants central control over a mixed IoT network — cameras, badge readers, HVAC, and guest devices — so it deploys SDN: OpenFlow switches whose forwarding tables are programmed by a central controller.

The lesson transfers only when local proof supports the same pattern.
The catch is finite flow-table memory and a controller that becomes critical infrastructure.
For an overview reader, the key move is to translate the published story into a local acceptance question.

Use a production SDN case study as a decision route: connect context and consequence to evidence, architecture choice, review, record, and the next action before adopting the lesson.

Major section

Flow-Table TCAM Exhaustion

OpenFlow rules that match on wildcards and priorities live in TCAM — fast but expensive and physically small.

A typical hardware switch holds only a few thousand TCAM flow entries (often ~2,000–8,000, sometimes fewer).
That needs 5,000 TCAM entries — more than a 2,000-entry switch can hold.
That record also needs an owner.

Major section

Flow-Table TCAM Exhaustion (continued)

Worked example: Suppose the design installs one specific flow rule per device for fine-grained policy, and the campus has 5,000 IoT endpoints.

When TCAM fills, new rules either fail to install or spill to slow software forwarding, and traffic that should be line-rate now crawls or drops.
The practitioner lesson for case-study transfer is to record the scale assumption behind every rule.
A paper may describe per-flow steering, but a production pilot should ask how many rules each switch will hold in normal operation, during a failover, and while temporary diagnostic rules are active.

Major section

Reactive, Proactive, Available

In proactive mode, rules are pre-installed before traffic arrives — no per-flow latency and no packet-in flood, at the cost of less on-the-fly flexibility.

The second concern is that the controller is now critical infrastructure.
If forwarding depends on it and it fails, the network can stop; even where switches keep forwarding on installed rules, no new policy can be applied.
Meanwhile a standby controller takes over when the primary is patched.

Major section

Reactive, Proactive, Available (continued)

So production designs run the controller in a high-availability cluster with failover, and often keep switches able to forward existing flows through a brief controller outage.

The convenience of central control is paid for with the discipline of central-control resilience.
Switching that subnet to proactive rules (traffic pre-authorised by class) removes the packet-in path, and rate-limiting packet-ins protects the controller elsewhere.
A deeper case-study review should ask which fail-open or fail-closed behavior is being claimed.
Production IoT networks lean proactive precisely because IoT flows are predictable and the packet-in path is a denial-of-service surface.

Deck summary

Key takeaways

A published case says central rule changes improved service, but the factory owner needs proof that local switches and staff can handle the same change and its failure modes.

A result from another site is only a clue until local proof matches its conditions.
A case study is proof, not a recipe.
A traffic-engineering case study starts with uneven path use or congestion risk across shared links.
A scheduled-forwarding case study starts with a control loop or industrial workflow that cannot tolerate unpredictable queuing.

Retrieval practice

Recall check 1 of 5

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

Q1A team wants to reuse a published SDN traffic-engineering case study for a mixed IoT network with shared uplinks, safety alarms, diagnostics, and a small control zone. What should the transfer check compare first?

ACompare local baseline, SDN pattern, path guards, switch and receiver proof, rollback, and owners.

BCopy a published policy because its headline link metric proves local safety.

CApply one engineering pattern to alarms, diagnostics, and control without risk separation.

DAssign alert, rollback, and cleanup owners only after a better pilot counter.

Show answer

Answer: A SDN production case studies transfer as proof patterns: local baseline, matching problem shape, SDN control pattern, guardrails, receiver outcome, rollback, and operations handoff must all be checked before the case becomes a local design argument.

Retrieval practice

Recall check 2 of 5

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

Q2A team wants to copy a traffic-engineering SDN case study because the published result sounds impressive. What should they verify first?

AVerify local path pressure, transferable assumptions, guardrails, and a bounded pilot.

BCopy published controller design immediately because case studies are already proven.

CCheck switch support only, then assume the reported utilization gain transfers.

DChoose the largest headline metric and reuse topology and rules unchanged.

Show answer

Answer: A A case-study lesson transfers only when the local baseline, assumptions, guardrails, pilot result, and operations handoff support the same pattern.

Retrieval practice

Recall check 3 of 5

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

Q3What does SDN separate, and how does OpenFlow fit in?

ASDN separates control from switch forwarding; OpenFlow programs switch rules.

BSDN separates cables from wireless, requiring every IoT device to be rewired.

CSDN merges controller and switch into one inseparable network device.

DSDN removes forwarding tables, leaving switches without packet rules.

Show answer

Answer: A The controller decides policy; OpenFlow installs the forwarding rules into the switches.

Retrieval practice

Recall check 4 of 5

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

Q45,000 IoT devices each get a specific OpenFlow rule, but the switch has ~2,000 TCAM entries. What happens, and what fixes it?

ATCAM overflows; aggregate rules by subnet or class instead of per-device entries.

BSwitch TCAM automatically grows by requesting memory from the controller.

CNothing happens because OpenFlow switch flow tables are unlimited.

DController stores extra rules so the switch never needs entries.

Show answer

Answer: A TCAM is small, so match on shared attributes rather than per-device to stay within capacity.

Retrieval practice

Recall check 5 of 5

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

Q5Why do production IoT SDN deployments favour proactive flow installation over reactive?

ABecause reactive packet-in adds lag and DoS load; proactive rules avoid both.

BBecause proactive installation removes controller need permanently.

CBecause reactive control cannot forward any packet at all.

DBecause proactive control requires no switch flow tables.

Show answer

Answer: A Predictable IoT flows suit proactive rules, sparing the controller the packet-in flood.

Print reference

Answers 1 of 2

Answer key.

A · SDN production case studies transfer as proof patterns: local baseline, matching problem shape, SDN control pattern, guardrails, receiver outcome, rollback, and operations handoff must all be checked before the case becomes a local design argument.
A · A case-study lesson transfers only when the local baseline, assumptions, guardrails, pilot result, and operations handoff support the same pattern.
A · The controller decides policy; OpenFlow installs the forwarding rules into the switches.

Print reference

Answers 2 of 2

Answer key.

A · TCAM is small, so match on shared attributes rather than per-device to stay within capacity.
A · Predictable IoT flows suit proactive rules, sparing the controller the packet-in flood.