MANO vs Cisco NSO: What's the Difference?
MANO vs Cisco NSO: What's the Difference?
In modern telco architectures, service orchestration does not stop at SOM. Below SOM, two major platforms frequently appear: ETSI MANO (Management and Orchestration) for virtualised and cloud-native network functions, and Cisco NSO (Network Services Orchestrator) for device-level network service automation. Understanding what each does — and what it does not do — is critical for architects designing the fulfillment stack.
These three systems — SOM, MANO, and NSO — are complementary, not competing. Each operates at a different abstraction layer. Confusion arises because their names sound similar ("orchestrator", "service management") and their functional boundaries are not always obvious. This section clarifies the distinctions.
Quick Definitions
Side-by-Side Comparison
The following table compares ETSI MANO, Cisco NSO, and SOM across key architectural dimensions. Pay attention to the differences in target objects, lifecycle scope, and integration style — these are the primary differentiators.
ETSI MANO vs Cisco NSO vs SOM
| Dimension | ETSI MANO | Cisco NSO | SOM |
|---|---|---|---|
| Primary domain | NFV infrastructure and VNF/CNF lifecycle | Multi-vendor network device configuration | End-to-end service fulfillment orchestration |
| Standards body | ETSI NFV ISG (GS NFV-MAN 001) | Proprietary (Cisco), uses IETF YANG/NETCONF | TM Forum (eTOM, SID, ODA, TMF641) |
| Main purpose | Instantiate, scale, heal, and terminate VNFs/CNFs on virtualised infrastructure | Configure network devices (routers, switches, firewalls) in a transactional, model-driven way | Receive service orders from COM, decompose CFS → RFS, orchestrate fulfillment across all downstream systems |
| Target objects | VNFs, CNFs, NS (Network Services), VDUs, virtual links | Device configurations (interfaces, routing, ACLs, VPNs, QoS policies) | CFS instances, RFS instances, Service Order Items |
| Lifecycle managed | VNF/CNF instantiate → configure → scale → heal → terminate | Device config: create → modify → rollback → audit → delete | Service order: acknowledged → inProgress → completed/failed |
| Southbound interfaces | VIM APIs (OpenStack, Kubernetes), VNFM plugins | NETCONF/YANG, CLI (SSH), SNMP, REST, gNMI | TMF652 (to ROM), TMF APIs, custom adapters to MANO/NSO/workforce |
| Northbound interfaces | SOL005 REST APIs (NSD, VNF lifecycle, NS lifecycle) | REST API, NETCONF, CLI, web UI | TMF641 (from COM), TMF638 (to Service Inventory) |
| Day-0 / Day-1 / Day-2 focus | Day-0 (infrastructure prep) and Day-1 (VNF instantiation). Limited Day-2. | Day-1 (initial config push) and Day-2 (ongoing config changes, audits, compliance) | Spans Day-0 through Day-2 at the service level — delegates infrastructure and device work to MANO/NSO |
| Best-fit use cases | Deploying virtualised or cloud-native workloads (vFirewall, vRouter, 5G UPF, SD-WAN VNF) | Configuring L2/L3 services, VPN provisioning, firewall rules, multi-vendor device automation | End-to-end order fulfillment: broadband provisioning, enterprise service activation, multi-domain orchestration |
| Not best for | Physical device configuration, commercial order logic, service-level orchestration | VM/container lifecycle, infrastructure scaling, cloud orchestration | Direct device configuration, VNF lifecycle management, infrastructure provisioning |
| Integration style | Called by SOM or ROM to manage VNF/CNF lifecycle as part of service fulfillment | Called by SOM or ROM to push device configurations as part of resource activation | Called by COM to initiate fulfillment; calls MANO, NSO, ROM, and other systems as needed |
| Data / state ownership | VNF instance state, NS instance state, NFVI resource allocation | Device configuration state (intended config, actual config, config diff) | Service order state, CFS/RFS instance state (in Service Inventory) |
Where Each System Sits in the Stack
The three systems form a natural layered hierarchy. SOM sits at the top (service layer), MANO and NSO sit in the middle (resource/network layer), and the actual infrastructure and devices sit at the bottom.
Think of it this way: SOM decides what needs to happen (e.g., "provision a cloud firewall and configure an L3VPN"). It then calls the right specialist system for each task. MANO handles the cloud firewall VNF lifecycle (create the VM, attach networks, verify health). NSO handles the L3VPN configuration on the routers (push PE/CE configs). SOM tracks overall progress and reports back to COM.
The key insight is that each RFS type in the service catalog maps to a specific execution engine. The service catalog (or a routing table within SOM/ROM) defines these mappings:
- RFS:vFirewall → MANO (VNF lifecycle)
- RFS:L3VPN-Config → NSO (device configuration)
- RFS:GPON-Bearer → Element Manager or SDN Controller (access network)
- RFS:CPE-Provisioning → TR-069 ACS or Workforce (physical install)
- RFS:Cloud-Controller-Link → Cloud Platform API (SaaS integration)
SOM does not need to know how MANO or NSO work internally. It submits a resource order item via TMF652 or a direct adapter, and tracks the result. This is the principle of delegation with tracking.
In complex enterprise services (e.g., SD-WAN with cloud security), a single service order may require SOM to coordinate across multiple downstream systems simultaneously: MANO for VNF deployment, NSO for device configuration, an SDN controller for transport path setup, and a cloud API for SaaS integration. SOM's orchestration plan manages the dependencies across these domains — for example, the MANO-deployed vFirewall must be running before NSO pushes the routing policy that references it.
When to Use MANO, NSO, or Both
Decision Guide: Which System Handles What?
| Scenario | System(s) Involved | Why |
|---|---|---|
| Deploy a virtual firewall | MANO | VNF lifecycle: create VM, attach vNICs, verify health. No device config needed yet. |
| Configure an L3VPN across PE routers | NSO | Device configuration: push VRF, BGP, and interface configs to PE routers via NETCONF. |
| Deploy SD-WAN CPE with cloud gateway | MANO + NSO | MANO deploys the vCPE/CNF. NSO configures the underlay routing and IPsec tunnels on PE routers. |
| Provision a new GPON broadband service | Neither (EMS / SDN Controller) | Access network provisioning is typically handled by Element Management Systems, not MANO or NSO. |
| Install physical CPE at customer site | Neither (Workforce Management) | Physical installation requires a field technician, managed by WFM (TMF646). |
| Activate a cloud-based UCaaS service | Neither (Cloud API) | SaaS activation via the vendor's provisioning API — no network function or device config involved. |
Section 9.1 Key Takeaways
- MANO, NSO, and SOM are complementary systems operating at different abstraction layers — not competing alternatives
- MANO manages VNF/CNF lifecycle (instantiate, scale, heal, terminate) on virtualised infrastructure per ETSI standards
- NSO manages device configuration (create, modify, rollback, audit) across multi-vendor networks using YANG models
- SOM orchestrates end-to-end service fulfillment and delegates infrastructure and device work to MANO and NSO
- The RFS type in the service catalog determines which execution engine SOM delegates to
- Complex services may require both MANO and NSO working in coordination, with SOM managing cross-domain dependencies
- Neither MANO nor NSO replaces SOM — they lack commercial context, service-level state management, and cross-domain orchestration