130  SDN Three-Layer Architecture

In 60 Seconds

The three-layer SDN architecture separates applications (top), control logic (middle), and forwarding hardware (bottom), connected by northbound REST APIs and southbound OpenFlow. Controller design choices – centralized (simple, single point of failure) vs distributed (resilient, complex consensus) – directly determine IoT network reliability and scale limits.

130.1 Learning Objectives

By the end of this chapter, you will be able to:

• Describe the Three-Layer SDN Architecture: Explain the application, control, and infrastructure layers and justify how their separation enables network programmability
• Analyze SDN Controller Design: Identify controller components including topology manager, routing engine, and statistics collector and explain their interactions
• Evaluate Controller Architectures: Compare centralized, distributed, and hierarchical controller deployments and recommend appropriate choices for given scale requirements
• Apply SDN Layers to IoT: Map specific IoT network requirements to SDN architectural components with quantified performance tradeoffs

MVU: Minimum Viable Understanding

Core concept: SDN uses a three-layer architecture: Application layer (network apps using APIs), Control layer (SDN controller with global view), and Infrastructure layer (OpenFlow switches forwarding packets). Why it matters: This separation enables network programmability - applications request network behavior through APIs rather than configuring individual devices. Key takeaway: The controller is the “brain” of SDN, but it doesn’t forward packets - it programs switches with flow rules that enable wire-speed forwarding in hardware.

For Beginners: SDN Three-Layer Architecture

Software-Defined Networking (SDN) separates the brain of a network (the control plane) from the muscles (the data plane). Think of a traffic management center: instead of each traffic light making its own decisions, a central system monitors all intersections and coordinates them for optimal flow. SDN brings this same centralized intelligence to IoT networks.

130.2 Prerequisites

• SDN Core Concepts: Understanding of control/data plane separation and traditional network limitations

---

130.3 SDN Architecture Overview

⏱️ ~15 min | ⭐⭐ Intermediate | 📋 P04.C28.U03

SDN Architecture

Figure 130.1: SDN three-layer architecture: application, control, and infrastructure planes

SDN introduces three-layer architecture with clean separation of concerns:

Figure 130.2: SDN Three-Layer Architecture: Application, Control, and Infrastructure

Figure 130.3: Alternative view: Physical deployment showing how SDN components are distributed across cloud (controllers, apps), edge (gateway, core switches), and access layers (switches, IoT devices). This highlights geographic/network placement and high availability through controller redundancy.

Figure 130.4: Alternative view: Sequence diagram showing the packet flow through SDN architecture. First packet of unknown flow triggers PACKET_IN to controller, which installs flow rules. Subsequent packets match installed rules and forward at line rate without controller involvement. This clarifies the reactive flow installation process.

---

130.4 Application Layer

Purpose: Network applications that define desired network behavior.

Applications:

• Traffic Engineering: Optimize paths based on network conditions
• Security: Firewall, IDS/IPS, DDoS mitigation
• Load Balancing: Distribute traffic across servers
• Network Monitoring: Real-time traffic analysis
• QoS Management: Prioritize critical IoT traffic

Interface: Northbound APIs (REST, JSON-RPC, gRPC)

---

130.5 Control Layer (SDN Controller)

Purpose: Brain of the network—maintains global view and makes routing decisions.

Tradeoff: Centralized vs Distributed SDN Controller

Option A: Centralized Controller - Single controller instance manages entire network with complete global view. Simpler architecture but creates single point of failure.

Option B: Distributed Controller Cluster - Multiple controller instances share state and load. Higher availability but increased complexity and synchronization overhead.

Decision Factors:

• Choose Centralized when: Network has fewer than 500 switches, latency requirements are relaxed (>10ms acceptable), budget constraints limit infrastructure, or simplicity is prioritized over availability. Typical failover time: 30-60 seconds with warm standby.

• Choose Distributed when: Network exceeds 1,000 switches, five-nines availability (99.999%) is required, geographic distribution spans multiple sites, or control plane latency must stay under 5ms. Typical failover time: 2-5 seconds with active-active clustering.

