1. Introduction

A 400G wavelength request lands on a controller, and two interfaces immediately go to work. Above the controller, an orchestrator asked for connectivity between two endpoints and a guaranteed bit rate — nothing about which ROADM, which wavelength, or which amplifier. Below it, the controller is setting a transponder's modulation format, programming a wavelength cross-connect, and nudging amplifier gain along the line. The upper conversation is abstract and stable; the lower one is concrete, vendor-specific, and changes every time a card is swapped. The controller exists to hold those two conversations at once and keep them consistent.

The Open Networking Foundation gave the two boundaries names that carry no directional baggage. The interface to applications is the application-controller plane interface (A-CPI), popularly the northbound interface or NBI. The interface to network elements is the data-controller plane interface (D-CPI), popularly the southbound interface or SBI. The ONF deliberately avoided "north" and "south" because the words imply a fixed hierarchy, and in a recursive controller stack the same interface can face up in one association and down in another. A domain controller's northbound A-CPI to an orchestrator and that orchestrator's southbound view of the domain are, formally, the same interface seen from opposite sides.

This article works through both interfaces at engineering depth: what each one carries, the protocols that implement them, how the abstraction between them is built and where it breaks, and how to size and deploy the pair without inheriting the failure modes that come free with centralized control. The treatment is protocol-current as of 2026 — OpenFlow's stall at version 1.5.1, the rise of NETCONF/YANG and gNMI/OpenConfig on the southbound side, and the consolidation of intent-style and model-driven APIs on the northbound side. The optical examples are concrete because that is where the abstraction is hardest and the consequences of getting it wrong are most expensive.

2. Fundamentals: the two boundaries

An SDN controller sits between a set of network elements it controls and a set of applications that consume the network as a service. The controller's job, in the ONF framing, is the real-time convergence of a changing resource pool and a changing service demand toward an optimum. To do that it terminates one interface family facing the equipment and presents another facing the applications, and it owns the model that connects them.

Direction is the defining property

"North" and "south" describe direction relative to the controller, not protocol or function. A southbound interface points down toward infrastructure; a northbound interface points up toward orchestration and applications. The same protocol can appear on either side depending on which way it faces — RESTCONF carrying YANG runs southbound to a device and northbound to an orchestrator, and only the direction distinguishes the two roles. This is why the ONF models the interfaces as client-server roles rather than fixed planes: across any association, a client commands and queries, a server responds and notifies.

The network element and its D-CPI

A network element (NE) provides at least one logical D-CPI that lets its functions be managed and controlled by the controller. "Logical" is the operative word — the D-CPI may contain any number of communication channels and protocols, and the NE itself may be a single shelf, a distributed system like a passive optical network, or a virtual machine. The D-CPI exposes three things: programmatic control of the functions the element chooses to expose, advertisement of its capabilities, and event notification. Nothing the controller cannot see across the D-CPI exists, as far as the controller is concerned — a design choice with direct security consequences covered in section 8.

The application and its A-CPI

SDN lets applications become network-aware rather than the network being forced to infer application intent. A traditional application describes its network requirements implicitly, through human-mediated negotiation; an SDN application states them across the A-CPI, where it invokes services from the controller. The A-CPI supports recursion: an application can itself expose an A-CPI to applications above it, which is exactly how multi-level orchestration stacks are built. The ONF describes these levels as having different latitudes — degrees of abstraction — and different longitudes — sets of functionality. A higher-latitude NBI hides whether the substrate is OpenFlow-based or optical or anything else; a lower-latitude one exposes more device detail.

The standards framework

Four bodies own the pieces. The ONF defines the overall SDN architecture (TR-521, successor framing to the original TR-502) and the A-CPI/D-CPI vocabulary, and historically standardized OpenFlow as the first open southbound protocol. The IETF owns NETCONF, RESTCONF, and the YANG modeling language that most modern device interfaces are built on, plus the ACTN framework for multi-domain orchestration. OpenConfig — an operator-led consortium rather than a formal SDO — publishes vendor-neutral YANG models and the gNMI/gNOI transport. The OIF validates interoperability of the ONF Transport API (T-API) for the optical northbound interface through its recurring multi-vendor interoperability demonstrations. These are complementary, not competing: T-API tends to sit northbound, OpenConfig southbound, and the IETF protocols carry both.

3. Architecture and signal flow

