1. Introduction

A national optical backbone is almost never one vendor end to end. Long-haul corridors carry amplifiers and reconfigurable optical add-drop multiplexers (ROADMs) procured in one cycle; the metro rings hanging off them came from a different supplier two refresh cycles later; and the routers terminating services increasingly carry coherent pluggables from a third. Each of those layers ships with its own element manager, its own command-line grammar, and its own idea of what a "service" is. The operator still has to present all of it to an Operations Support System (OSS) as a single programmable network, provision a wavelength from a city in one domain to a city in another without a human translating between three management systems, and do it in minutes rather than days.

Hierarchical Software-Defined Networking (SDN) is the structure the transport industry settled on to make that possible. The idea is a stack of controllers in which each layer hides detail from the layer above it. At the bottom sit the network elements (NEs): transponders, muxponders, ROADMs, amplifiers, and packet-optical platforms. Above each technology-or-vendor island sits a domain controller that speaks that island's native data models southbound and exposes a vendor-neutral abstraction northbound. Above the domain controllers sits an orchestrator — a parent controller that stitches the domains into end-to-end services and never has to know whose ROADM is whose. Above that sits the OSS/BSS, which deals in customer-facing services and is shielded from the network entirely.

Four interfaces became the consensus for wiring that stack together, and they are the spine of this article. TAPI, the Open Networking Foundation Transport API, runs northbound between controllers and carries an abstracted, technology-agnostic view of topology and connectivity. OpenConfig, a set of operator-driven vendor-neutral YANG models, runs southbound to configure and read devices. gNMI, the gRPC Network Management Interface, carries streaming telemetry off those devices. And NETCONF carries transactional configuration change, with the candidate-datastore and commit semantics that let a controller apply a multi-device change atomically or roll it all back. This division of labour is aligned with two reference architectures that describe the same shape from different angles: the ONF SDN Architecture for Transport Networks (TR-522) and the IETF Abstraction and Control of TE Networks framework (ACTN, RFC 8453).

The thesis of the article is the load-bearing idea behind all of it: per-domain controllers hide vendor difference from the orchestrator above. Abstraction is not a convenience layer bolted on for tidiness. It is the mechanism that makes the whole structure tractable, and it is the reason the architecture is hierarchical rather than flat. A single flat controller talking directly to every device in a multi-vendor optical network would have to model every vendor's proprietary configuration grammar, every vendor's analog impairment behaviour, and the full internal state of every domain at once. That neither scales nor respects the business and operational boundaries between an operator and its suppliers. Splitting control into a hierarchy lets each domain controller own the messy, vendor-specific detail locally and publish a clean summary upward, and lets the orchestrator reason about the network as a graph of abstract nodes and links.

That separation of concerns buys three things at once. It bounds the state any one controller has to hold, because the orchestrator sees an abstracted topology rather than every internal fibre and amplifier. It contains fault domains, because a domain controller failure does not take down the orchestrator's view of other domains. And it lets each domain controller keep using the deep, proprietary intelligence its vendor built for managing its own hardware, while still answering the orchestrator in a standard language. The price is that abstraction can hide information the orchestrator turns out to need, and that keeping the abstracted view consistent with the real network is a genuine engineering problem — both of which this article treats directly later on.

The scope here is the control and management plane for the optical transport layer specifically, and the model families and protocols that make multi-vendor control work in practice. The article walks down the stack and back up: why the optical layer's physics forces the hierarchy in the first place; the canonical layered model and how the ONF, IETF, and TM Forum vocabularies map onto each other; what TAPI actually carries northbound; how OpenConfig, NETCONF, and gNMI split the work southbound; the mechanics of how a domain controller abstracts vendor difference; the two pieces of mathematics — abstraction state-reduction and impairment-aware feasibility — that make the abstraction safe; the real controllers and open-source stacks that implement it; where the architecture still breaks; and where it is heading. The reader who has built any part of this will find the failure modes more interesting than the diagrams, and they are deliberately not glossed over.

2. Why the optical layer forces a hierarchy

An EDFA adds amplified spontaneous emission (ASE) noise with every gain stage, typically at a noise figure of 4–6 dB. A wavelength-selective switch (WSS) inside a ROADM imposes 5–7 dB of insertion loss and a passband whose exact shape is the vendor's own. Standard single-mode fibre to ITU-T G.652 loses roughly 0.18–0.20 dB/km in the C-band, and over thousands of kilometres that loss, the noise that accumulates fighting it, and the nonlinear interference generated when many channels share a fibre all combine into the single number that decides whether a lightpath works: its optical signal-to-noise ratio, conventionally referenced to a 0.1 nm (12.5 GHz) bandwidth. For modern coherent channels at 32 GBaud and above, the relevant figure is the generalized signal-to-noise ratio (GSNR), which folds nonlinear interference in alongside ASE across the channel's true bandwidth. These are measured quantities and physical limits, not configuration knobs — and they are the reason optical control cannot be flattened the way a packet network can.

The packet layer is digital and regenerative: a router either forwards a packet correctly or it does not, and a controller can treat each hop as independent. The optical layer is analog and accumulative. A wavelength is a continuous waveform that degrades end to end, and whether it arrives with enough margin depends on every amplifier, every span length, every filter it passed through, and on the power and proximity of every other channel sharing the fibre. Working out whether a given route is feasible means modelling all of that physics — the quality of transmission (QoT) — and that model is where vendors differ most. Two suppliers' amplifiers have different noise figures; two WSS designs filter the channel edges differently; the way a vendor equalizes power across the band is part of its calibration. A controller that wanted to compute a feasible cross-vendor lightpath from first principles would need an accurate, vendor-agnostic physical-layer model of a heterogeneous mix of components, which is precisely the hard problem that open-source efforts like the GNPy library set out to solve and which remains an active field rather than a settled one.