• Cost comparison: Centralized (2 VMs for primary/backup) costs ~$200/month. Distributed 3-node cluster (ONOS, OpenDaylight) costs ~$600/month but handles 10x more switches and provides sub-second failover. At 10,000+ devices, distributed becomes mandatory regardless of cost.

SDN Controller Architecture

Figure 130.5: SDN controller internal architecture with core modules for network intelligence

Responsibilities:

• Compute forwarding paths
• Install flow rules in switches
• Handle switch events (new flows, link failures)
• Provide network state to applications
• Maintain network topology

Putting Numbers to It

Consider an SDN controller managing 100 switches with an average of 50 flows per switch = 5,000 total flows. Each flow table entry requires periodic statistics polling. If the controller queries every flow every 5 seconds, the query rate is:

\[\text{Query Rate} = \frac{5000 \text{ flows}}{5 \text{ seconds}} = 1000 \text{ queries/second}\]

If each STATS_REQUEST/REPLY exchange takes 2ms round-trip latency:

\[\text{Controller CPU Time} = 1000 \times 0.002 = 2 \text{ seconds/second} = 200\% \text{ CPU}\]

This exceeds single-core capacity! Real controllers batch queries (query all flows on Switch 1, then Switch 2…) reducing overhead by 100x. With batching: \(\frac{100 \text{ switches}}{5 \text{ seconds}} = 20 \text{ batch requests/second} \times 0.002 = 0.04 \text{ seconds} = 4\%\) CPU – sustainable.

SDN Control Plane

Figure 130.6: SDN control plane showing controller-switch communication via OpenFlow

Popular Controllers:

• OpenDaylight: Java-based, modular, widely adopted
• ONOS: High availability, scalability for carriers
• Ryu: Python-based, easy development
• POX/NOX: Educational, Python/C++
• Floodlight: Java, fast performance

130.5.1 Controller Polling Rate Calculator

Estimate the monitoring overhead for your SDN deployment:

viewof numSwitchesCtrl = Inputs.range([10, 500], {value: 100, step: 10, label: "Number of switches"})

viewof flowsPerSwitch = Inputs.range([10, 2000], {value: 50, step: 10, label: "Flows per switch"})

viewof pollIntervalSec = Inputs.range([1, 60], {value: 5, step: 1, label: "Poll interval (seconds)"})

