Network Function Virtualization - Learning Module

Loading content...

0/228

Relationship with SDN: Complementary Technologies

NFV and SDN: Understanding the Relationship

NFV and SDN are two of the most significant transformations in networking over the past decade. They emerged around the same time, are often discussed together, and frequently appear in the same deployments. Yet they are fundamentally different technologies solving different problems.

The confusion between NFV and SDN is common—even among experienced network professionals. Both represent shifts toward software-based networking, both aim to increase flexibility and reduce costs, and both challenge traditional network architecture. But their approaches, origins, and mechanisms are distinct.

Understanding how NFV and SDN relate—where they overlap, where they differ, and how they complement each other—is essential for designing modern network infrastructure. This page provides that understanding.

What You Will Learn

By the end of this page, you will understand the fundamental differences between NFV and SDN, how they address different aspects of network transformation, where they overlap and complement each other, common integration patterns for NFV+SDN deployments, and how SDN enhances NFV infrastructure and VNF connectivity.

Distinguishing NFV and SDN

Before exploring how NFV and SDN work together, we must clearly distinguish what each technology actually is and what problems it solves.

Software-Defined Networking (SDN):

SDN is an architectural approach that separates the control plane from the data plane in network devices, centralizing control in software-based controllers.

Core SDN Principles:

Separation of Concerns: Control logic removed from individual network devices
Centralized Control: Network-wide decisions made by central controller
Programmability: Network behavior defined through software/APIs
Open Interfaces: Standardized protocols (OpenFlow) between layers

Network Function Virtualization (NFV):

NFV virtualizes network functions that traditionally ran on proprietary hardware appliances, implementing them as software on commodity hardware.

Core NFV Principles:

Virtualization: Network functions as software, not hardware
Commodity Infrastructure: Standard servers, not specialized appliances
Decoupling: Software lifecycle independent of hardware
Automation: Lifecycle management through MANO

NFV vs SDN: Fundamental Comparison
Aspect	SDN	NFV
Primary Goal	Centralize network control, enable programmability	Virtualize network functions, reduce appliance dependency
What It Changes	How network forwarding decisions are made	Where network functions execute
Core Mechanism	Control/data plane separation	Hardware to software virtualization
Key Technology	OpenFlow, controllers, southbound/northbound APIs	Hypervisors, VMs/containers, MANO
Origin	Academic research (Stanford/Berkeley, 2008)	Telecom operator initiative (ETSI, 2012)
Initial Focus	Data center switching, campus networks	Telecom network functions (SBC, EPC, firewalls)
Hardware Impact	Switches become simpler (forwarding only)	Specialized appliances replaced by servers
Standards Body	ONF (Open Networking Foundation)	ETSI ISG NFV

The Key Insight:

SDN is about the control and management of network connectivity
NFV is about the execution environment for network functions

They operate at different points in the network architecture:

SDN addresses: How do we route traffic? How do we configure forwarding rules?
NFV addresses: Where do we run the firewall? How do we deploy the load balancer?

This distinction explains why they're complementary—they solve different problems that both exist in a complete network architecture.

The Simple Mental Model

Think of it this way: NFV tells you that your firewall runs as software on a server instead of a dedicated appliance. SDN tells you how traffic reaches that firewall—the forwarding rules, the paths, the policies that direct packets to the right destination. You need both: somewhere to run the function (NFV) and a way to connect it (SDN can help with this).

Independent but Complementary

A crucial principle to understand: NFV and SDN are independent technologies. Neither requires the other. Yet they are deeply complementary, and combining them creates more powerful solutions than either alone.

NFV Without SDN:

Perfectly viable—and commonly deployed:

VNFs deployed on commodity servers
Traditional networking connects VNFs and external networks
VLANs, standard IP routing, conventional switches
NFV benefits (virtualization, automation) without SDN complexity

Use Cases:

Initial NFV deployments prioritizing simplicity
Environments with existing network infrastructure investment
Organizations lacking SDN expertise

SDN Without NFV:

Also common—SDN emerged earlier and has its own deployment patterns:

Physical network devices with separated control plane
SDN controllers manage forwarding on hardware switches
Network functions remain on physical appliances

Use Cases:

Data center fabrics (spine-leaf with SDN control)
Campus networks with SDN-based policy
WAN optimization with SD-WAN

NFV Standalone Benefits

•Reduced CapEx through commodity hardware
•Faster time-to-market for new functions
•Dynamic scaling of VNFs
•Automated VNF lifecycle management
•Multi-vendor VNF ecosystem

SDN Standalone Benefits

•Centralized network visibility and control
•Programmable network behavior
•Dynamic traffic engineering
•Simplified network operations
•Vendor-agnostic control plane

NFV + SDN Together:

When combined, NFV and SDN create synergies neither achieves alone:

SDN Enhances NFV:

Dynamic VNF connectivity as VNFs scale
Service function chaining through SDN forwarding
Network policies following VNFs as they migrate
Simplified multi-tenant network isolation
Consistent network abstraction across NFVI

NFV Enhances SDN:

SDN controllers as VNFs (virtualized control plane)
SDN applications deployed as VNFs
NFV infrastructure hosting SDN elements
Unified orchestration for network and functions

