Computer NetworksNetwork Function Virtualization

Network Function Virtualization (NFV)

LevelAdvanced

Duration90 mins

TopicNetwork Function Virtualization

3 / 5

NFV Architecture: The ETSI Framework

The NFV Architectural Framework: Building Blocks of Virtualized Networks

Understanding individual VNFs is essential, but VNFs don't operate in isolation. They require a sophisticated infrastructure to provide compute, storage, and networking resources, along with management and orchestration systems to deploy, monitor, and maintain them. The ETSI NFV Architectural Framework defines these components and their interactions, providing a standardized blueprint for NFV deployments.

This architecture is not merely theoretical—it's the foundation upon which major telecommunications operators and cloud providers have built production NFV infrastructure serving millions of users. Understanding this architecture is essential for anyone designing, deploying, or operating NFV systems.

What You Will Learn

By the end of this page, you will understand the complete ETSI NFV architectural framework, including NFVI (NFV Infrastructure) and its layered structure, MANO (Management and Orchestration) and its three key components (NFVO, VNFM, VIM), reference points that define interfaces between components, and how these elements interact to enable VNF deployment and operation.

NFV Architecture Overview

The ETSI NFV architecture defines a comprehensive framework for virtualizing network functions. At the highest level, it consists of three main domains:

1. Virtual Network Functions (VNFs): The software implementations of network functions that we explored in the previous page.

2. NFV Infrastructure (NFVI): The physical and virtual resources that host VNFs—compute, storage, and networking.

3. NFV Management and Orchestration (MANO): The systems that manage VNF lifecycle and orchestrate resources.

These three domains interact through well-defined interfaces called reference points, enabling multi-vendor interoperability and modular system design.

Converting Mermaid diagram...

The Reference Architecture Elements:

Let's understand each major element before diving into details:

OSS/BSS (Operations Support Systems / Business Support Systems):

Pre-existing operator systems for service management
Handles customer-facing operations, billing, inventory
NFV integrates with OSS/BSS via the NFVO

NFV Orchestrator (NFVO):

Top-level orchestration of network services
Manages lifecycle of Network Services (composed of VNFs)
Coordinates resources across multiple VIMs

VNF Manager (VNFM):

Manages lifecycle of individual VNF instances
Handles instantiation, scaling, healing, termination
May be generic or VNF-specific

Virtualized Infrastructure Manager (VIM):

Manages NFVI resources (compute, storage, network)
Allocates and releases virtual resources
OpenStack is the dominant VIM implementation

NFVI (NFV Infrastructure):

Physical and virtual resources hosting VNFs
Layered structure: hardware → virtualization → virtual resources

The ETSI Specification Hierarchy

The ETSI NFV framework is specified across multiple document groups: GS NFV (base specifications), GS NFV-IFA (interface and architecture), GS NFV-SOL (solutions and protocols), and GS NFV-SEC (security). Production implementations must navigate these specifications carefully, as real-world requirements often require combining elements from multiple specification groups.

NFV Infrastructure (NFVI) in Detail

The NFV Infrastructure is the foundation upon which all VNFs run. It encompasses all hardware and software components that create the environment for deploying and executing VNFs. NFVI is conceptually divided into three layers:

Layer 1: Hardware Resources

The physical infrastructure providing raw computing power:

Compute Resources: Industry-standard x86/ARM servers providing processing capacity
Storage Resources: Various storage technologies (local SSD/NVMe, SAN, NAS, distributed storage)
Network Resources: Physical NICs, switches, routers interconnecting NFVI nodes

Layer 2: Virtualization Layer

The software layer that abstracts physical resources into virtual resources:

Hypervisors: KVM, VMware ESXi, Hyper-V for VM-based virtualization
Container Runtimes: Docker, containerd, CRI-O for container-based VNFs
Virtual Networking: OVS, Linux bridge, Contrail for virtual connectivity

Layer 3: Virtual Resources

The resources presented to VNFs:

Virtual Compute: VMs or containers with assigned vCPUs and memory
Virtual Storage: Virtual disks, volumes, object storage
Virtual Networks: Virtual NICs, virtual switches, overlay networks

NFVI Layer Responsibilities
Layer	Components	Responsibilities	Key Technologies
Hardware Resources	Servers, storage, network equipment	Provide raw compute, storage, network capacity	x86 servers, NVMe SSDs, 100GbE NICs
Virtualization Layer	Hypervisor, vSwitch, virtual storage	Abstract hardware into virtual resources	KVM, OVS-DPDK, Ceph
Virtual Resources	VMs, containers, virtual NICs	Provide execution environment for VNFs	libvirt, Kubernetes pods, VirtIO

NFVI PoP (Point of Presence):

NFVI resources are organized into Points of Presence (PoPs)—physical locations housing NFVI hardware. An operator might have:

Central PoPs: Large data centers in major cities, hosting majority of VNFs
Regional PoPs: Medium facilities at regional hubs
Edge PoPs: Small deployments close to users (cell sites, central offices)

Each PoP contains:

Compute nodes (servers hosting VNFs)
Storage nodes (shared or local storage)
Network infrastructure (ToR switches, spine switches, border routers)
Management infrastructure (out-of-band management, monitoring)

NFVI Compute Node Architecture:

nfvi-compute-node-spec.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# Example NFVI Compute Node Specification
# Typical configuration for carrier-grade NFV deployment
 
compute_node_spec:
  hardware:
    # Server Platform
    platform: "Dell PowerEdge R750"  # Or equivalent: HP DL380, Lenovo SR650
    processors:
      count: 2
      model: "Intel Xeon Gold 6348 (Ice Lake)"
      cores_per_socket: 28
      threads_per_core: 2
      base_frequency: "2.6 GHz"
      turbo_frequency: "3.5 GHz"
      features:
        - AVX-512    # Vector processing for crypto
        - AES-NI     # Hardware crypto acceleration
        - Intel VT-x # Virtualization extensions
        - Intel VT-d # I/O virtualization (SR-IOV)
    
    memory:
      total: "512 GB"
      type: "DDR4-3200 ECC RDIMM"
      channels: 16  # 8 per socket
      numa_nodes: 2
      huge_pages:
        enabled: true
        size: "1GB"
        count: 480  # Reserve for VNFs
    
    storage:
      boot_drives:
        - type: "M.2 NVMe SSD"
          capacity: "480 GB"
          raid: "RAID-1"
      vnf_storage:
        - type: "NVMe SSD"
          capacity: "3.84 TB"
          count: 4
          raid: "RAID-10"
    
    network:
      management:
        - type: "1GbE"
          count: 2
          purpose: "IPMI, management"
      data:
        - type: "100GbE"
          model: "Intel E810"
          count: 2
          features:
            - "SR-IOV (128 VFs per port)"
            - "DPDK support"
            - "Hardware timestamping"
  
  software:
    os: "Ubuntu 22.04 LTS"
    kernel: "5.15.0-generic"  # Or RHEL 8.x / CentOS Stream
    hypervisor:
      type: "KVM/QEMU"
      version: "QEMU 6.2"
      libvirt: "8.0"
    
    acceleration:
      dpdk:
        enabled: true
        version: "21.11 LTS"
        driver: "vfio-pci"
      ovs_dpdk:
        enabled: true
        version: "2.17"
        pmd_cores: [2, 3, 4, 5]  # Poll Mode Driver cores
      sr_iov:
        enabled: true
        vf_count: 64  # Per physical function
    
    tuning:
      cpu_governor: "performance"
      numa_balancing: "disabled"  # Manual NUMA placement
      transparent_hugepages: "never"  # Explicit huge pages only
      isolcpus: "4-55"  # Isolate cores for VNF use
      nohz_full: "4-55"  # Disable timer ticks on VNF cores

