7.720 min read

MANO & Network Orchestration Vendors

Previous sections covered the BSS/OSS vendor landscape — CRM, catalog, billing, and service management platforms. This section covers the orchestration layer: MANO platforms (VNF/CNF lifecycle management) and network orchestrators (device configuration and service provisioning). These are the execution engines that SOM delegates to when fulfilling service and resource orders, as covered in Module 9.

Vendor-Neutral Assessment

As with all vendor sections in this module, the following assessments are factual and vendor-neutral. Some platforms covered here are open-source community projects, not commercial products — they are assessed on the same criteria regardless. Strengths and limitations are based on publicly available product information and typical deployment patterns. Actual capability varies by release version and operator configuration.

Orchestration Vendor Categories

Orchestration platforms fall into three distinct categories, each serving a different layer of the stack. Understanding these categories is essential because most operators need a combination of platforms — not a single tool.

Orchestration Platform Categories

Category	What It Does	Examples
ETSI MANO Implementations	VNF/CNF lifecycle management: instantiate, scale, heal, terminate per ETSI NFV standards	ONAP, OSM, Ericsson Orchestrator, Nokia CloudBand/TAF, VMware Telco Cloud
Network Service Orchestrators	Model-driven device configuration, multi-vendor service provisioning, transactional commits	Cisco NSO, Nokia NSP, Juniper Paragon, Ciena Blue Planet
Network Automation Platforms	Workflow-driven network automation, intent-based operations, API gateway/aggregation	Itential, Anuta Networks

MANO Implementations

ONAP at a Glance

Type: MANO + Service Orchestration | License: Open source (Linux Foundation) | Origin: AT&T ECOMP + China Mobile Open-O merger (2017) | Community: AT&T, China Mobile, Vodafone, Deutsche Telekom, Orange, and others | Scope: Full-stack — design-time catalog, service orchestration, VNF/CNF lifecycle, closed-loop automation, policy framework

ONAP is the most comprehensive open-source orchestration platform in the telco industry. It covers the full stack: design-time catalog (SDC), service orchestration (SO), VNF/CNF lifecycle management (VF-C, multi-cloud), closed-loop automation (DCAE/CL), policy framework, and multi-cloud support (Kubernetes, OpenStack, Azure). ONAP originated from the merger of AT&T's ECOMP platform and China Mobile's Open-O project under the Linux Foundation.

Strengths: Broadest functional scope of any open-source MANO — covers design-time through runtime
Strengths: Large community with contributions from major Tier 1 operators worldwide
Strengths: Supports both VNF and CNF lifecycle management across multiple VIMs/CaaS platforms
Strengths: Includes design-time tooling (SDC) for service and resource modeling
Strengths: Closed-loop automation with policy-driven healing and scaling (DCAE/CL)

Limitations: Extremely complex to deploy and operate — 100+ microservices in a full deployment
Limitations: Steep learning curve requiring a dedicated platform team
Limitations: Resource-heavy with significant compute and memory footprint
Limitations: Community governance can slow decision-making and release cycles
Limitations: Not all components are production-mature — some remain in incubation

Best For

Tier 1 operators with dedicated platform teams who need a full-stack open-source alternative to commercial MANO. Not recommended for operators seeking a lightweight or quick-to-deploy solution.

Network Service Orchestrators

Cisco NSO at a Glance

Type: Network Service Orchestrator | License: Commercial (Cisco, acquired Tail-f Networks 2014) | Architecture: Model-driven, YANG/NETCONF native | Key Feature: NED (Network Element Driver) architecture for multi-vendor device management | Installed Base: Most widely deployed model-driven network orchestrator in SP networks

NSO is covered in depth in Section 9.3 (SOM → NSO Integration). In the vendor landscape context: Cisco NSO is the most widely deployed model-driven network orchestrator in service provider networks. Its NED (Network Element Driver) architecture enables multi-vendor device management across IOS-XR, Junos, Nokia SR OS, Huawei, and dozens of other platforms.

Strengths: Multi-vendor device support via NEDs (IOS-XR, Junos, Nokia SR OS, Huawei, and more)
Strengths: Transactional commits with automatic rollback across multiple devices
Strengths: YANG-native service models with dry-run and compliance audit
Strengths: Massive installed base in service provider and enterprise networks
Strengths: Strong ecosystem of NED developers and service model templates

