ROM's Southbound Edge: Network Automation & Interfaces
Last updated 12 Oct 2026
At a glance
ROM is the last layer that reasons in TM Forum resource terms. Below it, the network’s own world takes over: automation platforms and controllers that hold intended state, protocols that carry it to devices, and the network elements themselves. An architect needs to know what each layer owns and where the boundary sits, not how to operate it.
The picture
ROM is the last layer that reasons in TMF resource terms. Below that line, the network's own models and protocols take over.
How it works
Not a fixed chain
ROM → automation platform → EMS/NMS → network is one common shape, not a rule. ROM may call a domain controller directly; an automation platform such as Cisco NSO may sit beside an EMS rather than above it; one vendor platform may combine several of these roles. The layers below are roles, not necessarily separate products.
Three layers below ROM
- Automation layer: network orchestrators and SDN controllers (for example Cisco NSO, Nokia NSP, OpenDaylight- or ONOS-based controllers, Itential). They are model-driven: a change from ROM becomes a change to a service or device model, and the platform computes and pushes the device configuration. This layer holds the network’s intended state and is the natural home of dry-run, multi-device change and transactional rollback.
- Interface layer: how configuration reaches devices. NETCONF/YANG for transactional, model-driven configuration; RESTCONF for the same models over HTTP; gNMI over gRPC, often with OpenConfig models, for streaming telemetry; SNMP for legacy monitoring; CLI, still scripted more often than anyone admits. Most estates use all of them.
- Network elements: IP/MPLS, optical transport, RAN and mobile core (increasingly cloud-native), SD-WAN edges and public-cloud constructs. Each domain usually has its own controller and often its own EMS (10.3).
Intent goes down
ROM issues a resource order
TMF652 or the platform’s own APIIt names the resource and the change, in TMF terms: a VLAN, an L3 VPN endpoint, a slice.
The controller computes configuration
Automation layerThe change is mapped onto service and device models to work out exactly what each affected element needs.
Configuration is pushed
Interface layerNETCONF, RESTCONF or gNMI carries it to the device, transactionally where the protocol allows.
State comes back up
The same interfaces carry actual state upwards: streaming telemetry, alarms, configuration drift. This path is what lets resource inventory be reconciled against the network, and it is the raw material of assurance in Trouble-to-Resolve. A design that only plans the downward path produces an inventory that is right on day one and wrong by day thirty.
Terms you will hear
| Term | What it means, architecturally | Where it sits |
|---|---|---|
| Config-as-code / GitOps | Configuration is versioned, reviewed and deployed like software; a repository holds intended state | Automation layer |
| Zero-touch provisioning | A device fetches its own configuration on first boot; nobody logs in | Automation layer → device |
| Intent-based networking | Declare the outcome; the controller derives and maintains the configuration | Automation layer |
| Closed-loop automation | Telemetry triggers remediation without a person in the loop | Both directions |
| Digital twin | A model of the network for what-if analysis before a change | Design time; runtime only if kept in sync |
Standards you will see named: NETCONF (RFC 6241), RESTCONF (RFC 8040), YANG (RFC 7950) and OpenConfig; the ONF for SDN and its Transport API (TAPI); MEF LSO for inter-carrier orchestration; 3GPP for mobile management interfaces. They are listed so the names resolve, not explained here.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Resource order | ROM | — | SOM | TMF652. ROM writes its outcome to resource inventory. |
| Assigned resources | Resource inventory | ROM | Automation layer | TMF639. The truth for what has been assigned. |
| Intended device and service configuration | Automation platform or controller, where one is used | — | ROM, resource inventory | In a config-as-code estate the repository may hold it instead. Name one. |
| Actual device state | The network element | — | Automation layer, EMS, resource inventory | The network is the truth for what is actually configured. |
| Telemetry and alarms | Network element, collected by EMS, NMS or controller | — | Assurance | Usually reaches assurance without passing through ROM. |
In practice
Products span the ROM and automation boundary. Cisco NSO, for example, can be the executor that ROM calls, or be wrapped so that it acts as the ROM for a domain; other orchestration platforms are deployed in similar ways. What must not blur is ownership: ROM owns the resource order and writes its outcome to resource inventory; the automation layer owns intended device state; the network owns actual state.
Each domain usually arrives with its own controller and management stack, chosen by the network team for network reasons. The OSS architect rarely chooses these; the job is to integrate them, agree where intended state lives for each domain, and make sure the upward path feeds inventory.
The decision to make before go-live is the reconciliation policy between inventory and network: correct inventory automatically, or flag and hold. Leaving it undecided means it gets decided ad hoc, one incident at a time.
The trade-off
What it solves
Separating ROM from the automation layer keeps TMF resource reasoning above the line and vendor- and protocol-specific detail below it, so each can change without rewriting the other.
What it does not solve
- Inventory drift. The boundary only helps if the upward path actually reconciles inventory with the network.
- Multi-domain consistency. Each domain’s controller still has its own models and behaviour.
What it adds
- Two places that can look like the record of intended state (ROM and the automation platform), unless ownership is written down.
- A model per domain in the automation layer, kept aligned with the resource catalog.
- Telemetry and drift handling as a continuous process, not a project deliverable.
Architecture decision
Where does the ROM / automation boundary sit for this domain?
ROM calls the automation platform as an executor
Choose when ROM handles several domains and needs one place to coordinate resource orders across them
The automation platform acts as ROM for the domain
Choose when one domain dominates, the platform already models it well, and a separate ROM would only pass orders through
Breaks if Both layers hold their own copy of what was assigned, and nobody owns reconciling them with each other and with the network.
Takeaways
Key Takeaways
- ROM is the last layer that thinks in TMF resource terms; below it the network’s own models and protocols take over.
- Below ROM sit an automation layer (intended state), an interface layer (NETCONF/YANG, RESTCONF, gNMI, SNMP, CLI) and the network elements.
- ROM → automation → EMS → network is one common shape, not a mandatory chain.
- The upward path (telemetry, alarms, drift) keeps resource inventory honest and feeds assurance.
- The boundary is a design choice; fix the reconciliation policy before go-live.
Check yourself
Inventory says a VPN endpoint is configured; the automation platform says it is not. Which is right?Show answerHide
Neither by default: the network element is the truth for actual state. Check the device, then correct whichever record is wrong under the agreed reconciliation policy.
Why does a design that only plans the downward path go wrong?Show answerHide
Without telemetry, alarms and drift flowing back up, inventory is never reconciled with the network and assurance lacks its inputs. Inventory is right on day one and wrong soon after.