9.218 min read

The MANO Domain: SOM + MANO + NFVI

ETSI NFV MANO (Management and Orchestration) defines a standardised architecture for managing the lifecycle of virtualised and cloud-native network functions. In a telco fulfillment stack, MANO sits below SOM — SOM delegates VNF/CNF lifecycle operations to MANO, which in turn manages the virtualised infrastructure through VIM. This section provides a deep dive into MANO's internal architecture, how SOM interacts with it, and where the responsibility boundaries lie.

Understanding MANO is essential for any architect working on NFV-based services (virtualised firewalls, SD-WAN gateways, 5G network functions, virtualised routers) because it defines who owns what in the VNF lifecycle — and getting this wrong leads to duplicated state, conflicting lifecycle actions, and operational chaos.

Key MANO Building Blocks

NFVI (NFV Infrastructure)

The physical and virtual compute, storage, and networking resources on which VNFs and CNFs run. NFVI includes bare-metal servers, hypervisors (KVM, VMware ESXi), container runtimes (Docker, containerd), virtual switches (OVS, VPP), and the underlying physical network. NFVI is the "cloud" that MANO manages — it does not include the VNFs themselves.

VIM (Virtualised Infrastructure Manager)

The system that manages NFVI resources: allocating compute, storage, and network to VNF instances. Common VIM implementations include OpenStack (for VM-based VNFs), Kubernetes (for CNFs), and VMware vCloud Director. VIM exposes APIs that MANO uses to create/delete VMs, attach virtual networks, and monitor resource utilisation. VIM does not understand "services" — it only understands infrastructure primitives.

MANO (NFVO + VNFM)

The ETSI management and orchestration layer comprising two key functional blocks: NFVO (NFV Orchestrator) manages Network Service (NS) lifecycle and coordinates across multiple VNFs and VIMs. VNFM (VNF Manager) manages individual VNF instance lifecycle — instantiation, configuration, scaling, healing, and termination. Together, NFVO and VNFM translate high-level NS requests into infrastructure-level operations via VIM.

SOM's Role Above MANO

SOM does not interact with NFVI or VIM directly. SOM submits RFS-level resource order items (e.g., "deploy vFirewall instance for customer X with 4 vCPUs and 8GB RAM") to MANO via SOL005 APIs or a ROM adapter. SOM tracks the overall service fulfillment lifecycle while MANO handles the VNF-specific lifecycle. SOM is responsible for the service context (which customer, which service order, what the CFS is); MANO is responsible for the infrastructure execution (which VM, which NFVI cluster, which virtual network).

NFVO, VNFM, and VIM Responsibilities

MANO's three functional blocks have clearly separated responsibilities. Understanding which block does what is essential for correct integration design.

The NFVO is the top-level orchestrator within MANO. It manages Network Services (NS) — composite services made up of multiple VNFs connected by virtual links. NFVO is the entry point for external systems like SOM.

NS Lifecycle Management: instantiate, scale, update, heal, and terminate Network Services
NS Catalog (NSD): stores Network Service Descriptors that define which VNFs are included, how they connect, and what scaling/healing policies apply
VNF Package Management: onboards and manages VNF packages (VNFDs) that describe individual VNF requirements
Multi-VIM Coordination: places VNF components across multiple VIMs/data centres based on affinity, anti-affinity, and latency rules
Resource Grant Decisions: decides whether a VNF instantiation request can be granted based on available NFVI capacity
Northbound API: exposes ETSI SOL005 REST APIs for external consumers (SOM, ROM, OSS portals)

Responsibility Boundaries

The following table maps each layer in the SOM-MANO-NFVI stack to its specific responsibilities, state ownership, and typical interfaces. This is the definitive reference for "who owns what".

SOM → MANO → VIM → NFVI Responsibility Map