NFVI Tuning is Critical

Default OS configurations are optimized for general-purpose computing, not NFV workloads. Proper NFVI tuning—CPU isolation, NUMA awareness, huge pages, DPDK—can improve VNF performance by 10-100x. Carrier-grade NFV deployments require systematic performance engineering at the NFVI layer.

Virtualized Infrastructure Manager (VIM)

The Virtualized Infrastructure Manager (VIM) is responsible for controlling and managing the NFVI compute, storage, and networking resources within an NFVI PoP. It's the interface between the upper management layers and the actual virtual infrastructure.

VIM Responsibilities:

Resource Management: Track and allocate compute, storage, and network resources
Virtual Resource Lifecycle: Create, modify, and delete VMs, containers, virtual networks
Performance Monitoring: Collect metrics on resource utilization
Fault Management: Detect and report infrastructure failures
Image Management: Store and manage VNF software images
Multi-Tenancy: Isolate resources between different VNFs and tenants

OpenStack as the Dominant VIM:

While the ETSI framework is VIM-agnostic, OpenStack has become the de facto standard VIM for NFV deployments. Its modular architecture aligns well with NFV requirements:

OpenStack Components for NFV
Component	NFV Role	Key Features for NFV
Nova	Compute management	CPU pinning, NUMA topology, huge pages, PCI passthrough
Neutron	Network management	OVS-DPDK, SR-IOV, multiple provider networks, trunk ports
Cinder	Block storage	Volume types, encryption, high-performance backends
Glance	Image management	VNF image storage, image properties, multi-format support
Keystone	Identity/authentication	Service accounts, project isolation
Heat	Template orchestration	HOT templates for VNF deployment
Tacker	NFV orchestration	VNFD/NSD processing, VNF lifecycle (optional VNFM/NFVO)
Barbican	Secrets management	Certificate storage, key management

VIM-VNF Interaction:

The VIM provides resources to VNFs but typically doesn't interact with VNF application logic directly. The interaction model:

VNFM requests resources via VIM's northbound API (typically OpenStack Nova/Neutron APIs)
VIM allocates resources according to the request (VM creation, network attachment)
VIM provides resource handles back to VNFM (instance IDs, network info)
VIM monitors resources and reports status/faults to VNFM
VNFM releases resources via VIM when VNF is terminated

Multi-VIM Deployments:

Large operators often deploy multiple VIMs:

Geographic Distribution: Separate VIM per PoP or region
Technology Diversity: Different VIMs for VMs vs. containers (OpenStack + Kubernetes)
Failure Domain Isolation: Limit blast radius of VIM failures
Capacity Scaling: Distribute load across multiple VIM instances

The NFVO coordinates across multiple VIMs, presenting a unified view to upper layers while managing the complexity of multi-VIM resource allocation.

vim-vnf-deployment-flow.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
# Conceptual VIM interaction for VNF deployment
# Shows the sequence of VIM API calls during VNF instantiation
 
from openstack import connection
import time
 
def deploy_vnf_via_vim(vnf_spec):
    """
    Deploy a VNF by interacting with VIM (OpenStack) APIs
    This represents the VNFM's interaction with VIM
    """
    # Connect to VIM (OpenStack)
    conn = connection.Connection(
        auth_url="https://vim.example.com:5000/v3",
        project_name="nfv-project",
        username="vnfm-service",
        password="<service-password>",
        region_name="region-01"
    )
    
    # Step 1: Verify/upload VNF image (Glance)
    print("Step 1: Checking VNF image availability...")
    image = conn.image.find_image(vnf_spec['image_name'])
    if not image:
        print(f"  Uploading image: {vnf_spec['image_name']}")
        image = conn.image.create_image(
            name=vnf_spec['image_name'],
            disk_format='qcow2',
            container_format='bare',
            data=open(vnf_spec['image_path'], 'rb')
        )
    
    # Step 2: Create networks (Neutron)
    print("Step 2: Creating virtual networks...")
    networks = {}
    for net_spec in vnf_spec['networks']:
        network = conn.network.create_network(
            name=net_spec['name'],
            provider_network_type=net_spec.get('type', 'vxlan'),
            provider_segmentation_id=net_spec.get('segment_id')
        )
        subnet = conn.network.create_subnet(
            name=f"{net_spec['name']}-subnet",
            network_id=network.id,
            cidr=net_spec['cidr'],
            ip_version=4,
            enable_dhcp=True
        )
        networks[net_spec['name']] = {'network': network, 'subnet': subnet}
    
    # Step 3: Create security groups (Neutron)
    print("Step 3: Creating security groups...")
    sg = conn.network.create_security_group(
        name=f"{vnf_spec['name']}-sg",
        description="VNF security group"
    )
    for rule in vnf_spec['security_rules']:
        conn.network.create_security_group_rule(
            security_group_id=sg.id,
            direction=rule['direction'],
            protocol=rule['protocol'],
            port_range_min=rule.get('port_min'),
            port_range_max=rule.get('port_max'),
            remote_ip_prefix=rule.get('source', '0.0.0.0/0')
        )
    
    # Step 4: Create ports with required features (Neutron)
    print("Step 4: Creating network ports...")
    ports = []
    for port_spec in vnf_spec['ports']:
        port_config = {
            'name': port_spec['name'],
            'network_id': networks[port_spec['network']]['network'].id,
            'security_groups': [sg.id] if port_spec.get('security') else []
        }
        
        # SR-IOV configuration for data plane ports
        if port_spec.get('sriov'):
            port_config['binding:vnic_type'] = 'direct'
        
        port = conn.network.create_port(**port_config)
        ports.append(port)
    
    # Step 5: Create server with NFV-optimized configuration (Nova)
    print("Step 5: Creating VNF instance...")
    server = conn.compute.create_server(
        name=vnf_spec['name'],
        image_id=image.id,
        flavor_id=vnf_spec['flavor_id'],  # NFV-optimized flavor
        networks=[{'port': p.id} for p in ports],
        availability_zone=vnf_spec.get('availability_zone', 'nova'),
        user_data=vnf_spec.get('cloud_init'),
        # Scheduler hints for HA
        scheduler_hints={
            'different_host': vnf_spec.get('anti_affinity_group', [])
        }
    )
    
    # Step 6: Wait for VNF to become active
    print("Step 6: Waiting for VNF to become active...")
    timeout = 300  # 5 minutes
    start_time = time.time()
    while time.time() - start_time < timeout:
        server = conn.compute.get_server(server.id)
        if server.status == 'ACTIVE':
            print(f"  VNF {vnf_spec['name']} is ACTIVE")
            break
        elif server.status == 'ERROR':
            raise Exception(f"VNF deployment failed: {server.fault}")
        time.sleep(5)
    else:
        raise Exception("VNF deployment timed out")
    
    # Return deployment result
    return {
        'vnf_id': server.id,
        'status': server.status,
        'addresses': server.addresses,
        'ports': [p.id for p in ports],
        'networks': [n['network'].id for n in networks.values()]
    }