The controller decomposes into a driver-agent pattern that repeats at every interface. Each interface is implemented by a driver-agent pair: the agent represents the infrastructure-facing (southern) side, and the driver represents the application-facing (northern) side. A controller is, at its core, a set of southbound agents terminating device protocols, a model that fuses their state into one coherent view, and a set of northbound drivers re-presenting that view as services.

How a request flows down and state flows up

A service request enters across the A-CPI as intent or as a fine-grained model object. The northbound driver interprets it against the controller's network model, the model's path-computation and resource-assignment logic chooses concrete resources, and the southbound agents translate those decisions into device commands across the D-CPI. State flows the other way continuously: elements advertise capabilities and emit event notifications across the D-CPI, the model absorbs them, and the northbound side pushes notifications to subscribed applications. The two directions run on different clocks — control actions complete in tens of milliseconds to seconds, while the model's longer-horizon optimization can keep adjusting the result for as long as the service lives.

4. The southbound interface (D-CPI)

The D-CPI is where abstraction meets silicon, and it is harder than the northbound side because it has to be honest about hardware. Three functions define it regardless of protocol: programmatic control of every function the element exposes through its resource database, capabilities advertisement so the controller learns what the element can do, and event notification so the controller learns what the element is doing. Everything below is a question of which protocol carries those three functions and how faithfully.

OpenFlow: the first open SBI, now frozen

OpenFlow proved the thesis — that forwarding behavior could be programmed through a common, vendor-independent protocol — and it did so by giving the controller direct write access to switch flow tables. A flow entry matches packet header fields (the original 1.0 defined a 12-tuple match) and applies actions; later versions added multiple flow tables, group tables for multicast and failover, and meter tables for rate limiting. The last public specification is OpenFlow 1.5.1, released March 2015, defining 44 controller-switch message types; no newer public version has appeared since, and versions 1.0 and 1.3 remain the most widely deployed. OpenFlow's structural limit is that it programs a fixed set of operations: a switch can only be told to do what the protocol already knows how to express, which is why purely OpenFlow-based data planes cannot gain new functionality without a switch upgrade.

OpenFlow never fit optical networks well. It was built for packet switching, and the photonic layer's continuous physical parameters — wavelength, launch power, modulation format, amplifier gain — don't map onto a flow-table abstraction. The SDN principles transferred to optical; the protocol largely did not.

NETCONF/YANG and gNMI: the model-driven SBI

The southbound interface that actually carries modern multi-vendor optical and packet networks is model-driven configuration over NETCONF or gNMI, using YANG data models. NETCONF (IETF) provides a candidate datastore, transactional commit, and rollback — a network element either applies a configuration change atomically or rejects it, which is exactly what you need before lighting a 400G channel. gNMI (from OpenConfig) is built for scale and telemetry: it streams hundreds of metrics per second from a device using the same YANG models, where NETCONF's polling cannot keep up. RESTCONF offers a REST-style HTTP binding to the same YANG-modeled data, popular where a web stack already exists.

The models matter more than the transport. OpenConfig publishes operationally complete, vendor-neutral YANG models that cover both configuration and operational state in one structure, including granular optical models for amplifiers, channel monitors, attenuators, and terminal optics. A controller can set target gain on an amplifier or subscribe to per-channel optical power using a common data structure regardless of vendor. OpenROADM defines a complementary set of models specifically for disaggregated ROADM interoperability. Where neither covers a function, the gap is filled by vendor-native YANG — and that is precisely where multi-vendor abstraction starts to leak.

# gNMI subscription across the D-CPI: stream per-channel optical power
$ gnmic -a roadm-a.core:57400 --skip-verify -u admin \
    subscribe --mode stream --sample-interval 10s \
    --path "/components/component[name=och-1]/optical-channel/state/output-power"
# controller absorbs each sample into its network model and
# re-publishes northbound to any subscribed assurance application

The protocol landscape, side by side

5. The northbound interface (A-CPI)

The northbound interface sells the network as a service. Where the D-CPI is constrained by what hardware can do, the A-CPI is constrained by what applications need to express — and those needs split cleanly into two styles the ONF formalized as two NBI flavors.

Intent-based versus fine-grained

An intent-based NBI lets an application state a goal and stay ignorant of how it is met: "a bidirectional 400G photonic media channel between site A and site B with 99.99% availability." The application does not choose the wavelength, the route, or the regeneration points. Behind the interface sits an intent execution environment with an intent interpreter that translates the goal into concrete actions against the network model, choosing the optimal realization given current context. The ONF treats intent as the recommended default NBI style because it maximizes portability — an application written against intent survives a substrate change underneath it.