The Resulting Architecture:

In the most advanced deployments, NFV and SDN merge into a unified software-defined infrastructure:

VNFs provide network functionality
SDN provides connectivity between VNFs
Unified orchestration manages both
Complete network is software-defined

Vendor Narratives vs. Reality

Vendors sometimes blur NFV and SDN distinctions for marketing purposes—selling 'SDN solutions' that are primarily NFV, or vice versa. Look past the terminology to understand what's actually being offered: Is it virtualizing functions? That's NFV. Is it centralizing network control? That's SDN. Is it both? Understand how each aspect works independently.

SDN in NFV Infrastructure

One of the most important integration points between NFV and SDN is using SDN to connect VNFs within the NFV Infrastructure. SDN-based virtual networking provides the flexibility and programmability that dynamic VNF deployments require.

The NFVI Networking Challenge:

VNFs create unique networking demands:

Dynamic Instantiation: New VNFs appear and disappear frequently
Scaling: VNF instances scale out and in based on load
Migration: VNFs may move between hosts for maintenance or load balancing
Multi-Tenancy: Different VNFs/tenants require isolation
Service Chaining: Traffic must flow through VNF sequences

Traditional networking struggles with this dynamism—VLANs don't scale, static configurations can't keep pace with VNF changes, and manual provisioning creates bottlenecks.

SDN Virtual Networking Solutions:

SDN-based virtual networking addresses these challenges:

SDN Virtual Networking for NFVI
Solution	Technology	How It Helps NFV
Open vSwitch (OVS)	Software-defined vSwitch	Flexible VM connectivity, programmable flow rules
OVS-DPDK	OVS with user-space data path	High-performance VNF connectivity
Neutron + SDN plugins	OpenStack networking + SDN	API-driven network provisioning for VNFs
Contrail/Tungsten Fabric	SDN controller + overlay	Scalable multi-tenant networking
NSX	VMware SDN platform	Microsegmentation, distributed services
Nuage Networks	Nokia SDN platform	Policy-based automation

SDN Controller Integration with VIM:

In OpenStack-based NFVI, SDN integrates through Neutron plugins:

VNFM requests network via NFVO/VIM APIs
Neutron receives request and delegates to SDN plugin
SDN controller programs virtual switches on compute nodes
VNF connectivity established automatically
Policies enforced through SDN flow rules

This integration enables:

Automatic network provisioning as VNFs instantiate
Consistent policy enforcement across VNF instances
Network reconfiguration as VNFs scale or migrate
Centralized visibility into VNF connectivity

Converting Mermaid diagram...

Performance Considerations

While SDN enables flexible VNF networking, software-defined virtual switches add latency compared to direct NIC access. For high-performance data plane VNFs, consider SR-IOV to bypass the virtual switch, accepting reduced flexibility for improved performance. The choice between flexibility and performance is a key architectural decision.

Service Function Chaining with SDN

One of the most powerful integrations of NFV and SDN is Service Function Chaining (SFC)—the ability to define and enforce traffic paths through sequences of VNFs.

The SFC Concept:

Traffic passing through a network often requires processing by multiple functions. Traditionally, this meant physical cabling through appliances. In NFV, we want the same chaining—but dynamically, for virtualized functions.

Example Service Chains:

Enterprise Security: Firewall → IDS/IPS → Web Proxy → Content Filter → NAT
Mobile Network: DPI → Policy Control → Charging → NAT44 → Internet
Cloud Provider: Load Balancer → WAF → Application Servers → Cache

The SFC Challenge:

Without SDN, traffic must be explicitly routed through each VNF—complicating addressing, creating single points of failure, and limiting flexibility. SDN provides the mechanisms to define chains declaratively and enforce them through forwarding rules.

SFC Architecture Components:

Classifier:

First element in the chain
Identifies traffic that should enter the chain
Matches on any packet headers (5-tuple, VLAN, etc.)
Attaches SFC metadata to qualifying traffic

Service Function Path (SFP):

Ordered list of service functions for traffic to visit
Defined by the orchestrator/controller
May have multiple paths for different traffic classes

Service Function Forwarder (SFF):

Steers traffic to the next function in the chain
Present at each hop in the chain
May be implemented in OVS, smart NICs, or physical switches

Network Service Header (NSH):

RFC 8300 standard for SFC metadata
Carried with packets through the chain
Contains: Service Path ID, Service Index, Metadata
Service Index decremented at each hop

sfc-configuration-example.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
# Service Function Chain Configuration Example
# OpenDaylight SFC Controller Configuration
 
service-function-chains:
  # Define the logical chain: FW -> DPI -> NAT
  - name: "enterprise-security-chain"
    symmetric: true  # Same path for return traffic
    sfc-service-function:
      - name: "firewall-sf"
        type: "firewall"
        order: 1
      - name: "dpi-sf"
        type: "dpi"
        order: 2
      - name: "nat-sf"
        type: "nat"
        order: 3
 