Kubernetes as VIM

For cloud-native VNFs (CNFs), Kubernetes increasingly serves as the VIM. Kubernetes native resource management (pods, services, volumes) replaces OpenStack APIs, while Container Network Interface (CNI) plugins provide networking. Many operators now run hybrid environments: OpenStack for VM-based VNFs and Kubernetes for container-based CNFs, orchestrated by a unified NFVO.

VNF Manager (VNFM)

The VNF Manager (VNFM) is responsible for the lifecycle management of VNF instances. It's the component that translates VNF deployment requests into actual infrastructure actions, manages VNF configuration, and ensures VNFs remain healthy during operation.

VNFM Responsibilities:

Core VNFM Functions

•VNF Lifecycle Management (LCM): Instantiate, terminate, scale, heal, and update VNF instances based on requests from NFVO or operators.
•VNFD Processing: Parse VNF Descriptors to understand resource requirements, deployment configurations, and lifecycle scripts.
•Resource Coordination: Request compute, storage, and network resources from VIM based on VNFD requirements.
•Configuration Management: Apply initial and runtime configuration to VNFs, potentially using configuration management tools.
•Fault Management: Monitor VNF health, detect failures, and initiate healing procedures.
•Performance Monitoring: Collect VNF metrics and report to NFVO for service-level monitoring.
•VNF Instance Repository: Maintain records of all managed VNF instances and their current state.

Generic vs. Specific VNFM:

The ETSI architecture supports two VNFM approaches:

Generic VNFM:

Manages any VNF that conforms to standard VNFD specifications
Vendor-neutral, handles basic lifecycle operations
Relies on VNF package scripts for VNF-specific behavior
Lower operational complexity (single VNFM for all VNFs)
May lack deep VNF-specific optimizations

Specific VNFM:

Designed for a particular VNF or VNF family
Deep integration with VNF internals
Can perform advanced VNF-specific operations
Often provided by VNF vendor
Higher operational complexity (multiple VNFMs to manage)

Practical Reality:

Most production environments use a hybrid approach:

Generic VNFM for simple VNFs and common lifecycle operations
Vendor-specific VNFM elements for complex, stateful VNFs
Adaptation layers to bridge vendor VNF expectations with generic platforms

Converting Mermaid diagram...

VNFM Implementations:

Several VNFM implementations are available:

OpenStack Tacker: Open-source VNFM/NFVO integrated with OpenStack
ONAP (VNF Lifecycle Management): Comprehensive platform including VNFM functions
OSM (Open Source MANO): ETSI-hosted open-source MANO stack
Cloudify: Commercial orchestration platform with VNFM capabilities
Vendor-specific: Ericsson, Nokia, Huawei each provide VNFM products

VNFM-VNF Communication:

The VNFM communicates with VNFs through several mechanisms:

Cloud-init/User Data: Initial configuration at boot time
SSH/WinRM: Remote command execution for lifecycle scripts
Configuration Management: Ansible, Puppet, Chef for complex configuration
VNF Indicator Interface: VNF-exposed API for health/status (Ve-Vnfm-em reference point)
Element Manager: VNF-specific management interface for deep integration

VNFM Scalability Challenge

In large deployments with thousands of VNF instances, VNFM becomes a potential bottleneck. A single VNFM managing thousands of VNFs must handle concurrent lifecycle operations, health monitoring for all instances, and configuration updates. Production deployments require VNFM clustering, careful rate limiting, and efficient database backends.

NFV Orchestrator (NFVO)

The NFV Orchestrator (NFVO) sits at the top of the MANO architecture, providing two critical functions:

Network Service Orchestration: Managing complex services composed of multiple VNFs
Resource Orchestration: Coordinating resources across multiple VIMs

Network Service Concept:

A Network Service (NS) is an end-to-end service composed of:

One or more VNFs
Virtual Links connecting VNFs
Connection to physical network access points

For example, a mobile core network service might include a vEPC, vIMS, and vSBC connected via virtual links, with connections to the radio access network.

NFVO Functions:

Network Service Lifecycle Management:

Instantiate NS: Deploy all constituent VNFs and connect them
Scale NS: Scale individual VNFs or add/remove VNFs from NS
Update NS: Modify NS configuration or upgrade VNF versions
Heal NS: Recover from failures affecting NS components
Terminate NS: Cleanly shutdown all VNFs and release resources

Resource Orchestration:

Resource Abstraction: Present unified resource view across multiple VIMs
Placement Decisions: Determine which VIM/PoP hosts each VNF
Resource Reservation: Reserve capacity for VNF deployments
Cross-VIM Connectivity: Establish network paths across VIM boundaries

Catalog Management:

VNF Package Repository: Store onboarded VNF packages
NSD Repository: Store Network Service Descriptors
Template Management: Version and manage deployment templates

network-service-descriptor.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
# Example Network Service Descriptor (NSD)
# Defines a mobile core network service composed of multiple VNFs
 
tosca_definitions_version: tosca_simple_yaml_1_3
 
description: 4G Mobile Core Network Service
 
metadata:
  template_name: mobile-core-ns
  template_version: "1.0.0"
  template_author: NetworkOperator
 
