Software-Defined Networking: SDN Architecture and OpenFlow

Software-Defined Networking fundamentally changes how networks are designed and operated by decoupling the control plane (the intelligence that decides where traffic goes) from the data plane (the hardware that forwards traffic). In a traditional network, each switch independently runs distributed protocols (OSPF, STP) and makes forwarding decisions locally. In an SDN, a centralized software controller computes the forwarding rules and programs them into switches through a standard protocol. This centralization enables network operators to program traffic flows programmatically, deploy new services rapidly, and observe the entire network state from a single interface.

The SDN Architecture

SDN’s three-layer architecture separates the network into:

1. Infrastructure layer — physical and virtual switches (OpenFlow-enabled) that forward packets according to rules installed by the controller.
2. Control layer — the SDN controller that maintains a unified view of the network topology, computes paths, and pushes flow entries to switches.
3. Application layer — network applications (load balancers, firewalls, traffic engineering, monitoring) that express their requirements to the controller through northbound APIs.

This separation allows the data plane to be built from commodity hardware (white-box switches running OpenFlow) while the control plane runs as software on standard servers.

Control Plane Separation

In traditional networking, each switch runs its own routing protocol instance — OSPF, BGP, STP — all consuming CPU and memory. Adding a new network service (a DDoS mitigation device in the traffic path) requires physical cabling changes or complex PBR configuration. SDN centralizes the control and abstracts the physical topology. A load-balancing application can tell the controller “redirect all traffic to server A to server B” — the controller computes the necessary flow rules across all affected switches and installs them automatically. This change takes milliseconds rather than hours.

The OpenFlow Protocol

OpenFlow (initially defined at Stanford in 2008, standardized as ONF TS-025) is the original southbound protocol for SDN. It defines how the controller communicates with switches.

Flow Table Entries

Each entry in a switch’s flow table contains three components:

Match fields define which packets the entry applies to. Matchable fields include ingress port, Ethernet source/destination MAC, Ethernet type, VLAN ID, VLAN priority, IP source/destination (with wildcard bits), IP protocol, TCP/UDP source/destination port, and MPLS label. OpenFlow 1.3 expanded matches to 40 fields.

Counters track packets, bytes, and duration per flow. The controller polls counters for monitoring and traffic engineering.

Instructions specify what to do with matching packets: forward to a physical port, forward to the controller (via Packet-In), drop, modify header fields (rewrite MAC, set VLAN, decrement TTL), or continue processing in the next flow table.

Flow Table Pipeline

OpenFlow 1.0 had a single flow table. OpenFlow 1.3+ supports multiple tables in a pipeline. A packet enters table 0 and proceeds through the chain. Each table can match and forward to the next table. This enables complex processing: table 0 applies ACLs (drop or forward to table 1), table 1 performs routing (forward or send to table 2 for QoS marking), table 2 marks DSCP and outputs. The pipeline model keeps individual flow tables small and fast.

OpenFlow Versions

OpenFlow 1.0 (2009) was the first production-capable version with single-table matching. OpenFlow 1.3 is the most widely deployed version — it added multiple tables, IPv6 support, MPLS, and meter tables for QoS. OpenFlow 1.5 added egress tables and packet type awareness. Practical deployments overwhelmingly use OpenFlow 1.3. The Open Networking Foundation ceased active development of OpenFlow in favor of the Stratum project and P4, but existing deployments number in the thousands.

SDN Controllers

OpenDaylight

OpenDaylight (Linux Foundation project) is a modular, Java-based controller. Its Model-Driven Service Abstraction Layer (MD-SAL) supports any southbound protocol via plugins: OpenFlow, NETCONF, SNMP, BGP, PCEP. OpenDaylight is the most feature-rich open-source controller but has a steep learning curve. It is used in service-provider and large-enterprise environments.

ONOS

ONOS (Open Network Operating System) is designed for carrier-grade deployments requiring high availability and performance. It uses a distributed core (based on Raft consensus) so multiple controller instances share the network state. A controller failure does not affect flows — the surviving instances continue programming. ONOS is deployed in production at AT&T, China Unicom, and Google.

Ryu

Ryu is a lightweight Python-based controller that is straightforward to learn and extend. It is ideal for prototyping and education. Ryu supports OpenFlow 1.0 through 1.5, NETCONF, OF-CONFIG, and a RESTful management API. A basic traffic engineering application can be written in under 100 lines of Python.

Network Virtualization with SDN

SDN paired with overlay network protocols enables network virtualization.

VXLAN

Virtual Extensible LAN (RFC 7348) encapsulates MAC frames in UDP over IP. A VXLAN tunnel endpoint (VTEP) adds a 24-bit VXLAN network identifier (VNI) that provides 16 million virtual network segments compared to VLAN’s 4,096. VXLAN is the dominant overlay in data-center SDN deployments. Combined with the EVPN control plane (RFC 7432), VXLAN enables any-to-any connectivity across layer-3 fabric.

Geneve

Generic Network Virtualization Encapsulation (RFC 8926) is a more flexible overlay than VXLAN. It uses a variable-length header that accommodates TLV-encoded options. Geneve was designed by the IETF NVO3 working group as a protocol-agnostic encapsulation.

