Loading learning content...
An SDN controller is only as useful as its interfaces. Without well-defined APIs, the controller remains a isolated brain—unable to command network devices or serve application needs. The northbound and southbound interfaces are the arteries that carry control traffic through the SDN architecture.
These interfaces aren't mere implementation details. They define the contract between architectural layers, determine what applications can express, constrain what devices must support, and ultimately shape what SDN can achieve. A controller with limited southbound protocols manages only compatible devices. A controller with primitive northbound APIs restricts application sophistication.
This page dissects both interface categories, exploring the protocols, paradigms, and design philosophies that enable controller communication. By understanding northbound and southbound APIs, you'll comprehend how SDN translates high-level intent into low-level forwarding behavior.
By the end of this page, you will understand the purpose and function of northbound and southbound interfaces, the major protocols and standards in each category, API design principles that enable SDN programmability, and how these interfaces work together to deliver intent-based networking.
SDN architecture organizes interfaces by their relationship to the controller—a directional classification that clarifies function and responsibility.
Interface Taxonomy
Northbound Interfaces: Connect applications above the controller
Southbound Interfaces: Connect devices below the controller
East-West Interfaces: Connect peer controllers
The north/south metaphor derives from network diagrams where applications sit atop infrastructure—controller in the middle, applications above, devices below.
The Abstraction Stack
Each interface layer provides abstraction:
Each layer hides complexity from the layer above. Applications don't know about flow table TCAM limits. Controllers don't know about ASIC pipeline specifics. This separation enables:
APIs are contracts. Northbound APIs promise applications certain capabilities and abstractions. Southbound APIs require devices to implement specific behaviors. Well-designed APIs are stable—they can evolve without breaking existing users. SDN's success depends on these contracts being well-specified, widely implemented, and carefully maintained.
Southbound interfaces enable controllers to program, monitor, and manage network devices. These protocols provide the mechanism through which abstract controller decisions become concrete forwarding behavior.
Core Functions
Southbound interfaces must support:
Imperative vs Declarative
Southbound protocols follow two paradigms:
Imperative: Controller specifies exact operations—"add this rule," "delete that entry"
Declarative: Controller specifies desired state—"ensure this configuration exists"
| Protocol | Model | Primary Use | Transport |
|---|---|---|---|
| OpenFlow | Imperative, flow-based | Flow rule programming | TCP/TLS (6633, 6653) |
| P4Runtime | Imperative, programmable | P4 pipeline programming | gRPC over TCP |
| NETCONF | Declarative, configuration | Device configuration | SSH or TLS (830) |
| RESTCONF | Declarative, RESTful | Configuration via HTTP | HTTPS (443) |
| gNMI | Declarative + streaming | Telemetry and config | gRPC over TCP |
| OVSDB | Configuration-focused | Open vSwitch management | JSON-RPC over TCP |
| OF-Config | Configuration extension | OpenFlow switch config | NETCONF |
OpenFlow: The Canonical Southbound Protocol
OpenFlow deserves special attention as the protocol that launched SDN:
OpenFlow's explicit flow programming enables fine-grained control but creates scaling challenges—large networks may have millions of flows requiring explicit rules.
P4Runtime: Programmable Pipeline Control
P4Runtime extends beyond OpenFlow's fixed-function model:
P4Runtime represents next-generation southbound control where the pipeline itself is programmable, not just the entries within fixed tables.
Real deployments often use multiple southbound protocols: OpenFlow for flow programming, NETCONF for device configuration, gNMI for streaming telemetry. The protocols are complementary, not competitive. Select based on what you need to control: flow-level forwarding, device configuration, or real-time observability.
OpenFlow remains the most widely deployed southbound SDN protocol. Understanding its operation is fundamental to SDN practice.
Connection Establishment
OpenFlow uses dedicated control channels:
Flow Table Structure
Switches contain one or more flow tables, each with entries comprising:
Flow Entry Components:┌─────────────────────────────────────────────────────────────┐│ MATCH FIELDS ││ ├── in_port: 1 ││ ├── eth_type: 0x0800 (IPv4) ││ ├── ipv4_src: 10.0.0.0/8 ││ ├── ipv4_dst: 192.168.1.100/32 ││ └── tcp_dst: 80 │├─────────────────────────────────────────────────────────────┤│ METADATA ││ ├── priority: 32768 ││ ├── cookie: 0x1234567890abcdef ││ ├── idle_timeout: 300 seconds ││ └── hard_timeout: 3600 seconds │├─────────────────────────────────────────────────────────────┤│ COUNTERS (read-only) ││ ├── packet_count: 1,234,567 ││ └── byte_count: 567,890,123 │├─────────────────────────────────────────────────────────────┤│ INSTRUCTIONS ││ ├── Apply-Actions: ││ │ ├── set_field: vlan_vid=100 ││ │ └── output: port 5 ││ └── Write-Metadata: 0xABCD │└─────────────────────────────────────────────────────────────┘Key Message Types
Controller-to-Switch:
OFPT_FLOW_MOD: Add/modify/delete flow entriesOFPT_PACKET_OUT: Send packet through switchOFPT_STATS_REQUEST: Query counters and stateOFPT_BARRIER_REQUEST: Ensure message orderingOFPT_GROUP_MOD: Modify group tables (multicast/failover)Switch-to-Controller:
OFPT_PACKET_IN: Unknown packet forwarded to controllerOFPT_FLOW_REMOVED: Flow entry expired or deletedOFPT_PORT_STATUS: Port state change (up/down/modified)OFPT_STATS_REPLY: Response to statistics requestOFPT_ERROR: Request failed (table full, invalid operation)OpenFlow Versions and Evolution
OpenFlow has evolved significantly:
Most production deployments use OpenFlow 1.3. Later versions added features but saw limited adoption as alternatives (P4Runtime, gNMI) emerged.
OpenFlow flows typically map to TCAM (Ternary Content-Addressable Memory) entries in switches. TCAM is expensive, power-hungry, and finite—typically 1K to 100K entries. Flow table capacity constrains what OpenFlow can express. Effective SDN design aggregates rules, uses default paths, and avoids per-host or per-flow entries where possible.
While OpenFlow handles flow-level programming, NETCONF and YANG provide configuration management for network devices. These protocols complement OpenFlow in comprehensive SDN deployments.
YANG: The Data Modeling Language
YANG defines the structure and semantics of configuration data:
YANG provides a schema that multiple protocols can transport—NETCONF, RESTCONF, and gNMI all work with YANG-modeled data.
NETCONF: The Configuration Protocol
NETCONF uses RPC over SSH to manage YANG-modeled configuration:
12345678910111213141516171819202122232425262728293031323334353637383940414243
module example-interfaces { namespace "urn:example:interfaces"; prefix "if"; container interfaces { list interface { key "name"; leaf name { type string; description "Interface identifier"; } leaf enabled { type boolean; default true; description "Administrative state"; } leaf mtu { type uint16 { range "68..65535"; } default 1500; description "Maximum transmission unit"; } container ipv4 { leaf address { type inet:ipv4-address; description "IPv4 address"; } leaf prefix-length { type uint8 { range "0..32"; } description "Prefix length"; } } } }}RESTCONF: REST over YANG
RESTCONF provides HTTP-based access to YANG data:
gNMI: Google Network Management Interface
gNMI represents the next evolution in device management:
gNMI excels at telemetry—streaming interface counters, routing state, and operational data at high frequency.
| Feature | NETCONF | RESTCONF | gNMI |
|---|---|---|---|
| Transport | SSH | HTTPS | gRPC |
| Encoding | XML | JSON or XML | Protobuf or JSON |
| Data Model | YANG | YANG | YANG (OpenConfig) |
| Streaming | Limited (notifications) | Limited | Native (subscribe) |
| Transactions | Full commit/rollback | Per-request | Set transactions |
| Client Tooling | Mature libraries | HTTP clients | gRPC libraries |
| Performance | Good | Moderate (text) | Excellent (binary) |
OpenConfig.net provides vendor-neutral YANG models for network devices. Instead of mapping between vendor-specific schemas, controllers using OpenConfig models work consistently across Cisco, Juniper, Arista, and others. This standardization dramatically reduces multi-vendor SDN complexity.
Northbound interfaces expose controller capabilities to applications—the software that consumes network services. Unlike southbound protocols (which have standards like OpenFlow), northbound APIs are largely controller-specific, though common patterns emerge.
Design Philosophies
Northbound APIs can be designed at different abstraction levels:
Low-Level APIs (Thin Abstraction)
Mid-Level APIs (Path and Policy Abstraction)
High-Level APIs (Intent Abstraction)
Common Northbound API Patterns
REST APIs Most controllers expose RESTful HTTP interfaces:
/topology/switches/dpid:123gRPC APIs Performance-critical interfaces increasingly use gRPC:
Event Streams Applications need real-time network updates:
Unlike southbound protocols (OpenFlow, NETCONF), northbound APIs lack universal standards. Each controller defines its own API, limiting application portability. Efforts like ONF's Common Information Model aim to standardize, but adoption remains limited. This reality means SDN applications often couple to specific controllers.
Intent-Based Networking (IBN) represents the highest abstraction level for northbound APIs. Instead of specifying how the network should behave, applications declare what they need—the controller determines how to achieve it.
The Intent Abstraction
Intent captures desired network behavior in business or application terms:
The controller translates intent into:
Intent Lifecycle
1234567891011121314151617181920212223242526
{ "type": "HostToHostIntent", "appId": "org.example.myapp", "priority": 100, "one": "00:00:00:00:00:01/None", "two": "00:00:00:00:00:02/None", "constraints": [ { "type": "BandwidthConstraint", "bandwidth": 1000000000 }, { "type": "LatencyConstraint", "latency": 10 } ], "treatment": { "instructions": [ { "type": "L2MODIFICATION", "subtype": "VLAN_ID", "vlanId": 100 } ] }}Intent Verification and Assurance
True IBN goes beyond configuration—it includes continuous verification:
This verification capability distinguishes IBN from traditional automation. Automation pushes configuration; IBN ensures the desired outcome is actually achieved.
Challenges in Intent Translation
Translating intent is hard:
Advanced IBN systems use constraint satisfaction, optimization algorithms, and even machine learning to navigate these challenges.
Intent-based networking represents SDN's ultimate promise: networks managed through business intent rather than CLI commands. The reality is that robust IBN remains challenging. Current systems handle structured intents well but struggle with complex, ambiguous requirements. Expect IBN to mature over the coming years as AI/ML techniques improve intent interpretation.
SDN APIs—both northbound and southbound—represent critical attack surfaces. Compromising controller APIs means compromising the entire network. Security must be designed in, not bolted on.
Southbound Security
Controller-to-device channels require protection:
OpenFlow Security
NETCONF Security
gNMI Security
| Security Aspect | Northbound Best Practice | Southbound Best Practice |
|---|---|---|
| Transport Encryption | HTTPS/TLS mandatory | TLS on OpenFlow; SSH on NETCONF |
| Authentication | OAuth2, JWT, API keys | Certificate-based, shared secrets |
| Authorization | RBAC with principle of least privilege | Controller-verified per-device ACLs |
| Rate Limiting | Per-client rate limits | Control channel bandwidth limits |
| Input Validation | Schema validation, sanitization | Protocol conformance checking |
| Audit Logging | All API calls logged | All configuration changes logged |
| Anomaly Detection | Unusual patterns trigger alerts | Control traffic anomalies flagged |
Northbound Security
Application interfaces present different challenges:
Authentication and Authorization
API Gateway Patterns
Multi-Tenancy
Common Attack Vectors
The SDN controller is the highest-value target in the network. Compromising it means controlling all traffic, accessing all data, and potentially bringing down entire infrastructure. Treat API security with the same rigor as your most sensitive systems. Defense in depth, monitoring, and incident response planning are essential.
We've explored the critical interfaces that connect SDN controllers to their ecosystem—the northbound APIs serving applications and southbound protocols commanding devices. Let's consolidate the key insights:
What's Next:
With a solid understanding of controller APIs, we'll examine specific popular SDN controllers. From open-source options like ONOS and OpenDaylight to commercial products like Cisco ACI and VMware NSX, we'll explore the landscape of controller implementations and their distinctive features.
You now understand the critical role of northbound and southbound APIs in SDN architecture. These interfaces enable the controller to command devices, serve applications, and translate high-level intent into low-level forwarding behavior. Next, we'll survey the most popular SDN controller implementations.