service-function-paths:
  # Instance of the chain for specific deployment
  - name: "esp-path-1"
    service-chain-name: "enterprise-security-chain"
    starting-index: 255
    symmetric: true
    service-path-hop:
      - hop-number: 0
        service-function-name: "firewall-1"  # Specific VNF instance
        service-function-forwarder: "sff-1"
      - hop-number: 1
        service-function-name: "dpi-1"
        service-function-forwarder: "sff-2"
      - hop-number: 2
        service-function-name: "nat-1"
        service-function-forwarder: "sff-2"
 
service-function-classifiers:
  - name: "enterprise-classifier"
    access-list: "enterprise-acl"
    scl-service-function-forwarder:
      - name: "classifier-sff"
        interface: "eth0"
 
access-lists:
  # Traffic matching rules
  - name: "enterprise-acl"
    access-list-entry:
      - rule-name: "http-traffic"
        matches:
          destination-port-range:
            lower-port: 80
            upper-port: 80
          protocol: 6  # TCP
        actions:
          service-function-path: "esp-path-1"
      - rule-name: "https-traffic"
        matches:
          destination-port-range:
            lower-port: 443
            upper-port: 443
          protocol: 6
        actions:
          service-function-path: "esp-path-1"
 
service-functions:
  # VNF registrations
  - name: "firewall-1"
    type: "firewall"
    ip-mgmt-address: "10.0.1.10"
    sf-data-plane-locator:
      - name: "fw1-dpl"
        ip: "10.0.10.10"
        port: 6633
        transport: "service-locator:vxlan-gpe"
  
  - name: "dpi-1"
    type: "dpi"
    ip-mgmt-address: "10.0.1.20"
    sf-data-plane-locator:
      - name: "dpi1-dpl"
        ip: "10.0.10.20"
        port: 6633
        transport: "service-locator:vxlan-gpe"
  
  - name: "nat-1"
    type: "nat"
    ip-mgmt-address: "10.0.1.30"
    sf-data-plane-locator:
      - name: "nat1-dpl"
        ip: "10.0.10.30"
        port: 6633
        transport: "service-locator:vxlan-gpe"

SDN Enables Dynamic SFC:

The power of SDN-based SFC comes from its dynamism:

Chain Modification: Add/remove functions without reconfiguring VNFs
Traffic Steering: Redirect specific flows to different paths
Scaling Integration: Update chains as VNFs scale out
Failure Handling: Reroute around failed VNF instances
Policy Enforcement: Apply business rules to chain selection

SFC Implementation Options:

Approach	Mechanism	Pros	Cons
NSH (RFC 8300)	Metadata header	Standard, flexible	VNFs must support NSH
VXLAN + Metadata	Overlay encapsulation	Widely supported	Requires specific VXLAN extensions
Policy-Based Routing	Next-hop steering	Simple, works with existing VNFs	Less flexible, harder to manage
Proxy/Agent	Inline agent at each hop	VNF-agnostic	Agent overhead, complexity

SFC is a Killer App for NFV+SDN

Service Function Chaining represents perhaps the clearest demonstration of NFV+SDN synergy. NFV provides the virtualized functions; SDN provides the intelligent traffic steering. Together, they enable service chains that would be impractical with physical appliances and traditional networking. For complex service delivery, SFC is often the justification for both technologies.

SDN Controllers as VNFs

The relationship between NFV and SDN isn't merely about SDN enabling NFV—NFV can also host SDN components. SDN controllers themselves are software applications that can run as VNFs on NFV infrastructure.

SDN Controller Virtualization:

Traditionally, SDN controllers run on dedicated servers or VMs. In an NFV context, they become VNFs:

Deployed through standard MANO procedures
Scaled dynamically based on network size
Managed with VNF lifecycle operations
Benefiting from NFVI HA capabilities

Benefits of Controller-as-VNF:

Unified Management: Single orchestration for all network software
Dynamic Placement: Deploy controllers close to managed infrastructure
Elastic Scaling: Scale controller capacity with network growth
Consistent Operations: Same lifecycle management as other VNFs

SDN Controllers Deployable as VNFs
Controller	Origin	Virtualization Support	Typical Use Case
OpenDaylight (ODL)	Linux Foundation	VM/Container images	Carrier SDN, enterprise
ONOS	ONF	Docker containers	Carrier/ISP networks
Ryu	Open source	Lightweight Python app	Research, simple deployments
Floodlight	Big Switch (now defunct)	Java application	Data center, education
Tungsten Fabric	Linux Foundation	Container microservices	Multi-cloud networking

Architectural Considerations:

Deploying SDN controllers as VNFs introduces dependencies that require careful design:

Bootstrap Problem:

VNF deployment requires networking
But networking is provided by SDN controller
Solution: Separate management network, staged bootstrap

High Availability:

Controller failure impacts all managed network elements
HA clustering essential (multiple controller instances)
Anti-affinity placement across physical hosts

Performance Sensitivity:

Controller latency affects network responsiveness
May require low-latency placement options
Consider SR-IOV for controller networking

Versioning and Updates:

Controller updates affect entire network
Careful rolling update procedures
Fallback strategies for failed upgrades

Converting Mermaid diagram...

Chicken-and-Egg Complexity

The most significant challenge with SDN controllers as VNFs is the bootstrap dependency: deploying VNFs requires network connectivity, but that connectivity depends on the SDN controller. Solutions include: dedicated out-of-band management networks, staged bootstrap with minimal static config, or hybrid approaches where basic connectivity is non-SDN while advanced features use SDN.

