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.
- That structure supports controller architecture decision route: SDN controller architecture decision route.
- 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.
- At responsibilities and boundaries, Applications makes the architecture testable.
- They should not need direct switch-rule access.
- The controller validates requests, combines state, computes rule changes, resolves conflicts, and records decisions.
Major section
Responsibilities and Boundaries (continued)
They need safe defaults for times when the controller is unavailable.
- 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.
Major section
Core Controller Services
A controller implementation may use different names, but most designs need the same service responsibilities.
- Together they explain the stale state and controller loss need safe device defaults figure claim: SDN controller decision loop from application intent through observed state and policy to scoped rule installation and evidence.
- Other services depend on its freshness and failure handling.
Major section
Core Controller Services (continued)
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.
- Owns state freshness, leader or owner selection, shared records, replay protection, and failover behavior.
- A diagram that lists services but does not show state ownership still leaves important architecture risk hidden.
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.
- That observation connects this visual to the chapter's running narrative: use it to justify the next design decision and to record what evidence would confirm it in operation.
- Reactive design should be bounded by scope, rate, and fallback behavior.
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.
- They need safe defaults for times when the controller is unavailable.
Retrieval practice
Recall check
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.
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.