1. Introduction

Send a 400G wavelength request into a modern optical network and two distinct systems react. One computes a path, picks a wavelength, programs the ROADM and the transponder, and then keeps optimizing the result as the network changes around it. The other never touches that decision — it inventories the card you just lit, watches its pre-FEC error rate for the next three years, and raises a ticket when an amplifier upstream starts to age. The first is the SDN controller. The second is the Network Management System.

The two get conflated because both, loosely, "manage the network." The distinction that actually matters is older and sharper: control versus management. Control is real-time service operations — deciding and acting on the live network on a clock measured in milliseconds to seconds. Management is lifecycle operations — the long-horizon bookkeeping of equipment, faults, performance, and contracts, on a clock measured in minutes to years. The Open Networking Foundation's SDN architecture (TR-521) frames the two not as separate boxes but as different aspects of the same thing, modelled as roles rather than planes.

This article works through that split in the optical context: what the controller is expected to do, what the NMS is expected to do, the southbound and northbound interfaces that both divide and connect them, the trust boundary that keeps them apart, the optical-specific control problems a packet controller never faces, how the layers stack in a real multi-vendor deployment, and the place where the clean line breaks down in production.

2. The control–management split

The ONF SDN architecture defines the controller as the node that performs the real-time convergence of a changing resource pool and a changing service demand toward an optimum, where even the optimization criteria can shift over time. "Real-time" and "convergence" carry the weight of that definition. The controller is a feedback element: it senses network state, computes against demand, acts, and senses again. Management is what the control and data planes are deliberately not built to do or not permitted to do — commissioning equipment, isolating faults, holding inventory, archiving performance, reconciling bills.

The architecture's first structural move is to separate the control plane from the data plane, the same split that lets a disaggregated OpenROADM control layer drive heterogeneous optics through one consistent model. Underneath sits the data plane: the physical glass and silicon — the reconfigurable add/drop node, the transponders, the line amplifiers. The diagram below places the two roles over that data plane. Management is drawn orthogonal to the control stack, not above it: it sets policy and absorbs telemetry across every plane at once rather than sitting in the service path.

The table below is the heart of the contrast. Read it as two answers to the same question — "what does this layer owe the network?" — that diverge on almost every axis: clock, decision authority, the state each holds as authoritative, the interfaces it speaks, and the trust domain it lives in.

3. What the controller is expected to do

A 400G wavelength request lands between two metro sites. The controller is expected to turn that intent into lit photons without a human in the loop, and to do it in seconds. First it consults its authoritative model of the network: the topology of fiber spans and degrees, and the spectrum occupancy across the C-band — which slots are taken, which are free, where the guard bands fall. Then it solves the routing-and-wavelength-assignment problem against that occupancy, picks a transponder mode and forward-error-correction setting, checks that the chosen path will actually close optically, and programs two things: the wavelength-selective-switch attenuation profiles at every ROADM the channel traverses, and the transponder's frequency and modulation.

The job does not end when the service comes up. The controller then holds that service against a changing network — re-optimizing channel power as spans age, defragmenting spectrum when a circuit tears down, and rerouting around a fiber cut. These operational interfaces are exposed and consumed through standard northbound and southbound interface protocols, the same discipline that turns vendor-specific CLI work into repeatable optical network automation. The protection numbers set the clock: an optical 1+1 selector switches in under 50 ms (a typical figure for loss-of-light triggered switching), while shared-mesh optical restoration completes in tens of seconds. Both are control-plane timescales, and both depend on the controller holding state that is current to the second.

The interface the controller exposes northward is increasingly the ONF Transport API. A connectivity request to a TAPI-speaking controller is a RESTCONF call against a YANG-modeled context — the controller takes the intent (endpoints, layer, capacity) and does the path computation and device programming itself.

POST /restconf/data/tapi-common:context/tapi-connectivity:connectivity-context
Content-Type: application/yang-data+json

{
  "tapi-connectivity:connectivity-service": [{
    "uuid": "och-svc-metro-0407",
    "connectivity-constraint": {
      "service-layer": "PHOTONIC_MEDIA",
      "requested-capacity": { "total-size": { "value": "400", "unit": "GBPS" } }
    },
    "end-point": [
      { "local-id": "A", "service-interface-point": {
          "service-interface-point-uuid": "sip-MET07-deg1" } },
      { "local-id": "Z", "service-interface-point": {
          "service-interface-point-uuid": "sip-MET08-deg2" } }
    ]
  }]
}

4. What the NMS is expected to do

