Chapter 17

SDN and NFV

The open ecology of the computing industry has brought about the booming
development of many fields such as general-purpose hardware, operating systems,
virtualization, middleware, cloud computing and software applications. The net-
working industry is also seeking to change and evolve, with Software Defined
Networking (SDN) and Network Functional Virtualization (NFV) being two con-
cepts in the limelight.
This chapter is designed to help engineers understand the concepts of SDN and
NFV, the SDN network architecture and NFV key technologies and the history of
architecture development. Meanwhile, it is also a brief introduction to Huawei SDN
solutions and NFV solutions.

17.1 Overview of Traditional Networks

17.1.1 Traditional Networks and Their Distributed Control

Architectures

Traditional network (classical IP network) is a distributed, peer-to-peer control

network. As shown in Fig. 17.1, each device in the network has a separate manage-
ment plane, control plane, and forwarding plane. The control plane of the devices
interacts with routing protocols peer-to-peer and then independently generates the
forwarding plane to guide the forwarding of messages.
• The management plane mainly includes the device management system and the
service management system. The device management system is responsible for
managing network topology, device interfaces and device characteristics, and can
also deliver configuration scripts to devices. The service management system is
responsible for managing services, such as service performance monitoring and
service alarm management.

© The Author(s) 2023 521

Huawei Technologies Co., Ltd., Data Communications and Network Technologies,
https://doi.org/10.1007/978-981-19-3029-4_17
522 17 SDN and NFV

Fig. 17.1 Distributed control architecture of traditional network

• The control plane is responsible for network control, and its main function is
protocol processing and computation. For example, routing protocols are used for
the calculation of routing information and the generation of routing tables.
• The forwarding plane refers to the device forwarding and processing the user
services according to the instructions generated by the control plane. For exam-
ple, the router forwards the received packets from the corresponding outbound
interface according to the routing table generated by the routing protocol.
The following takes a switch as an example to introduce the management plane,
control plane and forwarding plane.
• Switch management plane: the management plane provides functions such as
operation status monitoring, environment monitoring, log and alarm information
processing, system loading and system upgrade. The management plane of the
switch is for network managers to manage devices using TELNET, SSH, SNMP,
etc., and to support, understand and execute managers’ setting commands for
various network protocols of network devices. The management plane must
pre-set the parameters related to various protocols in the control plane and support
intervention in the operation of the control plane when it is necessary.
• Switch control plane: the control plane provides protocol processing, service
processing, routing operations, forwarding control, service scheduling, traffic
statistics, system security and other functions. The control plane of the switch
can control and manage the operations of all network protocols. It offers various
network information and forwarding query table entries required before the data
is processed and forwarded.
• Switch forwarding plane: the forwarding plane provides high-speed, unblocked
data channels to enable the service exchange function between various service
modules. The basic task of the switch is to process and forward various types of
data on different ports of the switch. Various specific data processing and
forwarding processes such as L2/L3/ACL/QoS/multicast/security protection all
belong to the tasks performed by the switch forwarding plane.
Traditional networks use a distributed control architecture. Distributed control here
means that in traditional IP networks, the control plane for protocol computation and
the forwarding plane for message forwarding are located in the same device. After
17.1 Overview of Traditional Networks 523

the routing calculation and topology change, each device has to re-calculate the
routes, which is called the distributed control process. In traditional IP networks,
each device independently collects network information and computes, and is
concerned only with its own routing. The disadvantage of this model architecture
is the lack of uniformity in the computation of paths by all devices.
The advantage of the traditional network is the decoupling of devices from the
protocol, better compatibility between vendors, and the network convergence
guaranteed by protocols in case of failures.

17.1.2 Problems Faced by Traditional Networks

1. The network is prone to congestion