Layer	Responsibilities	Owns Lifecycle State?	Typical Interfaces	Examples
SOM	Service order orchestration, CFS/RFS decomposition, cross-domain coordination, service inventory updates	Yes — Service Order state, CFS/RFS instance state	TMF641 (northbound from COM), SOL005 / TMF652 (southbound to MANO/ROM)	Ericsson SO, Nokia NSP Service Management, IBM Cloud Pak Network Automation
NFVO	NS lifecycle management, multi-VNF coordination, VNF placement, resource grant decisions	Yes — NS instance state, VNF package state	SOL005 (northbound), SOL003 (to VNFM), Or-Vi (to VIM)	ONAP, Open Source MANO (OSM), Ericsson Cloud Manager, Nokia CloudBand
VNFM	Individual VNF lifecycle (instantiate, scale, heal, terminate), Day-1 config application	Yes — VNF instance state (instantiated, configured, started, terminated)	SOL003 (from NFVO), Vi-Vnfm (to VIM), Ve-Vnfm (to VNF for config)	Generic VNFM (part of NFVO), vendor-specific VNFMs (e.g., Cisco ESC, Nokia CBAM)
VIM	Infrastructure resource management (compute, storage, network), resource monitoring, image management	Yes — VM/container state, virtual network state	OpenStack API, Kubernetes API, VMware vSphere API	OpenStack, Kubernetes, VMware vCloud, Azure Stack, AWS Outposts
NFVI	Physical hardware: servers, NICs, switches, storage arrays. No management logic — just execution.	No — managed by VIM	IPMI/Redfish (bare-metal), PXE (boot), hardware monitoring agents	Dell PowerEdge, HPE ProLiant, Cisco UCS, white-box servers

Day-0, Day-1, and Day-2 Operations

The "Day-0/1/2" model describes the lifecycle phases of a VNF or network service. Each phase has different activities and ownership. Understanding this model is critical for designing clean handoffs between SOM, MANO, and operations teams.

Day-0 / Day-1 / Day-2 Lifecycle Phases

Phase	What Happens	Who Owns It	Examples
Day-0: Design & Onboard	VNF package creation, VNFD/NSD design, image preparation, onboarding to NFVO catalog, connectivity template design	VNF vendor + NFV platform team	Create VNFD for vFirewall (CPU/RAM/storage requirements, virtual links, scaling policies). Upload VM image to VIM. Onboard package to NFVO.
Day-1: Instantiate & Configure	VNF instantiation (VM/container creation), initial configuration, network attachment, integration testing, service activation	MANO (instantiation) + SOM (service context) + NSO or config tool (initial device-level config)	NFVO instantiates NS. VNFM creates VMs via VIM. Cloud-init applies base config. NSO pushes routing policies to connect vFirewall to customer VPN.
Day-2: Operate & Optimise	Ongoing configuration changes, scaling (manual/auto), healing, monitoring, software upgrades, compliance audits, performance tuning	Operations team + MANO (scaling/healing) + NSO (config changes) + SOM (change orders)	Auto-scale vFirewall from 2 to 4 instances during peak traffic. Apply security patch to VNF image. Modify firewall rules via NSO. Upgrade VNF to new software version.

Day-2 Is Where Most Time Is Spent

Day-0 happens once (per VNF type). Day-1 happens once per VNF instance. But Day-2 is ongoing for the entire lifetime of the service — potentially years. Architectures that optimise only for Day-0/1 and neglect Day-2 operability create long-term operational debt. Ensure MANO supports auto-scaling policies, healing workflows, and in-service software upgrades from the start.

Worked Example: Cloud Firewall CNF for SD-WAN

This end-to-end walkthrough shows how a cloud-native firewall (CNF) is deployed as part of an SD-WAN service. It illustrates how SOM, MANO, and NSO work together across the full stack.

End-to-End: Cloud Firewall CNF Deployment

COM Receives Enterprise Order

COM

An enterprise customer orders "SD-WAN Premium with Cloud Security". COM creates a Product Order containing the SD-WAN bundle. The product specification maps to three CFS types: CFS:SD-WAN-Overlay, CFS:Cloud-Firewall, and CFS:Managed-Security.

COM Submits Service Order to SOM

COM → SOM

COM decomposes the product order into three Service Order Items (one per CFS) and submits a Service Order to SOM via TMF641. SOM acknowledges and begins orchestration planning.

SOM Decomposes CFS → RFS

SOM

SOM reads the service catalog and decomposes CFS:Cloud-Firewall into: RFS:CNF-Firewall-Instance (→ MANO), RFS:Firewall-Policy-Config (→ NSO), and RFS:Security-Monitoring-Feed (→ SIEM API). Dependencies: the CNF must be running before NSO pushes policies.

SOM Requests CNF Deployment from MANO

SOM → MANO (NFVO)

SOM submits a resource order to MANO (via ROM or direct SOL005 call) requesting instantiation of the "Cloud-Firewall-CNF" NS, specifying: customer tenant ID, target NFVI cluster, resource sizing (4 vCPUs, 8GB RAM), and virtual network attachments.

NFVO Orchestrates NS Instantiation

NFVO

