Software-defined networking (SDN) is a network architecture that separates control logic from packet forwarding. A logically centralised controller exposes the network to programmable applications.
- Control and data planes are decoupled.
- Applications express network policies through APIs.
- The controller maintains a network-wide view.
- Forwarding devices execute the rules installed by the controller.
Traditional Network Planes
A traditional network device combines 3 planes within the same device.
| Plane | Responsibility | Examples |
|---|---|---|
| Data plane | Forward packets using installed forwarding state. | Table lookups, packet switching, queueing. |
| Control plane | Compute forwarding decisions and install forwarding state. | OSPF, BGP, STP. |
| Management plane | Configure, monitor, and maintain the device. | CLI, SNMP, syslog. |
The control plane builds the routing information base (RIB). Selected routes populate the forwarding information base (FIB), which the data plane uses to forward packets.
Traditional routing distributes control across devices. Each device exchanges protocol messages with other devices and computes its own forwarding state.
- Distributed control supports resilience without a central controller.
- Network behaviour depends on the combined state of many devices.
- A routing protocol’s topology view does not provide a unified interface for all network policy and configuration.
Motivation for SDN
Vendor Dependence
Vertical integration bundles hardware, the operating system, and control software from a vendor.
- Vendor-specific interfaces restrict portability.
- New features depend on vendor release cycles.
- Hardware constraints can require equipment replacement.
- Deploying experimental control logic becomes difficult.
Network ossification is the difficulty of introducing changes into an established network architecture.
Per-Device Configuration
A network-wide policy often requires separate low-level changes on many devices.
- Vendor syntax differs across devices.
- Related changes must remain consistent.
- Testing, verification, and rollback become difficult.
- Manual configuration increases the opportunity for errors.
Examples:
- Keeping finance traffic off a guest uplink requires coordinated forwarding and access-control rules.
Traffic Engineering
Shortest-path routing selects paths according to configured link costs. The selected path may not satisfy utilisation, latency, price, or policy objectives.
- Congested links can coexist with underused alternatives.
- Network-wide optimisation requires topology and traffic information.
- Central control can select paths using both network state and policy.
Middlebox Management
Middleboxes perform functions beyond ordinary packet forwarding.
- Separate appliances require separate configuration and scaling.
- Traffic must traverse the required functions in the correct order.
- VLAN and routing configurations can make service paths difficult to verify.
Examples:
- Firewalls
- Load balancers
- Network address translators
- Intrusion detection and prevention systems
Cloud and Virtualisation
Virtualised workloads require network changes to follow workload changes.
- Virtual machine migration changes host locations.
- Tenants need isolated networks over shared infrastructure.
- Automated provisioning requires programmable network configuration.
SDN Architecture
The SDN architecture has 3 layers.
| Layer | Components | Responsibility |
|---|---|---|
| Application plane | Routing, security, load-balancing, and monitoring applications. | Express policy and desired network behaviour. |
| Control plane | SDN controller or network operating system. | Maintain network state and translate policy into device operations. |
| Data plane | Physical or virtual forwarding devices. | Process packets according to installed rules. |
Applications communicate with the controller through northbound interfaces. The controller communicates with forwarding devices through southbound interfaces.
The application plane in this model is distinct from the management plane of an individual device. Device configuration and monitoring remain necessary.
Northbound Interfaces
A northbound interface exposes controller services to network applications.
- Provides access to topology, statistics, events, and policy operations.
- Can use REST, gRPC, or native language APIs.
- The API depends on the controller platform.
Southbound Interfaces
A southbound interface connects the controller to network devices.
| Interface | Role |
|---|---|
| OpenFlow | Install and manage match-action forwarding rules. |
| P4Runtime | Control a data-plane pipeline described using P4. |
| NETCONF with YANG | Configure devices using structured data models. |
| gNMI | Exchange configuration and streaming telemetry. |
| OVSDB | Manage Open vSwitch configuration. |
| BGP-LS and PCEP | Export topology information and support controller-computed paths. |
East-West Interfaces
East-west interfaces support communication between controllers.
- Coordinate controller instances.
- Exchange information across administrative domains.
Logical Centralisation
Logical centralisation presents a unified network view to applications. Multiple physical controller instances can implement that view.
- Replicated state supports controller availability.
- Distributed instances support scale.
- Coordination keeps controller decisions consistent.
- A single physical controller introduces a failure point and capacity limit.
SDN Controller
An SDN controller provides shared network state and control services to applications.
- Discovery
Identifies devices and links. - Topology service
Represents the network as a graph. - Host tracking
Tracks host attachment points and movement. - Rule management
Installs forwarding rules and reconciles device state with desired state. - State storage
Stores topology, host, and policy information. - Event notification
Reports link failures, host movement, and traffic changes. - Protocol drivers
Translate controller operations into device-specific protocol messages.
A routing application can compute paths over the topology graph instead of configuring each device through its CLI.
Examples:
- NOX and POX
- Floodlight
- Ryu
- OpenDaylight
- ONOS
- Faucet
Network Programmability
Rules and Intents
Imperative control specifies the operations that devices should perform. Intent-based control specifies the desired network outcome.
| Approach | Example | Controller Responsibility |
|---|---|---|
| Imperative | Forward matching traffic through port 2. | Install the specified rule. |
| Intent-based | Connect 2 hosts within a specified latency bound. | Compute and install a path satisfying the requirement, when feasible. |
- Intent separates policy from device-level mechanisms.
- Topology changes can trigger recomputation of the implementation.
- Physical capacity and connectivity constrain which intents can be satisfied.
Traditional Networking and SDN
| Aspect | Traditional Networking | SDN |
|---|---|---|
| Control logic | Distributed across individual devices. | Logically centralised in a controller platform. |
| Policy configuration | Commonly expressed through per-device configuration. | Exposed through programmable interfaces. |
| Application view | Protocol-specific and device-specific state. | Shared network-wide state. |
| Feature changes | Often depend on vendor control software. | Can be implemented as controller applications within device capabilities. |
| Resilience | Distributed protocol convergence. | Controller availability plus data-plane recovery mechanisms. |
Benefits:
- Consistent network-wide policy.
- Automated provisioning and reconfiguration.
- Traffic engineering using a network-wide view.
- Separation of applications from device-specific configuration.
Trade-offs:
- Controller availability and capacity require explicit design.
- Replicated state introduces consistency challenges.
- Multi-device changes require coordination.
- Controller APIs and control channels require protection.
- Device capabilities and forwarding-table capacity remain constraints.
SDN shifts complexity into the controller platform and its applications. Cost and operational simplicity depend on the deployment.
SDN and NFV
Network functions virtualisation (NFV) runs network functions as software on general-purpose computing infrastructure.
| Technology | Main Concern | Example |
|---|---|---|
| SDN | Placement and programmability of network control. | A controller selects the path through a firewall. |
| NFV | Deployment of network functions. | A firewall runs as software instead of a dedicated appliance. |
Service function chaining directs traffic through an ordered set of network functions. SDN can steer traffic through functions deployed using NFV.
Applications of SDN
- Data centre networks
Central policy, workload connectivity, and tenant isolation. - Inter-data-centre WANs
Traffic engineering across expensive shared links. - SD-WAN
Central policy and application-aware selection across different access links. - Cloud virtual networks
Automated creation and management of isolated tenant networks. - Mobile networks
Separation of control and user-plane functions.