Calculating the forwarding path based on constant bandwidth is prone to network
congestion, and the solution is to calculate the forwarding path based on real-time
bandwidth. For example, when router C sends a message to router D, Link C-D is
the shortest forwarding path. When the service traffic between router C and router
D starts to exceed the bandwidth and packet loss occurs, the algorithm will still
choose the shortest path for forwarding though other links are available. A global
consideration will reveal that the optimal forwarding path at this time should be
C-A-D, as shown in Fig. 17.2.
2. Network technology is too complex
Traditional networks have a lot of protocols. If you want to become a network
technology expert, you need to read about 2500 documents of Request for
Comment (RFC) related to network equipment. If you read one per day, it
would take up to 6 years, and that is only 1/3 of the entire RFC, and the number
is still growing.
There are also countless configuration commands of traditional network. If
you want to become a know-all of the devices of a certain manufacturer, you need
to master over 10,000 network configuration command lines, and the number is
still increasing.
3. Network fault positioning and diagnosis are difficult

Fig. 17.2 Network

congestion
524 17 SDN and NFV

Fig. 17.3 Traditional network service deployment

In traditional operations and maintenance, network faults rely on manual

identification, manual positioning and manual diagnosis, making it hard to
discover faults. According to the statistics of the Data Center, it takes an average
of 76 min to locate a fault, and more than 85% of the faults are found only after
complaints. Traditional operation and maintenance cannot effectively and proac-
tively identify and analyze problems.
Traditional operation and maintenance only monitor equipment indicators and
lacks correlation analysis of users and network, so sometimes the indicators are
normal but users have poor experience.
4. The deployment speed of network services is too slow
Traditional network service deployment is slow and inflexible, as shown in
Fig. 17.3.
The goal of network service deployment: network policy enables service free
mobility, which is irrelevant to the physical location. New services are rapidly
deployed, and the physical network supports zero-configuration deployment, so
that plug-and-play can be enabled for devices.

17.2 SDN and OpenFlow Protocol

17.2.1 Concept of SDN

SDN (Software Defined Network) is a new innovative network architecture pro-

posed by Clean Slate Research Group at Stanford University in 2006. SDN proposes
three features: separation of transfer and control, centralized control and open
programming interfaces. The core concept of SDN is to enable centralized control
17.2 SDN and OpenFlow Protocol 525

Fig. 17.4 SDN architecture

of the control plane by separating the control plane of the network devices from the
forwarding plane so as to provide good support for the innovation of network
applications. The SDN architecture is shown in Fig. 17.4.
For the past 30 years, traditional networks have always been fully distributed and
have made distinctive achievements, satisfying the needs of a variety of uses. Today,
in order to better meet users’ needs SDN is trying to get rid of the hardware
limitations on the network architecture so that the network can be modified like
installing and upgrading software to facilitate the rapid deployment of more appli-
cations (Apps) to the network. If you think of the existing network as a cell phone,
the goal of SDN is to make an Android system for the network world.
The essence of SDN is to make the network resemble software and enhance the
network programmability. SDN is a reconfiguration of the network architecture,
rather than a new feature or function. We cannot simply equate SDN with the
separation of forwarding and control or OpenFlow protocol. Separation of control
and forwarding and separation of management and control are only a means to meet
the SDN, and the OpenFlow protocol is only a protocol to meet the SDN.

17.2.2 OpenFlow Protocol

SDN network adopts OpenFlow protocol, which is based on the flow table to
forward traffic. The flow table is generally calculated by OpenFlow controller and
then distributed to the switch. The OpenFLow switch forwards traffic by querying
the flow table. The flow table is variable in length and has all kinds of matching rules
and forwarding rules. A network device has multiple flow tables, as shown in
Fig. 17.5.
The matching principle of the flow table is that for the existing “table0-table255”,
the matching priority starts from Table0. Within the same table, it is matched
according to the priorities, and the one with higher priority is matched first.
526 17 SDN and NFV

Fig. 17.5 Flow tables in a network device

OpenFlow is a southbound interface protocol between a controller and a switch. It

