1. Introduction

A domain controller and an orchestrator solve two different problems, and a surprising share of multi-vendor automation projects fail because someone builds the wrong one, or builds one that quietly does both jobs at once. A domain controller's job is narrow and deep: take everything the network elements from one vendor or one technology can do — a ROADM's wavelength cross-connects, a router's segment-routing policies, a transponder's modulation format — and present it as one consistent, abstracted model to whatever sits above it. An orchestrator's job is broad and shallow by comparison: take a service request, work out which domains it touches, ask each domain controller for a segment, and stitch the segments into one end-to-end service, all without ever opening a management session to a device itself.

The distinction sounds obvious stated this way. In practice it is not, because both layers are software, both expose an API, and both can technically reach further than their job description allows. A domain controller can be extended to hold a customer ID and a bandwidth entitlement. An orchestrator can be extended to hold a shelf-and-slot inventory and push a raw NETCONF edit-config when the abstraction underneath it is inconvenient. Neither extension breaks anything on day one. Both break the architecture within a year, because the entire reason to split the two layers apart — letting one team swap a vendor without the other team noticing, letting the business layer change a policy without a maintenance window on the network layer — depends on the boundary holding.

This article works through why the split exists, how the industry's standards bodies define it (IETF's ACTN framework, the ONF's Transport API, MEF's Lifecycle Service Orchestration, and TM Forum's Open Digital Architecture all converge on the same two-layer pattern independently), where the boundary actually sits in a running network, and what the two characteristic failure modes look like when engineering teams get it wrong. The examples lean on optical and IP transport because that is where the pattern is easiest to see in production today, but the architectural lesson generalizes to any domain-controller-plus-orchestrator deployment.

2. Two Jobs, Two Failure Modes

Every operator that runs more than one vendor domain eventually hits the same integration problem, and it is worth stating in its plainest form before naming any standard. If every system that needs to provision a service talks directly to every vendor's devices, the number of point-to-point integrations grows with the square of the number of domains: two domains need one integration, five domains need ten, ten domains need forty-five. Each of those integrations has to track its own vendor's YANG models, its own firmware quirks, and its own release cadence. A hierarchical control architecture breaks that growth by inserting one abstraction layer per domain — the domain controller — and giving every domain controller the same northbound interface, so the layer above only ever has to speak one language regardless of how many vendors sit underneath.

Figure 1: Point-to-point integrations required under a flat mesh, C(n,2) = n(n-1)/2, grow quadratically with domain count. Under a hierarchical model, each domain needs exactly one standardized interface to the orchestrator, so integrations grow linearly. This is a combinatorial illustration of the architectural motivation, not a measurement of any specific deployment.

That is the structural argument for splitting the stack in two. The functional argument is just as important: a domain controller and an orchestrator are optimized for opposite things. A domain controller is optimized for depth — it needs to understand every configuration knob, every alarm code, and every timing constraint of one vendor's equipment, because that detail is exactly what it is supposed to hide from everyone else. An orchestrator is optimized for breadth — it needs to understand every domain well enough to sequence a service across them, but it must not need to understand any one domain's internals, because the moment it does, adding a new domain means changing the orchestrator's code rather than just plugging in a new domain controller.

What a domain controller owns

A domain controller sits directly above the network elements in one technology or vendor domain and is the single point of read and write access to them. In an optical domain this typically means the ROADMs, amplifiers, and transponders on one open line system; in an IP domain it typically means the routers running one operator's segment-routing or MPLS design. The domain controller speaks whatever southbound protocol the devices actually support — NETCONF and YANG, gNMI with OpenConfig models, or a vendor's OpenROADM implementation — and translates that device-level state into one consistent northbound model, most commonly exposed through the ONF's Transport API (TAPI) on the optical side or an equivalent IETF-defined topology and service model on the packet side.

The domain controller also owns local path computation: given a request for a wavelength or an ODU circuit between two points inside its own domain, it is the domain controller — not the orchestrator — that knows which fiber spans have spare capacity, which amplifiers are running close to a gain limit, and which internal route actually satisfies the request. That computation depends on state the orchestrator deliberately does not have, because giving it that state would mean re-deriving one vendor's internal topology model inside a system meant to stay vendor-agnostic.

What an orchestrator owns

The orchestrator sits above every domain controller in scope and owns the parts of the problem that are cross-domain by nature or business-facing by nature: translating a customer or operations request into a set of segment requests, working out which domains a service must cross, sequencing the provisioning calls to each domain controller, and reconciling the individual domain responses into one end-to-end service view. It also typically owns the business rules that no domain controller should ever need to know about — service-level agreements, bandwidth entitlements, maintenance-window policy, and the mapping between a customer-facing product and the underlying network resources that deliver it.

