9.315 min read

SOM → Cisco NSO Integration

Cisco NSO (Network Services Orchestrator) is one of the most widely deployed network automation platforms in service provider networks. When SOM needs to provision or modify device-level configurations — L3VPNs, firewall rules, QoS policies, interface configurations — NSO is frequently the execution engine. This section covers how SOM integrates with NSO, the available integration patterns, and where ownership boundaries lie.

Cisco NSO (Network Services Orchestrator)

A model-driven, transactional network automation platform. NSO uses YANG data models to represent device configurations and service models. Its core engine maintains an in-memory copy of every managed device's configuration (the CDB — Configuration Database) and uses NETCONF, CLI, SNMP, or REST to synchronise intended configuration with actual device state. NSO supports atomic transactions: a configuration change either succeeds on all affected devices or rolls back completely.

NSO's key capabilities relevant to SOM integration include:

Service Models (YANG): NSO defines network services as YANG models. An L3VPN service model, for example, abstracts PE router configurations into a high-level service interface (VPN name, endpoints, bandwidth, routing protocol)
Transactional Configuration: configuration changes are applied atomically across multiple devices. If one device fails, all changes roll back — critical for multi-device service provisioning
Device Abstraction (NEDs): Network Element Drivers (NEDs) translate between NSO's normalised data model and vendor-specific CLI/NETCONF syntax. This enables multi-vendor automation from a single service model
Compliance and Audit: NSO can detect configuration drift (actual vs intended), generate compliance reports, and automatically remediate non-compliant devices
Dry-Run and Commit Queue: NSO supports dry-run (preview changes without applying), commit queues (asynchronous device configuration), and rollback capabilities

Integration Patterns: SOM to NSO

There are three primary patterns for integrating SOM with NSO. The right choice depends on your architecture maturity, the role of ROM in your stack, and whether you need event-driven or synchronous interactions.

SOM calls NSO's REST or NETCONF API directly to create/modify/delete service instances in NSO. SOM maps RFS order items to NSO service model payloads and submits them. NSO executes the configuration change and returns the result.

Pros: Simplest integration, lowest latency, fewest moving parts. SOM has direct visibility into NSO responses and can react immediately to success/failure.
Pros: NSO's dry-run capability can be leveraged by SOM for pre-validation before committing.
Cons: Tight coupling between SOM and NSO. SOM must understand NSO service model payloads (YANG structure), versioning, and error semantics.
Cons: SOM becomes dependent on NSO availability — if NSO is down, SOM cannot progress affected order items.
Best for: Architectures where SOM has a direct relationship with NSO and ROM is not a separate system (or does not exist).

Worked Example: L3VPN Provisioning via NSO

This walkthrough demonstrates a typical enterprise L3VPN provisioning flow where SOM orchestrates the end-to-end service and NSO handles the device-level configuration across PE routers.

End-to-End: Enterprise L3VPN via NSO

COM Receives Enterprise VPN Order

COM

An enterprise customer orders "Managed L3VPN — 3 Sites". COM creates a Product Order with three order items (one per site). The Product Specification "Enterprise L3VPN" maps to CFS:L3VPN-Service.

COM Submits Service Order to SOM

COM → SOM

COM decomposes the product order into a Service Order with one CFS:L3VPN-Service item (containing three site endpoints as characteristics). Submitted to SOM via TMF641.

SOM Decomposes CFS → RFS

SOM

SOM reads the service catalog: CFS:L3VPN-Service decomposes into RFS:PE-VRF-Config (one per PE router / site) and RFS:CE-Interface-Config (one per CE router / site). For 3 sites with 3 PE routers, SOM generates 3 PE RFS items and 3 CE RFS items.

SOM Determines Execution Engine

SOM

The service catalog maps RFS:PE-VRF-Config and RFS:CE-Interface-Config to NSO as the execution engine. SOM builds resource order payloads containing: VPN name, VRF route distinguisher, route targets, per-site interface details, BGP AS numbers, and bandwidth.

SOM Submits to NSO (via ROM or Direct)

SOM → NSO

SOM submits the resource order to NSO. The payload maps to NSO's L3VPN YANG service model: /l3vpn:l3vpn-svc/vpn-services/vpn-service. NSO receives the request and begins transaction processing.

NSO Calculates Device Configurations

NSO

NSO's service model logic (YANG + template/Python mapping) calculates the required device-level configurations for each PE router: VRF definition, BGP VPNv4 neighbour, sub-interface, VLAN, and QoS policy. NSO uses NEDs to translate to vendor-specific syntax (IOS-XR, Junos, etc.).

NSO Pushes Configuration to PE Routers

NSO → Network Devices

NSO opens a transaction and pushes configurations to all 3 PE routers atomically via NETCONF. If any PE router rejects the configuration (syntax error, resource conflict), NSO rolls back all changes and returns an error to SOM.

NSO Confirms Commit Success

NSO

All 3 PE routers accept the configuration. NSO commits the transaction, updates its CDB (Configuration Database) with the new intended state, and returns a success response with the service instance reference.

SOM Updates Service Inventory

SOM

SOM receives the success response, marks all RFS order items as completed, and updates Service Inventory (TMF638) with the new CFS:L3VPN-Service instance. The instance record includes: VPN ID, site endpoints, PE router references, and status = active.

SOM Notifies COM

SOM → COM

SOM publishes a ServiceOrderStateChangeEvent (state: completed) to COM. COM marks the product order as completed, triggers billing activation for the L3VPN service, and sends a customer notification confirming the VPN is active.