topology_template:
  node_templates:
    
    # VNF 1: Virtualized Evolved Packet Core
    vEPC:
      type: tosca.nodes.nfv.VNF
      properties:
        descriptor_id: "vEPC-v2.1"
        provider: "Vendor-A"
        product_name: "Virtual EPC"
        software_version: "2.1.0"
        flavour_id: "large"
      requirements:
        - virtual_link: internal_network
    
    # VNF 2: Virtualized IMS Core
    vIMS:
      type: tosca.nodes.nfv.VNF
      properties:
        descriptor_id: "vIMS-v3.0"
        provider: "Vendor-B"
        product_name: "Cloud IMS"
        software_version: "3.0.2"
        flavour_id: "medium"
      requirements:
        - virtual_link: internal_network
        - virtual_link: sip_network
    
    # VNF 3: Session Border Controller
    vSBC:
      type: tosca.nodes.nfv.VNF
      properties:
        descriptor_id: "vSBC-v1.5"
        provider: "Vendor-C"
        product_name: "Virtual SBC"
        software_version: "1.5.1"
        flavour_id: "medium"
      requirements:
        - virtual_link: sip_network
        - virtual_link: external_network
    
    # Internal VL: Connects EPC and IMS
    internal_network:
      type: tosca.nodes.nfv.NsVirtualLink
      properties:
        connectivity_type:
          layer_protocols: [ipv4]
      capabilities:
        virtual_linkable:
          properties:
            bitrate_requirement: 10 Gbps
    
    # SIP VL: IMS to SBC communication
    sip_network:
      type: tosca.nodes.nfv.NsVirtualLink
      properties:
        connectivity_type:
          layer_protocols: [ipv4]
      capabilities:
        virtual_linkable:
          properties:
            bitrate_requirement: 1 Gbps
    
    # External VL: Connection to external SIP peers
    external_network:
      type: tosca.nodes.nfv.NsVirtualLink
      properties:
        connectivity_type:
          layer_protocols: [ipv4]
      requirements:
        - dependency: ext_connection_point
    
  # Policies for NS-level behavior
  policies:
    - ns_scaling:
        type: tosca.policies.nfv.NsScalingAspects
        properties:
          aspects:
            capacity_scaling:
              name: "Core capacity scaling"
              description: "Scale EPC and IMS together"
              scaling_level: 3
              vnf_to_level_mapping:
                vEPC: [1, 2, 3]
                vIMS: [1, 2, 3]
    
    - deployment_location:
        type: tosca.policies.Placement
        targets: [vEPC, vIMS, vSBC]
        properties:
          region: "us-east"
          availability_zone: "zone-1"
 
  # Connection to external networks  
  substitution_mappings:
    node_type: tosca.nodes.nfv.NS
    requirements:
      ran_connection: [vEPC, s1_port]
      internet_connection: [vSBC, external_port]

Service Function Chaining (SFC):

A critical NFVO capability is Service Function Chaining—the ability to define traffic paths through a sequence of VNFs:

Traffic → Firewall → DPI → NAT → Load Balancer → Destination

SFC requires:

Classifier: Identify traffic flows to be chained
Service Function Path: Define the VNF sequence
Service Function Forwarder: Steer traffic through the chain
Encapsulation: Carry SFC metadata (NSH, VXLAN)

NFVO Implementations:

OSM (Open Source MANO): ETSI-hosted reference implementation
ONAP: Linux Foundation's comprehensive platform
Cloudify: Commercial orchestration with NFVO capabilities
OpenStack Tacker: Integrated OpenStack option
Vendor Products: Cisco NSO, Ericsson Dynamic Orchestration, Nokia CloudBand

NFVO Integration Complexity

The NFVO integrates with OSS/BSS, multiple VNFMs, and multiple VIMs—making it one of the most integration-intensive components in the NFV architecture. Real-world deployments often spend more time on integration than on configuration, as each interface (Or-Vnfm, Or-Vi, Os-Ma-Nfvo) has variations between implementations despite theoretical standardization.

Reference Points and Interfaces

The ETSI NFV architecture defines reference points—standardized interfaces between architectural components. These reference points enable multi-vendor interoperability, allowing operators to mix components from different vendors.

Major Reference Points:

ETSI NFV Reference Points
Reference Point	Connects	Primary Functions	Typical Protocol
Os-Ma-Nfvo	OSS/BSS ↔ NFVO	NS lifecycle requests, resource info	REST API
Or-Vnfm	NFVO ↔ VNFM	VNF lifecycle coordination	REST (SOL003)
Or-Vi	NFVO ↔ VIM	Cross-VIM resource orchestration	REST (SOL005)
Vi-Vnfm	VIM ↔ VNFM	VNF resource requests	OpenStack API
Ve-Vnfm-em	VNFM ↔ VNF (EM)	VNF configuration and monitoring	NETCONF, REST
Ve-Vnfm-vnf	VNFM ↔ VNF	Direct VNF interface (indicators)	VNF-specific
Nf-Vi	VNF ↔ NFVI	Access to virtualized resources	SR-IOV, VirtIO
Vn-Nf	VNF ↔ VNF	Inter-VNF communication	VLs, IP networks

ETSI SOL Specifications:

The practical implementation of reference points is defined in ETSI SOL (Solutions) specifications:

SOL001: VNFD based on TOSCA

Defines the TOSCA-based format for VNF Descriptors
Data model for VDU, CP, VL definitions

SOL002: Ve-Vnfm Reference Point Interface

REST API for VNF lifecycle via Element Manager
Configuration and fault management operations

SOL003: Or-Vnfm Reference Point Interface

REST API for NFVO-VNFM communication
VNF lifecycle management operations from NFVO

SOL004: VNF Package Specification

CSAR package format for VNFs
Structure for images, scripts, metadata

SOL005: Or-Vi Reference Point Interface

REST API for NFVO-VIM communication
Resource management across VIMs

SOL007: NSD based on TOSCA

Defines Network Service Descriptor format
Composition of VNFs, VLs, and forwarding graphs

Converting Mermaid diagram...

Interoperability Reality

While ETSI specifications aim for interoperability, practical experience shows that vendor implementations often have subtle incompatibilities. Extensions, optional features, and interpretation differences mean that component substitution rarely works 'out of the box.' Thorough integration testing is essential when combining components from different vendors.

NFV Deployment Architectures

Understanding the architectural framework is essential, but real deployments require adapting the reference architecture to specific operational requirements. Several deployment patterns have emerged:

Pattern 1: Centralized MANO

All MANO components (NFVO, VNFM, VIM) deployed centrally, managing distributed NFVI:

Advantages: Single management point, simplified operations, unified view
Challenges: Single point of failure, WAN dependency for management traffic
Use Case: Initial NFV deployments, smaller operators

Pattern 2: Distributed MANO

MANO components distributed across locations with hierarchy:

Central NFVO with global view
Regional/PoP VNFMs and VIMs
Local autonomy with central coordination
Advantages: Resilience, reduced WAN dependency, scalability
Challenges: Consistency, synchronization complexity
Use Case: Large operators with multiple PoPs

Pattern 3: Hybrid Cloud NFV

NFV extended to public cloud:

Private NFVI for sensitive VNFs
Public cloud for burst capacity or specific workloads
Unified orchestration across environments
Advantages: Flexibility, burst capacity, reduced CapEx
Challenges: Security, connectivity, consistent performance
Use Case: Operators exploring cloud strategies

Centralized Pattern

•Single NFVO managing all resources
•Single VIM instance (or clustered)
•VNFMs at central location
•NFVI distributed across PoPs
•All management over WAN

Distributed Pattern

•Global NFVO + Regional NFVOs
•VIM per PoP or region
•VNFM distributed or per-function
•Local autonomy with synchronization
•Hierarchy for coordination

High Availability Considerations:

Production NFV deployments require HA at multiple levels:

MANO HA:

Clustered NFVO/VNFM instances
Database replication/clustering
Load balancing for API endpoints
No single point of failure in management path

NFVI HA:

Compute node redundancy (N+M sparing)
Storage replication/clustering
Network redundancy (dual switches, bonded NICs)
Automated failover/migration

VNF HA:

Multi-instance VNFs with load balancing
Active-standby or active-active configurations
Anti-affinity placement (VNFCs on different hosts)
Automatic healing on failure

Disaster Recovery:

Geographic redundancy for critical services
Data replication between sites
Automated failover procedures
Regular DR testing