NFV+SDN Integration Patterns

Various integration patterns have emerged for combining NFV and SDN in production deployments. Understanding these patterns helps in selecting the right approach for specific requirements.

Pattern 1: SDN-Enabled Underlay

SDN manages the physical network fabric; NFV runs independently on top.

┌─────────────────────┐
│  VNFs (NFV Layer)   │
├─────────────────────┤
│  Virtual Networking │  ← Traditional (VLANs) or Overlay
├─────────────────────┤
│  SDN-Controlled     │  ← SDN manages physical switches
│  Physical Fabric    │
└─────────────────────┘

Characteristics:

SDN optimizes physical network (spine-leaf, traffic engineering)
VNF networking uses standard virtualization mechanisms
Clear separation between infrastructure and workload networking
Simpler to implement than full SDN integration

Pattern 2: SDN-Managed Overlay

SDN extends into virtual networking, managing VNF connectivity through overlay networks.

┌─────────────────────┐
│  VNFs (NFV Layer)   │
├─────────────────────┤
│  SDN-Controlled     │  ← SDN controller manages overlays
│  Virtual Networking │     (Neutron + SDN plugin)
├─────────────────────┤
│  Physical Fabric    │  ← May or may not use SDN
└─────────────────────┘

Characteristics:

Complete programmability of VNF networking
Dynamic network provisioning as VNFs scale
Enables advanced features (SFC, microsegmentation)
More complex, requires mature SDN implementation

Pattern 3: Unified SDN Fabric

Single SDN controller manages both physical and virtual networking.

┌─────────────────────────────────────┐
│                                     │
│         SDN Controller              │
│  (Manages physical + virtual)       │
│                                     │
└─────────────┬───────────────────────┘
              │
        ┌─────┴─────┐
        ▼           ▼
    Physical    Virtual
    Switches    Switches

Characteristics:

Most comprehensive integration
End-to-end network visibility and control
Single policy domain across all networking
Highest complexity, requires deep integration

NFV+SDN Integration Pattern Comparison
Pattern	Complexity	Flexibility	Use Case
SDN-Enabled Underlay	Low	Limited	Initial NFV, existing SDN fabric
SDN-Managed Overlay	Medium	High	Dynamic VNF deployments, SFC
Unified SDN Fabric	High	Maximum	Greenfield, advanced requirements
Hybrid (Mixed)	Medium	Moderate	Migration, specific use cases

Real-World Implementation Examples:

Pattern 1 Example: Arista EOS + OpenStack

Arista EOS with CloudVision manages leaf-spine fabric
OpenStack Neutron with ML2/OVS for VNF networking
Clear boundary at ToR switches

Pattern 2 Example: OpenStack + Tungsten Fabric

Tungsten Fabric (Contrail) provides SDN overlay
Neutron API with Tungsten plugin
Overlay extends to bare-metal and VMs

Pattern 3 Example: VMware NSX-T + vCloud NFV

NSX-T manages physical and virtual networking
vCloud NFV for MANO
Integrated microsegmentation and SFC

Start Simple, Add Complexity Carefully

Most successful NFV+SDN deployments start with simpler integration patterns and evolve as requirements demand. Pattern 1 (SDN Underlay) provides a solid foundation. Add overlay SDN (Pattern 2) when dynamic VNF networking becomes a bottleneck. Consider unified fabric (Pattern 3) only when specific requirements justify the complexity—it's powerful but operationally demanding.

The ONAP and OPNFV Ecosystem

The Linux Foundation hosts key open-source projects that combine NFV and SDN capabilities, providing integrated platforms for software-defined network infrastructure.

ONAP (Open Network Automation Platform):

ONAP is the most comprehensive open-source platform for network automation, combining NFV orchestration with SDN control:

Key ONAP Capabilities:

Design-time Framework: Service design, policy creation, VNF onboarding
Runtime Framework: Orchestration, controllers, inventory
Controllers: SDN-C (SDN Controller), APP-C (Application Controller)
Policy Framework: Declarative policy for automation
AAI (Active and Available Inventory): Real-time resource tracking

Converting Mermaid diagram...

OPNFV (Open Platform for NFV):

OPNFV (now merged into Anuket) focused on NFV infrastructure and testing:

Reference Architecture: Validated NFVI configurations
Testing Frameworks: Functest, Yardstick, Bottlenecks
Integration Projects: Verified component combinations
Installer Projects: Multiple NFVI deployment options

Anuket (OPNFV + CNTT Merger):

The Anuket project continues OPNFV's mission with added focus on cloud-native:

Reference Model: Standardized infrastructure definitions
Reference Architecture: RA1 (OpenStack), RA2 (Kubernetes)
Reference Implementation: Validated deployments
Reference Conformance: Testing and certification

Open Source NFV+SDN Stack:

Key Open Source Projects for NFV+SDN
Project	Role	Key Features
ONAP	End-to-end platform	Design, orchestration, policy, control
OSM	MANO implementation	ETSI-aligned NFVO/VNFM
OpenStack	VIM	Compute, storage, networking
Kubernetes	Container platform	CNF hosting, container orchestration
OpenDaylight	SDN controller	OpenFlow, NETCONF, multi-protocol
ONOS	SDN controller	Carrier-grade SDN
Tungsten Fabric	SDN networking	Multi-cloud overlay networking
Anuket	Reference/testing	RA, RI, RC specifications

