Understanding Network Virtualization, NFV, and SDN

What is network virtualization? To explain this, we first show two simple, bold diagrams.

All communication applications consist of two parts: computing and networking. These two are inseparable, yet their relationship lacks symmetry; the network constantly drags down computing.

4G network RAN will continue to evolve, and future 4G air‑interface speeds are said to be ten times the current rate. With the explosion of smart devices, massive applications are connecting to 4G, creating a tsunami of traffic demand.

In traditional telecom networks, each service type runs on dedicated hardware with a specialized processor, occupying space regardless of usage, much like an executive’s private office that remains reserved even when the executive is absent.

This asymmetry hampers computing performance, leading some to consider virtualization. In other words, servers realize that being constantly slowed by the network is unsustainable and start “throwing bricks” at the network.

Dedicated hardware for dedicated services is expensive; to reduce cost we must make better use of resources.

Imagine a huge vacant apartment building that you want to rent out, but each tenant has different requirements. By virtualizing the building into various styles, you can rent different portions to different tenants, charging based on occupancy time and space usage.

In October 2012, thirteen operators, under the ETSI organization, formally established the Network Functions Virtualization (NFV) workgroup (ETSI ISG NFV) to define requirements and architecture for network virtualization.

Virtualization technology includes memory virtualization, where the required memory space can far exceed physical RAM, and VPN technology, which creates a secure, stable “tunnel” over a public network that feels like a private network.

NFV is built on large‑scale off‑the‑shelf (OTS) servers and uses software‑defined methods to virtualize network functions. The virtual machines (VMs) used in NFV are a form of virtualization.

Software‑defined VM deployment is low‑cost and can quickly adapt to changing network demands. A VM can host everything on a single physical server; with cloud computing and virtualization, redundant servers can be consolidated, enabling parallel processing, meeting peak traffic, releasing resources on demand, simplifying deployment, fault management, and rapid upgrades.

NFV technology overturns the traditional closed, dedicated telecom platform model and introduces flexible, elastic resource management. ETSI NFV proposes a breakthrough architecture that overcomes the limitations of traditional network elements.

NFV consists of three main components: VNF (Virtualized Network Function), NFVI (NFV Infrastructure), and MANO (Management and Orchestration).

(1) The virtual network layer (VNF) shares the same physical OTS server among multiple VNFs, representing the software implementation of various network functions such as EPC, IMS, etc.

(2) NFVI is the infrastructure layer, which from a cloud‑computing perspective is a resource pool. It virtualizes physical compute, storage, and switching resources into virtual pools, mapping to geographically distributed data centers connected by high‑speed links.

(3) NFV MANO, based on Service Level Agreements (SLAs), manages fair allocation of physical resources, redundancy, error handling, and elastic adjustments, similar to current OSS/BSS systems.

Thus, the modern mobile communication network architecture looks like this: the VNF at the top of the diagram represents the logical implementation of network element functions, and a VNF Forwarding Graph (VNF‑FG) composed of multiple VNFs defines LTE network services.

What is the relationship between Software‑Defined Networking (SDN) and NFV? NFV virtualizes various network functions, while SDN virtualizes the network itself (e.g., nodes and links between nodes).

In such a diagram, a network consists of nodes and the links between them. Each node has a control plane and exchanges network information with other nodes. When node H learns of a new network (10.2.3.x/24), it informs the control plane, which then propagates the information through linked nodes via Link State Advertisements (LSAs), updating routing tables across the network.

If a link between nodes C and E fails, nodes A may still try to send traffic through the broken C‑E link until the network converges, causing temporary congestion—a problem that worsens as the network scales.

Node G comprises a control plane and a data plane. The control plane, being software‑based, processes control messages slower (5‑10×) than hardware‑based data plane logic. While the control plane’s flexibility is valuable, its latency must improve to handle massive IoT device connections.

SDN separates the control plane from the data plane, consolidating network control into a unified view. Routing protocols, route generation, and other functions run in the control plane, while the data plane forwards packets. The OpenFlow protocol enables this separation by mirroring the network topology to the control plane, which then continuously updates it.

After initialization, the control plane sends forwarding tables to each forwarding node. When node H discovers a new network, it notifies the control plane via OpenFlow; the control plane then creates new routing entries for all nodes, allowing user data to reach the new network.

Tip: Search for “ICT_Architect” or scan the QR code below to follow the public account for more content.

It is said that friends who like and share the article have reached the pinnacle of life.