Start Simple, Evolve Carefully

Many organizations start with centralized MANO and evolve to distributed architectures as they gain experience. The complexity of distributed MANO—synchronization, conflict resolution, partial failure handling—is substantial. Master centralized operations before introducing distribution, and introduce distribution incrementally based on demonstrated needs.

Summary: NFV Architecture

We've comprehensively explored the ETSI NFV architectural framework. Let's consolidate the key concepts:

Key Takeaways

•The NFV architecture has three main domains — VNFs (the network functions), NFVI (the infrastructure hosting them), and MANO (the management and orchestration layer coordinating everything).
•NFVI provides the foundation — Physical hardware, virtualization layer, and virtual resources form a layered infrastructure that must be carefully tuned for carrier-grade VNF performance.
•The VIM manages NFVI resources — OpenStack is the dominant VIM, providing compute, storage, and network management through well-defined APIs.
•The VNFM handles VNF lifecycle — From instantiation through scaling and healing to termination, the VNFM translates high-level requests into concrete infrastructure actions.
•The NFVO orchestrates services and resources — Network Services composed of multiple VNFs are managed by the NFVO, which also coordinates resources across multiple VIMs.
•Reference points enable interoperability — Standardized interfaces (Or-Vnfm, Or-Vi, Vi-Vnfm, etc.) theoretically allow multi-vendor deployments, though practical interoperability requires careful testing.
•Deployment patterns vary by need — Centralized, distributed, and hybrid deployment architectures address different operational requirements and scale points.
•High availability is essential — Production NFV requires HA at MANO, NFVI, and VNF levels to meet carrier-grade reliability requirements.

What's Next:

With the NFV architecture understood, we'll explore the relationship between NFV and SDN—two distinct but complementary technologies that are often deployed together. Understanding how SDN and NFV interact is crucial for designing modern, software-defined network infrastructure.

Page Complete

You now understand the complete ETSI NFV architectural framework—NFVI, MANO components, reference points, and deployment patterns. This knowledge prepares you to design NFV infrastructure, evaluate MANO solutions, and understand how the pieces fit together in production deployments.

3 / 5

Loading learning content...

Computer NetworksNetwork Function Virtualization

Network Function Virtualization (NFV)

LevelAdvanced

Duration90 mins

TopicNetwork Function Virtualization

3 / 5

NFV Architecture: The ETSI Framework

The NFV Architectural Framework: Building Blocks of Virtualized Networks

What You Will Learn

NFV Architecture Overview

The ETSI NFV architecture defines a comprehensive framework for virtualizing network functions. At the highest level, it consists of three main domains:

1. Virtual Network Functions (VNFs): The software implementations of network functions that we explored in the previous page.

2. NFV Infrastructure (NFVI): The physical and virtual resources that host VNFs—compute, storage, and networking.

3. NFV Management and Orchestration (MANO): The systems that manage VNF lifecycle and orchestrate resources.

These three domains interact through well-defined interfaces called reference points, enabling multi-vendor interoperability and modular system design.

Converting Mermaid diagram...

The Reference Architecture Elements:

Let's understand each major element before diving into details:

OSS/BSS (Operations Support Systems / Business Support Systems):

Pre-existing operator systems for service management
Handles customer-facing operations, billing, inventory
NFV integrates with OSS/BSS via the NFVO

NFV Orchestrator (NFVO):

Top-level orchestration of network services
Manages lifecycle of Network Services (composed of VNFs)
Coordinates resources across multiple VIMs

VNF Manager (VNFM):

Manages lifecycle of individual VNF instances
Handles instantiation, scaling, healing, termination
May be generic or VNF-specific

Virtualized Infrastructure Manager (VIM):

Manages NFVI resources (compute, storage, network)
Allocates and releases virtual resources
OpenStack is the dominant VIM implementation

NFVI (NFV Infrastructure):

Physical and virtual resources hosting VNFs
Layered structure: hardware → virtualization → virtual resources

The ETSI Specification Hierarchy

NFV Infrastructure (NFVI) in Detail

Layer 1: Hardware Resources

The physical infrastructure providing raw computing power:

Compute Resources: Industry-standard x86/ARM servers providing processing capacity
Storage Resources: Various storage technologies (local SSD/NVMe, SAN, NAS, distributed storage)
Network Resources: Physical NICs, switches, routers interconnecting NFVI nodes

Layer 2: Virtualization Layer

The software layer that abstracts physical resources into virtual resources:

Hypervisors: KVM, VMware ESXi, Hyper-V for VM-based virtualization
Container Runtimes: Docker, containerd, CRI-O for container-based VNFs
Virtual Networking: OVS, Linux bridge, Contrail for virtual connectivity

Layer 3: Virtual Resources

The resources presented to VNFs:

Virtual Compute: VMs or containers with assigned vCPUs and memory
Virtual Storage: Virtual disks, volumes, object storage
Virtual Networks: Virtual NICs, virtual switches, overlay networks

NFVI Layer Responsibilities
Layer	Components	Responsibilities	Key Technologies
Hardware Resources	Servers, storage, network equipment	Provide raw compute, storage, network capacity	x86 servers, NVMe SSDs, 100GbE NICs
Virtualization Layer	Hypervisor, vSwitch, virtual storage	Abstract hardware into virtual resources	KVM, OVS-DPDK, Ceph
Virtual Resources	VMs, containers, virtual NICs	Provide execution environment for VNFs	libvirt, Kubernetes pods, VirtIO

NFVI PoP (Point of Presence):

NFVI resources are organized into Points of Presence (PoPs)—physical locations housing NFVI hardware. An operator might have:

Central PoPs: Large data centers in major cities, hosting majority of VNFs
Regional PoPs: Medium facilities at regional hubs
Edge PoPs: Small deployments close to users (cell sites, central offices)

Each PoP contains:

Compute nodes (servers hosting VNFs)
Storage nodes (shared or local storage)
Network infrastructure (ToR switches, spine switches, border routers)
Management infrastructure (out-of-band management, monitoring)

NFVI Compute Node Architecture:

nfvi-compute-node-spec.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# Example NFVI Compute Node Specification
# Typical configuration for carrier-grade NFV deployment
 
