BSS/OSS Academy
🔧
Section 11.2

The MANO Domain: SOM + MANO + NFVI

Deep dive into the MANO architecture: NFVO, VNFM, VIM layers, Day-0/1/2 lifecycle, and how SOM orchestrates above MANO.

ETSI NFV MANO (Management and Orchestration) defines the standardised architecture for managing virtualised and cloud-native network function lifecycles. In a telco fulfilment stack, MANO sits below SOM — receiving VNF/CNF lifecycle requests and managing them through NFVO, VNFM, and VIM. Click each layer to explore responsibilities, state ownership, and interfaces.

NFVO + VNFM + VIM = ETSI MANO

Click any layer to explore its responsibilities, interfaces, and state ownership

SOM → NFVO → VNFM → VIM → NFVI responsibility stack. Toggle between the architecture stack and Day-0/1/2 lifecycle views.

Worked Example: Cloud Firewall CNF for SD-WAN

End-to-End: Cloud Firewall CNF Deployment

1
COM Receives Enterprise Order
COM

Enterprise orders "SD-WAN Premium with Cloud Security". COM maps the product to three CFS types: SD-WAN-Overlay, Cloud-Firewall, and Managed-Security.

2
SOM Decomposes CFS → RFS
SOM

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

3
MANO Deploys CNF
NFVO → VNFM → VIM

NFVO reads the NSD, selects the target Kubernetes cluster, delegates to VNFM. VNFM translates the VNFD into Helm chart resources and VIM (Kubernetes) creates the pods. VNFM then applies Day-1 configuration.

4
MANO Reports Success → NSO Pushes Config
MANO → SOM → NSO

NFVO publishes an NS lifecycle event. SOM marks the CNF RFS as complete, then delegates firewall policy config to NSO. NSO pushes ACLs, NAT rules, and routing to connect the CNF to the customer VPN.

5
SOM Completes Service Order
SOM → COM

All RFS items complete. SOM updates SLM (TMF638) with the active CFS:Cloud-Firewall instance, publishes a ServiceOrderStateChangeEvent to COM, and billing activates.

Common Pitfalls

MANO ≠ NFVI Builder

MANO manages VNF lifecycle on top of existing NFVI — it does not provision bare-metal or install Kubernetes.

  • Infrastructure provisioning is a separate concern (MAAS, Terraform)
  • Conflating the two causes scope creep in MANO implementations

SOM Must Not Hard-Code Infra

SOM should never contain K8s namespace names, Helm versions, or container image refs.

  • These are MANO/VNFM concerns encapsulated in the VNFD/NSD
  • Hard-coding destroys the abstraction boundary

Service State ≠ Infra State

A VNF can be "running" (MANO) while the service is "not yet active" (SOM) — and vice versa.

  • SOM and MANO track different state dimensions
  • Ensure a clean event feedback loop between the two

Section 11.2 Key Takeaways

  • MANO = NFVO (NS orchestration) + VNFM (VNF lifecycle) + VIM (infrastructure management)
  • SOM provides service context and delegates VNF lifecycle to MANO — specify what, not how
  • Day-0 is design, Day-1 is instantiate/configure, Day-2 is ongoing operations — Day-2 dominates
  • Service state (SOM) and infrastructure state (MANO) are different dimensions that must not be conflated