RFS-to-Execution Engine Mapping

Not all RFS types route to NSO. The following table shows how common RFS types map to different execution engines, with reasoning for each assignment. This mapping is typically defined in the service catalog or a routing table within SOM/ROM.

RFS Type → Execution Engine Routing

RFS Type	Execution Engine	Reasoning
RFS:PE-VRF-Config	Cisco NSO	Device-level VRF, BGP, and interface configuration on PE routers — NSO's core competency with multi-vendor NED support
RFS:CE-Interface-Config	Cisco NSO	CE router interface and routing configuration, typically NETCONF/CLI managed
RFS:Firewall-Policy-Config	Cisco NSO	Firewall rule sets and NAT policies pushed to physical or virtual firewalls via NEDs
RFS:vFirewall-Instance	ETSI MANO	VNF lifecycle (VM/container deployment, scaling, healing) — MANO's domain, not NSO's
RFS:vRouter-Instance	ETSI MANO	Virtual router deployment as a VNF/CNF on NFVI — infrastructure lifecycle management
RFS:GPON-Bearer	EMS / SDN Controller	Access network provisioning via Element Management System or SDN controller — proprietary per access vendor
RFS:Transport-Path	SDN Controller	MPLS/Segment Routing transport path setup via SDN controller (e.g., Cisco WAN Automation Engine, Nokia NSP)
RFS:CPE-Provisioning	Workforce Management	Physical CPE installation requires a field technician — managed via TMF646 Appointment API
RFS:DNS-Record	Cloud/Infrastructure API	DNS record creation via cloud provider API (Route53, Azure DNS, on-prem DNS server API)
RFS:SaaS-Tenant	Vendor Cloud API	SaaS service activation via the vendor's provisioning API (e.g., UCaaS, security-as-a-service)

SOM vs NSO: Ownership Split

One of the most common integration mistakes is duplicating state or responsibility between SOM and NSO. The following table clearly delineates what each system owns. If an item is in the "SOM owns" column, NSO must not independently manage it — and vice versa.

SOM vs NSO Ownership Boundaries

Concern	SOM Owns	NSO Owns
Service order lifecycle	Yes — acknowledged → inProgress → completed/failed states	No — NSO does not understand service orders or TMF641
Customer context	Yes — customer ID, account, service address, contract terms	No — NSO is customer-unaware; it deals with network service instances and devices
CFS instance state	Yes — CFS:L3VPN-Service (active, suspended, terminated) in Service Inventory	No — NSO does not maintain CFS-level records
RFS-to-engine routing	Yes — SOM/ROM determines which engine handles each RFS type	No — NSO does not decide what to provision; it executes what SOM/ROM requests
Cross-domain orchestration	Yes — SOM coordinates MANO + NSO + EMS + workforce dependencies	No — NSO only manages its own device configuration domain
Device configuration intent	No — SOM does not know device CLI syntax or YANG paths	Yes — NSO owns the mapping from service model to device-level configuration
Transactional device commit	No — SOM does not push configs to devices	Yes — NSO owns atomic multi-device transactions with rollback
Configuration compliance	No — SOM does not audit device configurations	Yes — NSO detects config drift, generates compliance reports, and remediates
NED management	No — SOM does not interact with device-specific drivers	Yes — NSO manages NEDs for each vendor/device type
Service model (YANG)	No — SOM does not define NSO YANG service models	Yes — NSO owns service model design, templates, and mapping logic
Retry and compensation logic	Partially — SOM retries at the RFS order item level and triggers compensation	Partially — NSO handles transaction rollback at the device level
Billing trigger	Yes — SOM signals COM when service is active, triggering billing	No — NSO has no concept of billing or commercial lifecycle

Source of Record: SOM + NSO Domain

Source of Record: Orchestration & Network Automation

Entity	System of Record	System of Engagement	System of Reference	Notes
Service Order	SOM	COM (initiator)	Service Catalog (TMF633)	SOM creates and manages the service order through its lifecycle; COM is the initiator but not the owner
Resource Order	ROM	SOM (initiator)	Resource Catalog (TMF634)	ROM manages resource order lifecycle; SOM submits resource orders but does not own them
Device Configuration (intended)	Cisco NSO (CDB)	SOM/ROM (triggers changes)	—	NSO's CDB is the authoritative record of intended device configuration; SOM triggers changes but does not store device config
VNF/CNF Instance	MANO (NFVO/VNFM)	SOM/ROM (triggers lifecycle)	—	MANO owns VNF/CNF instance state (running, scaling, terminated); SOM references these instances but does not manage their lifecycle directly
Service Instance (CFS)	Service Inventory (TMF638)	SOM (creates/updates)	Service Catalog (TMF633)	Service Inventory is the SoR for active CFS instances; SOM writes to it upon service activation/modification/cessation

Section 9.3 Key Takeaways

NSO excels at model-driven, transactional device configuration across multi-vendor networks using YANG and NEDs
Three integration patterns exist: Direct API (simplest), Adapter via ROM (cleanest separation), and Event-Driven (maximum decoupling)
The RFS type in the service catalog determines whether SOM routes to NSO, MANO, an SDN controller, or another engine
SOM owns service context (customer, order, CFS state) while NSO owns device configuration intent (YANG models, CDB, NEDs)
NSO provides atomic multi-device transactions — if one device fails, all changes roll back, which SOM leverages for reliable provisioning
Never duplicate state: SOM should not store device configurations, and NSO should not track service orders or customer context
NSO's CDB (Configuration Database) is the source of record for intended device configuration — not SOM, not a CMDB