NFVO reads the NSD (Network Service Descriptor), determines the VNF components (firewall CNF + log-collector sidecar), selects the target Kubernetes cluster based on placement policies, and sends instantiation requests to VNFM.

VNFM Deploys CNF via VIM (Kubernetes)

VNFM → VIM (Kubernetes)

VNFM translates the VNFD into Kubernetes resources: Helm chart deployment (firewall pods, services, config maps), persistent volume claims for log storage, and network attachment definitions for data-plane interfaces. Kubernetes (VIM) creates the pods and reports readiness.

VNFM Applies Day-1 Configuration

VNFM

VNFM applies initial configuration to the firewall CNF: base security policy template, management interface registration, health-check endpoints, and logging configuration. The CNF transitions to "configured" state.

MANO Reports Success to SOM

MANO → SOM

NFVO publishes an NS lifecycle change notification indicating the firewall NS is instantiated and operational. SOM receives this event and marks the RFS:CNF-Firewall-Instance order item as completed. The dependency gate for RFS:Firewall-Policy-Config is now open.

SOM Requests Policy Config from NSO

SOM → NSO

With the CNF running, SOM now submits a resource order for RFS:Firewall-Policy-Config to NSO (via ROM or direct adapter). NSO pushes customer-specific firewall rules (source/destination ACLs, NAT rules, URL filtering policies) and configures PE routers to route customer traffic through the firewall CNF.

SOM Completes Service Order

SOM → COM

All RFS items are complete. SOM updates Service Inventory (TMF638) with the new CFS:Cloud-Firewall instance (status: active, linked to the CNF resource and firewall policy). SOM publishes a ServiceOrderStateChangeEvent to COM. COM marks the product order item as completed and activates billing.

Common Pitfalls

The SOM-MANO boundary is frequently misunderstood. The following pitfalls are observed in real-world deployments and should be avoided.

Pitfall: Treating MANO as an NFVI Builder

MANO manages VNF lifecycle on top of existing NFVI — it does not build the infrastructure itself. NFVI provisioning (racking servers, installing hypervisors, configuring underlay networking) is a separate concern handled by infrastructure automation tools (e.g., MAAS, Foreman, Terraform). Expecting MANO to provision bare-metal servers or install Kubernetes clusters conflates two different layers and leads to scope creep in MANO implementations.

Pitfall: SOM Hard-Coding Kubernetes Details

SOM should not contain Kubernetes namespace names, pod specifications, Helm chart versions, or container image references. These are MANO/VNFM concerns encapsulated in the VNFD/NSD. If SOM hard-codes infrastructure details, every Kubernetes upgrade or VNF version change requires SOM modifications — destroying the abstraction boundary. SOM should specify what to deploy (VNF type, sizing, customer context) and let MANO determine how.

Pitfall: Confusing Service State and Infrastructure State

A VNF can be "running" (MANO perspective: pods are healthy) but the service can be "not yet active" (SOM perspective: firewall policies have not been applied, traffic is not flowing). Conversely, a VNF may be "healing" (MANO restarting a failed pod) while the service remains "active" (SOM perspective: redundant instance is handling traffic). SOM and MANO track different state dimensions. Do not conflate VM/pod health with service readiness.

Pitfall: Missing Event Feedback Loop

MANO must publish lifecycle events (VNF instantiated, scaled, healed, terminated) that SOM can consume. Without this feedback loop, SOM has no visibility into what MANO is doing — it must resort to polling, which is inefficient and error-prone. Ensure the MANO-to-SOM event channel is designed from the start, with clearly defined event types, payloads, and delivery guarantees (at-least-once delivery with idempotency).

Section 9.2 Key Takeaways

MANO consists of three layers: NFVO (NS orchestration), VNFM (VNF lifecycle), and VIM (infrastructure management)
SOM operates above MANO — it provides service context (customer, order, CFS) and delegates VNF lifecycle to MANO
NFVO is the entry point for external systems; it coordinates multi-VNF Network Services and manages VNF placement
VNFM handles individual VNF instance lifecycle: instantiate, configure (Day-1), scale, heal, and terminate
VIM manages infrastructure primitives (VMs, containers, networks, storage) without understanding services or VNFs
Day-0 is design/onboard, Day-1 is instantiate/configure, Day-2 is ongoing operations — Day-2 consumes the most effort
SOM should specify what to deploy and let MANO determine how — never hard-code infrastructure details in SOM
Service state (SOM) and infrastructure state (MANO) are different dimensions that must not be conflated