One cut fiber produces forty alarms. The loss-of-light at the break is the root cause; the backward-defect indications, loss-of-frame, and downstream client failures cascading across ten network elements are symptoms. The NMS is expected to correlate that storm into a single root cause and a single ticket, so the operations team chases one fault instead of forty. That is the "F" in FCAPS — the fault, configuration, accounting, performance, and security functions that the ITU-T's TMN management model (M.3400) groups together as the work of the management layer.

Walk the rest of the set. Configuration management holds the inventory — every shelf, card, and pluggable, with software and firmware versions, plus configuration backups and the commissioning of new elements. Accounting covers usage records, SLA tracking, and the billing adjustment when a service breaches its commitment. Performance management archives the long history: pre-FEC bit-error-rate, Q-margin, and received optical power, trended over weeks and months so a slow degradation shows up as a line on a graph rather than a 3 a.m. outage. Security management owns the logs, role-based access control, and credential lifecycle. None of this runs on a control-plane clock; it runs on minutes-to-years. In optics, this layer grew out of the per-vendor element management system, federated upward into an NMS — the world before NETCONF and YANG gave operators a vendor-neutral way in, when each vendor's gear meant its own TL1 or SNMP interface and its own GUI.

The fault and performance side is where the NMS earns its keep day to day. The alarm log below shows the distinction concretely: the root-cause LOS, the downstream symptoms the NMS should suppress under it, the controller's restoration action, and the clear.

2026-06-24T08:14:02Z  NODE-MET-07  CRITICAL  LOS   och-os 1/3/2   (root: fiber cut, span MET07-MET08)
2026-06-24T08:14:02Z  NODE-MET-08  MAJOR     BDI   odu4   1/3/2   (downstream, suppressed under root LOS)
2026-06-24T08:14:03Z  NODE-MET-08  MAJOR     LOF   otu4   1/3/2   (downstream, suppressed)
2026-06-24T08:14:09Z  CONTROLLER   INFO      restoration: reroute MET07->MET12->MET08, retune 193.95 THz
2026-06-24T08:14:31Z  NODE-MET-08  OK        LOS cleared  och-os 1/3/2   (service restored, 29 s)

5. The interfaces between them

The protocol on the wire tells you which layer you are in. Southbound — the data-controller plane interface — the controller programs network elements with NETCONF or RESTCONF over SSH on port 830, and subscribes to streaming telemetry with gNMI. The data itself is shaped by YANG device models: OpenConfig where the operators want a vendor-neutral model, OpenROADM where the optical line system is disaggregated. Legacy management still rides TL1 and SNMP into the NMS. gNMI exists because polling does not scale to optical telemetry density; its dial-out subscriptions are reported to reach roughly a hundredfold the resolution of SNMP polling, a vendor-and-operator claim from the OpenConfig community rather than a fixed standard figure.

Northbound — the application-controller plane interface — is where the ONF Transport API sits. TAPI is a RESTCONF/YANG interface defined explicitly for the boundary between SDN controllers, orchestrators, management systems, and OSS. It exposes topology, connectivity, path-computation, notification, and OAM services across layers 0, 1, and 2 (photonic, OTN, and Ethernet), and the v2.4.0 release added impairment awareness and a unified alarm-and-performance model. The same TAPI runs between a domain controller and a hierarchical orchestrator — the upper interface carries an abstracted map, the lower one carries device-level detail, but the model is identical. This is the interoperability that multi-vendor operations consolidation depends on, and it is how a controller drives a third-party open line system it did not build. The IETF runs a parallel framework, ACTN (Abstraction and Control of TE Networks), for the same multi-domain problem.

6. Trust domains: the split as a security boundary

The 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, can hold a controller that requests services across an operator's optical layer — while that operator keeps the equipment's lifecycle, fault management, and audit firmly on its own side. The ONF architecture is explicit about why: the single strongest reason to keep a task out of the SDN control and data planes is that the controller may live in a customer trust domain, while business and security reasons demand that core management stay in the provider domain. The recommended default is to expose nothing rather than everything.

That default-deny posture is the mechanism. A network element exposes to its controller only the resources and the actions that policy permits; everything else is invisible, and an unexpected signal on an unconfigured port is treated as an exception to be raised, not traffic to be accepted. The management layer, sitting in the provider domain, instantiates that policy, installs the enforcement, and audits expected-versus-discovered state. This is the same boundary that makes multi-vendor optical line system integration tractable: the line system can be driven by a customer-chosen controller precisely because the provider's management retains the lock, the audit, and the system-of-record.

7. Optical-specific control: RWA, impairments, restoration