Crucially, the orchestrator's topology view of each domain is abstracted, not detailed. It sees that a domain controller can deliver a 400G circuit between two edge points; it does not see, and should not need to see, which ROADM degree or which amplifier stage that circuit rides on. That is precisely the abstraction the standards bodies below formalize, and precisely the boundary that gets violated when teams take shortcuts under deadline pressure.

3. The Three-Tier Control Architecture

IETF's Abstraction and Control of TE Networks framework, published as RFC 8453, gives the cleanest formal statement of the pattern because it names three tiers rather than two. At the top, a Customer Network Controller (CNC) issues connectivity requests in the customer's own language — a bandwidth demand between two sites, a protection class, a required latency. In the middle, the Multi-Domain Service Coordinator (MDSC) is the orchestrator: it decomposes that request into per-domain segments, maintains an abstracted, network-wide topology built from what each domain chooses to expose, and coordinates the domains to deliver one coherent end-to-end service. At the bottom, one or more Provisioning Network Controllers (PNCs) are the domain controllers: each one manages a single technology or vendor domain and is the only system with write access to the devices in it.

Two named interfaces enforce the boundary. The CNC-MDSC Interface (CMI) carries customer intent down to the orchestrator and carries service status back up. The MDSC-PNC Interface (MPI) carries the orchestrator's per-domain requests down to each domain controller and carries that domain's topology and status back up. Neither interface allows the orchestrator to skip a layer: the MDSC never gets a direct channel to a network element, and the CNC never gets a direct channel to a PNC.

The Open Networking Foundation's Transport API formalizes the southbound half of this picture for optical and multi-layer transport. TAPI is a RESTCONF interface built on YANG models, purpose-built to sit "between SDN controllers and orchestrators," in the ONF's own framing, which is exactly the CMI/MPI split ACTN describes stated as one reusable protocol. The same TAPI interface runs twice in a real deployment — once between a domain controller and the devices or sub-controllers under it, and again between that domain controller and the orchestrator above it — with the upper instance carrying an abstracted view and the lower instance carrying device-level detail. Following ONF's 2023 merger of its open-source project portfolio into the Linux Foundation, TAPI's ongoing development now sits under the Linux Foundation's Open Network Models and Interfaces project, with the ONF Transport SDN interoperability testing historically run in partnership with the Optical Internetworking Forum continuing to validate multi-vendor TAPI deployments.

4. The Boundary and the Usual Mistake

Every architecture diagram of the three-tier model draws a clean horizontal line between the orchestrator and the domain controllers. Production systems rarely stay that clean, because the line is crossed one convenient shortcut at a time, and each individual shortcut looks harmless in isolation. There are exactly two directions the boundary gets violated, and they produce two different, equally expensive failure modes.

Business logic pushed down into the controller

The first failure mode happens when a domain controller — built to expose device state and accept provisioning requests — starts accumulating knowledge that belongs to the business layer: a specific customer's SLA thresholds, a hard-coded bandwidth entitlement, a maintenance-window calendar, or logic that decides which of two paths is "the good one" for a named account. This usually starts as a well-intentioned optimization: an engineer under deadline pressure adds a rule directly to the domain controller's provisioning template because that is the fastest place to make the immediate problem go away. The domain controller now works correctly for that one customer, on that one release.

The cost shows up the next time the business rule changes. Because the rule lives inside a vendor's controller — often behind that vendor's own release cycle, testing process, and change-control window — every SLA policy change now requires a network-layer software change, not a service-layer configuration change. Multiply that by every customer-specific rule accumulated the same way, and the domain controller has effectively become a second, undocumented orchestrator, coupled to one vendor's platform, that the actual orchestrator above it cannot see or reason about.

Device detail pulled up into the orchestrator

The second failure mode runs the opposite direction. An orchestrator is meant to work from an abstracted view — "this domain can deliver a 400G circuit between edge point X and edge point Y" — without needing to know which shelf, slot, or amplifier stage that circuit rides on. The violation happens when the orchestrator's data model grows fields for chassis inventory, vendor-specific alarm codes, or raw optical power readings, usually because someone needed one report or one dashboard and the fastest way to build it was to have the orchestrator query the device directly, sidestepping the domain controller's abstraction.

Cisco's own guidance on hierarchical controller design names the practical failure this produces with unusual directness: when more than one controller has write access to the same router, the operator faces the question of "who controls what" and "how will the router know who to prioritize," and every additional system with a management session open to a device is described as another "door opened" — another potential point of conflict and another point of security exposure. That is precisely what happens when an orchestrator, or any other system, bypasses the domain controller and reaches a device directly: it recreates the multi-writer conflict the hierarchical model exists to eliminate, even if the orchestrator's second connection was only ever meant to be read-only.

5. Building the Boundary Correctly