defines three types of messages, controller-to-switch, asynchronous and symmetric
messages, each of which contains additional subtypes.
1. Controller-to-switch: this message is sent by the controller to manage the switch
and query information about the switch.
The controller-to-switch message have the following subtypes.
• Features message: after an SSL/TCP session is established, the controller
sends a features message to the switch requesting information about the
switch, and the switch must respond with the features it supports, including
basic information such as the interface name, interface MAC address and the
rate supported by the interface.
• Configuration message: the controller can set or query the state of the switch.
• Modify-State message: the controller can send this message to the switch to
manage the state of the switch, i.e., add, delete, change the flow table, and set
the interface properties of the switch.
• Read-State message: the controller can use this message to collect statistical
information on the switch.
• Send-Packet message: the controller can send this message to a specific
interface of the switch.
17.2 SDN and OpenFlow Protocol 527

2. Asynchronous: this message is initiated by the switch. When the state of the
switch changes, this message is sent to tell the controller about the change in state.
The asynchronous message has the following subtypes.
• Packet-in message: the switch sends a packet-in message to the controller
when there is no matching table entry in the flow table or when it matches
“send to Controller”.
• Packet-out message: it is a response message from the controller.
• Flow-Removed message: when a table entry is added to the switch, a timeout
period is set. When the timeout expires, the entry is removed. This is when the
switch sends a flow-removed message to the controller; the switch also sends
this message to the controller when an entry is to be deleted from the flow
table.
• Port-status message: this message can be used to notify the controller when a
data path interface is added, deleted or modified.
3. Symmetric: this message has no fixed initiator and can be initiated by the switch
or controller, for example, the Hello, Echo, Error messages.
• Hello message: when an OpenFlow connection is established, the controller
and switch will immediately send an OFPT_HELLO message to the other side,
and the version field in this message is populated with the highest version
number of the OpenFlow protocol supported by the sender; after receiving the
message, the receiver will calculate the protocol version number, i.e., choose
the smaller one of the version numbers of the sender and the receiver; if the
receiver supports this version, it continues to process the connection and the
connection is successful; otherwise, the receiver responds with an
OFPT_ERROR message with the type field populated with ofp_error_type.
OFPET_HELLO_FAILED.
• Echo message: either switch and controller can initiate an Echo request
message, but the receiver must respond with an Echo reply message. This
message measures latency and the connectivity between controller and switch,
i.e., the heartbeat message.
• Error messages: when the switch wants to notify the controller of a problem or
error, it sends an Error message to the controller.
More and more complete message types can be viewed on the official ONF website.

17.2.3 Introduction to FlowTable

OpenFlow switches, that is, switches that support the OpenFlow protocol, are based
on FlowTables to forward messages. Each flow table entry consists of match fields,
priority, counters, instructions, timeout, cookie and flags, as shown in Fig. 17.6. The
two key elements of forwarding are match fields and instructions.
528 17 SDN and NFV

Fig. 17.6 Composition of stream flow entries

1. Match fields consist of flow table fields, and the fields are matching rules, which
can be customized.
2. Instructions are used to describe the processing after matching.
• Match Fields: the flow table entry match fields (OpenFlow version 1.5.1
supports 45 optional match fields) can match inbound interfaces, physical
inbound interfaces, inter-flow table data, Layer 2 message headers, Layer
3 message headers, Layer 4 port numbers and other message fields.
• Priority: the priority of flow table entries defines the matching order of flow
table items, and the entry with higher priority is matched first.
• Counters: the counters of flow table entries can count how many messages and
bytes can be matched to the flow table entry.
• Instructions: the instructions set of flow table entries defines the instructions to
be performed by the messages matching the flow table entry. When a message
matches a flow table entry, the instructions set contained in each flow table
entry is executed. These instructions affect the message, the instructions set,
and the pipeline flow.
• Timeouts: the timeouts of flow table entries include idle time and hard time.
– Idle Time: after the idle time timeout, the flow table entry will be deleted if
no message matches it.
– Hard Time: after the hard time timeout, the flow table entry will be deleted
regardless of whether there are messages matching it.

• Cookie: it is the identifier of the flow table entry delivered by the controller.
• Flags: this field changes the management of the flow entry.

17.2.4 SDN Network Architecture

SDN is a reconfiguration of the traditional network architecture from the original

distributed control network architecture to the centralized control network architec-
ture (Fig. 17.7).
17.2 SDN and OpenFlow Protocol 529