Open Source Complexity

These open-source platforms are powerful but complex. ONAP alone comprises dozens of microservices. Production deployments require significant expertise, customization, and ongoing maintenance. Many operators use commercial distributions that package and support the open-source components rather than deploying raw upstream projects.

Summary: Relationship with SDN

We've comprehensively explored the relationship between NFV and SDN. Let's consolidate the key concepts:

Key Takeaways

•NFV and SDN are distinct technologies — NFV virtualizes network functions; SDN centralizes network control. They solve different problems through different mechanisms.
•Neither requires the other — NFV can run on traditional networks; SDN can manage physical appliances. Each provides value independently.
•They are deeply complementary — Combined, they create software-defined infrastructure where both functions and connectivity are programmable and dynamic.
•SDN enhances NFV networking — SDN-based virtual networking provides the flexibility VNFs need: dynamic provisioning, service chaining, policy enforcement.
•Service Function Chaining is a key integration point — SDN enables traffic steering through VNF sequences, one of the most valuable NFV+SDN use cases.
•SDN components can be VNFs — SDN controllers themselves can run as virtualized functions on NFV infrastructure, creating unified software-defined platforms.
•Multiple integration patterns exist — From SDN-enabled underlay to unified SDN fabric, different patterns suit different requirements and maturity levels.
•Open source ecosystems integrate NFV and SDN — Platforms like ONAP provide comprehensive NFV+SDN capabilities, though with significant complexity.

What's Next:

With the NFV-SDN relationship understood, we'll explore NFV Use Cases in the final page of this module—examining how NFV is deployed in practice across telecommunications, enterprise, and service provider environments.

Page Complete

You now understand how NFV and SDN relate—their distinctions, complementary nature, and integration patterns. This knowledge enables you to make informed decisions about combining these technologies and to understand modern network architectures that leverage both.

Relationship with SDN: Complementary Technologies

NFV and SDN: Understanding the Relationship

What You Will Learn

Distinguishing NFV and SDN

Before exploring how NFV and SDN work together, we must clearly distinguish what each technology actually is and what problems it solves.

Software-Defined Networking (SDN):

SDN is an architectural approach that separates the control plane from the data plane in network devices, centralizing control in software-based controllers.

Core SDN Principles:

Separation of Concerns: Control logic removed from individual network devices
Centralized Control: Network-wide decisions made by central controller
Programmability: Network behavior defined through software/APIs
Open Interfaces: Standardized protocols (OpenFlow) between layers

Network Function Virtualization (NFV):

NFV virtualizes network functions that traditionally ran on proprietary hardware appliances, implementing them as software on commodity hardware.

Core NFV Principles:

Virtualization: Network functions as software, not hardware
Commodity Infrastructure: Standard servers, not specialized appliances
Decoupling: Software lifecycle independent of hardware
Automation: Lifecycle management through MANO

NFV vs SDN: Fundamental Comparison
Aspect	SDN	NFV
Primary Goal	Centralize network control, enable programmability	Virtualize network functions, reduce appliance dependency
What It Changes	How network forwarding decisions are made	Where network functions execute
Core Mechanism	Control/data plane separation	Hardware to software virtualization
Key Technology	OpenFlow, controllers, southbound/northbound APIs	Hypervisors, VMs/containers, MANO
Origin	Academic research (Stanford/Berkeley, 2008)	Telecom operator initiative (ETSI, 2012)
Initial Focus	Data center switching, campus networks	Telecom network functions (SBC, EPC, firewalls)
Hardware Impact	Switches become simpler (forwarding only)	Specialized appliances replaced by servers
Standards Body	ONF (Open Networking Foundation)	ETSI ISG NFV

The Key Insight:

SDN is about the control and management of network connectivity
NFV is about the execution environment for network functions

They operate at different points in the network architecture:

SDN addresses: How do we route traffic? How do we configure forwarding rules?
NFV addresses: Where do we run the firewall? How do we deploy the load balancer?

This distinction explains why they're complementary—they solve different problems that both exist in a complete network architecture.

The Simple Mental Model

Independent but Complementary

NFV Without SDN:

Perfectly viable—and commonly deployed:

VNFs deployed on commodity servers
Traditional networking connects VNFs and external networks
VLANs, standard IP routing, conventional switches
NFV benefits (virtualization, automation) without SDN complexity

Use Cases:

Initial NFV deployments prioritizing simplicity
Environments with existing network infrastructure investment
Organizations lacking SDN expertise

SDN Without NFV:

Also common—SDN emerged earlier and has its own deployment patterns:

Physical network devices with separated control plane
SDN controllers manage forwarding on hardware switches
Network functions remain on physical appliances

Use Cases:

Data center fabrics (spine-leaf with SDN control)
Campus networks with SDN-based policy
WAN optimization with SD-WAN

NFV Standalone Benefits

•Reduced CapEx through commodity hardware
•Faster time-to-market for new functions
•Dynamic scaling of VNFs
•Automated VNF lifecycle management
•Multi-vendor VNF ecosystem