Keeping the boundary clean is mostly a design discipline rather than a technology choice, because the standards already give architects the vocabulary to draw the line correctly. Three practical habits keep a hierarchical control architecture healthy as it grows.

Name every interface and enforce it in code, not convention

MEF's Lifecycle Service Orchestration framework — now maintained under the Mplify Alliance following MEF's 2026 rebrand — is useful here because it names the boundary interfaces explicitly rather than leaving them implicit. LSO Presto governs orchestration within one provider across multiple technology domains; LSO Legato governs the north-south interface between a provider's business support systems and its Service Orchestration Functionality; LSO Sonata and LSO Cantata govern business interactions between providers; LSO Allegro and LSO Interlude govern operational interactions between providers. Each reference point has a defined scope, and — this is the part worth copying regardless of which standard an operator actually implements — a defined set of things it must never carry. Sonata is explicitly a business interface; it is not permitted to carry device-level provisioning detail, the same way TAPI's upper interface is not permitted to carry the same raw detail its lower interface carries.

Figure 4: MEF's Lifecycle Service Orchestration framework names a separate reference point for each interaction type — business versus operational, north-south versus east-west — rather than letting one generic API carry all of them. Structural count per the MEF/Mplify LSO reference architecture.

Give the orchestrator a service model, not a device model

The most reliable test for whether an orchestrator's data model has drifted across the boundary is whether it can answer a question about a device it has never been told about. A correctly scoped orchestrator can onboard a new domain controller from a fourth vendor and provision a service across it without a code change, because every domain controller it talks to exposes the same abstracted model, whether that model is TAPI's topology and connectivity services or an equivalent vendor-neutral schema. If adding a domain requires touching the orchestrator's code rather than its configuration, the model has already leaked device detail somewhere.

Give the domain controller a device model, not a policy model

The mirror test applies at the bottom of the stack: a correctly scoped domain controller can have its SLA policy changed by the orchestrator issuing a new request, with zero changes to the domain controller's own software. If a policy change requires a domain-controller release, business logic has leaked downward, and the fix is to move the rule up to the orchestrator layer where it was always supposed to live — even if that means the orchestrator now has to pass a parameter southbound that it did not pass before. Passing a parameter is a contract change on an existing interface; moving logic into the wrong layer is an architecture change that gets more expensive every quarter it is left alone.

6. Fault Domains and Operational Impact

The responsibility split has a direct operational consequence that is easy to overlook until an incident forces the question: which system is supposed to know what went wrong first? A clean boundary gives every fault a natural home. A device failure — a card reset, a fiber cut, an amplifier gain excursion — is detected and, where possible, locally protected by the domain controller, because the domain controller is the only system with the detailed state to recognize the failure and the only system with write access to react to it. The orchestrator learns about the failure only as a change in the abstracted service state the domain controller exposes: a circuit that was up is now degraded or down. It does not need, and should not receive, the raw alarm feed.

That containment is what keeps a multi-domain outage from becoming a multi-domain diagnosis problem. When a domain controller correctly owns its own fault domain, an operator troubleshooting a service failure can localize the problem to one domain from the orchestrator's service view alone, then hand the ticket to the team that owns that domain controller with a known starting point. When the boundary has already been violated — when the orchestrator has been pulling raw device alarms because a dashboard needed them — the orchestrator's event stream fills with detail its operators are not equipped to interpret, and the very abstraction that was supposed to speed up triage instead adds a second, redundant place to search.

The same logic governs where multi-domain path restoration decisions belong. A single-domain protection switch — moving traffic from a primary ROADM path to a pre-computed backup inside the same open line system — is fast enough to belong entirely inside the domain controller, typically completing before the orchestrator is even notified. A cross-domain restoration, where the replacement path has to be recomputed across two or more domain controllers, is by definition an orchestrator decision, because only the orchestrator holds the cross-domain view needed to pick a new combination of segments. Conflating the two by having the orchestrator arbitrate single-domain protection switching adds a coordination hop to a decision that used to complete in milliseconds; conflating them the other way, by having a domain controller attempt cross-domain restoration on its own, requires it to guess at capacity in a domain it cannot see.

7. Compared With Other Models

The domain-controller-plus-orchestrator pattern is not the only way to run a multi-vendor network, and it is worth being explicit about what the alternatives cost, because the hierarchical model is not free either — it trades integration simplicity for an extra hop on every cross-domain request.

A single, flat NMS per vendor, no orchestrator

The simplest alternative is to let each vendor's own network management system stand alone, with a human or a ticket-driven process coordinating any service that crosses domains. This works acceptably at small scale and fails predictably as domain count grows, for exactly the combinatorial reason described in Figure 1: every cross-domain service becomes a manually coordinated project, and the coordination burden grows faster than the network does. This is the starting point most operators are automating away from, not the target state.

A single monolithic controller for everything