SDN Use Cases

Data Center Traffic Engineering

SDN controllers optimize data-center fabric utilization. Microsoft’s SWAN and Google’s B4 (both described in published SIGCOMM papers) centrally compute tunnel assignments across the WAN, achieving over 90 percent link utilization versus 30-50 percent with traditional distributed routing. The controller shifts flows based on real-time utilization measurements.

Network Security

SDN enables reactive security: the controller monitors traffic via Packet-In messages, detects an anomalous flow (e.g., a compromised host performing port scans), and installs drop rules on the access switch to quarantine the host. This containment operates at machine time (milliseconds) rather than human time (hours to days).

WAN Optimization

Google’s B4 SDN WAN, documented by Jain et al. (SIGCOMM 2013), interconnects Google’s data centers worldwide. B4 uses a centralized traffic engineering service that assigns bandwidth shares to application classes, preempting less-important traffic when demand exceeds capacity. This allowed Google to double its inter-data-center bandwidth without building new fiber.

P4 and Programmable Data Planes

P4 (Programming Protocol-independent Packet Processors) represents the next evolution beyond OpenFlow. While OpenFlow allows the control plane to program entries into fixed match-action tables, P4 allows the programmer to define the match-action tables themselves — including the parser that determines which protocol headers the switch understands. P4 is a domain-specific language that targets programmable ASICs (Intel Tofino, AMD Pensando) or software targets (BPF). A P4 program can implement a custom forwarding behavior (e.g., a new transport protocol parser) that an OpenFlow switch could not support.

FAQ

Q: Is SDN the same as network virtualization?
A: No. SDN decouples control from data plane for programmability. Network virtualization (e.g., VXLAN, VMware NSX) abstracts the physical network into multiple virtual networks. SDN can be used to implement network virtualization, but they are distinct concepts.

Q: Do I need OpenFlow for SDN?
A: Not necessarily. While OpenFlow is the canonical southbound protocol, SDN is defined by the architecture — centralized control, programmable forwarding. Alternatives include NETCONF/YANG (Cisco), RESTCONF, gRPC/gNMI (Google, Arista), and P4Runtime.

Q: Is SDN widely deployed?
A: SDN in data-center fabrics (Cisco ACI, VMware NSX, Arista+CloudVision) is mainstream. SD-WAN (a related paradigm) is deployed by most enterprises. Pure OpenFlow-based networks are less common but exist in research networks (Internet2, OF@TEIN) and some service providers.

Q: What is the difference between overlay and underlay in SDN?
A: The underlay is the physical IP network (routers, switches, cables). The overlay is the virtual network built on top (VXLAN tunnels between hypervisors or fabric switches). The controller manages the overlay; the underlay runs a standard IGP.

Q: Does SDN make traditional routing protocols obsolete?
A: For the underlay, no — IS-IS or OSPF still run on the physical fabric to provide basic IP connectivity and loop-free paths. SDN replaces the control plane for the overlay and for traffic engineering, but the underlay still needs a distributed IGP for resilience.

Internal Links

• Network Automation — how automation and SDN converge on programmable infrastructure
• Network Topologies — leaf-spine topology for SDN data-center fabrics
• Routing Guide — comparing SDN centralized routing with distributed routing protocols

References

• McKeown, N. et al., “OpenFlow: Enabling Innovation in Campus Networks,” ACM SIGCOMM Computer Communication Review, 2008
• Jain, S. et al., “B4: Experience with a Globally-Deployed Software Defined WAN,” ACM SIGCOMM, 2013
• RFC 7426, “Software-Defined Networking (SDN): Layers and Architecture Terminology”
• RFC 7348, “Virtual eXtensible Local Area Network (VXLAN)”
• ONF. “OpenFlow Switch Specification Version 1.3.0.” Open Networking Foundation. https://opennetworking.org/
• Kurose, J. F. and Ross, K. W., Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2021, Section 5.6 (“Network Management and SNMP”)

For a comprehensive overview, read our article on Cabling Standards.

For a comprehensive overview, read our article on Cdn Guide.

Related Concepts and Further Reading

Understanding sdn requires familiarity with several interconnected ideas and principles that together form a complete picture. Exploring these related concepts deepens your knowledge and provides context that makes the core material more meaningful and applicable. Each concept builds on the others, creating a web of understanding that supports deeper learning and practical application. Taking time to explore how these elements connect reveals patterns that accelerate comprehension and retention of new information.

The relationship between sdn and adjacent fields is worth particular attention. Many of the most important insights emerge at the boundaries between disciplines, where ideas from different areas combine to create new approaches and solutions that neither field could produce alone. Exploring these connections pays dividends in both breadth and depth of understanding, revealing patterns and principles that might otherwise remain hidden from view. Cross-disciplinary knowledge is increasingly valued as problems become more complex and interconnected.

For those looking to go beyond introductory material, several excellent resources provide deeper treatment of specific aspects of sdn. Academic journals, industry publications, authoritative reference works, and online courses each offer different perspectives and levels of detail. The key is to match your reading to your current learning goals and build knowledge progressively, focusing on quality over quantity in your study materials. A well-chosen resource that matches your current level is worth more than dozens of resources that are too basic or too advanced.