SDN Standalone Benefits

•Centralized network visibility and control
•Programmable network behavior
•Dynamic traffic engineering
•Simplified network operations
•Vendor-agnostic control plane

NFV + SDN Together:

When combined, NFV and SDN create synergies neither achieves alone:

SDN Enhances NFV:

Dynamic VNF connectivity as VNFs scale
Service function chaining through SDN forwarding
Network policies following VNFs as they migrate
Simplified multi-tenant network isolation
Consistent network abstraction across NFVI

NFV Enhances SDN:

SDN controllers as VNFs (virtualized control plane)
SDN applications deployed as VNFs
NFV infrastructure hosting SDN elements
Unified orchestration for network and functions

The Resulting Architecture:

In the most advanced deployments, NFV and SDN merge into a unified software-defined infrastructure:

VNFs provide network functionality
SDN provides connectivity between VNFs
Unified orchestration manages both
Complete network is software-defined

Vendor Narratives vs. Reality

SDN in NFV Infrastructure

The NFVI Networking Challenge:

VNFs create unique networking demands:

Dynamic Instantiation: New VNFs appear and disappear frequently
Scaling: VNF instances scale out and in based on load
Migration: VNFs may move between hosts for maintenance or load balancing
Multi-Tenancy: Different VNFs/tenants require isolation
Service Chaining: Traffic must flow through VNF sequences

Traditional networking struggles with this dynamism—VLANs don't scale, static configurations can't keep pace with VNF changes, and manual provisioning creates bottlenecks.

SDN Virtual Networking Solutions:

SDN-based virtual networking addresses these challenges:

SDN Virtual Networking for NFVI
Solution	Technology	How It Helps NFV
Open vSwitch (OVS)	Software-defined vSwitch	Flexible VM connectivity, programmable flow rules
OVS-DPDK	OVS with user-space data path	High-performance VNF connectivity
Neutron + SDN plugins	OpenStack networking + SDN	API-driven network provisioning for VNFs
Contrail/Tungsten Fabric	SDN controller + overlay	Scalable multi-tenant networking
NSX	VMware SDN platform	Microsegmentation, distributed services
Nuage Networks	Nokia SDN platform	Policy-based automation

SDN Controller Integration with VIM:

In OpenStack-based NFVI, SDN integrates through Neutron plugins:

VNFM requests network via NFVO/VIM APIs
Neutron receives request and delegates to SDN plugin
SDN controller programs virtual switches on compute nodes
VNF connectivity established automatically
Policies enforced through SDN flow rules

This integration enables:

Automatic network provisioning as VNFs instantiate
Consistent policy enforcement across VNF instances
Network reconfiguration as VNFs scale or migrate
Centralized visibility into VNF connectivity

Converting Mermaid diagram...

Performance Considerations

Service Function Chaining with SDN

One of the most powerful integrations of NFV and SDN is Service Function Chaining (SFC)—the ability to define and enforce traffic paths through sequences of VNFs.

The SFC Concept:

Example Service Chains:

Enterprise Security: Firewall → IDS/IPS → Web Proxy → Content Filter → NAT
Mobile Network: DPI → Policy Control → Charging → NAT44 → Internet
Cloud Provider: Load Balancer → WAF → Application Servers → Cache

The SFC Challenge:

SFC Architecture Components:

Classifier:

First element in the chain
Identifies traffic that should enter the chain
Matches on any packet headers (5-tuple, VLAN, etc.)
Attaches SFC metadata to qualifying traffic

Service Function Path (SFP):

Ordered list of service functions for traffic to visit
Defined by the orchestrator/controller
May have multiple paths for different traffic classes

Service Function Forwarder (SFF):

Steers traffic to the next function in the chain
Present at each hop in the chain
May be implemented in OVS, smart NICs, or physical switches

Network Service Header (NSH):

RFC 8300 standard for SFC metadata
Carried with packets through the chain
Contains: Service Path ID, Service Index, Metadata
Service Index decremented at each hop

sfc-configuration-example.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
# Service Function Chain Configuration Example
# OpenDaylight SFC Controller Configuration
 
service-function-chains:
  # Define the logical chain: FW -> DPI -> NAT
  - name: "enterprise-security-chain"
    symmetric: true  # Same path for return traffic
    sfc-service-function:
      - name: "firewall-sf"
        type: "firewall"
        order: 1
      - name: "dpi-sf"
        type: "dpi"
        order: 2
      - name: "nat-sf"
        type: "nat"
        order: 3
 
service-function-paths:
  # Instance of the chain for specific deployment
  - name: "esp-path-1"
    service-chain-name: "enterprise-security-chain"
    starting-index: 255
    symmetric: true
    service-path-hop:
      - hop-number: 0
        service-function-name: "firewall-1"  # Specific VNF instance
        service-function-forwarder: "sff-1"
      - hop-number: 1
        service-function-name: "dpi-1"
        service-function-forwarder: "sff-2"
      - hop-number: 2
        service-function-name: "nat-1"
        service-function-forwarder: "sff-2"
 
