ROM's Southbound Edge: Network Automation & Interfaces

What sits below ROM — network orchestrators and SDN controllers, the NETCONF/YANG, gNMI and SNMP interfaces they use, and the multi-domain network elements they configure. A map, not a tutorial.

Resource Order Management is the last BSS/OSS domain that reasons in TM Forum resource terms. ROM receives a TMF652 resource order, decides which network resources must change, and records the outcome in Resource Inventory. Everything below ROM speaks the network's language instead: device models, configuration protocols, controllers, telemetry. This section maps that territory. An architect needs to know it exists and what each layer owns — not to operate it.

ROM is the last layer that reasons in TMF resource terms. Below that line, the network's own models and protocols take over.

Below the southbound boundary: the automation layer holds intended state, the interface layer carries it to devices, and the network elements are where it becomes real. Intent flows down; state and telemetry flow back up.

The three layers below ROM

Automation layer — network orchestrators and SDN controllers

Products such as Cisco NSO, Nokia NSP, OpenDaylight- and ONOS-class SDN controllers, and Itential-style automation platforms. They are model-driven: a resource order from ROM becomes a change to a service or device model, and the platform computes and pushes the device-level configuration that realises it. This layer holds the network's intended state — what the configuration should be — and is the natural home of transactional rollback, dry-run and multi-device change.

Interface layer — how the automation layer reaches devices

NETCONF/YANG is the transactional, model-driven configuration protocol (IETF RFC 6241, data models in YANG). RESTCONF exposes the same YANG models over HTTP (RFC 8040). gNMI over gRPC, usually with OpenConfig vendor-neutral models, adds streaming telemetry — devices push state rather than being polled. SNMP remains the pervasive legacy monitoring protocol, and CLI is still screen-scraped more often than anyone admits. A real network estate uses all five at once.

Network elements — the multi-domain reality

IP/MPLS routers, optical transport, mobile RAN and core (increasingly cloud-native functions), SD-WAN edges and public-cloud constructs. Each domain typically has its own controller and often its own EMS (see 7.4). ROM rarely touches a device directly; it talks to whichever controller or EMS owns that domain, and that controller talks to the device.

Two directions of traffic

Intent goes down

ROM issues a resource order

ROM

A TMF652 order names the resource and the change required — a VLAN, an L3 VPN endpoint, a slice — in TMF terms.

The controller computes device configuration

Automation layer

The orchestrator maps the change onto its service and device models and works out the exact configuration for each affected element.

Configuration is pushed over the interface layer

Interface layer

NETCONF, RESTCONF or gNMI carries the change to the device, transactionally where the protocol supports it.

State comes back up. The same interfaces carry the network's actual state upwards: streaming telemetry, alarms, configuration drift. This upward path matters more than it looks. It is what lets Resource Inventory be reconciled against the network (7.4's inventory-drift problem), and it is the raw material of assurance in Trouble-to-Resolve. A design that only thinks about the downward path produces an inventory that is right on day one and wrong by day thirty.

The concepts you'll hear

These terms belong to the network-automation world rather than to BSS/OSS, but an OSS architect meets them constantly. Each is glossed in one line, architecturally. None is covered in depth here.

Term	What it means, architecturally	Where it sits
Config-as-Code / GitOps	Network configuration is versioned, reviewed and deployed like software — a git repository is the source of truth for intended state.	Automation layer
Zero-touch provisioning (ZTP)	A device fetches its own configuration from the automation layer on first boot; no engineer logs in.	Automation layer → device (first boot)
Intent-based networking (IBN)	Declare the outcome ("these two sites must reach each other at this bandwidth"); the controller derives and maintains the configuration.	Automation layer
Closed-loop automation	Telemetry triggers a remediation action without a human in the loop — the upward path feeding straight back into the downward path.	Both directions
Digital twin	A model of the network used for what-if analysis before a change is pushed for real.	Automation layer — design-time for what-if; runtime only if kept in sync

Where the boundary actually sits

The ROM / automation boundary is a design decision, not a given

Products span it. Cisco NSO can be the executor that ROM calls, or it can be wrapped so that it is the ROM for a domain. Blue Planet does both depending on deployment. What must not be blurred is ownership: ROM owns the TMF652 resource order and writes its outcome to Resource Inventory (TMF639); the automation layer owns device state. The network is the truth for actual state, inventory is the truth for assigned state, and 7.4 is explicit that inventory must be fed from the network, not maintained independently. The decision to make before go-live is therefore the reconciliation policy — auto-correct inventory, or flag and hold — not which side is right.

Standards you will see named: IETF RFC 6241 (NETCONF) and RFC 8040 (RESTCONF); YANG (RFC 7950) and the OpenConfig model set; the ONF for SDN and its transport API (TAPI); MEF LSO for inter-carrier service orchestration; 3GPP for mobile management interfaces. They are listed here so the names resolve, not because this section explains them.

Section 7.5 Key Takeaways

ROM is the last layer that thinks in TMF resource terms; below the southbound boundary the network's own models and protocols take over.
Three layers sit below ROM: the automation layer (intended state), the interface layer (NETCONF/YANG, RESTCONF, gNMI, SNMP, CLI) and the network elements themselves, per domain.
Traffic runs both ways. The upward path — telemetry, alarms, drift — is what keeps Resource Inventory honest and feeds assurance.
Config-as-Code, ZTP, intent-based networking, closed-loop automation and digital twins are automation-layer concepts an OSS architect must be able to place, not necessarily operate.
The ROM / automation boundary is chosen, not inherited. Fix the reconciliation policy between inventory and network before go-live.