compute_node_spec:
  hardware:
    # Server Platform
    platform: "Dell PowerEdge R750"  # Or equivalent: HP DL380, Lenovo SR650
    processors:
      count: 2
      model: "Intel Xeon Gold 6348 (Ice Lake)"
      cores_per_socket: 28
      threads_per_core: 2
      base_frequency: "2.6 GHz"
      turbo_frequency: "3.5 GHz"
      features:
        - AVX-512    # Vector processing for crypto
        - AES-NI     # Hardware crypto acceleration
        - Intel VT-x # Virtualization extensions
        - Intel VT-d # I/O virtualization (SR-IOV)
    
    memory:
      total: "512 GB"
      type: "DDR4-3200 ECC RDIMM"
      channels: 16  # 8 per socket
      numa_nodes: 2
      huge_pages:
        enabled: true
        size: "1GB"
        count: 480  # Reserve for VNFs
    
    storage:
      boot_drives:
        - type: "M.2 NVMe SSD"
          capacity: "480 GB"
          raid: "RAID-1"
      vnf_storage:
        - type: "NVMe SSD"
          capacity: "3.84 TB"
          count: 4
          raid: "RAID-10"
    
    network:
      management:
        - type: "1GbE"
          count: 2
          purpose: "IPMI, management"
      data:
        - type: "100GbE"
          model: "Intel E810"
          count: 2
          features:
            - "SR-IOV (128 VFs per port)"
            - "DPDK support"
            - "Hardware timestamping"
  
  software:
    os: "Ubuntu 22.04 LTS"
    kernel: "5.15.0-generic"  # Or RHEL 8.x / CentOS Stream
    hypervisor:
      type: "KVM/QEMU"
      version: "QEMU 6.2"
      libvirt: "8.0"
    
    acceleration:
      dpdk:
        enabled: true
        version: "21.11 LTS"
        driver: "vfio-pci"
      ovs_dpdk:
        enabled: true
        version: "2.17"
        pmd_cores: [2, 3, 4, 5]  # Poll Mode Driver cores
      sr_iov:
        enabled: true
        vf_count: 64  # Per physical function
    
    tuning:
      cpu_governor: "performance"
      numa_balancing: "disabled"  # Manual NUMA placement
      transparent_hugepages: "never"  # Explicit huge pages only
      isolcpus: "4-55"  # Isolate cores for VNF use
      nohz_full: "4-55"  # Disable timer ticks on VNF cores

NFVI Tuning is Critical

Virtualized Infrastructure Manager (VIM)

VIM Responsibilities:

Resource Management: Track and allocate compute, storage, and network resources
Virtual Resource Lifecycle: Create, modify, and delete VMs, containers, virtual networks
Performance Monitoring: Collect metrics on resource utilization
Fault Management: Detect and report infrastructure failures
Image Management: Store and manage VNF software images
Multi-Tenancy: Isolate resources between different VNFs and tenants

OpenStack as the Dominant VIM:

While the ETSI framework is VIM-agnostic, OpenStack has become the de facto standard VIM for NFV deployments. Its modular architecture aligns well with NFV requirements:

OpenStack Components for NFV
Component	NFV Role	Key Features for NFV
Nova	Compute management	CPU pinning, NUMA topology, huge pages, PCI passthrough
Neutron	Network management	OVS-DPDK, SR-IOV, multiple provider networks, trunk ports
Cinder	Block storage	Volume types, encryption, high-performance backends
Glance	Image management	VNF image storage, image properties, multi-format support
Keystone	Identity/authentication	Service accounts, project isolation
Heat	Template orchestration	HOT templates for VNF deployment
Tacker	NFV orchestration	VNFD/NSD processing, VNF lifecycle (optional VNFM/NFVO)
Barbican	Secrets management	Certificate storage, key management

VIM-VNF Interaction:

The VIM provides resources to VNFs but typically doesn't interact with VNF application logic directly. The interaction model:

VNFM requests resources via VIM's northbound API (typically OpenStack Nova/Neutron APIs)
VIM allocates resources according to the request (VM creation, network attachment)
VIM provides resource handles back to VNFM (instance IDs, network info)
VIM monitors resources and reports status/faults to VNFM
VNFM releases resources via VIM when VNF is terminated

Multi-VIM Deployments:

Large operators often deploy multiple VIMs:

Geographic Distribution: Separate VIM per PoP or region
Technology Diversity: Different VIMs for VMs vs. containers (OpenStack + Kubernetes)
Failure Domain Isolation: Limit blast radius of VIM failures
Capacity Scaling: Distribute load across multiple VIM instances

The NFVO coordinates across multiple VIMs, presenting a unified view to upper layers while managing the complexity of multi-VIM resource allocation.

vim-vnf-deployment-flow.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
# Conceptual VIM interaction for VNF deployment
# Shows the sequence of VIM API calls during VNF instantiation
 
from openstack import connection
import time
 
def deploy_vnf_via_vim(vnf_spec):
    """
    Deploy a VNF by interacting with VIM (OpenStack) APIs
    This represents the VNFM's interaction with VIM
    """
    # Connect to VIM (OpenStack)
    conn = connection.Connection(
        auth_url="https://vim.example.com:5000/v3",
        project_name="nfv-project",
        username="vnfm-service",
        password="<service-password>",
        region_name="region-01"
    )
    
    # Step 1: Verify/upload VNF image (Glance)
    print("Step 1: Checking VNF image availability...")
    image = conn.image.find_image(vnf_spec['image_name'])
    if not image:
        print(f"  Uploading image: {vnf_spec['image_name']}")
        image = conn.image.create_image(
            name=vnf_spec['image_name'],
            disk_format='qcow2',
            container_format='bare',
            data=open(vnf_spec['image_path'], 'rb')
        )
    
    # Step 2: Create networks (Neutron)
    print("Step 2: Creating virtual networks...")
    networks = {}
    for net_spec in vnf_spec['networks']:
        network = conn.network.create_network(
            name=net_spec['name'],
            provider_network_type=net_spec.get('type', 'vxlan'),
            provider_segmentation_id=net_spec.get('segment_id')
        )
        subnet = conn.network.create_subnet(
            name=f"{net_spec['name']}-subnet",
            network_id=network.id,
            cidr=net_spec['cidr'],
            ip_version=4,
            enable_dhcp=True
        )
        networks[net_spec['name']] = {'network': network, 'subnet': subnet}
    
    # Step 3: Create security groups (Neutron)
    print("Step 3: Creating security groups...")
    sg = conn.network.create_security_group(
        name=f"{vnf_spec['name']}-sg",
        description="VNF security group"
    )
    for rule in vnf_spec['security_rules']:
        conn.network.create_security_group_rule(
            security_group_id=sg.id,
            direction=rule['direction'],
            protocol=rule['protocol'],
            port_range_min=rule.get('port_min'),
            port_range_max=rule.get('port_max'),
            remote_ip_prefix=rule.get('source', '0.0.0.0/0')
        )
    
    # Step 4: Create ports with required features (Neutron)
    print("Step 4: Creating network ports...")
    ports = []
    for port_spec in vnf_spec['ports']:
        port_config = {
            'name': port_spec['name'],
            'network_id': networks[port_spec['network']]['network'].id,
            'security_groups': [sg.id] if port_spec.get('security') else []
        }
        
        # SR-IOV configuration for data plane ports
        if port_spec.get('sriov'):
            port_config['binding:vnic_type'] = 'direct'
        
        port = conn.network.create_port(**port_config)
        ports.append(port)
    
    # Step 5: Create server with NFV-optimized configuration (Nova)
    print("Step 5: Creating VNF instance...")
    server = conn.compute.create_server(
        name=vnf_spec['name'],
        image_id=image.id,
        flavor_id=vnf_spec['flavor_id'],  # NFV-optimized flavor
        networks=[{'port': p.id} for p in ports],
        availability_zone=vnf_spec.get('availability_zone', 'nova'),
        user_data=vnf_spec.get('cloud_init'),
        # Scheduler hints for HA
        scheduler_hints={
            'different_host': vnf_spec.get('anti_affinity_group', [])
        }
    )
    
    # Step 6: Wait for VNF to become active
    print("Step 6: Waiting for VNF to become active...")
    timeout = 300  # 5 minutes
    start_time = time.time()
    while time.time() - start_time < timeout:
        server = conn.compute.get_server(server.id)
        if server.status == 'ACTIVE':
            print(f"  VNF {vnf_spec['name']} is ACTIVE")
            break
        elif server.status == 'ERROR':
            raise Exception(f"VNF deployment failed: {server.fault}")
        time.sleep(5)
    else:
        raise Exception("VNF deployment timed out")
    
    # Return deployment result
    return {
        'vnf_id': server.id,
        'status': server.status,
        'addresses': server.addresses,
        'ports': [p.id for p in ports],
        'networks': [n['network'].id for n in networks.values()]
    }