totalFlowsCtrl = numSwitchesCtrl * flowsPerSwitch
perFlowQueryRate = totalFlowsCtrl / pollIntervalSec
batchQueryRate = numSwitchesCtrl / pollIntervalSec
perFlowCpu = perFlowQueryRate * 0.002
batchCpu = batchQueryRate * 0.002

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; margin-top: 0.5rem;">
<p><strong>Total flows:</strong> ${totalFlowsCtrl.toLocaleString()}</p>
<p><strong>Per-flow polling:</strong> ${perFlowQueryRate.toFixed(0)} queries/sec (${(perFlowCpu * 100).toFixed(1)}% CPU ${perFlowCpu > 1 ? "-- EXCEEDS single-core capacity!" : "-- OK"})</p>
<p><strong>Batched polling:</strong> ${batchQueryRate.toFixed(1)} batch requests/sec (${(batchCpu * 100).toFixed(1)}% CPU -- ${batchCpu < 0.5 ? "sustainable" : "high load"})</p>
<p><strong>Batching speedup:</strong> ${(perFlowQueryRate / batchQueryRate).toFixed(0)}x reduction in controller overhead</p>
</div>`

---

Quick Check: Controller Architecture Tradeoff

130.6 Data/Infrastructure Layer

Purpose: Packet forwarding based on flow rules installed by controller.

SDN Data Plane Architecture

Figure 130.7: SDN data plane with OpenFlow switches and flow table pipeline

Components:

• OpenFlow Switches: Hardware or software switches
• Flow Tables: Store forwarding rules (match-action)
• Secure Channel: Connection to controller (TLS)

OpenFlow Switch Internals

Figure 130.8: OpenFlow switch architecture with flow table pipeline processing

Flow Processing:

1. Packet arrives at switch
2. Match against flow table
3. If match: execute action (forward, drop, modify)
4. If no match: send to controller (PACKET_IN)

Putting Numbers to It

Flow table lookups use TCAM (Ternary Content-Addressable Memory) hardware for parallel matching at wire speed. A 10 Gbps switch forwarding minimum-size packets:

\[\text{Packet Rate} = \frac{10 \times 10^9 \text{ bits/sec}}{(64 \text{ bytes} + 20 \text{ preamble/IFG}) \times 8 \text{ bits/byte}} = 14.88 \text{ million packets/sec}\]

Each packet requires one TCAM lookup. Modern TCAM completes lookups in ~10 nanoseconds:

\[\text{Lookup Capacity} = \frac{1}{10 \times 10^{-9}} = 100 \text{ million lookups/sec}\]

This exceeds required 14.88M lookups/sec by 6.7×, providing headroom for multi-table pipelines (OpenFlow 1.3+ supports 255 tables per switch). However, TCAM is expensive: $1 per entry vs $0.01 for DRAM. A switch with 4,000 TCAM entries costs ~$4,000 just for flow table memory.

Tradeoff: Proactive vs Reactive Flow Installation

Option A: Proactive Flow Installation - Controller pre-installs flow rules for all expected traffic patterns before packets arrive. First packet forwarded immediately at line rate.

Option B: Reactive Flow Installation - Controller installs flow rules only when first packet of new flow triggers PACKET_IN. Flexible but adds latency for first packet.

Decision Factors:

• Choose Proactive when: Traffic patterns are predictable (IoT sensors with known destinations), first-packet latency is critical (<1ms required), controller resources are limited, or network operates in environments where controller connectivity may be intermittent.

• Choose Reactive when: Traffic patterns are dynamic and unpredictable, flow table memory is constrained (reactive uses space only for active flows), fine-grained per-flow policies are needed, or network topology changes frequently requiring adaptive routing.

• Latency comparison: Proactive achieves ~50 microseconds (hardware forwarding only). Reactive adds 5-50ms for first packet (controller round-trip) but subsequent packets match installed rule at line rate. For IoT sensor networks with 1000+ devices sending periodic telemetry, proactive saves 5-50ms × 1000 = 5-50 seconds of cumulative delay per reporting interval.

---

130.7 Knowledge Check

Test your understanding of SDN architecture concepts.

Quiz: SDN Architecture

---

130.8 Cost-Benefit Analysis: SDN vs Traditional Networking for IoT

Deploying SDN requires upfront investment in controllers and OpenFlow-capable switches. The payback depends on network scale and operational complexity.

Cost Factor	Traditional (500 devices)	SDN (500 devices)
Switch hardware	$75K (legacy L2/L3)	$90K (OpenFlow-capable)
Controller software	N/A	$15K (ONOS open-source + server)
Network engineer FTEs	2.5 FTE ($250K/year)	1.5 FTE ($150K/year)
Change management time	4-8 hours per policy change	5-15 minutes per policy change
Mean time to repair	2-4 hours (manual diagnosis)	15-45 minutes (automated root cause)
Annual unplanned downtime	8-12 hours	2-4 hours
3-year TCO	$855K	$555K

Break-even point: SDN pays for itself at approximately 200 managed devices. Below that threshold, the controller overhead and learning curve exceed operational savings. Above 1,000 devices, SDN becomes essential because manual configuration of individual switches becomes the bottleneck for any network change.

Why Google, Facebook, and Microsoft chose SDN: These hyperscalers found that at data center scale (100,000+ switches), the cost of running distributed routing protocols on every switch exceeded the cost of centralized SDN controllers by 3-5x. Google’s B4 WAN saved an estimated $10M annually by deferring capacity expansion through better link utilization alone.

130.9 Worked Example: SDN Migration for a University IoT Campus Network

Scenario: A university manages a campus network connecting 3,200 IoT devices (environmental sensors, smart lighting, access controls, digital signage) across 15 buildings. The current traditional network uses 48 managed switches configured individually via CLI. Each policy change (e.g., adding a new VLAN for a research lab’s sensors) requires 2 network engineers and takes 4-6 hours to propagate across all switches. The university experiences 3-4 policy changes per week and averages 14 hours of unplanned downtime per year from misconfigured switches.

Step 1: Quantify current pain points

Problem	Frequency	Cost
Policy change labor	3.5 changes/week x 5 hours x $75/hr x 2 engineers	$136,500/year
Unplanned downtime	14 hours/year x $2,800/hr (productivity loss)	$39,200/year
Troubleshooting (no global view)	8 hours/week x $75/hr	$31,200/year
Total operational cost		$206,900/year

Step 2: Design the SDN architecture

• Controller: ONOS cluster (3-node active-active) on existing VMware infrastructure – $0 license cost (open source), 3 VMs at $150/month = $5,400/year
• Switches: Replace 48 legacy switches with 48 OpenFlow-capable switches. Hardware cost: $1,800/switch x 48 = $86,400 (one-time). Note: OpenFlow switches cost ~20% more than equivalent legacy switches, but the premium buys programmability
• Migration: Phased rollout over 6 months, one building at a time. Professional services: $45,000

Step 3: Calculate SDN operational costs

Task	SDN Approach	Time/Cost
Policy changes	Single API call propagated by controller	5-15 min, 1 engineer = $27,300/year (80% reduction)
Unplanned downtime	Controller detects and reroutes in seconds	3 hours/year = $8,400/year (79% reduction)
Troubleshooting	Controller provides global topology view	2 hours/week = $7,800/year (75% reduction)
Controller maintenance	Firmware updates, monitoring	$12,000/year
Total SDN operational cost		$55,500/year

Step 4: ROI calculation

• Annual savings: $206,900 - $55,500 = $151,400/year
• One-time investment: $86,400 (switches) + $45,000 (migration) + $5,400 (first year VMs) = $136,800
• Payback period: 10.8 months
• 3-year net savings: $136,800 investment vs $454,200 savings = $317,400 net benefit

Step 5: IoT-specific SDN value

Beyond cost savings, SDN enables IoT capabilities impossible with traditional networking:

• Dynamic QoS: During fire alarm events, the controller automatically deprioritizes digital signage traffic and allocates 90% of bandwidth to emergency sensor data and access control systems – a policy change that would take 4 hours manually but executes in 200ms via SDN
• Micro-segmentation: Each sensor type (temperature, access control, cameras) runs on an isolated virtual network. A compromised smart light cannot reach access control systems. Adding a new sensor type requires one API call, not 48 switch configurations
• Automated quarantine: When the intrusion detection application detects anomalous traffic from a compromised IoT device, it instructs the controller to isolate that device’s port in under 1 second – vs 15-30 minutes for manual CLI intervention

Match the SDN Component to Its Function

Order the SDN Three-Layer Processing Sequence

Key Concepts

• SDN (Software-Defined Networking): An architectural approach separating the network control plane (routing decisions) from the data plane (packet forwarding), centralizing control in a software controller for programmable network management
• Control Plane: The network intelligence layer making routing and forwarding decisions, centralized in an SDN controller rather than distributed across individual switches as in traditional networking
• Data Plane: The network forwarding layer physically moving packets based on rules installed by the control plane — in SDN, this is the switch hardware executing OpenFlow flow table entries
• OpenFlow: The foundational SDN protocol enabling communication between an SDN controller and network switches, allowing the controller to install, modify, and delete flow table entries that govern packet forwarding
• SDN Controller: The centralized network operating system providing a global view of the network topology and programming switch forwarding behavior through southbound APIs (OpenFlow) and exposing northbound APIs to applications
• Flow Table: A data structure in an SDN switch containing match-action rules: each entry matches packet headers (source IP, destination MAC, port number) and specifies forwarding action (forward, drop, modify, send-to-controller)
• Southbound API: The interface between an SDN controller and the data plane switches — OpenFlow is the dominant southbound API, though NETCONF, OVSDB, and P4Runtime are also used

Common Pitfalls

1. Misunderstanding Reactive vs Proactive Flow Installation

Deploying reactive SDN (packet-in for every unknown flow) for IoT where new device connections are frequent. Each new IoT device triggers a controller round-trip (10–100 ms) before any packets are forwarded. Use proactive flow installation for predictable IoT communication patterns.

2. Not Separating Physical and Logical Topology

Conflating the physical switch topology (cables between switches) with the logical topology (flow-level overlay paths). SDN can create logical paths that do not follow physical shortest paths — monitoring must track both to diagnose performance issues correctly.

3. Ignoring Failure Modes at Each Architectural Layer

Designing the SDN architecture without analyzing failure at each layer: controller crash (flow tables freeze), controller-switch link loss (split-brain), switch failure (route re-convergence). Each layer has distinct failure signatures requiring different monitoring and recovery strategies.

4. Not Planning for OpenFlow Version Migration

Deploying an OpenFlow 1.3 architecture without considering that future features (group tables, metering, port descriptions) require OpenFlow 1.5 support from switches. Verify switch firmware upgrade paths support target OpenFlow versions before committing to a switch hardware platform.

Label the Diagram

💻 Code Challenge

130.10 Summary

This chapter explored the SDN three-layer architecture:

• Application Layer: Network applications (traffic engineering, security, load balancing) using northbound APIs (REST, gRPC) to request network behavior
• Control Layer: SDN controller as the network “brain” with topology manager, routing engine, and statistics collector - providing global network view and installing flow rules
• Infrastructure Layer: OpenFlow switches executing flow rules in hardware at wire-speed, with flow tables storing match-action rules
• Controller Tradeoffs: Centralized (simple, single point of failure) vs distributed (scalable, complex synchronization) architectures
• Flow Installation: Proactive (pre-installed, low latency) vs reactive (on-demand, flexible) strategies

For Kids: Meet the Sensor Squad!

The SDN three-layer architecture is like a restaurant with a head chef, kitchen managers, and cooks!

130.10.1 The Sensor Squad Adventure: The Three-Layer Kitchen

The Sensor Squad decided to build the most organized network ever, and they modeled it after their favorite restaurant!

Top Floor – The Menu (Application Layer): “This is where we decide WHAT the network should do,” explained Max the Microcontroller. “We have different apps like a traffic engineer that finds the best routes, a security guard that blocks bad messages, and a load balancer that spreads work evenly.” Just like a restaurant menu lists what customers can order!

Middle Floor – The Head Chef (Control Layer): Connie the Controller ran the kitchen. She knew where every ingredient was, what every cook was doing, and could change the plan instantly. “I’m the brain! I use a Topology Manager to know the network map, a Routing Engine to find paths, and a Statistics Collector to check how everything is running.”

Bottom Floor – The Cooks (Infrastructure Layer): “We are the OpenFlow switches!” said the switches. “We don’t make decisions – we just follow Connie’s recipes REALLY fast!” When a new dish (packet) came in, they checked the recipe book (flow table). If they found a match, they cooked it right away. If not, they called Connie: “PACKET_IN! New dish I don’t recognize!”

Sammy the Sensor loved the system: “Apps decide what, Connie decides how, and switches just do it – fast!”

130.10.2 Key Words for Kids

Word	What It Means
Three Layers	Apps (what to do), Controller (how to do it), Switches (do it fast!)
Northbound API	How apps talk to the controller (like ordering from a menu)
Southbound API	How the controller talks to switches (like a chef giving instructions to cooks)

Key Takeaway

The SDN three-layer architecture separates concerns: the Application Layer defines desired network behavior through northbound APIs, the Control Layer (SDN controller) maintains global network state and computes forwarding decisions, and the Infrastructure Layer (OpenFlow switches) executes packet forwarding at wire-speed. The critical design choice between centralized and distributed controllers determines your network’s reliability and scale limits.

130.11 What’s Next

If you want to…	Read this
Study OpenFlow core concepts	OpenFlow Core Concepts
Learn the OpenFlow protocol details	OpenFlow Protocol
Try the OpenFlow hands-on lab	OpenFlow Hands-On Lab
Explore SDN architecture fundamentals	SDN Architecture Fundamentals
Study SDN controller basics	SDN Controller Basics