A second pressure comes from timing. Coherent digital signal processing advances on roughly a two-year cadence — each generation lifts baud rate, spectral efficiency, and reach — while the analog photonic line of amplifiers and ROADMs has a service life closer to a decade. Locking both to one vendor forces an operator to replace a perfectly good line system to get the latest transponder, or to forgo the transponder to protect the line system. Disaggregation breaks that coupling, and it is why the most widely deployed form of multi-vendor optical today is the alien wavelength model: a transponder from one vendor launched across an open line system from another, where the line-system vendor characterizes its network and the alien transponder is configured to meet a published envelope of frequency, launch power, and OSNR tolerance. Putting multiple vendors' components inside one line system is the emerging next step, and true ROADM-to-ROADM interoperation across vendors — where a lightpath is switched by one vendor's WSS and received by another's — remains the hard frontier, gated by passband shape, insertion loss, transient response, and crosstalk that a multi-wavelength interface specification has yet to make fully plug-and-play.

Both pressures point at the same architectural conclusion. The physics that makes a cross-vendor lightpath hard to evaluate is concentrated inside each vendor's line system, and the controller that already knows that line system's calibration is the vendor's own domain controller. So the natural place to keep the impairment model is local, inside the domain controller, where it has the measured characterization data and the proprietary algorithms to use it. The domain controller then exposes upward only what the orchestrator needs to stitch services across domains — abstract nodes, abstract links, available service endpoints, and feasibility answers — without exporting the analog detail. The hierarchy, in other words, is not an arbitrary layering choice. It falls out of where the hard optical knowledge actually lives. The boundaries between controllers tend to land exactly on the boundaries between vendor line systems, because that is where the QoT model and the calibration data naturally sit. Engineers coming from the IP world, where a flat controller over a uniform device base is reasonable, consistently underestimate how much this single fact shapes optical control. A deeper treatment of the impairment side lives in the MapYourTech notes on multi-vendor optical line system integration and on GSNR-based link planning.

3. The layered control model, end to end

The canonical stack has four tiers, and the work each tier does is defined by what it hides from the tier above. The network elements at the bottom hold the real state — wavelengths, amplifier gains, cross-connects, optical power. A domain controller sits above each vendor or technology island, talks to those elements in their native model southbound, and publishes an abstracted view northbound. The orchestrator, or parent controller, consumes those abstracted views from several domain controllers, holds a stitched end-to-end topology, and computes and provisions services that cross domain boundaries. The OSS/BSS on top deals only in customer-facing services and never touches the network directly. Each boundary between tiers is a control interface, and the same interface technology can appear at more than one boundary — which is what makes the structure recursive.

3.1 Three vocabularies, one architecture

The same stack is described by three standards communities, and a working engineer needs to read all three because vendor documentation switches between them without warning. The IETF ACTN framework (RFC 8453) names the controllers explicitly: a Customer Network Controller (CNC) represents the service consumer, a Multi-Domain Service Coordinator (MDSC) is the orchestrator, and a Provisioning Network Controller (PNC) is the per-domain controller. ACTN also names the interfaces — the CMI (CNC–MDSC Interface) is the business boundary between customer and operator, the MPI (MDSC–PNC Interface) is the boundary between orchestration and domain control, and the SBI is the southbound interface to the physical network. The framework is explicit that the relationship is recursive: an MDSC can be a client of a higher MDSC, so a hierarchy of MDSCs can partition work and the same primitives apply at every level.

The ONF SDN Architecture for Transport Networks (TR-522) describes the identical layering in SDN-architecture terms. A controller exposes an application-controller plane interface (A-CPI) upward to its clients and a data-controller plane interface (D-CPI) downward to the resources it controls, and the architecture builds hierarchy by recursion: one controller's A-CPI client can be another controller, so the orchestrator's southbound D-CPI to a domain controller is the same kind of interface as that domain controller's A-CPI to its own clients. ONF places virtualization and a resource database inside each controller, which is precisely where the abstraction is computed — the controller takes the detailed model of its resources and exposes a reduced, client-specific view across the A-CPI. The MDSC role itself is often decomposed into a service-coordination function and a network-orchestration function, sometimes drawn as a hierarchical MDSC over a lower MDSC, which matters when an operator wants a thin business-facing layer separate from the engine doing multi-domain path computation.

The TM Forum vocabulary, which dominates OSS conversations, maps the orchestrator onto service and resource orchestration and the domain controllers onto vendor domain managers, with the hierarchical or parent controller sitting between the OSS and the domain controllers. The terms differ but the shape is the same in all three: a customer-or-service tier, a multi-domain orchestration tier, a per-domain control tier, and the network elements. Reading a vendor datasheet that calls its product an MDSO, an SDN-O, a hierarchical controller, or a domain orchestrator is just a matter of locating it on this map. Figure 2 lines the three vocabularies up against the same four tiers and marks where each interface family lives.

Sanjay Yadav

Optical Communications & Network Automation Expert | Author of 3 Books for Optical Engineers | Founder, MapYourTech

Optical networking engineer with nearly two decades of experience across DWDM, OTN, coherent optics, submarine systems, and cloud infrastructure. Founder of MapYourTech. Read full bio →

Follow on LinkedIn

Related Articles on MapYourTech

Free · Jul 11, 2026

Connector Types and Their Loss Budgets: SC, LC, MPO

Automation · Jul 11, 2026

Cooled vs Uncooled Lasers: The Pluggable Power Trade-off

Automation · Jul 11, 2026

Automation Blast Radius: Scoping What a Bad Intent Can Touch

Analysis · Jul 11, 2026

ASE Channel Loading: Running a Line System Full From Day One