Limitations: NED licensing per device type adds cost
Limitations: YANG service model development requires specialised skills
Limitations: Focused on device configuration — does not manage VNF/CNF lifecycle (complement with MANO)
Limitations: Cisco commercial licensing model
Limitations: Learning curve for YANG/XPath modelling

TMF API Integration Note

NSO does not natively expose TMF Open APIs. Integration with SOM/ROM typically requires an adapter layer that maps TMF652 resource orders to NSO RESTCONF/NETCONF calls. See Section 9.3 for detailed integration patterns.

Network Automation Platforms

A newer category of orchestration tooling — platforms that provide workflow-driven network automation and API aggregation. These sit above or alongside traditional orchestrators and focus on operational automation, self-service, and integration between disparate network tools.

Itential at a Glance

Type: Network Automation Platform | License: Commercial (Itential, founded 2015) | Focus: Low-code network automation, workflow orchestration, and API aggregation | Integration: Aggregates APIs from NSO, NSP, Ansible, Terraform, SD-WAN controllers, and cloud providers

Itential provides a low-code automation platform that aggregates network controller APIs (NSO, NSP, SD-WAN controllers, cloud APIs) into unified workflows. It focuses on operational automation: change management, compliance checks, provisioning workflows, and self-service portals. Itential bridges the gap between ITSM/BSS systems and the underlying network controllers.

Strengths: Low-code workflow builder reduces need for custom scripting
Strengths: API aggregation layer across heterogeneous network tools
Strengths: Pre-built integrations with NSO, Ansible, Terraform, and cloud APIs
Strengths: Strong operational automation (change management, compliance, self-service)
Strengths: Bridges the gap between ITSM/BSS and network controllers

Limitations: Relatively newer vendor with smaller installed base than NSO or ONAP
Limitations: Adds another layer to the stack (SOM → Itential → NSO/controllers)
Limitations: Not a replacement for NSO or MANO — complementary platform
Limitations: Commercial licensing
Limitations: Less telco-specific domain depth compared to NSO or MANO

Emerging: Nephio (Kubernetes-Native Network Automation)

Nephio

Type: Kubernetes-native network automation | License: Open source (Linux Foundation) | Origin: Google (2022) | Approach: Uses Kubernetes Resource Model (KRM) and GitOps to manage network function deployment and configuration | Backers: Google, Nokia, Telus, and several Tier 1 operators | Status: Pre-production (R3 release as of 2025)

Nephio represents the next-generation approach to network orchestration: rather than layering MANO on top of Kubernetes, it uses Kubernetes itself as the orchestration engine. Network function descriptors, site configurations, and infrastructure intent are all expressed as Kubernetes custom resources managed via GitOps workflows. Still early-stage (pre-production) but backed by Google, Nokia, and several Tier 1 operators. Worth watching as a potential long-term replacement for traditional MANO in cloud-native telco environments.

NFVI Platforms: What Sits Below MANO

MANO orchestrates VNF/CNF lifecycle — but it cannot do this without an NFV Infrastructure (NFVI) layer beneath it. NFVI provides the compute, storage, and networking resources that VNFs actually run on. The relationship is hierarchical: SOM dispatches service/resource orders → MANO (NFVO/VNFM) manages VNF lifecycle → VIM allocates infrastructure resources on the → NFVI platform (hypervisor, OpenStack, Kubernetes). Choosing an NFVI platform is an infrastructure decision, but it directly constrains which MANO and VIM combinations are available.

SOM → MANO → NFVI: The Full Stack

SOM Dispatches Resource Order

SOM

SOM decomposes a CFS into RFS items and routes VNF-related RFS items to MANO via ETSI SOL005 API (TMF652 resource order or direct). SOM does not know or care which NFVI platform hosts the VNF.

NFVO Validates and Plans Deployment

MANO (NFVO)

The NFVO reads the VNF Descriptor (VNFD), validates resource requirements (vCPUs, RAM, storage, virtual links), selects the target data centre / availability zone, and instructs the VNFM to instantiate the VNF.

