20 SDN and NFV Overview
20 SDN and NFV Overview
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer.
All or part of the products, services and features described in this document may not be within the purchase scope or
the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this
document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or
implied.
The information in this document is subject to change without notice. Every effort has been made in the preparation
of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this
document do not constitute a warranty of any kind, express or implied.
1.3.3 Current Situation of the Network Industry: Typical IP Network - Distributed Network ...................................... 3
1.3.4 Thinking in the Network Field: Problems Faced by Typical Networks ........................................................................ 5
1.3.16 Huawei SDN Solution - Integrating Management, Control, and Analysis to Build an Intent-Driven
Network ........................................................................................................................................................................................................ 14
1.1 Foreword
The open ecosystem of the computing industry brings booming development of multiple
fields, such as Commercial Off-the-Shelf (COTS), operating system, virtualization, middleware,
cloud computing, and software applications. The network industry is also seeking
transformation and development. Software Defined Networking (SDN) and Network
Functions Virtualization (NFV) are mainly used.
This course aims to help engineers understand the development of SDN and NFV and
introduce Huawei SDN and NFV solutions.
1.2 Objectives
On completion of this course, you will be able to:
In 1964, IBM spent US$5 billion on developing IBM System/360 (S/360), which started the
history of mainframes. Mainframes typically use the centralized architecture. The architecture
features excellent I/O processing capability and is the most suitable for processing large-scale
transaction data. Compared with PCs, mainframes have dedicated hardware, operating
systems, and applications.
PCs have undergone multiple innovations from hardware, operating systems, to applications.
Every innovation has brought about great changes and development. The following three
factors support rapid innovation of the entire PC ecosystem:
Hardware substrate: The PC industry has adapted a simple and universal hardware base,
x86 instruction set.
Software-defined: The upper-layer applications and lower-layer basic software (OS and
virtualization) are greatly innovated.
Open-source: The flourishing development of Linux has verified the correctness of open
source and bazaar model. Thousands of developers can quickly formulate standards to
accelerate innovation.
SDN and NFV Overview Page 3
The advantage of a typical IP network is that network devices are decoupled from protocols,
devices from different vendors are compatible with each other, and network convergence is
ensured in fault scenarios.
The switch is used as an example to describe the forwarding plane, control plane, and
management plane.
Forwarding plane: provides high-speed, non-blocking data channels for service switching
between service modules. The basic task of a switch is to process and forward various types of
data on its interfaces. Specific data processing and forwarding, such as Layer 2, Layer 3, ACL,
QoS, multicast, and security protection, occur on the forwarding plane.
Control plane: provides functions such as protocol processing, service processing, route
calculation, forwarding control, service scheduling, traffic statistics collection, and system
security. The control plane of a switch is used to control and manage the running of all
network protocols. The control plane provides various network information and forwarding
query entries required for data processing and forwarding on the data plane.
Some Huawei series products are divided into the data plane, management plane, and
monitoring plane.
SDN and NFV Overview Page 5
The network computes forwarding paths based on bandwidth. The link from router C to
router D is the shortest forwarding path. The volume of service traffic from router C to
router D exceeds the bandwidth, causing packet loss. Although other links are idle, the
algorithm still selects the shortest path for forwarding. The optimal traffic forwarding
path is C-A-D.
Difficult network configuration: To be familiar with devices of a specific vendor, you need to
master tens of thousands of commands. Additionally, the number of commands is still
increasing.
Traditional O&M networks rely on manual fault identification, location, and diagnosis.
More than 85% of network faults are found only after service complaints. Problems
cannot be proactively identified or analyzed.
SDN and NFV Overview Page 7
Traditional O&M only monitors device indicators. Some indicators are normal, but user
experience is poor. There is no correlated analysis of users and networks.
According to data center network (DCN) statistics, it takes 76 minutes to locate a fault on
average.
Plug-and-play of devices
Controller-to-Switch messages:
Features message: After an SSL/TCP session is established, the controller sends Features
messages to a switch to request switch information. The switch must send a response,
including the interface name, MAC address, and interface rate.
Configuration message: The controller can set or query the switch status.
Modify-State message: The controller sends this message to a switch to manage the
switch status, that is, to add, delete, or modify the flow table and set interface attributes
of the switch.
Read-State message: The controller sends this message to collect statistics on the switch.
Send-Packet message: The controller sends the message to a specific interface of the
switch.
Asynchronous messages:
Packet-in message: If no matching entry exists in the flow table or the action
"send-to-controller" is matched, the switch sends a packet-in message to the controller.
Flow-Removed message: When an entry is added to a switch, the timeout interval is set.
When the timeout interval is reached, the entry is deleted. The switch then sends a
Flow-Removed message to the controller. When an entry in the flow table needs to be
deleted, the switch also sends this message to the controller.
Port-status message: A switch sends this message to notify the controller when the
interface configuration or state changes.
Symmetric messages:
Hello message: When an OpenFlow connection is established, the controller and switch
immediately send an OFPT_HELLO message to each other. The version field in the
SDN and NFV Overview Page 10
message is filled with the latest OpenFlow version supported by the sender. After
receiving the message, the receiver calculates the protocol version number, that is,
selects the smaller one between the versions supported by the sender and the receiver. If
the receiver supports the version, connection requests are processed until the
connection is successful. Otherwise, the receiver replies with an OFPT_ERROR message, in
which the type field is filled with ofp_error_type.OFPET_HELLO_FAILED.
Echo message: Either a switch or controller can send an Echo Request message, but the
receiver must reply with an Echo Reply message. This message can be used to measure
the latency and connectivity between the controller and switch. That is, Echo messages
are heartbeat messages.
Error message: When a switch needs to notify the controller of a fault or error, the switch
sends an Error message to the controller.
The OpenFlow protocol is still being updated. For more message types, see the OpenFlow
Switch Specification released by Open Networking Foundation (ONF).
Each flow entry includes the Match Fields, Priority, Counters, Instructions, Timeouts, Cookie,
and Flags. The Match Fields and Instructions are key fields for packet forwarding.
The Match Fields is a field against which a packet is matched and can be customized.
The Instructions field indicates OpenFlow processing when a packet matches a flow
entry.
Match Fields: a field against which a packet is matched. (OpenFlow 1.5.1 supports 45 options).
It can contain the inbound interface, inter-flow table data, Layer 2 packet header, Layer 3
packet header, and Layer 4 port number.
Priority: matching sequence of a flow entry. The flow entry with a higher priority is matched
first.
Instructions: OpenFlow processing when a packet matches a flow entry. When a packet
matches a flow entry, an action defined in the Instructions field of each flow entry is executed.
The Instructions field affects packets, action sets, and pipeline processing.
Timeouts: aging time of flow entries, including Idle Time and Hard Time.
Idle Time: If no packet matches a flow entry after Idle Time expires, the flow entry is
deleted.
Hard Time: After Hard Time expires, a flow entry is deleted regardless of whether a
packet matches the flow entry.
In typical cases, network devices query routing tables to guide traffic forwarding.
Entries in a routing table are calculated by running a routing protocol between network
devices.
The length of the routing table is fixed. Network devices forward packets based on the
longest match rule. A network device has only one routing table.
OpenFlow:
Flow tables are calculated by the OpenFlow controller and then delivered to switches.
SDN and NFV Overview Page 12
A flow table has variable length and defines various matching and forwarding rules. A
network device has multiple flow tables.
For tables 0-255, table 0 is first matched. In a flow table, flow entries are matched by priority.
The flow entry with a higher priority is matched first.
Currently, OpenFlow is mainly used on software switches, such as OVSs and CE1800Vs, in DCs,
but not on physical switches to separate forwarding and control planes.
Shields technical differences, simplifies network configuration, and reduces O&M costs.
Orchestration application layer: provides various upper-layer applications for service intents,
such as OSS and OpenStack. The OSS is responsible for service orchestration of the entire
network, and OpenStack is used for service orchestration of network, compute, and storage
resources in a DC. There are other orchestration-layer applications. For example, a user wants
to deploy a security app. The security app is irrelevant to the user host location but invokes
NBIs of the controller. Then the controller delivers instructions to each network device. The
command varies according to the SBI protocol.
Controller layer: The SDN controller is deployed at this layer, which is the core 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.
Device layer: A network device receives instructions from the controller and performs
forwarding.
NBI: NBIs are used by the controller to interconnect with the orchestration application layer,
mainly RESTful.
SBI: SBIs used by the controller to interact with devices through protocols such as NETCONF,
SNMP, OpenFlow, and OVSDB.
Cloud platform: resource management platform in a cloud DC. The cloud platform manages
network, compute, and storage resources. OpenStack is the most mainstream open-source
cloud platform.
The Element Management System (EMS) manages one or more telecommunication network
elements (NEs) of a specific type.
Orchestration (container orchestration): The container orchestration tool can also provide the
network service orchestration function. Kubernetes is a mainstream tool.
MTOSI or CORBA is used to interconnect with the BSS or OSS. Kafka or SFTP can be used to
connect to a big data platform.
iMaster NCE converts service intents into physical network configurations. It manages,
controls, and analyzes global networks in a centralized manner in the southbound direction. It
enables resource cloudification, full-lifecycle network automation, and intelligent closed-loop
driven by data analysis for business and service intents. It provides northbound open APIs for
quick integration with IT systems.
iMaster NCE can be used in the enterprise data center network (DCN), enterprise campus, and
enterprise branch interconnection (SD-WAN) scenarios to make enterprise networks simple,
smart, open, and secure, accelerating enterprise service transformation and innovation.
SDN and NFV Overview Page 16
Simplified deployment
Intelligent O&M:
Rapid fault detection and location based on knowledge graph and expert experience
Real-time optimization:
AI-Fabric-oriented local traffic inference and online model training and optimization
The network administrator clicks the icon on iMaster NCE to start the ZTP task.
iMaster NCE determines the device role (spine or leaf node), delivers configurations such
as the management IP address, SNMP configuration, and NETCONF configuration to
online devices, and manages the devices through the management IP address.
The device goes online successfully, and the administrator views network-wide
information on iMaster NCE.
iMaster NCE-Fabric can connect to a user's IT system to match the intent model for user
intents and deliver configurations to devices through NETCONF to implement fast
service deployment.
iMaster NCE-Fabric can interconnect with the mainstream cloud platform (OpenStack),
virtualization platform (vCenter/System Center), and container orchestration platforms
(Kubernetes).
Free mobility: GUI-based policy configuration, allowing users to access the network
anytime and anywhere without changing the roaming permission and user experience
Precise fault analysis: Proactively identifying 85% of typical network issues and providing
suggestions, and comparing and analyzing real-time data to predict faults
SDN and NFV Overview Page 20
Device Plug-and-Play
Device plug-and-play includes but is not limited to deployment by scanning bar codes
using an app, DHCP-based deployment, and deployment through the registration query
center.
Registration center: Huawei device registration query center, also called registration
center, is one of the main components of Huawei CloudCampus solution. It is used to
query the device management mode and registration ownership. A device determines
whether to switch to the cloud-based management mode and which cloud management
platform to register with based on the query result. The AP is used as an example.
Huawei devices that support cloud-based management are pre-configured with the URL
(register.naas.huawei.com) and port number (10020) of the Huawei device registration
center.
SDN and NFV Overview Page 21
Free mobility: Enables users to have consistent network rights and security policies
regardless of their locations and IP addresses.
SDN and NFV Overview Page 22
Wired and wireless authentication point separation, distributed policy control, separation
of control and data traffic forwarding, and troubleshooting and management difficulties.
User- and application-based QoS policies ensure experience of high-priority users and
applications
In recent years, IT technologies such as virtualization and cloud computing have been
booming, and applications deployed on hardware have been gradually migrated to the cloud.
Applications are deployed on private clouds, public clouds, or hybrid clouds as software.
Virtualized network functions (VNFs) are implemented by virtualizing traditional NEs such as
IMSs and CPEs of carriers. After hardware is universalized, traditional NEs are no longer the
products with embedded software and hardware. Instead, they are installed on universal
hardware (NFVI) as software.
In 2013, the ETSI NFV ISG conducted the first phase of research and completed the
formulation of related standards. The ETSI NFV ISG defined NFV requirements and
architecture and sorts out the standardization processes of different interfaces.
In 2015, NFV research entered the second phase. The main research objective is to build an
interoperable NFV ecosystem, promote wider industry participation, and ensure that the
requirements defined in phase 1 are met. In addition, the ETSI NFV ISG specified the
collaboration relationships between NFV and SDN standards and open source projects. Five
working groups are involved in NFV phase 2: IFA (architecture and interface), EVE (ecosystem),
REL (reliability), SEC (security), and TST (test, execution, and open source). Each working group
mainly discusses the deliverable document framework and delivery plan.
The ETSI NFV standard organization cooperates with the Linux Foundation to start the open
source project OPNFV (NFV open source project, providing an integrated and open reference
platform), integrate resources in the industry, and actively build the NFV industry ecosystem.
In 2015, OPNFV released the first version, further promoting NFV commercial deployment.
3GPP SA5 working group: focuses on technical standards and specifications of 3GPP NE
virtualization management (MANO-related).
Open ecosystem
Shortened service rollout time: In the NFV architecture, adding new service nodes becomes
simple. No complex site survey or hardware installation is required. For service deployment,
you only need to request virtual resources (compute, storage, and network resources) and
software loading, simplifying network deployment. To update service logic, you simply need
to add new software or load new service modules to complete service orchestration. Service
innovations become simple.
SDN and NFV Overview Page 27
Reduced network construction cost: Virtualized NEs can be integrated into COTS devices to
reduce the cost. Enhancing network resource utilization and lowering power consumption
can lower overall network costs. NFV uses cloud computing technologies and universal
hardware to build a unified resource pool. Resources are dynamically allocated on demand
based on service requirements, implementing resource sharing and improving resource
utilization. For example, automatic scale-in and scale-out can be used to solve the resource
usage problem in the tidal effect.
Enhanced network O&M efficiency: Automated and centralized management improves the
operation efficiency and reduces the O&M cost. Automation includes DC-based hardware
unit management automation, MANO application service life management automation, NFV-
or SDN-based coordinated network automation.
Open ecosystem: The legacy telecom network exclusive software/hardware model defines a
closed system. NFV-based telecom networks use an architecture based on standard hardware
platforms and virtual software. The architecture easily provides open platforms and open
interfaces for third-party developers, and allows carriers to build open ecosystems together
with third-party partners.
Using universal hardware helps carriers reduce the cost of purchasing dedicated
hardware. Service software can be rapidly developed through iteration, which enables
SDN and NFV Overview Page 28
carriers to innovate services quickly and improve their competitiveness. By dong this,
carriers can enter the cloud computing market.
Cloudification
According to the NIST, cloud computing services have the following characteristics:
Broad network access: Users can access networks anytime and anywhere.
Rapid elasticity: Resources can be quickly provisioned and released. The resource
can be used immediately after being requested, and can be reclaimed immediately
after being released.
Measured service: The charging basis is that used resources are measurable. For
example, charging is based on the number of CPUs, storage space, and network
bandwidth.
SDN and NFV Overview Page 29
Each layer of the NFV architecture can be provided by different vendors, which improves
system development but increases system integration complexity.
NFV implements efficient resource utilization through device normalization and software and
hardware decoupling, reducing carriers' TCO, shortening service rollout time, and building an
open industry ecosystem.
The NFVI consists of the hardware layer and virtualization layer, which are also called COTS
and CloudOS in the industry.
COTS: universal hardware, focusing on availability and universality, for example, Huawei
FusionServer series hardware server.
CloudOS: cloud-based platform software, which can be regarded as the operating system
of the telecom industry. CloudOS virtualizes physical compute, storage, and network
resources into virtual resources for upper-layer software to use, for example, Huawei
FusionSphere.
SDN and NFV Overview Page 30
VNF: A VNF can be considered as an app with different network functions and is implemented
by software of traditional NEs (such as IMS, EPC, BRAS, and CPE) of carriers.
MANO: MANO is introduced to provision network services in the NFV multi-CT or multi-IT
vendor environment, including allocating physical and virtual resources, vertically
streamlining management layers, and quickly adapting to and interconnecting with new
vendors' NEs. The MANO includes the Network Functions Virtualization Orchestrator (NFVO,
responsible for lifecycle management of network services), Virtualized Network Function
Manager (VNFM, responsible for lifecycle management of VNFs), and Virtualized
Infrastructure Manager (VIM, responsible for resource management of the NFVI).
Figure 1-45 Main functional modules defined in the standard NFV architecture
A hypervisor is a software layer between physical servers and OSs. It allows multiple OSs and
applications to share the same set of physical hardware. It can be regarded as a meta
operating system in the virtual environment, and can coordinate all physical resources and
VMs on the server. It is also called virtual machine monitor (VMM). The hypervisor is the core
of all virtualization technologies. Mainstream hypervisors include KVM, VMWare ESXi, Xen,
and Hyper-V.
Interface Description
Is used between the virtualization layer and hardware layer. The virtualization
Vi-Ha
layer meets basic hardware compatibility requirements.
Is used between a VM and the NFVI. It ensures that VMs can be deployed on
Vn-Nf the NFVI to meet performance, reliability, and scalability requirements. The
NFVI meets VMs' OS compatibility requirements.
Huawei provides cloud-based solutions for carriers' wireless networks, bearer networks,
transport networks, access networks, and core networks.
1.5 FAQ
Q1: What is the relationship between SDN and NFV in the industry?
A: Both SDN and NFV involve network transformation and the NFV concept was proposed at
the SDN and OpenFlow World Congress. However, they are independent of each other. SDN
mainly affects the network architecture, and NFV mainly affects the NE deployment mode.
Q2: What is the relationship between SDN and NFV in Huawei solutions?
A: Huawei provides different solutions for SDN and NFV, but they are associated. Huawei
NFVI solution is provided by HUAWEI CLOUD Stack.
SDN and NFV Overview Page 33
1.6 Quiz
1. (Single) Which of the following statements about OpenFlow is incorrect? ( )
A. OpenFlow is a protocol used to configure network switches. The process is
similar to the application programming interface (API).
B. OpenFlow is an open source protocol.
C. OpenFlow switches forward packets based on flow tables.
D. OpenFlow is implemented through XML.
2. (Multiple) OpenFlow matches and processes network packets based on
user-defined or preset rules. Which of the following are the components of an
OpenFlow rule? ( )
A. Match Fields
B. Priority
C. Processing instructions
D. Statistics (such as Counters)
3. (Multiple) Which of the following statements about the key features of Network
Functions Virtualization (NFV) is false? ( )
A. Centralized control and global efficiency optimization
B. Open interfaces and accelerate service rollout
C. Cloud-based upper-layer services and standard underlying hardware
D. Hierarchical operation, accelerating service rollout and innovation
4. (Multiple) In the SDN network architecture, which of the following belong to the
application layer? ( )
A. Openstack
B. Third-party app platform
C. Server
D. Switch
5. (Multiple) Huawei SDN network architecture supports various southbound and
northbound interfaces, including OpenFlow, OVSDB, NETCONF, PCEP, RESTful,
SNMP, BGP, JsonRPC, and RESTCONF. ( )
A. True
B. False
6. (Multiple) Which of the following statements about Huawei SDN solution are true?
( )
A. The solution supports various SBI protocols, such as RESTful, NETCONF, and OVSDB.
SDN and NFV Overview Page 34
C. The solution integrates management, control, and analysis to build a simplified network.
D. The solution provides open and programmable network interfaces to support third-party
application development and system interconnection.
1.7 Summary
With the transformation and development of the network industry, SDN and NFV are
proposed.