Fig. 17.7 SND network

architecture

1. The collaborative application layer mainly includes various upper layer applica-
tions to meet user needs. Typical collaborative application layer applications
include OSS, OpenStack, etc. OSS is responsible for service collaboration of
the whole network, and OpenStack cloud platform is generally used in data
centers, responsible for service collaboration of network, computing and storage.
There are other collaborative application layer applications. For example, users
want to deploy a security App, and this App does not care about the specific
deployment location of the device and only calls the northbound interface of the
controller, like Block (source IP, Dest IP), and then the controller will give
instructions to each network device, and the instructions will vary according to
the southbound protocol.
2. The entity at the controller layer is the SDN controller, which is also the most
central part of the SDN network architecture. The controller layer is the brain of
the SDN system, and its core function is to implement network service
orchestration.
3. Network devices in the device layer can receive commands from the controller
and perform device forwarding.
4. Northbound interface (NBI) is the interface of the controller connected to the
collaborative application layer, mainly RESTful. RESTful is a network applica-
tion design style and development approach based on HTTP, and can be defined
using XML format or JSON format.
5. Southbound interface (SBI) is the protocol for the controller to interact with
devices, which includes NETCONF, SNMP, OpenFlow, OVSDB, etc.
530 17 SDN and NFV

17.3 Overview of NFV

17.3.1 Concepts of NFV

In recent years, IT technologies such as virtualization and cloud computing have

flourished, and traditional applications are gradually cloud-based and deployed on
private, public or hybrid clouds in a software-based manner.
Network Function Virtualization (NFV) builds a Data Center Network (DCN) by
integrating many different types of network devices (such as Servers, Switches and
Storage), forms a Virtual Machine (VM) through virtualization technology, and then
deploys traditional Communications Technology (CT) services to the VM.
When we talk about VNF (Virtualized Network Function), we usually refer to
tasks carried out after the virtualization of carrier IMS (IP Multi-Media Sub-System,
a generic term for various network entities in a communication network), CPE
(Customer Premise Equipment), and other traditional network elements (network
elements, including servers, storage, switches, and network services)., including
servers, storage, switches and routers). After the hardware generalization, the tradi-
tional network elements are no longer embedded hardware and software products,
but are mounted on the general hardware as pure software, i.e., NFV Infrastructure
(NFVI).
The evolution of the NFV concept is as follows.
In October 2012, 13 major carriers (AT&T, Verizon, VDF, DT, T-Mobile, BT,
Telefonica, etc.) released the first version of the NFV white paper at the SDN and
OpenFlow World Congress, and established the ISG (Industry Specification Group)
to promote the requirements definition and system architecture formulation for
network virtualization.
In 2013, the NFV ISG (Industry Specification Group) of the European Telecom-
munications Standards Institute (ETSI) conducted the first phase of research and
developed related standards. It mainly defines the requirements and architecture of
network function virtualization and sorts out the standardization process of different
interfaces.
In 2015, the NFV research entered the second phase. The main goal of this phase
of research is to build an interoperable NFV ecosystem, promote broader industry
participation, and ensure that the requirements defined in the first phase are met. In
the meantime, it also clarifies related standards such as NFV and SDN, as well as
collaborative relationship of open-source projects, etc. The second phase of NFV
research is divided into five working groups: IFA (Interface and Architecture), EVE
(Evolution and Ecosystem), REL (Reliability), SEC (Security) and TST (Testing,
Experimentation and Open Source). These working groups mainly discuss the
documentation framework of deliverables and delivery plans.
The ETSI NFV standards organization cooperated with the Linux Foundation to
launch the open-source project OPNFV (aiming to provide an integrated, open
reference platform) to bring together the industry’s superior resources and actively
17.3 Overview of NFV 531

build the NFV industrial ecology. 2015 saw the release of the first version of
OPNFV, which further promoted the commercial deployment of NFV.

17.3.2 Value of NFV

NFV is proposed by carriers to solve the problems of overelaborate hardware,