service-function-classifiers:
  - name: "enterprise-classifier"
    access-list: "enterprise-acl"
    scl-service-function-forwarder:
      - name: "classifier-sff"
        interface: "eth0"
 
access-lists:
  # Traffic matching rules
  - name: "enterprise-acl"
    access-list-entry:
      - rule-name: "http-traffic"
        matches:
          destination-port-range:
            lower-port: 80
            upper-port: 80
          protocol: 6  # TCP
        actions:
          service-function-path: "esp-path-1"
      - rule-name: "https-traffic"
        matches:
          destination-port-range:
            lower-port: 443
            upper-port: 443
          protocol: 6
        actions:
          service-function-path: "esp-path-1"
 
service-functions:
  # VNF registrations
  - name: "firewall-1"
    type: "firewall"
    ip-mgmt-address: "10.0.1.10"
    sf-data-plane-locator:
      - name: "fw1-dpl"
        ip: "10.0.10.10"
        port: 6633
        transport: "service-locator:vxlan-gpe"
  
  - name: "dpi-1"
    type: "dpi"
    ip-mgmt-address: "10.0.1.20"
    sf-data-plane-locator:
      - name: "dpi1-dpl"
        ip: "10.0.10.20"
        port: 6633
        transport: "service-locator:vxlan-gpe"
  
  - name: "nat-1"
    type: "nat"
    ip-mgmt-address: "10.0.1.30"
    sf-data-plane-locator:
      - name: "nat1-dpl"
        ip: "10.0.10.30"
        port: 6633
        transport: "service-locator:vxlan-gpe"

SDN Enables Dynamic SFC:

The power of SDN-based SFC comes from its dynamism:

Chain Modification: Add/remove functions without reconfiguring VNFs
Traffic Steering: Redirect specific flows to different paths
Scaling Integration: Update chains as VNFs scale out
Failure Handling: Reroute around failed VNF instances
Policy Enforcement: Apply business rules to chain selection

SFC Implementation Options:

Approach	Mechanism	Pros	Cons
NSH (RFC 8300)	Metadata header	Standard, flexible	VNFs must support NSH
VXLAN + Metadata	Overlay encapsulation	Widely supported	Requires specific VXLAN extensions
Policy-Based Routing	Next-hop steering	Simple, works with existing VNFs	Less flexible, harder to manage
Proxy/Agent	Inline agent at each hop	VNF-agnostic	Agent overhead, complexity

SFC is a Killer App for NFV+SDN

SDN Controllers as VNFs

SDN Controller Virtualization:

Traditionally, SDN controllers run on dedicated servers or VMs. In an NFV context, they become VNFs:

Deployed through standard MANO procedures
Scaled dynamically based on network size
Managed with VNF lifecycle operations
Benefiting from NFVI HA capabilities

Benefits of Controller-as-VNF:

Unified Management: Single orchestration for all network software
Dynamic Placement: Deploy controllers close to managed infrastructure
Elastic Scaling: Scale controller capacity with network growth
Consistent Operations: Same lifecycle management as other VNFs

SDN Controllers Deployable as VNFs
Controller	Origin	Virtualization Support	Typical Use Case
OpenDaylight (ODL)	Linux Foundation	VM/Container images	Carrier SDN, enterprise
ONOS	ONF	Docker containers	Carrier/ISP networks
Ryu	Open source	Lightweight Python app	Research, simple deployments
Floodlight	Big Switch (now defunct)	Java application	Data center, education
Tungsten Fabric	Linux Foundation	Container microservices	Multi-cloud networking

Architectural Considerations:

Deploying SDN controllers as VNFs introduces dependencies that require careful design:

Bootstrap Problem:

VNF deployment requires networking
But networking is provided by SDN controller
Solution: Separate management network, staged bootstrap

High Availability:

Controller failure impacts all managed network elements
HA clustering essential (multiple controller instances)
Anti-affinity placement across physical hosts

Performance Sensitivity:

Controller latency affects network responsiveness
May require low-latency placement options
Consider SR-IOV for controller networking

Versioning and Updates:

Controller updates affect entire network
Careful rolling update procedures
Fallback strategies for failed upgrades

Converting Mermaid diagram...

Chicken-and-Egg Complexity

NFV+SDN Integration Patterns

Various integration patterns have emerged for combining NFV and SDN in production deployments. Understanding these patterns helps in selecting the right approach for specific requirements.

Pattern 1: SDN-Enabled Underlay

SDN manages the physical network fabric; NFV runs independently on top.

┌─────────────────────┐
│  VNFs (NFV Layer)   │
├─────────────────────┤
│  Virtual Networking │  ← Traditional (VLANs) or Overlay
├─────────────────────┤
│  SDN-Controlled     │  ← SDN manages physical switches
│  Physical Fabric    │
└─────────────────────┘

Characteristics:

SDN optimizes physical network (spine-leaf, traffic engineering)
VNF networking uses standard virtualization mechanisms
Clear separation between infrastructure and workload networking
Simpler to implement than full SDN integration

Pattern 2: SDN-Managed Overlay

SDN extends into virtual networking, managing VNF connectivity through overlay networks.

