the southbound API
Picture the SDN architecture drawn as a stack on a whiteboard: control applications at the top, the controller in the middle, the physical switches at the bottom. The word southbound just means the direction pointing down — from the controller toward the switches. The southbound API is the interface and protocol the controller uses to talk to the actual forwarding hardware below it: to install rules, read counters, and hear about events.
Concretely, the southbound API is how the controller's decisions become real behaviour in the switches. Through it the controller adds, changes, and deletes match-action entries; it reads statistics (how many packets matched a rule); and it receives notifications such as a port going down or a packet that matched nothing (a packet-in). OpenFlow is the best-known southbound protocol, but it is not the only one — others include NETCONF/YANG for configuration, gRPC-based interfaces like gNMI, and vendor-specific channels. The key property is that the southbound API is hardware-facing and detailed: it deals in flow rules, ports, and counters, the concrete machinery of forwarding.
Why it matters: the southbound API is what makes the data plane controllable from software, and standardizing it is what lets you mix switches from different vendors under one controller. It pairs with the northbound API (the controller's upward-facing interface to applications), and the two are deliberately different in altitude: southbound is low-level and switch-specific, northbound is high-level and application-friendly. An honest note: south and north are just orientation words from how the diagram is drawn — there is nothing geographic about them, and a controller usually speaks several southbound protocols at once to reach a mixed fleet of devices.
A load-balancing application tells the controller, through the northbound API, to spread web traffic across three servers. The controller turns that wish into concrete flow rules and pushes them down through the southbound API (over OpenFlow) into each switch. The switches now rewrite and forward packets accordingly — the southbound step is where intent finally becomes hardware behaviour.
Southbound is the downhill path: from the controller's decisions to the switches' actions.
Southbound and northbound are just diagram directions (down toward switches, up toward apps), not standards by themselves. OpenFlow is a southbound protocol, but the southbound API is a role that many protocols can fill.