SDN and NFV

Abstract

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 networking industry is also seeking to change and evolve, with Software Defined Networking (SDN) and Network Functional Virtualization (NFV) being two concepts in the limelight.

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 networking industry is also seeking to change and evolve, with Software Defined Networking (SDN) and Network Functional Virtualization (NFV) being two concepts 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 management 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 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 example, 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 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.

Fig. 17.1

Distributed control architecture of traditional network

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

  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 proactively 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.

Fig. 17.2

Network congestion

Fig. 17.3

Traditional network service deployment

17.2 SDN and OpenFlow Protocol

17.2.1 Concept of SDN

SDN (Software Defined Network) is a new innovative network architecture proposed 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 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.

Fig. 17.4

SDN architecture

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 applications (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.

Fig. 17.5

Flow tables in a network device

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.

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.

• 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.

• 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.

Fig. 17.6

Composition of stream flow entries

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 architecture (Fig. 17.7).

• 1. The collaborative application layer mainly includes various upper layer applications 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 application 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.

Fig. 17.7

SND network architecture

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 traditional 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 Telecommunications 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 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 innovation 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 technology 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 automation of centralized management of hardware units in data centers, the automation of application lifecycle management based on MANO (Management and Orchestration), 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.

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 independent 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, 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 provisioned 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.

Fig. 17.8

Virtualization characteristics

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/Business Support System) functional modules, as shown in Fig. 17.9.

• 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 hardware 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 software. 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 opening 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 shutdown), VIM (Virtualized Infrastructure Manager, which is responsible for resource management of NFVI and usually runs in the corresponding infrastructure site; its main functions include resource discovery, management and allocation 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.

Fig. 17.9

NFV architecture

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. 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.

Fig. 17.10

Huawei NFV solution

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 networks, 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?