A fine-grained NBI is for applications that want to prescribe how a goal is met and therefore need to understand the relevant network detail. Fine-grained NBIs are typically exposed as RESTful APIs with JSON schemas, derived from the controller's common information model by pruning and refactoring it into an application-specific view. A topology API, a connectivity API, a path-computation API — each exposes the slice of the information model that its function needs and renames the underlying objects into terms that fit the API.

Latitude and longitude

Two dimensions place any NBI. Latitude is the degree of abstraction: a high-latitude NBI hides whether the substrate is OpenFlow, optical, or anything else; a low-latitude one exposes device-level structure. Longitude is the breadth of functionality the NBI covers. An application can tap the controller at whatever latitude and longitude suits it, and a single controller commonly exposes several NBIs at once — a high-latitude intent API for service requests and a lower-latitude topology API for a path-computation application that wants to see the graph.

T-API: the optical northbound interface

For optical domain controllers, the ONF Transport API (T-API) is the standardized northbound interface, validated through OIF interoperability testing. T-API is a RESTCONF/YANG interface that exposes topology, connectivity, path-computation, notification, and OAM services across layers 0, 1, and 2 — photonic, OTN, and Ethernet. An orchestrator requests a service by endpoints and characteristics without deep knowledge of the underlying line system; the domain controller translates that into vendor-specific configuration. The same T-API runs between a domain controller and a hierarchical orchestrator — the upper interface carries an abstracted map, the lower carries device detail, but the model is identical, which is the recursion of section 3 made concrete. Recent releases (the 2.4.0 generation) added impairment awareness and a unified alarm-and-performance model.

6. The abstraction in the middle

The controller's value is the translation between the abstract service its A-CPI sells and the concrete device state its D-CPI commands. That translation is built by pruning and refactoring a common information model: each northbound API takes the controller's full model, removes the parts its function doesn't need, and renames and restructures what remains into terms that fit the API. The same model objects that the southbound side fuses from device state are the raw material the northbound side reshapes into services. When the model is faithful, the abstraction holds; when it isn't, the controller lies to its applications.

Virtualization and the network model

The controller represents the resources it controls as a set of virtual network elements (VNEs) interconnected into subnetworks, and a VNE can itself be a subnetwork through successive abstraction. This is how a controller hides a whole multi-node optical domain behind a single apparent element on its northbound interface — and how an orchestrator above it sees one abstracted node where the domain controller sees fifty. The architecture is blind to whether a data-plane resource is physical or virtual, as long as the functions the model advertises are correctly executed. That last clause is the entire risk: the abstraction is only as good as the fidelity of the model to the hardware beneath it.

Why the abstraction is the main failure point

Three failure modes recur. First, model drift: the controller's view diverges from device reality after a non-transactional change, a missed notification, or a device reboot the controller didn't observe — and every northbound answer derived from a stale model is wrong. Second, opaque attributes: when a device exposes a function the model can't structure, the controller either ignores it (losing control) or passes it through opaquely (losing portability). Third, semantic mismatch: the same word means different things across an interface, so a "400G service" requested northbound resolves to incompatible operational modes on different vendors' hardware southbound. The ONF anticipated this — it requires that any association support at least a subset of a common information view and deal with misalignment gracefully, with compatibility known a priori, discovered, or negotiated when the client-server association is established.

7. Performance, sizing, and trade-offs

The two interfaces run on different clocks and fail in different ways, so they size differently. The southbound interface is latency- and throughput-sensitive in the control loop: a protection switch or a flow update has to complete fast enough that traffic doesn't notice. The northbound interface is correctness- and concurrency-sensitive: many applications query and subscribe at once, and the controller has to serialize conflicting requests without lying about state.

Quantifying the control loop

A useful first-order model of a closed-loop control action's latency separates the interface costs from the compute cost:

The chart below contrasts representative latency budgets for control actions across southbound mechanisms. These are order-of-magnitude engineering figures for comparison, not vendor benchmarks — the point is the ranking, not the exact millisecond.

The standing trade-offs

8. Practical deployment

In a real multi-vendor optical network the interface pair stacks into a hierarchy. Domain controllers terminate device protocols southbound and present T-API northbound; a hierarchical orchestrator consumes those T-APIs as its own southbound view and presents intent northbound to OSS and business systems. The same interface concept appears three or four times up the stack, each level abstracting the one below into VNEs.

Common configurations