VNFM Instantiates the VNF

MANO (VNFM)

The VNFM manages VNF lifecycle: instantiate, configure, scale, heal. It calls the VIM to allocate the required infrastructure resources (VMs, containers, virtual networks, storage volumes).

VIM Allocates Resources on NFVI

VIM

The VIM (e.g., OpenStack Nova/Neutron, vCenter, Kubernetes API server) translates the resource request into platform-native operations: create VM/pod, attach virtual NICs, allocate storage, apply security groups. The VIM is the bridge between MANO and the physical/virtual infrastructure.

NFVI Hosts the VNF Workload

NFVI

The NFVI platform (hypervisor cluster, OpenStack cloud, Kubernetes cluster) runs the VNF workload on physical servers. NFVI provides compute isolation (VMs or containers), virtual networking (OVS, SR-IOV, DPDK), and storage (Ceph, local SSD, SAN). The VNF is now running and reachable.

Status Propagates Back Up the Stack

NFVI → VIM → MANO → SOM

VIM confirms resource allocation → VNFM confirms VNF instantiation → NFVO confirms NS deployment → MANO reports success to SOM → SOM updates service inventory (TMF638) and notifies COM.

VIM Is the Glue

MANO never talks to NFVI directly — it goes through the VIM (Virtualised Infrastructure Manager). OpenStack is both a VIM and an NFVI platform. For VMware, vCenter is the VIM and vSphere/ESXi is the NFVI. For Kubernetes, the API server is the VIM and the worker nodes are the NFVI. When evaluating NFVI vendors, always check which VIM interface MANO uses to communicate with them.

VMware vSphere / vCloud at a Glance

Type: Hypervisor-based NFVI | License: Commercial (Broadcom, acquired VMware 2023) | VIM: vCenter Server | Workload Type: VMs (VNFs) | Installed Base: Dominant telco NFVI — majority of Tier 1 operators run VNFs on vSphere | Status: Incumbent but facing migration pressure due to Broadcom licensing changes

Strengths: Largest installed base in telco NFVI — proven, stable, well-understood by infrastructure teams
Strengths: Mature VM lifecycle management, live migration (vMotion), HA, and DRS for workload balancing
Strengths: Strong SR-IOV and DPDK support for high-performance VNF networking
Strengths: Extensive VNF vendor certification — most VNF vendors certify on vSphere first

Limitations: Broadcom acquisition has driven significant licence cost increases and bundle changes
Limitations: Proprietary platform creates vendor lock-in — migration off vSphere is expensive
Limitations: Less cloud-native than OpenStack or Kubernetes — CNF support via Tanzu is still maturing
Limitations: Per-socket licensing model is costly at telco scale (thousands of servers)

Broadcom Impact

The Broadcom acquisition (2023) has accelerated NFVI migration planning across the industry. Many operators are evaluating OpenStack or Kubernetes as alternatives to reduce VMware dependency. However, migrating running VNFs off vSphere is a multi-year effort — VMware will remain the dominant telco NFVI for the near term.

Orchestration Vendor Comparison Matrix

Orchestration Vendors — Capability Comparison