complex deployment, operation and maintenance, and difficulties in service inno-
vation of telecommunications. While reconfiguring telecom networks, the NFV
brings the following values to carriers.
1. Shortened service launch time.
In a network with NFV architecture, adding new service nodes becomes
exceptionally simple. No more complex work surveys and hardware installation
processes are required. For service deployment, you need to apply virtualized
resources (computing, storage, network, etc.) and load the software, making
network deployment much easier. At the same time, if you need to update the
service logic, you only need to update the software or load new service modules
to complete the service orchestration, so business innovation becomes simpler.
2. Reduced network construction cost
First, the virtualized network elements can be merged into general devices to
obtain economies of scale. Second, the network resource utility and efficiency are
increased to reduce the networking cost. NFV adopts cloud computing technol-
ogy to build a unified resource pool using generalized hardware, and dynamically
allocate resources according to the actual needs of the services so as to share
resources and improve resource utilization and efficiency. For example, it solves
the resource utilization problem caused by the tidal effect of services through
automatic capacity expansion and reduction.
3. Improved network operation and maintenance efficiency
Automated centralized management can improve operational efficiency and
reduce operation and maintenance costs. Some of the examples are the automa-
tion of centralized management of hardware units in data centers, the automation
of application lifecycle management based on MANO (Management and Orches-
tration), and the network automation based on NFV/SDN collaboration.
4. The building of an open ecosystem
The traditional telecom network is a closed system because of its proprietary
hardware and software model. On the other hand, the telecom network under
NFV architecture, based on the standard hardware platform and virtualized
software architecture, is easier to open the platform and interfaces to introduce
third-party developers, so that carriers can build an open ecosystem with third-
party partners.
532 17 SDN and NFV

17.3.3 Key Technologies for NFV

On the road to NFV, virtualization is the foundation and cloudization is the key.
1. Virtualization
In traditional telecom networks, individual network elements are implemented
by dedicated hardware. The problem with this approach is that, on the one hand,
building a network requires a lot of interoperability testing and installation and
configuration of different hardware, which is time-consuming and laborious. On
the other hand, service innovation is dependent on the hardware vendors, which
usually takes a long time and is thus difficult to meet the carrier’s demand for
service innovation.
In this context, carriers want to introduce the virtualization model, which make
network elements resemble software so that they can be run on a general
infrastructure (including general servers, storage, switches, etc.). Virtualization
has the characteristics of partitioning, isolation and encapsulation, and is inde-
pendent relative to hardware, so it can well meet the needs of NFV, as shown in
Fig. 17.8.
By using general hardware, firstly, carriers can reduce the cost of procuring
dedicated hardware; secondly, service software can be developed rapidly and
iteratively, which also allows operators to quickly innovate their services and
enhance their competitiveness; and finally, this also empowers operators to enter
the cloud computing market.
2. Cloudization
Cloudization is the process of migrating existing services to a cloud computing
platform. As defined by the National Institute of Standards and Technology,

Fig. 17.8 Virtualization characteristics

17.3 Overview of NFV 533

cloud computing is a model for enabling ubiquitous, convenient, on-demand

network access to a shared pool of configurable computing resources (e.g.,
networks, servers, storage, applications and services) that can be rapidly provi-
sioned and released with minimal management effort or service provider
interaction.
Cloud computing services should have the following characteristics.
• On-demand self-service: cloud computing enables on-demand self-service of
IT resources, so that resources can be requested and released without the
intervention of IT administrators.
• Extensive network access: the network can be accessed anywhere, anytime as
long as there is a network.
• Resource pooling: resources in the resource pool, including network, server,
storage and other resources, are available to users.
• Fast resilient scaling: resources can be quickly provisioned and released.
Resources can be used upon request and reclaimed immediately upon release.
• Measurable service: billing function. The basis for the billing is that the
resources used are measurable. For example, the number of CPUs, occupied
storage space, and bandwidth of the network are combined for billing based on
hours of use.
The cloudization of network functions in carrier networks mainly takes advantage of
both resource pooling and fast resilient scaling.

17.3.4 NFV Architecture