Kubernetes as VIM

VNF Manager (VNFM)

VNFM Responsibilities:

Core VNFM Functions

•VNF Lifecycle Management (LCM): Instantiate, terminate, scale, heal, and update VNF instances based on requests from NFVO or operators.
•VNFD Processing: Parse VNF Descriptors to understand resource requirements, deployment configurations, and lifecycle scripts.
•Resource Coordination: Request compute, storage, and network resources from VIM based on VNFD requirements.
•Configuration Management: Apply initial and runtime configuration to VNFs, potentially using configuration management tools.
•Fault Management: Monitor VNF health, detect failures, and initiate healing procedures.
•Performance Monitoring: Collect VNF metrics and report to NFVO for service-level monitoring.
•VNF Instance Repository: Maintain records of all managed VNF instances and their current state.

Generic vs. Specific VNFM:

The ETSI architecture supports two VNFM approaches:

Generic VNFM:

Manages any VNF that conforms to standard VNFD specifications
Vendor-neutral, handles basic lifecycle operations
Relies on VNF package scripts for VNF-specific behavior
Lower operational complexity (single VNFM for all VNFs)
May lack deep VNF-specific optimizations

Specific VNFM:

Designed for a particular VNF or VNF family
Deep integration with VNF internals
Can perform advanced VNF-specific operations
Often provided by VNF vendor
Higher operational complexity (multiple VNFMs to manage)

Practical Reality:

Most production environments use a hybrid approach:

Generic VNFM for simple VNFs and common lifecycle operations
Vendor-specific VNFM elements for complex, stateful VNFs
Adaptation layers to bridge vendor VNF expectations with generic platforms

Converting Mermaid diagram...

VNFM Implementations:

Several VNFM implementations are available:

OpenStack Tacker: Open-source VNFM/NFVO integrated with OpenStack
ONAP (VNF Lifecycle Management): Comprehensive platform including VNFM functions
OSM (Open Source MANO): ETSI-hosted open-source MANO stack
Cloudify: Commercial orchestration platform with VNFM capabilities
Vendor-specific: Ericsson, Nokia, Huawei each provide VNFM products

VNFM-VNF Communication:

The VNFM communicates with VNFs through several mechanisms:

Cloud-init/User Data: Initial configuration at boot time
SSH/WinRM: Remote command execution for lifecycle scripts
Configuration Management: Ansible, Puppet, Chef for complex configuration
VNF Indicator Interface: VNF-exposed API for health/status (Ve-Vnfm-em reference point)
Element Manager: VNF-specific management interface for deep integration

VNFM Scalability Challenge

NFV Orchestrator (NFVO)

The NFV Orchestrator (NFVO) sits at the top of the MANO architecture, providing two critical functions:

Network Service Orchestration: Managing complex services composed of multiple VNFs
Resource Orchestration: Coordinating resources across multiple VIMs

Network Service Concept:

A Network Service (NS) is an end-to-end service composed of:

One or more VNFs
Virtual Links connecting VNFs
Connection to physical network access points

For example, a mobile core network service might include a vEPC, vIMS, and vSBC connected via virtual links, with connections to the radio access network.

NFVO Functions:

Network Service Lifecycle Management:

Instantiate NS: Deploy all constituent VNFs and connect them
Scale NS: Scale individual VNFs or add/remove VNFs from NS
Update NS: Modify NS configuration or upgrade VNF versions
Heal NS: Recover from failures affecting NS components
Terminate NS: Cleanly shutdown all VNFs and release resources

Resource Orchestration:

Resource Abstraction: Present unified resource view across multiple VIMs
Placement Decisions: Determine which VIM/PoP hosts each VNF
Resource Reservation: Reserve capacity for VNF deployments
Cross-VIM Connectivity: Establish network paths across VIM boundaries

Catalog Management:

VNF Package Repository: Store onboarded VNF packages
NSD Repository: Store Network Service Descriptors
Template Management: Version and manage deployment templates

network-service-descriptor.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
# Example Network Service Descriptor (NSD)
# Defines a mobile core network service composed of multiple VNFs
 
tosca_definitions_version: tosca_simple_yaml_1_3
 
description: 4G Mobile Core Network Service
 
metadata:
  template_name: mobile-core-ns
  template_version: "1.0.0"
  template_author: NetworkOperator
 
topology_template:
  node_templates:
    
    # VNF 1: Virtualized Evolved Packet Core
    vEPC:
      type: tosca.nodes.nfv.VNF
      properties:
        descriptor_id: "vEPC-v2.1"
        provider: "Vendor-A"
        product_name: "Virtual EPC"
        software_version: "2.1.0"
        flavour_id: "large"
      requirements:
        - virtual_link: internal_network
    
    # VNF 2: Virtualized IMS Core
    vIMS:
      type: tosca.nodes.nfv.VNF
      properties:
        descriptor_id: "vIMS-v3.0"
        provider: "Vendor-B"
        product_name: "Cloud IMS"
        software_version: "3.0.2"
        flavour_id: "medium"
      requirements:
        - virtual_link: internal_network
        - virtual_link: sip_network
    
    # VNF 3: Session Border Controller
    vSBC:
      type: tosca.nodes.nfv.VNF
      properties:
        descriptor_id: "vSBC-v1.5"
        provider: "Vendor-C"
        product_name: "Virtual SBC"
        software_version: "1.5.1"
        flavour_id: "medium"
      requirements:
        - virtual_link: sip_network
        - virtual_link: external_network
    
    # Internal VL: Connects EPC and IMS
    internal_network:
      type: tosca.nodes.nfv.NsVirtualLink
      properties:
        connectivity_type:
          layer_protocols: [ipv4]
      capabilities:
        virtual_linkable:
          properties:
            bitrate_requirement: 10 Gbps
    
    # SIP VL: IMS to SBC communication
    sip_network:
      type: tosca.nodes.nfv.NsVirtualLink
      properties:
        connectivity_type:
          layer_protocols: [ipv4]
      capabilities:
        virtual_linkable:
          properties:
            bitrate_requirement: 1 Gbps
    
    # External VL: Connection to external SIP peers
    external_network:
      type: tosca.nodes.nfv.NsVirtualLink
      properties:
        connectivity_type:
          layer_protocols: [ipv4]
      requirements:
        - dependency: ext_connection_point
    
  # Policies for NS-level behavior
  policies:
    - ns_scaling:
        type: tosca.policies.nfv.NsScalingAspects
        properties:
          aspects:
            capacity_scaling:
              name: "Core capacity scaling"
              description: "Scale EPC and IMS together"
              scaling_level: 3
              vnf_to_level_mapping:
                vEPC: [1, 2, 3]
                vIMS: [1, 2, 3]
    
    - deployment_location:
        type: tosca.policies.Placement
        targets: [vEPC, vIMS, vSBC]
        properties:
          region: "us-east"
          availability_zone: "zone-1"
 
  # Connection to external networks  
  substitution_mappings:
    node_type: tosca.nodes.nfv.NS
    requirements:
      ran_connection: [vEPC, s1_port]
      internet_connection: [vSBC, external_port]