Vendor / Platform	Type	License	VNF Lifecycle	CNF/K8s	Multi-Vendor Devices	TMF API Alignment	Maturity
ONAP	MANO	Open source	Yes (SO + VF-C)	Yes (K8s plugin)	Via external controllers	Partial (community-driven)	Production (Tier 1)
ETSI OSM	MANO	Open source	Yes (SOL005)	Yes (Juju/Helm)	Via external controllers	SOL005 compliant	Production (mid-tier)
Ericsson Orchestrator	MANO	Commercial	Yes	Yes	Ericsson-first	Ericsson-aligned	Production (Tier 1)
Nokia CloudBand/TAF	MANO	Commercial	Yes	Yes (TAF)	Nokia-first	Nokia-aligned	Production (Tier 1)
VMware Telco Cloud	MANO	Commercial	Yes	Yes (Tanzu)	VMware NFVI-first	VMware-aligned	Production (large base)
Cisco NSO	Network Orchestrator	Commercial	No (pair with MANO)	No	Yes (NED architecture)	Adapter required	Production (dominant)
Nokia NSP	Network Orchestrator	Commercial	Partial	Partial	Nokia-first	Nokia-aligned	Production
Juniper Paragon	Network Orchestrator	Commercial	No	Partial (Contrail)	Juniper-first	Limited	Production (evolving)
Ciena Blue Planet	Service Orchestrator	Commercial	No	No	Yes (inventory federation)	Yes (TMF641/638)	Production
Itential	Automation Platform	Commercial	No	Via integrations	Via API aggregation	No (ITSM-aligned)	Production (growing)
Ansible	IaC Tool	Open source	No	Via K8s modules	Yes (modules)	No	Mature (ubiquitous)
Nephio	K8s-native automation	Open source	N/A	Yes (native)	Via KRM	Emerging	Pre-production
VMware vSphere	NFVI (hypervisor)	Commercial	Hosts VNFs	Via Tanzu	N/A (infrastructure)	N/A	Dominant incumbent
Red Hat OpenStack	NFVI (cloud platform)	Open source / Commercial	Hosts VNFs	Via OpenShift	N/A (infrastructure)	N/A	Production (Tier 1)
StarlingX / Wind River	NFVI (edge)	Open source / Commercial	Hosts VNFs	Yes (integrated K8s)	N/A (infrastructure)	N/A	Production (edge)
Kubernetes (CaaS)	NFVI (container)	Open source	N/A (CNFs only)	Yes (native)	N/A (infrastructure)	N/A	Production (growing)

When to Choose: Decision Guide

Choosing an orchestration platform depends on your operator profile, existing stack, and strategic direction. The following guide maps common operator profiles to recommended platform combinations.

Orchestration Decision Guide by Operator Profile

Operator Profile	Recommended Approach	Reasoning
Tier 1, multi-vendor, full-stack open source	ONAP + Cisco NSO	ONAP for VNF/CNF lifecycle, NSO for multi-vendor device config — combined for end-to-end orchestration
Tier 1, single-vendor RAN/core (Ericsson)	Ericsson Orchestrator + Cisco NSO	Ericsson MANO for own NFs with proven integration, NSO for multi-vendor WAN/transport configuration
Mid-tier, standards-first, lean team	ETSI OSM + Cisco NSO	OSM for ETSI-compliant MANO with simpler operations, NSO for device config — less complex than ONAP
Enterprise / SD-WAN focus	Itential + Cisco NSO	Itential for workflow automation and self-service portals, NSO for device-level configuration
Cloud-native greenfield	Nephio (future) + MANO (transition)	Start with OSM or ONAP today, evaluate Nephio as it matures for K8s-native operations
Brownfield, VMware-heavy NFVI	VMware Telco Cloud + Cisco NSO	VMware MANO for existing vSphere VNFs, NSO for device config — plan CNF migration path

Section 7.7 Key Takeaways

Orchestration vendors fall into three categories: MANO implementations (VNF/CNF lifecycle), network service orchestrators (device config), and automation platforms (workflow/API aggregation)
ONAP is the most comprehensive open-source MANO but carries significant operational complexity — best for Tier 1 operators with dedicated platform teams
OSM provides lightweight ETSI-compliant MANO — ideal for mid-tier operators, PoCs, and standards-first deployments
Cisco NSO dominates multi-vendor device orchestration with its NED architecture — but does not manage VNF/CNF lifecycle (pair with MANO)
Commercial vendor MANOs (Ericsson, Nokia, VMware) excel at managing their own NFs but offer weaker multi-vendor support
Itential fills the gap between ITSM/BSS and network controllers with low-code workflow automation and API aggregation
Nephio represents the future direction: Kubernetes-native network automation using KRM and GitOps — pre-production today but backed by major industry players
MANO cannot operate without NFVI — the full stack is SOM → MANO (NFVO/VNFM) → VIM → NFVI. VMware vSphere dominates today but Broadcom licensing changes are accelerating migration to OpenStack and Kubernetes
Most operators need a combination: MANO for VNF/CNF lifecycle + NFVI platform for compute/storage/networking + network orchestrator for device config + automation platform for operational workflows