Domain Integration: The Universal Pattern
The integration pattern shared by every OSS-to-network conversation: service intent β resource intent β domain commands β network state. Establishes the abstraction contract domain controllers must hold, the protocols that carry each layer (NETCONF/YANG, gNMI, 3GPP SBI, RADIUS, TR-069/USP, legacy SNMP/TL1/SOAP), data-model alignment (SID β YANG β proprietary), and the rollback shapes that exist by domain class. Anti-patterns: scripting the EMS, imperative payloads, assumed cross-domain ACID.
Section 11.1 established the strict layering above the network β COM/SOM, cross-domain orchestration, ROM / domain execution. This section establishes the integration pattern that all four layers share when they actually talk to each other. Before going domain-by-domain into IP/MPLS, mobile core, transport, and access, the universal pattern needs to be made explicit, because the failure modes are largely the same regardless of which technology the bottom layer is configuring.
The pattern is a chain of progressively concrete contracts. Each layer consumes a contract from above, applies its own decomposition, and exposes a more specific contract below. The orchestrator never commands a router. The catalog never knows about NETCONF. The discipline of which layer translates which abstraction is what keeps the architecture from collapsing into a brittle script that talks directly from order capture to a CLI session.
The Integration Chain: Intent β Commands β Network State
Every fulfilment in OSS, regardless of domain, traverses the same chain of abstraction reductions. The terms differ by vendor β service request, service intent, technical intent, resource order, configuration payload β but the shape is invariant.
The four contracts in every integration
| Contract | Speaks the language of | Owned by | Example |
|---|---|---|---|
| Service Intent | Customer-visible product / service catalog (CFS) | COM/SOM | "Activate Enterprise SD-WAN, Site A, 100 Mbps, 99.99% SLA" |
| Resource Intent | Technical service decomposition (RFS) | Cross-domain orchestration | "L3VPN VRF cust-A, transport class gold, route-target 65000:1001 across PE-1 and PE-7; CPE config profile EntSDWAN-100M; IP block from pool ENT-SDWAN-V4" |
| Domain Commands | Controller-specific service models (YANG, 3GPP NF profiles, RADIUS attributes) | ROM / domain controllers | NETCONF edit-config to PE-1 with l3vpn-svc YANG payload; UDM Nudm_SDM update for slice S-NSSAI; OLT line-card PON profile push |
| Network State | Native device configuration / running state | Network elements | Updated VRF, BGP-VPN routes, applied QoS policy, live data session, lit ONT |
The Abstraction Contract: What Domain Controllers Hide
A domain controller is judged by what it refuses to expose. The orchestrator above it should not have to know which vendor's router is at PE-7, which IOS-XR version is running, or which YANG service model maps to which device-level CLI. If those concerns leak upward, the orchestration layer becomes a vendor-specific scripting layer.
Synchronicity, Idempotency, Transactionality
Every integration in the chain has to make explicit choices about three properties. Most failed transformations get these wrong because the choice was implicit.
- Synchronicity β does the caller block waiting for the result, or get an acknowledgement and a callback?
- Idempotency β if the caller retries the same request, does the system end up in the same state, or does it double-apply?
- Transactionality β if a multi-step operation fails halfway, can the system roll back to the prior state, or are partial changes left behind?
COM/SOM is asynchronous and stateful β orders run for minutes to weeks, with jeopardy management and human steps. Cross-domain orchestration is asynchronous within itself but exposes a synchronous-looking faΓ§ade to SOM via TMF641 lifecycle states. Domain controllers are typically synchronous within a transaction window (NSO's commit-or-rollback) but asynchronous against the network (commits queue, devices apply at their own pace). Network elements are eventually-consistent β the change you sent is the change that will be running, eventually, unless something diverges.
Idempotency is non-negotiable at every layer because retries are inevitable. A service order that re-issues on duplicate event must not double-provision. A NETCONF edit-config that re-applies must not re-allocate a VLAN. The discipline is to make every NBI and every payload declarative β "this is the desired state" β not imperative ("add this VRF"). Declarative payloads are idempotent by construction.
True transactional rollback exists within a domain controller (NSO commit, MANO transaction) and within a service-order saga at the SOM layer. It does not exist across domains in real time. If five domain commits succeed and the sixth fails, the rollback is a compensating saga at the orchestration layer β not a network-wide ACID rollback. Designers who assume cross-domain ACID will discover this the first time a partial failure leaves a half-provisioned service in production.
- Within-controller: transactional, candidate-config commit, automatic rollback on failure.
- Cross-domain: compensating saga β explicitly modelled rollback steps per domain, with their own failure modes.
- Against the live network: never truly atomic β there is always a window where some elements have applied and others have not.
The Protocol Inventory
The protocols that carry these contracts cluster by purpose, not by technology. The same domain often supports several β a modern PE router speaks NETCONF, gNMI, and CLI simultaneously. The choice of protocol is an integration decision, not a network-engineering decision, and it determines the shape of every adapter above it.
Protocols by purpose, with where they live
| Protocol family | Purpose | Typical layer | Typical domains |
|---|---|---|---|
| TMF Open APIs (TMF622/641 service order, TMF640 service activation, TMF638 service inventory, TMF634 service test) | Cross-layer service contracts β order, activation, inventory, test | COM/SOM β XDO β ROM | All β these are layer-to-layer, not domain-specific |
| NETCONF / YANG, RESTCONF | Model-driven device and service configuration | ROM β network elements / domain controllers | IP/MPLS, transport, access (modern OLT/BNG) |
| gNMI / gNOI | Streaming telemetry, OS install, device certificate management | ROM / assurance β network elements | IP/MPLS, transport (modern controllers) |
| 3GPP Service-Based Interfaces (Nudm, Nudr, Nnssmf, Namf, Nsmf, Nausf) | 5GC NF-to-NF and orchestrator-to-NF interactions | XDO / mobile core ROM β 5GC NFs | Mobile core (5G) |
| Diameter (S6a, Sh, Gx, Gy) | Subscriber data and policy interactions | OSS β HSS / PCRF | Mobile core (4G/EPC) |
| RADIUS / Diameter NAS | Subscriber session authorisation, policy push | BNG β AAA β subscriber | Fixed access (BNG/BRAS), Wi-Fi |
| TR-069 / TR-369 (USP) | CPE management β config, firmware, diagnostics | OSS β ACS β CPE | Fixed broadband (CPE/ONT) |
| SNMP, syslog, TL1 | Legacy device management and event collection | EMS β legacy network elements | SDH/SONET, legacy IP, legacy transport |
| SOAP / CORBA / proprietary EMS | Legacy vendor-specific EMS adapters | OSS β EMS | Legacy domains across all technologies |
Data Model Alignment: SID, YANG, and Vendor-Proprietary
Each layer in the chain has its own modelling language. TM Forum SID describes the business and service entities at the COM/SOM and orchestration layers. YANG (IETF, OpenConfig, vendor) describes service and device models at the controller layer. Vendor-proprietary schemas (Nokia model-driven controllers, Huawei iManager, legacy EMS) describe whatever the vendor chose. Translating between these is a major source of integration cost, and one of the most common sources of catalog leakage.
Where each modelling language belongs
| Modelling language | Native to | Strengths | Limits |
|---|---|---|---|
| TM Forum SID | Business / service abstractions | Vendor-neutral, well-defined relationships, mature | Coarse-grained β does not describe device configuration; loose around resource detail |
| IETF YANG (l3vpn-svc, l2nm, slice-ng) | Service-level network models | Standard, vendor-neutral, machine-validated | Limited per-domain coverage; vendors extend with proprietary deviations |
| OpenConfig YANG | Device-level configuration and telemetry | Multi-vendor adoption, operator-driven | Coverage gaps in mobile core, access, optical |
| Vendor-native YANG / proprietary | Device feature surface | Complete coverage of vendor features | Locks adapter to vendor; no portability |
| 3GPP information models (28-series) | Mobile network functions and slicing | Standard, slice-aware, NF-aware | Mobile-only; needs adaptation to align with SID |
Service with serviceCharacteristics is not the same as a YANG l3vpn-svc:vpn-service β the SID instance is service-lifecycle-aware and SLA-aware, the YANG instance is configuration-aware. The mapping must be explicit and modelled, typically in a service-design tool, not implicit in adapter code.Failure and Rollback by Domain Class
Rollback is one of the most over-claimed properties in OSS. Every product datasheet mentions rollback. Almost no two products mean the same thing by it. The shape of rollback is dictated by what the domain is doing, and the orchestrator above must understand which kind it is consuming.
Rollback shapes by domain class
| Domain class | Failure window | Rollback shape | Typical surprise |
|---|---|---|---|
| Stateless device config (NETCONF candidate-commit) | Within a single transaction | Candidate config discarded automatically; running config unchanged | Multi-device commits may succeed on some, fail on others β that is a saga, not a transaction |
| Stateful service provisioning (HSS, BNG, OLT) | Per-element after commit | Compensating action β explicit "delete subscriber", "deactivate session"; not automatic | Compensating action may itself fail; idempotent retry required |
| Long-running async (5GC slice instantiation, FTTH activation) | Hours to days, with human steps | Saga with persisted state at the orchestrator; partial completion explicitly modelled | Saga state outliving an orchestrator restart β durable state is mandatory |
| Live network state (BGP routes, traffic flows) | Always β the network is live | Compensating change β there is no "undo"; only "apply the inverse" | Inverse may not produce identical state due to convergence and external events |
Common Anti-Patterns in Domain Integration
Integration anti-patterns and why they fail
| Anti-pattern | What it looks like | What breaks first |
|---|---|---|
| The orchestrator scripts the EMS | XDO sends per-device CLI through an EMS adapter; no service model in between | First feature change in the EMS breaks the integration; rollback becomes impossible because there is no service-level state to roll back to |
| Imperative payloads | Service intent expressed as "add VRF X, then BGP peer Y, then route-map Z" | Idempotent retry is impossible; replay creates duplicates; reconciliation between desired and running state cannot be computed |
| Cross-domain ACID assumed | Service order saga assumes all-or-nothing across IP, mobile, and access | First partial failure leaves a half-provisioned service in production; ops are paged; manual cleanup becomes routine |
| Treating every domain like NETCONF/YANG | Same adapter pattern applied to mobile core, BNG, and SDH EMS | Mobile core requires 3GPP SBI semantics; legacy EMS requires session-based RPC; "one adapter framework" forces lowest-common-denominator design |
| Vendor-native YANG leaking up | XDO consumes vendor-specific YANG models because the controller did not abstract them | Replacing the controller becomes a multi-quarter project because the orchestration layer is now coupled to one vendor's schema |
| No domain capability metadata | Orchestrator hard-codes which domain handles which service type | Adding a new domain (or a new vendor in an existing domain) requires orchestrator code change instead of metadata change |
Section 11.2 Key Takeaways
- Every domain integration is the same chain: service intent β resource intent β domain commands β network state. Each layer reduces abstraction; skipping a reduction is a leak.
- A domain controller is judged by what it refuses to expose. If vendor-specific concerns leak upward, the orchestration layer becomes a vendor-specific scripting layer.
- Synchronicity, idempotency, and transactionality must be explicit choices per integration. Idempotency is non-negotiable; cross-domain ACID is a fiction.
- Modern protocols (NETCONF/YANG, gNMI, 3GPP SBI, USP) coexist permanently with legacy (SNMP, TL1, CORBA, SOAP). Designs that assume migration to a single protocol are planning for a state that may not arrive.
- SID, YANG, and vendor-proprietary models are translated, not aliased. The mapping must be explicit and modelled, not implicit in adapter code.
- Rollback is domain-class-specific. Within-controller rollback is transactional; cross-domain rollback is a compensating saga; against live network state there is no rollback, only inverse change.
- The fastest integration disaster is to script the EMS from the orchestrator, with imperative payloads, against an assumption of cross-domain ACID. Every Tier-1 transformation has at least one programme that did this.