┌─────────────────────┐
│  VNFs (NFV Layer)   │
├─────────────────────┤
│  SDN-Controlled     │  ← SDN controller manages overlays
│  Virtual Networking │     (Neutron + SDN plugin)
├─────────────────────┤
│  Physical Fabric    │  ← May or may not use SDN
└─────────────────────┘

Characteristics:

Complete programmability of VNF networking
Dynamic network provisioning as VNFs scale
Enables advanced features (SFC, microsegmentation)
More complex, requires mature SDN implementation

Pattern 3: Unified SDN Fabric

Single SDN controller manages both physical and virtual networking.

┌─────────────────────────────────────┐
│                                     │
│         SDN Controller              │
│  (Manages physical + virtual)       │
│                                     │
└─────────────┬───────────────────────┘
              │
        ┌─────┴─────┐
        ▼           ▼
    Physical    Virtual
    Switches    Switches

Characteristics:

Most comprehensive integration
End-to-end network visibility and control
Single policy domain across all networking
Highest complexity, requires deep integration

NFV+SDN Integration Pattern Comparison
Pattern	Complexity	Flexibility	Use Case
SDN-Enabled Underlay	Low	Limited	Initial NFV, existing SDN fabric
SDN-Managed Overlay	Medium	High	Dynamic VNF deployments, SFC
Unified SDN Fabric	High	Maximum	Greenfield, advanced requirements
Hybrid (Mixed)	Medium	Moderate	Migration, specific use cases

Real-World Implementation Examples:

Pattern 1 Example: Arista EOS + OpenStack

Arista EOS with CloudVision manages leaf-spine fabric
OpenStack Neutron with ML2/OVS for VNF networking
Clear boundary at ToR switches

Pattern 2 Example: OpenStack + Tungsten Fabric

Tungsten Fabric (Contrail) provides SDN overlay
Neutron API with Tungsten plugin
Overlay extends to bare-metal and VMs

Pattern 3 Example: VMware NSX-T + vCloud NFV

NSX-T manages physical and virtual networking
vCloud NFV for MANO
Integrated microsegmentation and SFC

Start Simple, Add Complexity Carefully

The ONAP and OPNFV Ecosystem

The Linux Foundation hosts key open-source projects that combine NFV and SDN capabilities, providing integrated platforms for software-defined network infrastructure.

ONAP (Open Network Automation Platform):

ONAP is the most comprehensive open-source platform for network automation, combining NFV orchestration with SDN control:

Key ONAP Capabilities:

Design-time Framework: Service design, policy creation, VNF onboarding
Runtime Framework: Orchestration, controllers, inventory
Controllers: SDN-C (SDN Controller), APP-C (Application Controller)
Policy Framework: Declarative policy for automation
AAI (Active and Available Inventory): Real-time resource tracking

Converting Mermaid diagram...

OPNFV (Open Platform for NFV):

OPNFV (now merged into Anuket) focused on NFV infrastructure and testing:

Reference Architecture: Validated NFVI configurations
Testing Frameworks: Functest, Yardstick, Bottlenecks
Integration Projects: Verified component combinations
Installer Projects: Multiple NFVI deployment options

Anuket (OPNFV + CNTT Merger):

The Anuket project continues OPNFV's mission with added focus on cloud-native:

Reference Model: Standardized infrastructure definitions
Reference Architecture: RA1 (OpenStack), RA2 (Kubernetes)
Reference Implementation: Validated deployments
Reference Conformance: Testing and certification

Open Source NFV+SDN Stack:

Key Open Source Projects for NFV+SDN
Project	Role	Key Features
ONAP	End-to-end platform	Design, orchestration, policy, control
OSM	MANO implementation	ETSI-aligned NFVO/VNFM
OpenStack	VIM	Compute, storage, networking
Kubernetes	Container platform	CNF hosting, container orchestration
OpenDaylight	SDN controller	OpenFlow, NETCONF, multi-protocol
ONOS	SDN controller	Carrier-grade SDN
Tungsten Fabric	SDN networking	Multi-cloud overlay networking
Anuket	Reference/testing	RA, RI, RC specifications

Open Source Complexity

Summary: Relationship with SDN

We've comprehensively explored the relationship between NFV and SDN. Let's consolidate the key concepts:

Key Takeaways

•NFV and SDN are distinct technologies — NFV virtualizes network functions; SDN centralizes network control. They solve different problems through different mechanisms.
•Neither requires the other — NFV can run on traditional networks; SDN can manage physical appliances. Each provides value independently.
•They are deeply complementary — Combined, they create software-defined infrastructure where both functions and connectivity are programmable and dynamic.
•SDN enhances NFV networking — SDN-based virtual networking provides the flexibility VNFs need: dynamic provisioning, service chaining, policy enforcement.
•Service Function Chaining is a key integration point — SDN enables traffic steering through VNF sequences, one of the most valuable NFV+SDN use cases.
•SDN components can be VNFs — SDN controllers themselves can run as virtualized functions on NFV infrastructure, creating unified software-defined platforms.
•Multiple integration patterns exist — From SDN-enabled underlay to unified SDN fabric, different patterns suit different requirements and maturity levels.
•Open source ecosystems integrate NFV and SDN — Platforms like ONAP provide comprehensive NFV+SDN capabilities, though with significant complexity.

What's Next:

Page Complete