A typical optical deployment runs OpenConfig and OpenROADM YANG over NETCONF and gNMI on the D-CPI between domain controller and equipment, and T-API (RESTCONF/YANG) on the A-CPI between domain controller and orchestrator. Vendor SDN platforms in this space include Ciena's MCP and Blue Planet, Nokia's Network Services Platform, Cisco's optical controllers, and Ribbon's Muse SDN orchestrator, alongside open-source controllers and the ETSI TeraFlowSDN project. Field validations have built exactly the OpenConfig + NETCONF/gNMI + T-API stack into a hierarchical controller and confirmed coordinated IP-and-optical provisioning across vendors — gated, in practice, by the maturity of device-mode standardization rather than by the interfaces themselves.

The trust boundary — a security-driven design rule

The D-CPI is a security boundary, not just a control boundary. A controller can sit in a trust domain that is not the network owner's — a wholesale customer or a higher-level orchestrator run by a different team. The ONF's recommended posture is default-deny: a network element exposes to its controller only the resources and actions that policy permits, and everything else is invisible. An unexpected signal on an unconfigured port is treated as an exception to be raised, not traffic to be accepted. This is why "nothing the controller can't see exists" is a feature — the invisible surface can't be attacked through the controller.

Troubleshooting quick reference

For the broader management context around these interfaces — how an EMS, NMS, controller, and orchestrator divide the work — the control-versus-management split is the companion read, and the protocol families themselves are surveyed in the NBI and SBI protocol introduction. The execution side — how controllers actually push actions to devices as automation matures — runs through the autonomous-network levels, and the converged-layer case where one controller drives both IP and optical appears in the IP over DWDM walkthrough. The full automation hierarchy that sits above the A-CPI is laid out in the optical network automation guide.

9. Future outlook

The trajectory is set. OpenFlow's freeze at 1.5.1 confirmed that flow-table programming was the wrong abstraction for everything outside packet switching, and the industry has consolidated southbound on model-driven configuration — NETCONF for transactional safety, gNMI for telemetry, YANG for the models, with P4 carrying programmable-data-plane work where flow tables once stood. Northbound, intent continues to displace prescriptive APIs as operators chase portability, and the IETF's ACTN framework and the ONF's T-API converge on the same multi-domain abstraction problem from two directions.

The open problem is the one this article keeps returning to: closing the abstraction gap so a controller can read every vendor's operational mode as structured data rather than opaque attributes. Until that gap closes, multi-vendor abstraction stays leaky and the integration effort stays on the operator. The skills that pay off are model-driven ones — YANG, NETCONF, gNMI, OpenConfig, T-API, and the Python tooling that drives them — because the interface concept is stable even as the protocols underneath it turn over.

10. Reference section

Key specifications at a glance

Glossary

• A-CPI — Application-Controller Plane Interface; the northbound boundary where applications invoke controller services.
• D-CPI — Data-Controller Plane Interface; the southbound boundary where the controller manages network elements.
• NBI / SBI — Northbound / Southbound Interface; the directional, popular names for A-CPI and D-CPI.
• Latitude — degree of abstraction an NBI presents; higher hides more substrate detail.
• Longitude — breadth of functionality an NBI covers.
• VNE — Virtual Network Element; the controller's abstracted representation of one or more real resources, recursively nestable.
• Intent NBI — northbound style where the application states a goal, not a method.
• Fine-grained NBI — northbound style where the application prescribes method and needs network detail.
• Driver-agent pair — the implementation pattern for any interface: agent faces infrastructure, driver faces applications.
• Model drift — divergence between the controller's network model and actual device state.
• T-API — ONF Transport API; the standardized northbound interface for optical domain controllers.
• YANG — IETF data modeling language underpinning NETCONF, RESTCONF, gNMI, OpenConfig, and T-API.

References

• Open Networking Foundation, SDN Architecture (TR-521), Open Networking Foundation.
• Open Networking Foundation, OpenFlow Switch Specification, Open Networking Foundation.
• Open Networking Foundation, Transport API (T-API) Functional Requirements Specification, Open Networking Foundation.
• Internet Engineering Task Force, Network Configuration Protocol (NETCONF) and the YANG Data Modeling Language, IETF.
• OpenConfig, Vendor-Neutral Data Models and gNMI, OpenConfig operator working group.

Sanjay Yadav, "Optical Network Communications: An Engineer's Perspective" — Bridge the Gap Between Theory and Practice in Optical Networking.