In a packet network the controller picks a path and the bits arrive or they don't. In an optical network the controller must also prove the light will arrive intact before it commits the circuit, and that is a problem no packet controller faces. Routing-and-wavelength-assignment is constrained: a wavelength must satisfy continuity (the same frequency end to end, unless a regenerator intervenes) and contiguity (enough adjacent spectrum for the channel's width). On top of that sits the physical-layer question — will the chosen path close? The controller computes an impairment-aware feasibility estimate, comparing the generalized signal-to-noise ratio the path will deliver against the minimum the transponder mode needs.

Restoration is where this becomes real-time. A colorless-directionless-contentionless ROADM lets the controller reroute a wavelength onto a diverse path and retune the transponder to whatever frequency is free there, the same switching that underpins optical protection and restoration. Shared-mesh optical restoration completes in tens of seconds — slower than the sub-50 ms reroute available to IP-over-DWDM protection, because the controller is recomputing feasibility and retuning hardware, not flipping a pre-armed selector. The mechanism has a clear boundary: impairment-aware path computation is only as trustworthy as the controller's link model, and that model drifts. Splices age, EDFA gain tilts, connectors degrade — and the record of that drift lives in the NMS's performance history, not in the controller's live snapshot.

8. The hierarchy in practice

In a real multi-vendor network the stack has four tiers, and the controller-versus-NMS question resolves differently at each. At the bottom are the physical network elements — ROADMs, transponders, amplifiers — grouped into domains, often one domain per vendor or per region. Above each domain sits an optical domain controller doing real-time control within its own scope: RWA, power balancing, and wavelength restoration for its slice of the network. Above the domain controllers sits a multi-domain orchestrator — a hierarchical controller that stitches services end to end across domains using the same TAPI, but at a higher abstraction; it sees a map of inter-domain links, not every device. And alongside the whole stack sits the OSS/NMS/BSS, holding the cross-domain system-of-record and running fulfillment and assurance.

This maps onto the IETF's ACTN naming directly: the domain controller is a provisioning network controller, the orchestrator a multi-domain service coordinator. The vendor reality matches the network-as-code picture — Cisco's Optical Network Controller exposes a TAPI northbound as an optical domain controller; Ribbon's Muse provides SDN domain orchestration above its Apollo line system, which itself speaks NETCONF/YANG with OpenROADM interworking; Ciena's MCP and Nokia's NSP play the domain-controller and management-and-control role for their platforms. The orchestrator that sits above them is frequently driven by intent-based networking at the top of the stack, turning a service request into multi-domain connectivity without an operator touching a device.

9. Convergence — and the failure mode at the seam

The line between controller and NMS has been migrating toward the controller for a decade, and the ONF architecture predicted it. The document is explicit that most functions historically performed by element and network management systems fall within the long-term scope of the SDN controller, and that today's managers may find themselves recast as application clients sitting north of the controller rather than as a separate stack beside it. The market has followed: vendor domain controllers now absorb fault and performance management, and platforms that began life as an NMS expose programmatic, model-driven provisioning. The hard boundary that does not move is the system-of-record and the audit — those shift north and become the thing the controller is measured against, not something that disappears.

That migration creates a specific failure mode, and it lives exactly at the seam between the two layers. Real-time control needs a current, trustworthy model of the network. But the ground truth — what is physically installed, which alarms are real versus suppressed symptoms, what the fiber plant degraded to last quarter — is maintained by the management layer. When the two disagree, control acts on fiction. A controller restoring against stale inventory reroutes a wavelength onto a span the operator retired weeks ago. A controller computing feasibility against an outdated impairment model commits a circuit that will not close. The reconciliation between the controller's live state and the NMS's system-of-record is where most real integration pain concentrates, and it is the reason the NMS cannot be reduced to a read-only dashboard.

10. Conclusion

The controller-versus-NMS question is not a product comparison; it is two clocks and two trust postures over the same glass. The controller decides and acts in real time, holds the live topology and spectrum, and is measured on how fast it provisions and restores. The NMS remembers, oversees, holds the audit, and is measured on whether its record matches the ground. Treat them as competing tools and you will either starve the control plane of automation or strip the management plane of its system-of-record — both are expensive mistakes.

As TAPI and model-driven telemetry mature, the controller will keep absorbing functions the NMS used to own, and the management layer will keep moving north toward orchestration and assurance. The boundary that endures is the one that matters most under failure: someone has to know what is actually installed and what has actually drifted, and the controller has to be reconciled against that truth before it acts. Design that seam first, and the rest of the architecture — the interfaces, the hierarchy, the trust domains — tends to fall into place around it.