Cloud, SDN & Production Architectures · Study deck
SDN Controllers: Architecture Foundations
The controller must read current state, choose a rule, install it, and show that the service still works.
Cloud Clara is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Map the major services inside an SDN controller and explain what each service owns.
- Trace a packet event or application request through validation, policy checks, rule computation, southbound installation, and proof collection.
- Distinguish state that needs strong coordination from state that can be sampled, stale, local, or externally verified.
- Compare proactive, reactive, and hybrid rule installation without relying on unsupported latency promises.
Major section
Start With the Controller Job
The controller must read current state, choose a rule, install it, and show that the service still works.
- Telemetry means status and measurements reported by network parts.
- Latency means the time from the request to the result that matters.
- An accepted request is not proof of useful forwarding.
- Request one allowed change and one forbidden change.
Major section
Start With the Controller Job (continued)
Central coordination can improve the network, but it should not erase the device's failure boundary.
- This opening does not choose one controller layout or promise instant change.
- Staff should see the rule state, service result, owner, and safe fallback without guessing.
- An SDN controller is not just a dashboard.
Major section
Controller Architecture Decision Route
At controller architecture decision route, Service intent makes the architecture testable.
- The rule result then names matches, actions, timeouts, and affected devices; installation can be accepted, rejected, partial, or degraded.
- A topology change or missing proof reopens review, since a controller decision is only as current as the state and outcome it can show.
- Close the route by comparing controller records with switch counters, receiver behaviour, alert state, and rollback proof; that final comparison reconnects the controller decision to the service intent that opened the route.
Major section
Responsibilities and Boundaries
The controller sits between applications and forwarding devices.
- It should not erase the boundary between them.
- The controller validates those requests, combines state, resolves conflicts, computes changes, and records its decision.
- Switches and gateways then enforce installed behaviour locally, including a safe default when the controller is absent.
- A controller decision is not proof that the service outcome occurred.
Major section
Responsibilities and Boundaries (continued)
Operations closes the path by asking who requested the change, what was installed, where it landed, what result appeared, and whether rollback was tested.
- They should not need direct switch-rule access.
- The controller validates requests, combines state, computes rule changes, resolves conflicts, and records decisions.
- They need safe defaults for times when the controller is unavailable.
Major section
Responsibilities and Boundaries (continued)
Operations needs proof: who asked, what changed, where it was installed, what worked, and how rollback was tested.
- The controller should coordinate network behavior, not forward routine packets through software.
- Routine traffic should stay in the data plane after rules are installed.
- Controller involvement should be deliberate, observable, and bounded.
Major section
Core Controller Services
A controller implementation may use different names, but most designs need the same service responsibilities.
- Other services depend on its freshness and failure handling.
- Tracks device sessions, capabilities, switch roles, ports, supported actions, and connection changes.
- Translates approved decisions into match-action rules, priorities, timeouts, counters, and install or remove actions.
Major section
State Model and Ownership
Controller state does not all need the same consistency model.
- Policy ownership, conflicting writes, active rule records, rollback gates, and controller role decisions need clear ownership.
- Topology and device capability records can change.
- A controller should know when this state is stale before computing new rules.
Major section
State Model and Ownership (continued)
Telemetry counters and trends can often be delayed or approximate, as long as decisions account for that delay.
- Switch tables, buffers, port state, cached rules, and fallback behavior must be verified at the device, not assumed from the controller.
- Receiver health, application acknowledgement, gateway logs, incident records, and operator approval prove the service outcome.
- The most important decision question is: "Could two controller paths make conflicting decisions for the same scope?" If yes, define a decision owner, idempotency rule, and conflict resolution path before trusting automation.
Major section
Message Flow: Packet Event to Rule
Reactive events are useful when the controller must decide about traffic it has not seen before.
- The switch sends an event or summary to the controller, which validates switch identity, ingress port, and state freshness before consulting topology and policy.
- Reactive design should be bounded by scope, rate, and fallback behavior.
- The rule manager computes changes for the current and affected devices, but each switch may accept, reject, partly apply, or defer them.
Major section
Message Flow: Packet Event to Rule (continued)
Because this reactive path adds delay and load, its scope, rate, and fallback behaviour must remain bounded.
- The controller record must combine its decision with switch responses, counter movement, receiver evidence, and rollback state.
- Unknown or suspicious traffic can be reactive.
- Known sensor-to-gateway paths, protected alerts, routine telemetry, and maintenance rollback paths usually need planned rules or local fallback.
Deck summary
Key takeaways
The controller must read current state, choose a rule, install it, and show that the service still works.
- Central coordination can improve the network, but it should not erase the device's failure boundary.
- At controller architecture decision route, Service intent makes the architecture testable.
- The controller sits between applications and forwarding devices.
- Operations closes the path by asking who requested the change, what was installed, where it landed, what result appeared, and whether rollback was tested.
Retrieval practice
Recall check 1 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q1A topology update triggers an SDN rule change. What should happen before rule computation?
Show answer
Answer: C The route first evaluates the request against a fresh and scoped controller view.
Q2An SDN controller becomes unavailable. What should forwarding devices have prepared?
Show answer
Answer: B The device boundary includes local enforcement and safe defaults.
Retrieval practice
Recall check 2 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q3An SDN controller manages rule ownership while switches report changing link counters. Which state needs stronger coordination?
Show answer
Answer: B Conflicting rule owners can change forwarding behavior.
Retrieval practice
Recall check 3 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q4An SDN switch carries protected alerts and sometimes sees unfamiliar traffic. Which rule plan is defensible?
Show answer
Answer: A Planned rules protect known traffic while bounded reaction handles uncertainty.
Print reference
Answers
Answer key.
- C · The route first evaluates the request against a fresh and scoped controller view.
- B · The device boundary includes local enforcement and safe defaults.
- B · Conflicting rule owners can change forwarding behavior.
- A · Planned rules protect known traffic while bounded reaction handles uncertainty.