The NFV architecture is divided into functional modules such as NFVI, VNF and
MANO, and also supports the existing OSS/BSS (Operation Support System/Busi-
ness Support System) functional modules, as shown in Fig. 17.9.

Fig. 17.9 NFV architecture

534 17 SDN and NFV

1. OSS/BSS: it is the management functional module of the service provider, which

is not a functional component within the NFV framework. However, MANO and
network elements need to provide interface support to OSS/BSS.
2. VNF: it refers to the virtual machine and the service network elements, network
function software and others deployed on the virtual machine. VNF can also be
understood as an App of various different network functions, which is the
software implementation of the carrier’s traditional network elements (IMS,
EPC, BRAS, CPE, etc.).
3. NFVI: NFV infrastructure contains a hardware layer and a virtualization layer,
which provides the operating environment for VNFs. It is also referred to as
COTS and CloudOS in the industry.
• COTS (Commercial Off-The-Shelf), or general hardware, emphasizes easy
availability and versatility. For example, Huawei FusionServer series hard-
ware servers.
• CloudOS: platform software for cloud-based devices, which can be regarded
as an operating system for the telecom industry. CloudOS provides the ability
to virtualize hardware devices, which can turn physical computing, storage
and network resources into virtual resources to be used by upper-layer soft-
ware. For example, Huawei cloud operating system Fusion Sphere.

4. MANO: the introduction of MANO is to solve the problem of delivering network

services in the NFV multi-CT/IT vendor environment, including vertically open-
ing up the management layers and quickly adapting to and interconnecting new
network elements from new vendors. The MANO includes three parts, namely,
NFVO (Network Functions Virtualization Orchestrator, which orchestrates and
manages the entire NFV infrastructure, software resources and network services),
VNFM (Virtualized Network Function Manager, which is responsible for the
lifecycle management of VNFs, such as instantiation, configuration and shut-
down), VIM (Virtualized Infrastructure Manager, which is responsible for
resource management of NFVI and usually runs in the corresponding infrastruc-
ture site; its main functions include resource discovery, management and alloca-
tion of virtual resources, fault handling, etc.).
The solutions of each functional module of NFV architecture can be provided
by different vendors, which increases the complexity of system integration while
improving system developability.

17.3.5 Huawei NFV Solutions

In Huawei’s NFV solution (see Fig. 17.10), Huawei CloudStack can provide some
functions of NFNI: computing can be provided by FusionCompute, the storage can
be provided by FusionStorage, and network can be provided by FusionNetwork.
17.4 Exercises 535

Fig. 17.10 Huawei NFV solution

FusionNetwork is not a specific product, but a generic term for network

virtualization or software-defined network functional modules. Huawei CloudStack
is capable of comprehensive virtualization of computing, storage and network
resources, and can unify the management, monitoring and optimization of physical
hardware virtualization resources.
Huawei VNF solutions include CloudBB, Cloud DSL/OLT, CloudEdge,
CloudCore and 5G Core, which correspond to virtualization solutions for virtual
network elements carried by different kinds of core networks. Huawei provides
comprehensive cloud-based solutions for carriers’ wireless networks, bearer net-
works, transmission networks, access networks, core networks and so on. [Note:
DSL is a digital subscriber line; and OLT is an optical line terminal.

17.4 Exercises

1. What is the relationship between SDN and NFV?

2. What is the relationship between SDN and NFV in Huawei solution?

Open Access This chapter is licensed under the terms of the Creative Commons Attribution-
NonCommercial-NoDerivatives 4.0 International License (http://creativecommons.org/licenses/by-
nc-nd/4.0/), which permits any noncommercial use, sharing, distribution and reproduction in any
medium or format, as long as you give appropriate credit to the original author(s) and the source,
provide a link to the Creative Commons license and indicate if you modified the licensed material.
You do not have permission under this license to share adapted material derived from this chapter or
parts of it.
The images or other third party material in this chapter are included in the chapter’s Creative
Commons license, unless indicated otherwise in a credit line to the material. If material is not
included in the chapter’s Creative Commons license and your intended use is not permitted by
statutory regulation or exceeds the permitted use, you will need to obtain permission directly from
the copyright holder.