The opposite alternative is a single controller that talks to every device across every vendor and technology directly, with no domain-controller layer at all. This removes one hop from every request, which looks attractive on a latency budget, but it means the one controller must understand every vendor's data model in full detail, and every vendor firmware upgrade becomes a risk to that shared controller's stability. It also reintroduces the multi-writer conflict from a different angle: any second system that also needs device state — a planning tool, a separate assurance platform — now has to either go through the monolith or open its own device sessions, which is the pattern the hierarchical model exists specifically to avoid, discussed in more detail in Northbound (NBI) and Southbound (SBI) Interface Protocols.

Domain controller and orchestrator, correctly bounded

The hierarchical model accepts one extra hop on every cross-domain request in exchange for a genuinely pluggable architecture: a new domain controller from a new vendor can be added by pointing it at the orchestrator's standard northbound-facing interface, with no change to the orchestrator's code, and a domain controller can be replaced — the classic vendor-swap scenario — without the orchestrator or the business layer above it needing to know it happened, provided the boundary in Figure 3 has been held. That property is the entire economic case for the extra hop, and it is only real if the boundary has not been quietly eroded the way Section 4 describes.

8. Where This Is Heading

The responsibility boundary between domain controller and orchestrator is not standing still, and the direction of travel in 2026 is adding a new layer on top of the orchestrator rather than blurring the boundary underneath it. TM Forum's Open Digital Architecture program used its June 2026 DTW Ignite event to launch AI-native extensions to the ODA specification — a governed execution layer that lets autonomous AI agents and large language models operate natively within the existing ODA component architecture and its Open APIs, alongside a Model-as-a-Service framework intended to give operators one control point for governing which AI models can act on which parts of the stack. The framing matters for this article's argument: the new layer is explicitly designed to sit on top of the existing orchestration and resource layers through their existing APIs, extending the same north-south boundary discipline to an agentic decision-maker rather than replacing it.

That direction lines up with TM Forum's broader Autonomous Networks maturity model, where Level 4 automation is defined as multiple closed loops running concurrently across domains, with AI agents increasingly positioned as the mechanism for reaching single-domain autonomy first before cross-domain coordination follows. An AI agent making provisioning or remediation decisions inside a domain controller's boundary is a natural extension of the domain controller's existing job; an AI agent making cross-domain sequencing decisions belongs at the orchestrator layer for the same reason a human operator's cross-domain decision does today. The boundary this article describes does not disappear when the decision-maker is a model instead of a person — if anything, the boundary matters more, because an agent that can act needs the same clear scope limits a domain controller already has, and for the same reasons.

On the standards side, the governance of the interfaces that enforce this boundary is also shifting. TAPI's continued development moved from the Open Networking Foundation into the Linux Foundation's Open Network Models and Interfaces project as part of ONF's broader 2023 portfolio transition, and MEF rebranded to the Mplify Alliance while continuing to publish new releases of the LSO Sonata and Presto SDKs under the new name. Neither change alters the architectural pattern; both are evidence that the industry keeps re-investing in the same boundary rather than replacing it, which is the strongest practical argument for building new automation against it rather than around it.

9. Conclusion

Four standards bodies that never coordinated with each other arrived at the same two-layer split because the split reflects a real constraint, not a design preference: a system that has to understand one vendor's devices in full detail cannot also stay vendor-agnostic, and a system that stays vendor-agnostic cannot also carry business rules that belong to one customer relationship. The domain controller and the orchestrator are not two implementations of the same idea; they are the two halves of a problem that only separates cleanly if each half resists the temptation to do a little of the other's job.

Holding that boundary is less a matter of picking the right platform than of a design habit an architecture team either keeps or lets slip one shortcut at a time. The question worth asking before any change ships to either layer is simple enough to fit on a whiteboard: does this belong to one vendor's devices, or does it belong to the service the customer is actually paying for. Everything in this article follows from answering that question honestly, and answering it the same way six months from now that it was answered today.

References

• IETF, RFC 8453 — Framework for Abstraction and Control of TE Networks (ACTN).
• IETF, RFC 8454 — Information Model for Abstraction and Control of TE Networks (ACTN).
• IETF TEAS Working Group, Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI).
• Open Networking Foundation / Linux Foundation Open Network Models and Interfaces Project, Transport API (TAPI) Specification and Release Notes.
• Mplify Alliance (formerly MEF), MEF 55.1 — Lifecycle Service Orchestration (LSO): Reference Architecture and Framework.
• TM Forum, Open Digital Architecture (ODA) Technical Architecture and AI-Native Extensions.
• Cisco, Routed Optical Networking Solution Guide — Crosswork Hierarchical Controller Components.
• Sanjay Yadav, "Optical Network Communications: An Engineer's Perspective" – Bridge the Gap Between Theory and Practice in Optical Networking.