Service Function Chaining (SFC):

A critical NFVO capability is Service Function Chaining—the ability to define traffic paths through a sequence of VNFs:

Traffic → Firewall → DPI → NAT → Load Balancer → Destination

SFC requires:

Classifier: Identify traffic flows to be chained
Service Function Path: Define the VNF sequence
Service Function Forwarder: Steer traffic through the chain
Encapsulation: Carry SFC metadata (NSH, VXLAN)

NFVO Implementations:

OSM (Open Source MANO): ETSI-hosted reference implementation
ONAP: Linux Foundation's comprehensive platform
Cloudify: Commercial orchestration with NFVO capabilities
OpenStack Tacker: Integrated OpenStack option
Vendor Products: Cisco NSO, Ericsson Dynamic Orchestration, Nokia CloudBand

NFVO Integration Complexity

Reference Points and Interfaces

Major Reference Points:

ETSI NFV Reference Points
Reference Point	Connects	Primary Functions	Typical Protocol
Os-Ma-Nfvo	OSS/BSS ↔ NFVO	NS lifecycle requests, resource info	REST API
Or-Vnfm	NFVO ↔ VNFM	VNF lifecycle coordination	REST (SOL003)
Or-Vi	NFVO ↔ VIM	Cross-VIM resource orchestration	REST (SOL005)
Vi-Vnfm	VIM ↔ VNFM	VNF resource requests	OpenStack API
Ve-Vnfm-em	VNFM ↔ VNF (EM)	VNF configuration and monitoring	NETCONF, REST
Ve-Vnfm-vnf	VNFM ↔ VNF	Direct VNF interface (indicators)	VNF-specific
Nf-Vi	VNF ↔ NFVI	Access to virtualized resources	SR-IOV, VirtIO
Vn-Nf	VNF ↔ VNF	Inter-VNF communication	VLs, IP networks

ETSI SOL Specifications:

The practical implementation of reference points is defined in ETSI SOL (Solutions) specifications:

SOL001: VNFD based on TOSCA

Defines the TOSCA-based format for VNF Descriptors
Data model for VDU, CP, VL definitions

SOL002: Ve-Vnfm Reference Point Interface

REST API for VNF lifecycle via Element Manager
Configuration and fault management operations

SOL003: Or-Vnfm Reference Point Interface

REST API for NFVO-VNFM communication
VNF lifecycle management operations from NFVO

SOL004: VNF Package Specification

CSAR package format for VNFs
Structure for images, scripts, metadata

SOL005: Or-Vi Reference Point Interface

REST API for NFVO-VIM communication
Resource management across VIMs

SOL007: NSD based on TOSCA

Defines Network Service Descriptor format
Composition of VNFs, VLs, and forwarding graphs

Converting Mermaid diagram...

Interoperability Reality

NFV Deployment Architectures

Pattern 1: Centralized MANO

All MANO components (NFVO, VNFM, VIM) deployed centrally, managing distributed NFVI:

Advantages: Single management point, simplified operations, unified view
Challenges: Single point of failure, WAN dependency for management traffic
Use Case: Initial NFV deployments, smaller operators

Pattern 2: Distributed MANO

MANO components distributed across locations with hierarchy:

Central NFVO with global view
Regional/PoP VNFMs and VIMs
Local autonomy with central coordination
Advantages: Resilience, reduced WAN dependency, scalability
Challenges: Consistency, synchronization complexity
Use Case: Large operators with multiple PoPs

Pattern 3: Hybrid Cloud NFV

NFV extended to public cloud:

Private NFVI for sensitive VNFs
Public cloud for burst capacity or specific workloads
Unified orchestration across environments
Advantages: Flexibility, burst capacity, reduced CapEx
Challenges: Security, connectivity, consistent performance
Use Case: Operators exploring cloud strategies

Centralized Pattern

•Single NFVO managing all resources
•Single VIM instance (or clustered)
•VNFMs at central location
•NFVI distributed across PoPs
•All management over WAN

Distributed Pattern

•Global NFVO + Regional NFVOs
•VIM per PoP or region
•VNFM distributed or per-function
•Local autonomy with synchronization
•Hierarchy for coordination

High Availability Considerations:

Production NFV deployments require HA at multiple levels:

MANO HA:

Clustered NFVO/VNFM instances
Database replication/clustering
Load balancing for API endpoints
No single point of failure in management path

NFVI HA:

Compute node redundancy (N+M sparing)
Storage replication/clustering
Network redundancy (dual switches, bonded NICs)
Automated failover/migration

VNF HA:

Multi-instance VNFs with load balancing
Active-standby or active-active configurations
Anti-affinity placement (VNFCs on different hosts)
Automatic healing on failure

Disaster Recovery:

Geographic redundancy for critical services
Data replication between sites
Automated failover procedures
Regular DR testing

Start Simple, Evolve Carefully

Summary: NFV Architecture

We've comprehensively explored the ETSI NFV architectural framework. Let's consolidate the key concepts:

Key Takeaways

•The NFV architecture has three main domains — VNFs (the network functions), NFVI (the infrastructure hosting them), and MANO (the management and orchestration layer coordinating everything).
•NFVI provides the foundation — Physical hardware, virtualization layer, and virtual resources form a layered infrastructure that must be carefully tuned for carrier-grade VNF performance.
•The VIM manages NFVI resources — OpenStack is the dominant VIM, providing compute, storage, and network management through well-defined APIs.
•The VNFM handles VNF lifecycle — From instantiation through scaling and healing to termination, the VNFM translates high-level requests into concrete infrastructure actions.
•The NFVO orchestrates services and resources — Network Services composed of multiple VNFs are managed by the NFVO, which also coordinates resources across multiple VIMs.
•Reference points enable interoperability — Standardized interfaces (Or-Vnfm, Or-Vi, Vi-Vnfm, etc.) theoretically allow multi-vendor deployments, though practical interoperability requires careful testing.
•Deployment patterns vary by need — Centralized, distributed, and hybrid deployment architectures address different operational requirements and scale points.
•High availability is essential — Production NFV requires HA at MANO, NFVI, and VNF levels to meet carrier-grade reliability requirements.

What's Next:

Page Complete

3 / 5