Internet Research Task Force (IRTF) CJ. Bernardos
Request for Comments: 8568 UC3M
Category: Informational A. Rahman
ISSN: 2070-1721 InterDigital
JC. Zuniga
SIGFOX
LM. Contreras
TID
P. Aranda
UC3M
P. Lynch
Keysight Technologies
April 2019
Internet Research Task Force (IRTF) CJ. Bernardos
Request for Comments: 8568 UC3M
Category: Informational A. Rahman
ISSN: 2070-1721 InterDigital
JC. Zuniga
SIGFOX
LM. Contreras
TID
P. Aranda
UC3M
P. Lynch
Keysight Technologies
April 2019
Network Virtualization Research Challenges
网络虚拟化研究面临的挑战
Abstract
摘要
This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges. This document is a product of the Network Function Virtualization Research Group (NFVRG).
本文档描述了网络虚拟化的开放式研究挑战。网络虚拟化正沿着与云计算类似的路径发展。具体而言，云计算普及了计算功能（如应用程序）和存储从本地、专用物理资源到可通过互联网访问的远程虚拟功能的迁移。以类似的方式，网络虚拟化鼓励将网络功能从专用物理硬件节点迁移到虚拟化资源池。然而，网络虚拟化可以被认为是一个比云计算更复杂的问题，因为它不仅涉及计算和存储功能的虚拟化，还涉及网络本身的抽象。本文档描述了网络虚拟化领域当前的研究和工程挑战，包括服务质量保证、性能改进、多域支持、网络切片、服务组合、设备虚拟化、隐私和安全、控制问题分离、网络功能布局、，和测试。此外，还就IETF和IRTF中的新活动提出了一些建议，以应对其中的一些挑战。本文档是网络功能虚拟化研究组（NFVRG）的产品。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Network Function Virtualization Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究任务组（IRTF）网络功能虚拟化研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8568.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8568.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Network Function Virtualization . . . . . . . . . . . . . 6
3.2. Software-Defined Networking . . . . . . . . . . . . . . . 9
3.3. ITU-T Functional Architecture of SDN . . . . . . . . . . 13
3.4. Multi-Access Edge Computing . . . . . . . . . . . . . . . 15
3.5. IEEE 802.1CF (OmniRAN) . . . . . . . . . . . . . . . . . 15
3.6. Distributed Management Task Force (DMTF) . . . . . . . . 15
3.7. Open-Source Initiatives . . . . . . . . . . . . . . . . . 16
4. Network Virtualization Challenges . . . . . . . . . . . . . . 18
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Guaranteeing Quality of Service . . . . . . . . . . . . . 18
4.2.1. Virtualization Technologies . . . . . . . . . . . . . 18
4.2.2. Metrics for NFV Characterization . . . . . . . . . . 19
4.2.3. Predictive Analysis . . . . . . . . . . . . . . . . . 20
4.2.4. Portability . . . . . . . . . . . . . . . . . . . . . 20
4.3. Performance Improvement . . . . . . . . . . . . . . . . . 21
4.3.1. Energy Efficiency . . . . . . . . . . . . . . . . . . 21
4.3.2. Improved Link Usage . . . . . . . . . . . . . . . . . 21
4.4. Multiple Domains . . . . . . . . . . . . . . . . . . . . 22
4.5. 5G and Network Slicing . . . . . . . . . . . . . . . . . 22
4.5.1. Virtual Network Operators . . . . . . . . . . . . . . 23
4.5.2. Extending Virtual Networks and Systems to the
Internet of Things . . . . . . . . . . . . . . . . . 24
4.6. Service Composition . . . . . . . . . . . . . . . . . . . 25
4.7. Device Virtualization for End Users . . . . . . . . . . . 27
4.8. Security and Privacy . . . . . . . . . . . . . . . . . . 27
4.9. Separation of Control Concerns . . . . . . . . . . . . . 29
4.10. Network Function Placement . . . . . . . . . . . . . . . 29
4.11. Testing . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.11.1. Changes in Methodology . . . . . . . . . . . . . . . 30
4.11.2. New Functionality . . . . . . . . . . . . . . . . . 31
4.11.3. Opportunities . . . . . . . . . . . . . . . . . . . 32
5. Technology Gaps and Potential IETF Efforts . . . . . . . . . 33
6. NFVRG Focus Areas . . . . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. Informative References . . . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Network Function Virtualization . . . . . . . . . . . . . 6
3.2. Software-Defined Networking . . . . . . . . . . . . . . . 9
3.3. ITU-T Functional Architecture of SDN . . . . . . . . . . 13
3.4. Multi-Access Edge Computing . . . . . . . . . . . . . . . 15
3.5. IEEE 802.1CF (OmniRAN) . . . . . . . . . . . . . . . . . 15
3.6. Distributed Management Task Force (DMTF) . . . . . . . . 15
3.7. Open-Source Initiatives . . . . . . . . . . . . . . . . . 16
4. Network Virtualization Challenges . . . . . . . . . . . . . . 18
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Guaranteeing Quality of Service . . . . . . . . . . . . . 18
4.2.1. Virtualization Technologies . . . . . . . . . . . . . 18
4.2.2. Metrics for NFV Characterization . . . . . . . . . . 19
4.2.3. Predictive Analysis . . . . . . . . . . . . . . . . . 20
4.2.4. Portability . . . . . . . . . . . . . . . . . . . . . 20
4.3. Performance Improvement . . . . . . . . . . . . . . . . . 21
4.3.1. Energy Efficiency . . . . . . . . . . . . . . . . . . 21
4.3.2. Improved Link Usage . . . . . . . . . . . . . . . . . 21
4.4. Multiple Domains . . . . . . . . . . . . . . . . . . . . 22
4.5. 5G and Network Slicing . . . . . . . . . . . . . . . . . 22
4.5.1. Virtual Network Operators . . . . . . . . . . . . . . 23
4.5.2. Extending Virtual Networks and Systems to the
Internet of Things . . . . . . . . . . . . . . . . . 24
4.6. Service Composition . . . . . . . . . . . . . . . . . . . 25
4.7. Device Virtualization for End Users . . . . . . . . . . . 27
4.8. Security and Privacy . . . . . . . . . . . . . . . . . . 27
4.9. Separation of Control Concerns . . . . . . . . . . . . . 29
4.10. Network Function Placement . . . . . . . . . . . . . . . 29
4.11. Testing . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.11.1. Changes in Methodology . . . . . . . . . . . . . . . 30
4.11.2. New Functionality . . . . . . . . . . . . . . . . . 31
4.11.3. Opportunities . . . . . . . . . . . . . . . . . . . 32
5. Technology Gaps and Potential IETF Efforts . . . . . . . . . 33
6. NFVRG Focus Areas . . . . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. Informative References . . . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
The telecommunications sector is experiencing a major revolution that will shape the way networks and services are designed and deployed for the next few decades. In order to cope with continuously increasing demand and cost, network operators are taking lessons from the IT paradigm of cloud computing. This new approach of virtualizing network functions will enable multi-fold advantages by moving communication services from bespoke hardware in the operator's core network to Commercial Off-The-Shelf (COTS) equipment distributed across data centers.
电信部门正在经历一场重大革命，这场革命将决定未来几十年网络和服务的设计和部署方式。为了应对不断增长的需求和成本，网络运营商正在借鉴云计算的IT范式。通过将通信服务从运营商核心网络中的定制硬件转移到跨数据中心分布的商用现货（COTS）设备，这种虚拟化网络功能的新方法将实现多重优势。
Some of the network virtualization mechanisms that are being considered include the following: sharing of network infrastructure to reduce costs, virtualization of core and edge servers/services running in data centers as a way of supporting their load-aware elastic dimensioning, and dynamic energy policies to reduce the electricity consumption.
正在考虑的一些网络虚拟化机制包括：共享网络基础设施以降低成本，虚拟化数据中心中运行的核心和边缘服务器/服务以支持其负载感知弹性尺寸，以及动态能源政策以降低电能消耗。
This document presents research and engineering challenges in network virtualization that need to be addressed in order to achieve these goals, spanning from pure research and engineering/standards space. The objective of this memo is to document the technical challenges and corresponding current approaches and to expose requirements that should be addressed by future research and standards work.
本文档介绍了网络虚拟化方面的研究和工程挑战，这些挑战需要从纯研究和工程/标准领域解决，以实现这些目标。本备忘录的目的是记录技术挑战和相应的当前方法，并揭示未来研究和标准工作应解决的需求。
This document represents the consensus of the Network Function Virtualization Research Group (NFVRG). It has been reviewed by the RG members active in the specific areas of work covered by the document.
本文件代表了网络功能虚拟化研究小组（NFVRG）的共识。在本文件所涵盖的特定工作领域内活跃的RG成员已经对其进行了审查。
The following terms used in this document are defined by the ETSI Network Function Virtualization (NFV) Industrial Study Group (ISG) [etsi_gs_nfv_003], the Open Networking Foundation (ONF) [onf_tr_521], and the IETF [RFC7426] [RFC7665]:
本文档中使用的以下术语由ETSI网络功能虚拟化（NFV）工业研究组（ISG）[ ETSIIGGSYNFVY03]、开放网络基金会（ONF）[ONFYTRY521]和IETF[RCF7626] [RCF7665 ]定义。
Application Plane: The collection of applications and services that program network behavior.
应用程序平面：对网络行为进行编程的应用程序和服务的集合。
Control Plane (CP): The collection of functions responsible for controlling one or more network devices. The CP instructs network devices with respect to how to process and forward packets. The control plane interacts primarily with the forwarding plane and, to a lesser extent, with the operational plane.
控制平面（CP）：负责控制一个或多个网络设备的功能集合。CP指示网络设备如何处理和转发数据包。控制平面主要与转发平面交互，并在较小程度上与操作平面交互。
Forwarding Plane (FP): The collection of resources across all network devices responsible for forwarding traffic.
转发平面（FP）：负责转发流量的所有网络设备上的资源集合。
Management Plane (MP): The collection of functions responsible for monitoring, configuring, and maintaining one or more network devices or parts of network devices. The management plane is mostly related to the operational plane (it is related less to the forwarding plane).
管理平面（MP）：负责监视、配置和维护一个或多个网络设备或网络设备的一部分的功能集合。管理平面主要与操作平面相关（与转发平面的关系较小）。
NFV Infrastructure (NFVI): Totality of all hardware and software components that build up the environment in which VNFs are deployed.
NFV基础设施（NFVI）：构成部署VNF的环境的所有硬件和软件组件的总和。
NFV Management and Orchestration (NFV-MANO): Functions collectively provided by NFVO, VNFM, and VIM.
NFV管理和编排（NFV-MANO）：由NFVO、VNFM和VIM共同提供的功能。
NFV Orchestrator (NFVO): Functional block that manages the Network Service (NS) life cycle and coordinates the management of NS life cycle, VNF life cycle (supported by the VNFM) and NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity.
NFV Orchestrator（NFVO）：管理网络服务（NS）生命周期并协调NS生命周期、VNF生命周期（由VNFM支持）和NFVI资源（由VIM支持）管理的功能块，以确保必要资源和连接的优化分配。
Operational Plane (OP): The collection of resources responsible for managing the overall operation of individual network devices.
操作平面（OP）：负责管理单个网络设备整体操作的资源集合。
Physical Network Function (PNF): Physical implementation of a network function in a monolithic realization.
物理网络功能（PNF）：网络功能在单片实现中的物理实现。
Service Function Chain (SFC): For a given service, the abstracted view of the required service functions and the order in which they are to be applied. This is somehow equivalent to the Network Function Forwarding Graph (NF-FG) at ETSI.
服务功能链（SFC）：对于给定的服务，所需服务功能的抽象视图及其应用顺序。这在某种程度上相当于ETSI的网络功能转发图（NF-FG）。
Service Function Path (SFP): The selection of specific service function instances on specific network nodes to form a service graph through which an SFC is instantiated.
服务功能路径（SFP）：选择特定网络节点上的特定服务功能实例，形成服务图，通过该图实例化SFC。
Virtualized Infrastructure Manager (VIM): Functional block that is responsible for controlling and managing the NFVI compute, storage, and network resources, usually within one infrastructure operator's domain.
虚拟化基础架构管理器（VIM）：负责控制和管理NFVI计算、存储和网络资源的功能块，通常位于一个基础架构运营商的域内。
Virtualized Network Function (VNF): Implementation of a Network Function that can be deployed on a Network Function Virtualization Infrastructure (NFVI).
虚拟化网络功能（VNF）：可部署在网络功能虚拟化基础设施（NFVI）上的网络功能的实现。
Virtualized Network Function Manager (VNFM): Functional block that is responsible for the life-cycle management of VNF.
虚拟化网络功能管理器（VNFM）：负责VNF生命周期管理的功能块。
This section briefly describes some basic background technologies as well as other Standards Developing Organizations (SDOs) and open-source initiatives working on network virtualization or related topics.
本节简要介绍了一些基本的背景技术以及其他标准开发组织（SDO）和从事网络虚拟化或相关主题的开源计划。
The ETSI ISG Network Function Virtualization (NFV) is a working group that, since 2012, has aimed to evolve quasi-standard IT virtualization technology to consolidate many network equipment types into industry standard high-volume servers, switches, and storage. It enables implementing network functions in software that can run on a range of industry-standard server hardware and can be moved to, or loaded in, various locations in the network as required, without the need to install new equipment. The ETSI NFV is one of the predominant NFV reference framework and architectural footprints [nfv_sota_research_challenges]. The ETSI NFV framework architecture is composed of three domains (Figure 1):
ETSI ISG网络功能虚拟化（NFV）是一个工作组，自2012年以来，该工作组一直致力于发展准标准IT虚拟化技术，以将多种网络设备类型整合到行业标准的大容量服务器、交换机和存储中。它可以在软件中实现网络功能，该软件可以在一系列行业标准服务器硬件上运行，并且可以根据需要移动到或加载到网络中的各个位置，而无需安装新设备。ETSI NFV是主要的NFV参考框架和架构足迹之一[NFV_sota_research_challenges]。ETSI NFV框架架构由三个域组成（图1）：
o Virtualized Network Function, running over the NFVI.
o 通过NFVI运行的虚拟化网络功能。
o NFVI, including the diversity of physical resources and how these can be virtualized. NFVI supports the execution of the VNFs.
o NFVI，包括物理资源的多样性以及如何虚拟化这些资源。NFVI支持VNFs的执行。
o NFV Management and Orchestration, which covers the orchestration and life-cycle management of physical and/or software resources that support the infrastructure virtualization, and the life-cycle management of VNFs. NFV Management and Orchestration focuses on all virtualization-specific management tasks necessary in the NFV framework.
o NFV管理和编排，包括支持基础架构虚拟化的物理和/或软件资源的编排和生命周期管理，以及VNF的生命周期管理。NFV管理和编排侧重于NFV框架中所需的所有特定于虚拟化的管理任务。
+-------------------------------------------+ +---------------+
| Virtualized Network Functions (VNFs) | | |
| ------- ------- ------- ------- | | |
| | | | | | | | | | | |
| | VNF | | VNF | | VNF | | VNF | | | |
| | | | | | | | | | | |
| ------- ------- ------- ------- | | |
+-------------------------------------------+ | |
| |
+-------------------------------------------+ | |
| NFV Infrastructure (NFVI) | | NFV |
| ----------- ----------- ----------- | | Management |
| | Virtual | | Virtual | | Virtual | | | and |
| | Compute | | Storage | | Network | | | Orchestration |
| ----------- ----------- ----------- | | |
| +---------------------------------------+ | | |
| | Virtualization Layer | | | |
| +---------------------------------------+ | | |
| +---------------------------------------+ | | |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | |
| +---------------------------------------+ | | |
+-------------------------------------------+ +---------------+
+-------------------------------------------+ +---------------+
| Virtualized Network Functions (VNFs) | | |
| ------- ------- ------- ------- | | |
| | | | | | | | | | | |
| | VNF | | VNF | | VNF | | VNF | | | |
| | | | | | | | | | | |
| ------- ------- ------- ------- | | |
+-------------------------------------------+ | |
| |
+-------------------------------------------+ | |
| NFV Infrastructure (NFVI) | | NFV |
| ----------- ----------- ----------- | | Management |
| | Virtual | | Virtual | | Virtual | | | and |
| | Compute | | Storage | | Network | | | Orchestration |
| ----------- ----------- ----------- | | |
| +---------------------------------------+ | | |
| | Virtualization Layer | | | |
| +---------------------------------------+ | | |
| +---------------------------------------+ | | |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | |
| +---------------------------------------+ | | |
+-------------------------------------------+ +---------------+
Figure 1: ETSI NFV Framework
图1:ETSI NFV框架
The NFV architectural framework identifies functional blocks and the main reference points between such blocks. Some of these are already present in current deployments, whilst others might be necessary additions in order to support the virtualization process and consequent operation. The functional blocks are (Figure 2):
NFV架构框架确定了功能块和这些块之间的主要参考点。其中一些已经存在于当前部署中，而其他可能是必要的补充，以支持虚拟化过程和后续操作。功能块包括（图2）：
o Virtualized Network Function (VNF)
o 虚拟化网络功能（VNF）
o Element Management (EM)
o 要素管理（EM）
o NFV Infrastructure, including: Hardware and virtualized resources as well as the Virtualization Layer.
o NFV基础设施，包括：硬件和虚拟化资源以及虚拟化层。
o Virtualized Infrastructure Manager(s) (VIM)
o 虚拟化基础架构管理器（VIM）
o NFV Orchestrator
o NFV配器
o VNF Manager(s)
o VNF经理（s）
o Service, VNF and Infrastructure Description
o 服务、VNF和基础设施描述
o Operational Support Systems and Business Support Systems (OSS and BSS)
o 运营支持系统和业务支持系统（OSS和BSS）
+--------------------+
+-------------------------------------------+ | ---------------- |
| OSS/BSS | | | NFV | |
+-------------------------------------------+ | | Orchestrator +-- |
| ---+------------ | |
+-------------------------------------------+ | | | |
| --------- --------- --------- | | | | |
| | EM 1 | | EM 2 | | EM 3 | | | | | |
| ----+---- ----+---- ----+---- | | ---+---------- | |
| | | | |--|-| VNF | | |
| ----+---- ----+---- ----+---- | | | manager(s) | | |
| | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | |
| ----+---- ----+---- ----+---- | | | | |
+------|-------------|-------------|--------+ | | | |
| | | | | | |
+------+-------------+-------------+--------+ | | | |
| NFV Infrastructure (NFVI) | | | | |
| ----------- ----------- ----------- | | | | |
| | Virtual | | Virtual | | Virtual | | | | | |
| | Compute | | Storage | | Network | | | | | |
| ----------- ----------- ----------- | | ---+------ | |
| +---------------------------------------+ | | | | | |
| | Virtualization Layer | |--|-| VIM(s) +-------- |
| +---------------------------------------+ | | | | |
| +---------------------------------------+ | | ---------- |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | | hardware| | hardware| | hardware| | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | NFV Management |
| +---------------------------------------+ | | and Orchestration |
+-------------------------------------------+ +--------------------+
+--------------------+
+-------------------------------------------+ | ---------------- |
| OSS/BSS | | | NFV | |
+-------------------------------------------+ | | Orchestrator +-- |
| ---+------------ | |
+-------------------------------------------+ | | | |
| --------- --------- --------- | | | | |
| | EM 1 | | EM 2 | | EM 3 | | | | | |
| ----+---- ----+---- ----+---- | | ---+---------- | |
| | | | |--|-| VNF | | |
| ----+---- ----+---- ----+---- | | | manager(s) | | |
| | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | |
| ----+---- ----+---- ----+---- | | | | |
+------|-------------|-------------|--------+ | | | |
| | | | | | |
+------+-------------+-------------+--------+ | | | |
| NFV Infrastructure (NFVI) | | | | |
| ----------- ----------- ----------- | | | | |
| | Virtual | | Virtual | | Virtual | | | | | |
| | Compute | | Storage | | Network | | | | | |
| ----------- ----------- ----------- | | ---+------ | |
| +---------------------------------------+ | | | | | |
| | Virtualization Layer | |--|-| VIM(s) +-------- |
| +---------------------------------------+ | | | | |
| +---------------------------------------+ | | ---------- |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | | hardware| | hardware| | hardware| | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | NFV Management |
| +---------------------------------------+ | | and Orchestration |
+-------------------------------------------+ +--------------------+
Figure 2: ETSI NFV Reference Architecture
图2:ETSI NFV参考体系结构
The Software-Defined Networking (SDN) paradigm pushes the intelligence currently residing in the network elements to a central controller implementing the network functionality through software. In contrast to traditional approaches, in which the network's control plane is distributed throughout all network devices, with SDN, the control plane is logically centralized. In this way, the deployment of new characteristics in the network no longer requires complex and costly changes in equipment or firmware updates, but only a change in the software running in the controller. The main advantage of this approach is the flexibility it provides operators to manage their network, i.e., an operator can easily change its policies on how traffic is distributed throughout the network.
软件定义网络（SDN）范式将当前驻留在网元中的智能推送到通过软件实现网络功能的中央控制器。与传统方法（网络的控制平面分布在所有网络设备上）不同，使用SDN，控制平面在逻辑上是集中的。这样，在网络中部署新特性不再需要对设备或固件更新进行复杂且昂贵的更改，而只需要对控制器中运行的软件进行更改。这种方法的主要优点是，它为运营商提供了管理其网络的灵活性，即运营商可以轻松地更改其在整个网络中如何分配流量的策略。
One of the most well-known protocols for the SDN control plane between the central controller and the networking elements is the OpenFlow Protocol (OFP), which is maintained and extended by the Open Network Foundation (ONF) <https://www.opennetworking.org/>. Originally, this protocol was developed specifically for IEEE 802.1 switches conforming to the ONF OpenFlow Switch specification [OpenFlow]. As the benefits of the SDN paradigm have reached a wider audience, its application has been extended to more complex scenarios such as wireless and mobile networks. Within this area of work, the ONF is actively developing new OFP extensions addressing three key scenarios: (i) wireless backhaul, (ii) cellular Evolved Packet Core (EPC), and (iii) unified access and management across enterprise wireless and fixed networks.
在中央控制器和网络单元之间的SDN控制平面最著名的协议之一是OpenFLASH协议（OFP），它由开放网络基金会（ONF）维护和扩展。https://www.opennetworking.org/>. 最初，该协议是专门为符合ONF OpenFlow交换机规范[OpenFlow]的IEEE 802.1交换机开发的。随着SDN模式的好处已惠及更广泛的受众，其应用已扩展到更复杂的场景，如无线和移动网络。在这一工作领域内，ONF正在积极开发新的OFP扩展，解决三个关键场景：（i）无线回程，（ii）蜂窝演进包核心（EPC），以及（iii）跨企业无线和固定网络的统一访问和管理。
+----------+
| ------- |
| |Oper.| | O
| |Mgmt.| |<........> -+- Network Operator
| |Iface| | ^
| ------- | +----------------------------------------+
| | | +------------------------------------+ |
| | | | --------- --------- --------- | |
|--------- | | | | App 1 | | App 2 | ... | App n | | |
||Plugins| |<....>| | --------- --------- --------- | |
|--------- | | | Plugins | |
| | | +------------------------------------+ |
| | | Application Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +------------------------------------+ |
|--------- | | | ------------ ------------ | |
|| Netw. | | | | | Module 1 | | Module 2 | | |
||Engine | |<....>| | ------------ ------------ | |
|--------- | | | Network Engine | |
| | | +------------------------------------+ |
| | | Control Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +--------------+ +--------------+ |
| | | | ------------ | | ------------ | |
|----------| | | | OpenFlow | | | | OpenFlow | | |
||OpenFlow||<....>| | ------------ | | ------------ | |
|----------| | | NE | | NE | |
| | | +--------------+ +--------------+ |
| | | Data Plane |
|Management| +----------------------------------------+
+----------+
+----------+
| ------- |
| |Oper.| | O
| |Mgmt.| |<........> -+- Network Operator
| |Iface| | ^
| ------- | +----------------------------------------+
| | | +------------------------------------+ |
| | | | --------- --------- --------- | |
|--------- | | | | App 1 | | App 2 | ... | App n | | |
||Plugins| |<....>| | --------- --------- --------- | |
|--------- | | | Plugins | |
| | | +------------------------------------+ |
| | | Application Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +------------------------------------+ |
|--------- | | | ------------ ------------ | |
|| Netw. | | | | | Module 1 | | Module 2 | | |
||Engine | |<....>| | ------------ ------------ | |
|--------- | | | Network Engine | |
| | | +------------------------------------+ |
| | | Control Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +--------------+ +--------------+ |
| | | | ------------ | | ------------ | |
|----------| | | | OpenFlow | | | | OpenFlow | | |
||OpenFlow||<....>| | ------------ | | ------------ | |
|----------| | | NE | | NE | |
| | | +--------------+ +--------------+ |
| | | Data Plane |
|Management| +----------------------------------------+
+----------+
Figure 3: High-Level SDN ONF Architecture
图3：高级SDN ONF体系结构
Figure 3 shows the blocks and the functional interfaces of the ONF architecture, which comprises three planes: data, controller, and application. The data plane comprehends several Network Entities (NEs), which expose their capabilities toward the control plane via a Southbound API. The control plane includes several cooperating modules devoted to the creation and maintenance of an abstracted
图3显示了ONF体系结构的模块和功能接口，它包括三个平面：数据、控制器和应用程序。数据平面包含多个网络实体（NE），这些实体通过南行API向控制平面公开其功能。控制平面包括几个用于创建和维护抽象模型的协作模块
resource model of the underlying network. Such a model is exposed to the applications via a Northbound API where the application plane comprises several applications/services, each of which has exclusive control of a set of exposed resources.
基础网络的资源模型。这样的模型通过北行API向应用程序公开，其中应用程序平面包括多个应用程序/服务，每个应用程序/服务对一组公开的资源具有独占控制。
The management plane spans its functionality across all planes performing the initial configuration of the network elements in the data plane, the assignment of the SDN controller and the resources under its responsibility. In the control plane, the management needs to configure the policies defining the scope of the control given to the SDN applications, to monitor the performance of the system and to configure the parameters required by the SDN controller modules. In the application plane, the management plane configures the parameters of the applications and the service-level agreements. In addition to these interactions, the management plane exposes several functions to network operators that can easily and quickly configure and tune the network at each layer.
管理平面将其功能跨越所有平面，这些平面执行数据平面中网元的初始配置、SDN控制器的分配以及其负责的资源。在控制平面中，管理层需要配置定义SDN应用程序控制范围的策略，监控系统性能，并配置SDN控制器模块所需的参数。在应用程序平面中，管理平面配置应用程序和服务级别协议的参数。除了这些交互之外，管理平面还向网络运营商公开了一些功能，这些功能可以轻松快速地在每一层配置和调整网络。
In RFC 7426 [RFC7426], the IRTF Software-Defined Networking Research Group (SDNRG) documented a layer model of an SDN architecture. This was due to the following controversial discussion topics (among others). What exactly is SDN? What is the layer structure of the SDN architecture? How do layers interface with each other?
在RFC 7426[RFC7426]中，IRTF软件定义网络研究小组（SDNRG）记录了SDN体系结构的层模型。这是由于以下有争议的讨论主题（除其他外）。SDN到底是什么？SDN体系结构的层结构是什么？各层如何相互连接？
Figure 4 reproduces the figure included in RFC 7426 [RFC7426] to summarize the SDN architecture abstractions in the form of a detailed, high-level schematic. In a particular implementation, planes can be collocated with other planes or can be physically separated.
图4再现了RFC 7426[RFC7426]中包含的图，以详细的高级示意图的形式总结SDN架构抽象。在特定实现中，平面可以与其他平面并置，也可以物理分离。
In SDN, a controller manipulates controlled entities via an interface. Interfaces, when local, are mostly API invocations through some library or system call. However, such interfaces may be extended via some protocol definition, which may use local interprocess communication (IPC) or a protocol that could also act remotely; the protocol may be defined as an open standard or in a proprietary manner.
在SDN中，控制器通过接口操纵受控实体。本地接口主要是通过一些库或系统调用进行的API调用。然而，这些接口可以通过一些协议定义进行扩展，这些协议定义可以使用本地进程间通信（IPC）或也可以远程操作的协议；协议可定义为开放标准或专有方式。
SDN expands multiple planes: forwarding, operational, control, management, and application. All planes mentioned above are connected via interfaces. Additionally, RFC 7426 [RFC7426] considers four abstraction layers: the Device and resource Abstraction Layer (DAL), the Control Abstraction Layer (CAL), the Management Abstraction Layer (MAL), and the Network Services Abstraction Layer (NSAL).
SDN扩展了多个平面：转发、操作、控制、管理和应用。上述所有平面均通过接口连接。此外，RFC7426[RFC7426]考虑了四个抽象层：设备和资源抽象层（DAL）、控制抽象层（CAL）、管理抽象层（MAL）和网络服务抽象层（NSAL）。
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
Figure 4: SDN-Layer Architecture
图4:SDN层架构
While SDN is often directly associated to OpenFlow, this is just one (relevant) example of a southbound protocol between the central controller and the network entities. Other relevant examples of protocols in the SDN family are NETCONF [RFC6241], RESTCONF [RFC8040], and ForCES [RFC5810].
虽然SDN通常直接与OpenFlow关联，但这只是中央控制器和网络实体之间的南向协议的一个（相关）示例。SDN系列中的其他相关协议示例包括NETCONF[RFC6241]、RESTCONF[RFC8040]和ForCES[RFC5810]。
The ITU-T (the Telecommunication standardization sector of the International Telecommunication Union) has also looked into SDN architectures, defining a slightly modified one from what other SDOs have done. In ITU-T recommendation Y.3302 [itu-t-y.3302], the ITU-T provides a functional architecture of SDN with descriptions of functional components and reference points. The described functional architecture is intended to be used as an enabler for further studies on other aspects such as protocols and security as well as being used to customize SDN in support of appropriate use cases (e.g., cloud computing, mobile networks). This recommendation is based on ITU-T Y.3300 [itu-t-y.3300] and ITU-T Y.3301 [itu-t-y.3301]. While the first describes the framework of SDN (including definitions, objectives, high-level capabilities, requirements, and the high-level architecture of SDN), the second describes more-detailed requirements.
ITU-T（国际电信联盟的电信标准化部门）也对SDN体系结构进行了研究，定义了一个与其他SDO所做工作略有不同的体系结构。在ITU-T建议Y.3302[ITU-T-Y.3302]中，ITU-T提供了SDN的功能体系结构，并描述了功能组件和参考点。所描述的功能架构旨在用作对协议和安全性等其他方面的进一步研究的启用码，以及用于定制SDN以支持适当的用例（例如，云计算、移动网络）。本建议基于ITU-T Y.3300[ITU-T-Y.3300]和ITU-T Y.3301[ITU-T-Y.3301]。第一个描述了SDN的框架（包括定义、目标、高级功能、需求和SDN的高级体系结构），第二个描述了更详细的需求。
Figure 5 shows the SDN functional architecture defined by the ITU-T. It is a layered architecture composed of the SDN application layer (SDN-AL), the SDN control layer (SDN-CL), and the SDN resource layer (SDN-RL). It also has multi-layer management functions (MMF), which provide the ability to manage the functionalities of SDN layers, i.e., SDN-AL, SDN-CL, and SDN-RL. MMF interacts with these layers using Multi-layer Management Functions Application (MMFA), Multi-layer Management Functions Control (MMFC), and Multi-layer Management Functions Resource (MMFR) reference points.
图5显示了ITU-T定义的SDN功能架构。它是由SDN应用层（SDN-AL）、SDN控制层（SDN-CL）和SDN资源层（SDN-RL）组成的分层架构。它还具有多层管理功能（MMF），能够管理SDN层的功能，即SDN-AL、SDN-CL和SDN-RL。MMF使用多层管理功能应用程序（MMFA）、多层管理功能控制（MMFC）和多层管理功能资源（MMFR）参考点与这些层交互。
The SDN-AL enables a service-aware behavior of the underlying network in a programmatic manner. The SDN-CL provides programmable means to control the behavior of SDN-RL resources (such as data transport and processing) following requests received from the SDN-AL according to MMF policies. The SDN-RL is where the physical or virtual network elements perform transport and/or processing of data packets according to SDN-CL decisions.
SDN-AL以编程方式支持底层网络的服务感知行为。根据MMF策略，SDN-CL提供了可编程的方法来控制SDN-RL资源（如数据传输和处理）在收到来自SDN-AL的请求后的行为。SDN-RL是物理或虚拟网络元件根据SDN-CL决定执行数据分组的传输和/或处理的地方。
MMFO MMFA
+-----+ . +---------------------+ . +--------------------+
| | . |+---+ +---+ +-------+| . |+---------+ +-----+ |
| | . || | | | | || . || AL. | | | |
| | . || E | | | | App. || . || Mngmt. | | SDN | | SDN-AL
| | . || x | | M | | Layer || . || Support | | App | |
| | . || t.| | u | | Mngmt.|| . || & Orch. | | | |
| | . || | | l | +-------+| . |+---------+ +-----+ |
| | . || R | | t | | . +--------------------+
| | . || e | | i | |MMFC ..................... ACI
| | . || l | | - | | . +--------------------+
| | . || a | | l | +-------+| . |+------+ +---------+|
| OSS/| . || t | | a | | || . || | | App. ||
| BSS | . || i | | y | | || . || | | Support ||
| | . || o | | e | | || . || | +---------+|
| | . || n | | r | | || . || CL | +---------+|
| | . || s | | | |Control|| . ||Mngmt.| | Control ||
| | . || h | | M | | Layer || . || Supp.| | Layer || SDN-CL
| | . || i | | a | | Mngmt.|| . || and | | Serv. ||
| | . || p | | n | | || . || Orch.| +---------+|
| | . || | | a | | || . || | +---------+|
| | . || M | | g | | || . || | | Resource||
| | . || n | | e | | || . || | | Abstrac.||
| | . || g | | m | +-------+| . |+------+ +---------+|
| | . || m | | e | | . +--------------------+
| | . || t.| | n | |MMFR ..................... RCI
| | . || | | t | | . +--------------------+
+-----+ . |+---+ | | +-------+| . |+------++----------+|
| | O | | || . || ||RL Control||
| | r | |Resour.|| . || RL |+----------+|
MMF | | c | | Layer || . ||Mngmt.|+----++----+| SDN-RL
| | h.| | Mngmt.|| . || Supp.||Data||Data||
| | | | || . || ||Tran||Proc||
| +---+ +-------+| . |+------++----++----+|
+---------------------+ . +--------------------+
MMFO MMFA
+-----+ . +---------------------+ . +--------------------+
| | . |+---+ +---+ +-------+| . |+---------+ +-----+ |
| | . || | | | | || . || AL. | | | |
| | . || E | | | | App. || . || Mngmt. | | SDN | | SDN-AL
| | . || x | | M | | Layer || . || Support | | App | |
| | . || t.| | u | | Mngmt.|| . || & Orch. | | | |
| | . || | | l | +-------+| . |+---------+ +-----+ |
| | . || R | | t | | . +--------------------+
| | . || e | | i | |MMFC ..................... ACI
| | . || l | | - | | . +--------------------+
| | . || a | | l | +-------+| . |+------+ +---------+|
| OSS/| . || t | | a | | || . || | | App. ||
| BSS | . || i | | y | | || . || | | Support ||
| | . || o | | e | | || . || | +---------+|
| | . || n | | r | | || . || CL | +---------+|
| | . || s | | | |Control|| . ||Mngmt.| | Control ||
| | . || h | | M | | Layer || . || Supp.| | Layer || SDN-CL
| | . || i | | a | | Mngmt.|| . || and | | Serv. ||
| | . || p | | n | | || . || Orch.| +---------+|
| | . || | | a | | || . || | +---------+|
| | . || M | | g | | || . || | | Resource||
| | . || n | | e | | || . || | | Abstrac.||
| | . || g | | m | +-------+| . |+------+ +---------+|
| | . || m | | e | | . +--------------------+
| | . || t.| | n | |MMFR ..................... RCI
| | . || | | t | | . +--------------------+
+-----+ . |+---+ | | +-------+| . |+------++----------+|
| | O | | || . || ||RL Control||
| | r | |Resour.|| . || RL |+----------+|
MMF | | c | | Layer || . ||Mngmt.|+----++----+| SDN-RL
| | h.| | Mngmt.|| . || Supp.||Data||Data||
| | | | || . || ||Tran||Proc||
| +---+ +-------+| . |+------++----++----+|
+---------------------+ . +--------------------+
Legend: ACI: Application Control Interface MMFA: Multi-layer Management Functions Application MMFC: Multi-layer Management Functions Control MMFO: Multi-layer Management Functions OSS/BSS MMFR: Multi-layer Management Functions Resource RCI: Resource Control Interfaces RL: Resource Layer
图例：ACI:应用程序控制接口MMFA:多层管理功能应用程序MMFC:多层管理功能控制MMFO:多层管理功能OSS/BSS MMFR:多层管理功能资源RCI:资源控制接口RL:资源层
Figure 5: ITU-T SDN Functional Architecture
图5:ITU-T SDN功能架构
Multi-access Edge Computing (MEC) -- formerly known as Mobile Edge Computing -- capabilities deployed in the edge of the mobile network can facilitate the efficient and dynamic provision of services to mobile users. The ETSI ISG MEC working group, operative from end of 2014, intends to specify an open environment for integrating MEC capabilities with service providers' networks, also including applications from third parties. These distributed computing capabilities provide IT infrastructure as in a cloud environment for the deployment of functions in mobile access networks. It can be seen then as a complement to both NFV and SDN.
多接入边缘计算（MEC）——以前称为移动边缘计算——部署在移动网络边缘的功能可以促进高效、动态地向移动用户提供服务。ETSI ISG MEC工作组于2014年底开始运作，旨在为MEC功能与服务提供商网络（也包括第三方应用程序）的集成指定一个开放环境。这些分布式计算能力为移动接入网络中的功能部署提供了云环境中的IT基础设施。它可以被视为NFV和SDN的补充。
The IEEE 802.1CF Recommended Practice [omniran] specifies an access network that connects terminals to their access routers utilizing technologies based on the family of IEEE 802 Standards (e.g., 802.3 Ethernet, 802.11 Wi-Fi, etc.). The specification defines an access network reference model, including entities and reference points along with behavioral and functional descriptions of communications among those entities.
IEEE 802.1CF推荐规程[omniran]规定了一种接入网络，该网络利用基于IEEE 802标准系列（例如，802.3以太网、802.11 Wi-Fi等）的技术将终端连接到其接入路由器。该规范定义了接入网参考模型，包括实体和参考点以及这些实体之间通信的行为和功能描述。
The goal of this project is to help unify the support of different interfaces, enabling shared-network control and use of SDN principles, thereby lowering the barriers to new network technologies, to new network operators, and to new service providers.
该项目的目标是帮助统一对不同接口的支持，实现共享网络控制和SDN原则的使用，从而降低对新网络技术、新网络运营商和新服务提供商的障碍。
The DMTF <https://www.dmtf.org/> is an industry standards organization working to simplify the manageability of network-accessible technologies through open and collaborative efforts by some technology companies. The DMTF is involved in the creation and adoption of interoperable management standards, supporting implementations that enable the management of diverse traditional and emerging technologies including cloud, virtualization, network, and infrastructure.
DMTF<https://www.dmtf.org/>是一个行业标准组织，致力于通过一些技术公司的开放和协作努力简化网络可访问技术的可管理性。DMTF参与创建和采用可互操作的管理标准，支持实现对各种传统和新兴技术（包括云、虚拟化、网络和基础设施）的管理。
There are several DMTF initiatives that are relevant to the network virtualization area, such as the Open Virtualization Format (OVF) for VNF packaging; the Cloud Infrastructure Management Interface (CIMI) for cloud infrastructure management; the Network Management (NETMAN), for VNF management; and the Virtualization Management (VMAN), for virtualization infrastructure management.
有几个与网络虚拟化领域相关的DMTF计划，例如用于VNF打包的开放虚拟化格式（OVF）；用于云基础设施管理的云基础设施管理接口（CIMI）；网络管理（NETMAN），用于VNF管理；以及虚拟化管理（VMAN），用于虚拟化基础架构管理。
The open-source community is especially active in the area of network virtualization and orchestration. We next summarize some of the active efforts:
开源社区在网络虚拟化和编排领域尤其活跃。我们接下来总结一些积极的努力：
o OpenStack. OpenStack is a free and open-source cloud-computing software platform. OpenStack software controls large pools of compute, storage, and networking resources throughout a data center, managed through a dashboard or via the OpenStack API.
o OpenStack。OpenStack是一个免费的开源云计算软件平台。OpenStack软件控制整个数据中心的大型计算、存储和网络资源池，通过仪表板或OpenStack API进行管理。
o Kubernetes. Kubernetes is an open-source system for automating deployment, scaling and management of containerized applications. Kubernetes can schedule and run application containers on clusters of physical or virtual machines. Kubernetes allows (i) Scale on the fly, (ii) Limit hardware usage to required resources only, (iii) Load-balancing Monitoring, and (iv) Efficient life-cycle management.
o 库伯内特斯。Kubernetes是一个开源系统，用于自动化容器化应用程序的部署、扩展和管理。Kubernetes可以在物理或虚拟机集群上调度和运行应用程序容器。Kubernetes允许（i）动态扩展，（ii）仅将硬件使用限制在所需资源范围内，（iii）负载平衡监控，以及（iv）高效的生命周期管理。
o OpenDayLight. OpenDayLight (ODL) is a highly available, modular, extensible and scalable multiprotocol controller infrastructure built for SDN deployments on modern heterogeneous multi-vendor networks. It provides a model-driven service abstraction platform that allows users to write apps that easily work across a wide variety of hardware and southbound protocols.
o 露天采光。OpenDayLight（ODL）是一种高可用性、模块化、可扩展和可扩展的多协议控制器基础设施，专为现代异构多供应商网络上的SDN部署而构建。它提供了一个模型驱动的服务抽象平台，允许用户编写能够轻松跨各种硬件和南向协议工作的应用程序。
o ONOS. The Open Network Operating System (ONOS) project is an open-source community hosted by The Linux Foundation. The goal of the project is to create an SDN operating system for communications service providers that is designed for scalability, high performance, and high availability.
o 小野。开放网络操作系统（ONOS）项目是Linux基金会托管的开源社区。该项目的目标是为通信服务提供商创建SDN操作系统，该系统旨在实现可扩展性、高性能和高可用性。
o OpenContrail. OpenContrail is a licensed Apache 2.0 project that is built using standards-based protocols and that provides all the necessary components for network virtualization: an SDN controller, a virtual router, an analytics engine, and published northbound APIs. It has an extensive Representational State Transfer (REST) API to configure and gather operational and analytics data from the system.
o 开放轨迹。OpenContrail是一个获得许可的Apache 2.0项目，它使用基于标准的协议构建，并提供网络虚拟化所需的所有组件：SDN控制器、虚拟路由器、分析引擎和已发布的北行API。它有一个广泛的代表性状态传输（REST）API，用于配置和收集系统中的操作和分析数据。
o OPNFV. The Open Platform for NFV (OPNFV) is a carrier-grade, integrated, open-source platform to accelerate the introduction of new NFV products and services. By integrating components from upstream projects, the OPNFV community aims at conducting performance and use case-based testing to ensure the platform's suitability for NFV use cases. The scope of OPNFV's initial release is focused on building NFV Infrastructure (NFVI) and Virtualized Infrastructure Manager (VIM) by integrating components
o OPNFV。NFV开放平台（OPNFV）是一个运营商级的、集成的、开源的平台，用于加速新NFV产品和服务的引入。通过集成上游项目的组件，OPNFV社区旨在进行基于性能和用例的测试，以确保平台适合NFV用例。OPNFV最初发布的范围集中于通过集成组件构建NFV基础设施（NFVI）和虚拟化基础设施管理器（VIM）
from upstream projects such as OpenDayLight, OpenStack, Ceph Storage, Kernel-based Virtual Machine (KVM), Open vSwitch, and Linux. These components, along with APIs to other NFV elements, form the basic infrastructure required for Virtualized Network Functions (VNFs) and Management and Orchestration (MANO) components. OPNFV's goal is to (i) increase performance and power efficiency, (ii) improve reliability, availability, and serviceability, and (iii) deliver comprehensive platform instrumentation.
来自上游项目，如OpenDayLight、OpenStack、Ceph存储、基于内核的虚拟机（KVM）、OpenVSwitch和Linux。这些组件以及其他NFV元素的API构成了虚拟化网络功能（VNF）和管理与编排（MANO）组件所需的基本基础设施。OPNFV的目标是（i）提高性能和电源效率，（ii）提高可靠性、可用性和可维护性，以及（iii）提供全面的平台仪表。
o OSM. Open Source Mano (OSM) is an ETSI-hosted project to develop an Open Source NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV. OSM is based on components from previous projects, such Telefonica's OpenMANO or Canonical's Juju, among others.
o 奥斯曼。开源Mano（OSM）是一个ETSI托管的项目，旨在开发与ETSI NFV一致的开源NFV管理和编排（Mano）软件堆栈。OSM基于以前项目的组件，如Telefonica的OpenMANO或Canonical的Juju等。
o OpenBaton. OpenBaton is a Network Function Virtualization Orchestrator (NFVO) that is ETSI NFV compliant. OpenBaton was part of the OpenSDNCore project started with the objective of providing a compliant implementation of the ETSI NFV specification.
o 开放式指挥棒。OpenBaton是一个符合ETSI NFV的网络功能虚拟化编排器（NFVO）。OpenBaton是OpenSDNCore项目的一部分，该项目的目标是提供ETSI NFV规范的兼容实现。
o ONAP. Open Network Automation Platform (ONAP) is an open-source software platform that delivers capabilities for the design, creation, orchestration, monitoring, and life-cycle management of (i) Virtual Network Functions (VNFs), (ii) The carrier-scale Software-Defined Networks (SDNs) that contain them, and (iii) higher-level services that combine the above. ONAP (derived from the AT&T's ECOMP) provides for automatic, policy-driven interaction of these functions and services in a dynamic, real-time cloud environment.
o ONAP。开放式网络自动化平台（ONAP）是一个开源软件平台，提供以下功能的设计、创建、编排、监控和生命周期管理：（i）虚拟网络功能（VNF），（ii）包含它们的运营商规模软件定义网络（SDN），以及（iii）结合以上内容的更高级别服务。ONAP（源自AT&T的ECOMP）在动态实时云环境中提供这些功能和服务的自动、策略驱动交互。
o SONA. The Simplified Overlay Network Architecture (SONA) is an extension to ONOS to have an almost full SDN network control in OpenStack for virtual tenant network provisioning. Basically, SONA is an SDN-based network virtualization solution for cloud DC.
o 索纳。简化覆盖网络架构（Simplified Overlay Network Architecture，SONA）是ONOS的一个扩展，在OpenStack中拥有几乎完整的SDN网络控制，用于虚拟租户网络资源调配。基本上，SONA是一个基于SDN的云DC网络虚拟化解决方案。
Among the main areas that are being developed by the aforementioned open-source activities that relate to network virtualization research, we can highlight policy-based resource management, analytics for visibility and orchestration, and service verification with regard to security and resiliency.
在上述与网络虚拟化研究相关的开源活动正在开发的主要领域中，我们可以重点介绍基于策略的资源管理、可视性和协调分析，以及安全性和弹性方面的服务验证。
Network virtualization is changing the way the telecommunications sector will deploy, extend, and operate their networks. These new technologies aim at reducing the overall costs by moving communication services from specific hardware in the operators' cores to server farms scattered in data centers (i.e., compute and storage virtualization). In addition, the networks interconnecting the functions that compose a network service are fundamentally affected in the way they route, process, and control traffic (i.e., network virtualization).
网络虚拟化正在改变电信部门部署、扩展和运营网络的方式。这些新技术旨在通过将通信服务从运营商核心的特定硬件转移到分散在数据中心的服务器场（即计算和存储虚拟化）来降低总体成本。此外，连接构成网络服务的功能的网络在路由、处理和控制流量的方式（即网络虚拟化）方面受到根本性影响。
Achieving a given QoS in an NFV environment with virtualized and distributed computing, storage, and networking functions is more challenging than providing the equivalent in discrete non-virtualized components. For example, ensuring a guaranteed and stable forwarding data rate has proven not to be straightforward when the forwarding function is virtualized and runs on top of COTS server hardware [openmano_dataplane] [NFV-COTS] [etsi_nfv_whitepaper_3]. Again, the comparison point is against a router or forwarder built on optimized hardware. We next identify some of the challenges that this poses.
在具有虚拟化和分布式计算、存储和网络功能的NFV环境中实现给定的QoS比在离散的非虚拟化组件中提供同等服务更具挑战性。例如，当转发功能被虚拟化并在COTS服务器硬件[openmano_dataplane][NFV-COTS][etsi_NFV_Whitepaper3]上运行时，确保有保证且稳定的转发数据速率已被证明并非易事。同样，比较点是针对建立在优化硬件上的路由器或转发器。接下来，我们将确定这带来的一些挑战。
The issue of guaranteeing a network QoS is less of an issue for "traditional" cloud computing because the workloads that are treated there are servers or clients in the networking sense and hardly ever process packets. Cloud computing provides hosting for applications on shared servers in a highly separated way. Its main advantage is that the infrastructure costs are shared among tenants and that the cloud infrastructure provides levels of reliability that can not be achieved on individual premises in a cost-efficient way [intel_10_differences_nfv_cloud]. NFV has very strict requirements posed in terms of performance, stability, and consistency. Although there are some tools and mechanisms to improve this, such as Enhanced Performance Awareness (EPA), Single Root I/O Virtualization (SR-IOV), Non-Uniform Memory Access (NUMA), Data Plane Development Kit (DPDK), etc., these are still unsolved challenges. One open research issue is finding out technologies that are different from Virtual Machines (VMs) and more suitable for dealing with network functionalities.
对于“传统”云计算来说，保证网络QoS的问题不是什么问题，因为在那里处理的工作负载是网络意义上的服务器或客户端，几乎从不处理数据包。云计算以高度分离的方式为共享服务器上的应用程序提供托管。其主要优势在于，基础设施成本由租户共同承担，云基础设施提供的可靠性水平无法在单个场所以经济高效的方式实现[intel_10_differences_nfv_cloud]。NFV在性能、稳定性和一致性方面提出了非常严格的要求。尽管有一些工具和机制可以改进这一点，如增强性能感知（EPA）、单根I/O虚拟化（SR-IOV）、非统一内存访问（NUMA）、数据平面开发工具包（DPDK）等，但这些仍然是未解决的挑战。一个公开的研究问题是找出不同于虚拟机（VM）的技术，以及更适合处理网络功能的技术。
Lately, a number of lightweight virtualization technologies including containers, unikernels (specialized VMs) and minimalistic distributions of general-purpose OSes have appeared as virtualization
最近，许多轻量级虚拟化技术，包括容器、unikernels（专用VM）和通用操作系统的最低版本，都以虚拟化的形式出现
approaches that can be used when constructing an NFV platform. [LIGHT-NFV] describes the challenges in building such a platform and discusses to what extent these technologies, as well as traditional VMs, are able to address them.
构建NFV平台时可以使用的方法。[LIGHT-NFV]描述了构建这样一个平台的挑战，并讨论了这些技术以及传统虚拟机能够在多大程度上解决这些挑战。
Another relevant aspect is the need for tools for diagnostics and measurements suited for NFV. There is a pressing need to define metrics and associated protocols to measure the performance of NFV. Specifically, since NFV is based on the concept of taking centralized functions and evolving them to highly distributed software (SW) functions, there is a commensurate need to fully understand and measure the baseline performance of such systems.
另一个相关方面是需要适合NFV的诊断和测量工具。迫切需要定义度量标准和相关协议来衡量NFV的性能。具体而言，由于NFV基于集中功能并将其演变为高度分布式软件（SW）功能的概念，因此需要充分了解和测量此类系统的基线性能。
The IP Performance Metrics (IPPM) WG defines metrics that can be used to measure the quality and performance of Internet services and applications running over transport-layer protocols (e.g., TCP and UDP) over IP. It also develops and maintains protocols for the measurement of these metrics. While the IPPM WG is a long-running WG that started in 1997, at the time of writing, it does not have a charter item or active Internet-Drafts related to the topic of network virtualization. In addition to using IPPM to evaluate QoS, there is a need for specific metrics for assessing the performance of network-virtualization techniques.
IP性能指标（IPPM）工作组定义了可用于测量通过IP传输层协议（如TCP和UDP）运行的Internet服务和应用程序的质量和性能的指标。它还开发和维护用于测量这些指标的协议。虽然IPPM工作组是一个长期运行的工作组，始于1997年，但在撰写本文时，它没有与网络虚拟化主题相关的特许条款或现行互联网草案。除了使用IPPM评估QoS外，还需要特定的指标来评估网络虚拟化技术的性能。
The Benchmarking Methodology Working Group (BMWG) is also performing work related to NFV metrics. For example, [RFC8172] investigates additional methodological considerations necessary when benchmarking VNFs that are instantiated and hosted in general-purpose hardware, using bare-metal hypervisors or other isolation environments (such as Linux containers). An essential consideration is benchmarking physical and VNFs in the same way when possible, thereby allowing direct comparison.
基准方法工作组（BMWG）也在执行与NFV指标相关的工作。例如，[RFC8172]研究了在使用裸机管理程序或其他隔离环境（如Linux容器）对在通用硬件中实例化和托管的VNF进行基准测试时需要考虑的其他方法。一个重要的考虑因素是尽可能以相同的方式对物理和VNF进行基准测试，从而允许直接比较。
There is a clear motivation for the work on performance metrics for NFV [etsi_gs_nfv_per_001], as stated in [RFC8172] (and replicated here):
如[RFC8172]所述，NFV[etsi_gs_NFV_per_001]的性能指标工作有明确的动机（并在此处复制）：
I'm designing and building my NFV Infrastructure platform. The first steps were easy because I had a small number of categories of VNFs to support and the VNF vendor gave HW recommendations that I followed. Now I need to deploy more VNFs from new vendors, and there are different hardware recommendations. How well will the new VNFs perform on my existing hardware? Which among several new VNFs in a given category are most efficient in terms of capacity they deliver? And, when I operate multiple categories of VNFs (and PNFs) *concurrently* on a hardware platform such that they
我正在设计和构建我的NFV基础设施平台。第一步很简单，因为我需要支持少量的VNF类别，并且VNF供应商给出了我遵循的硬件建议。现在我需要从新的供应商那里部署更多的VNF，并且有不同的硬件建议。新的VNF在我现有的硬件上的性能如何？在给定类别的几个新VNF中，哪一个在提供容量方面最有效？而且，当我在硬件平台上同时操作多类VNF（和PNF）*时
share resources, what are the new performance limits, and what are the software design choices I can make to optimize my chosen hardware platform? Conversely, what hardware platform upgrades should I pursue to increase the capacity of these concurrently operating VNFs?
共享资源，新的性能限制是什么，我可以选择哪些软件设计来优化我选择的硬件平台？相反，我应该进行哪些硬件平台升级以增加这些并发运行的VNF的容量？
Lately, there are also some efforts looking into VNF benchmarking. The selection of an NFV Infrastructure Point of Presence to host a VNF or allocation of resources (e.g., virtual CPUs, memory) needs to be done over virtualized (abstracted and simplified) resource views [vnf_benchmarking] [VNF-VBAAS].
最近，也有一些研究VNF基准的工作。选择NFV基础设施存在点来承载VNF或分配资源（例如，虚拟CPU、内存）需要在虚拟化（抽象和简化）资源视图上完成[VNF_基准测试][VNF-VBAAS]。
On top of diagnostic tools that enable an assessment of the QoS, predictive analyses are required to react before anomalies occur. Due to the SW characteristics of VNFs, a reliable diagnosis framework could potentially enable the prevention of issues by a proper diagnosis and then a reaction in terms of acting on the potentially impacted service (e.g., migration to a different compute node, scaling in/out, up/down, etc.).
除了能够评估QoS的诊断工具之外，还需要进行预测性分析，以便在异常发生之前作出反应。由于VNF的软件特性，可靠的诊断框架可能通过正确的诊断和对可能受影响的服务的反应（例如，迁移到不同的计算节点、放大/缩小、放大/缩小等）来预防问题。
Portability in NFV refers to the ability to run a given VNF on multiple NFVIs, that is, guaranteeing that the VNF would be able to perform its functions with a high and predictable performance given that a set of requirements on the NFVI resources is met. Therefore, portability is a key feature that, if fully enabled, would contribute to making the NFV environment achieve a better reliability than a traditional system. Implementing functionality in SW over "commodity" infrastructure should make it much easier to port/move functions from one place to another. However, this is not yet as ideal as it sounds, and there are aspects that are not fully tackled. The existence of different hypervisors, specific hardware dependencies (e.g., EPA related), or state-synchronization aspects are just some examples of troublemakers for portability purposes.
NFV中的可移植性是指在多个NFVI上运行给定VNF的能力，即，在满足NFVI资源的一组要求的情况下，保证VNF能够以高且可预测的性能执行其功能。因此，可移植性是一个关键特性，如果完全启用，将有助于使NFV环境实现比传统系统更好的可靠性。通过“商品”基础设施在软件中实现功能，应该可以更容易地将功能从一个地方移植/移动到另一个地方。然而，这还没有听起来那么理想，有些方面还没有完全解决。不同虚拟机监控程序的存在、特定的硬件依赖性（例如，与EPA相关的）或状态同步方面只是出于可移植性目的的一些麻烦制造者的例子。
The ETSI NFV ISG is doing work in relation to portability. [etsi_gs_nfv_per_001] provides a list of minimal features that the VM Descriptor and Compute Host Descriptor should contain for the appropriate deployment of VM images over an NFVI (i.e., a "telco data center"), in order to guarantee high and predictable performance of data-plane workloads while assuring their portability. In addition, [etsi_gs_nfv_per_001] provides a set of recommendations on the minimum requirements that hardware (HW) and hypervisor should have for a "telco data center" suitable for different workloads (data plane, control plane, etc.) present in VNFs. The purpose of
ETSI NFV ISG正在进行与便携性相关的工作。[etsi_gs_nfv_per_001]提供了虚拟机描述符和计算主机描述符应包含的最低功能列表，用于在NFVI（即“电信数据中心”）上适当部署虚拟机映像，以确保数据平面工作负载的高性能和可预测性，同时确保其可移植性。此外，[etsi_gs_nfv_per_001]提供了一套关于硬件（HW）和虚拟机监控程序应具备的最低要求的建议，该最低要求适用于VNFs中存在的不同工作负载（数据平面、控制平面等）。目的
[etsi_gs_nfv_per_001] is to provide the list of VM requirements that should be included in the VM Descriptor template, and the list of HW capabilities that should be included in the Compute Host Descriptor (CHD) to assure predictable high performance. ETSI NFV assumes that the MANO functions will make the mix & match. Therefore, there are still several research challenges to be addressed here.
[etsi_gs_nfv_per_001]将提供应包含在虚拟机描述符模板中的虚拟机需求列表，以及应包含在计算主机描述符（CHD）中的硬件功能列表，以确保可预测的高性能。ETSI NFV假设MANO功能将进行混合和匹配。因此，这里仍有一些研究挑战需要解决。
Virtualization is typically seen as a direct enabler of energy savings. Some of the enablers for this that are often mentioned [nfv_sota_research_challenges] are (i) the multiplexing gains achieved by centralizing functions in data centers reduce the overall energy consumed and (ii) the flexibility brought by network programmability enables to switch off infrastructure as needed in a much easier way. However, there is still a lot of room for improvement in terms of virtualization techniques to reduce the power consumption, such as enhanced-hypervisor technologies.
虚拟化通常被视为节能的直接促成因素。为此，经常提到的一些促成因素[nfv_sota_research_challenges]是：（i）通过将功能集中在数据中心实现的多路复用增益降低了总体能耗；（ii）网络可编程性带来的灵活性使我们能够更轻松地根据需要关闭基础设施。然而，在降低功耗的虚拟化技术方面，如增强的虚拟机监控程序技术，仍有很大的改进空间。
Some additional examples of research topics that could enable energy savings are [nfv_sota_research_challenges]:
可以节约能源的研究主题的其他一些例子是[nfv_sota_research_challenges]：
o Energy-aware scaling (e.g., reductions in CPU speeds and partially turning off some hardware components to meet a given energy consumption target.
o 能量感知扩展（例如，降低CPU速度并部分关闭某些硬件组件以满足给定的能耗目标）。
o Energy-aware function placement.
o 能量感知功能布局。
o Scheduling and chaining algorithms, for example, adapting the network topology and operating parameters to minimize the operation cost (e.g., tracking energy costs to identify the cheapest prices).
o 调度和链接算法，例如，调整网络拓扑和操作参数以最小化操作成本（例如，跟踪能源成本以确定最便宜的价格）。
Note that it is also important to analyze the trade-off between energy efficiency and network performance.
请注意，分析能源效率和网络性能之间的权衡也很重要。
The use of NFV and SDN technologies can help improve link usage. SDN has already shown that it can greatly increase average link utilization (e.g., Google example [google_sdn_wan]). NFV adds more complexity (e.g., due to service-function chaining / VNF forwarding graphs), which needs to be considered. Aspects like the ones described in [NFVRG-TOPO] (on NFV data center topology design) have to be looked at carefully as well.
NFV和SDN技术的使用有助于提高链路使用率。SDN已经表明，它可以大大提高平均链路利用率（例如，Google示例[Google_SDN_wan]）。NFV增加了更多的复杂性（例如，由于服务功能链/VNF转发图），这需要加以考虑。还必须仔细研究[NFVRG-TOPO]（关于NFV数据中心拓扑设计）中描述的方面。
Market fragmentation has resulted in a multitude of network operators each focused on different countries and regions. This makes it difficult to create infrastructure services spanning multiple countries, such as virtual connectivity or compute resources, as no single operator has a footprint everywhere. Cross-domain orchestration of services over multiple administrations or over multi-domain single administrations will allow end-to-end network and service elements to mix in multi-vendor, heterogeneous technology, and resource environments [multi-domain_5GEx].
市场分割导致众多网络运营商专注于不同的国家和地区。这使得创建跨多个国家的基础设施服务（如虚拟连接或计算资源）变得困难，因为没有一家运营商在任何地方都有足迹。跨多个管理或跨多域单管理的跨域服务编排将允许端到端网络和服务元素在多供应商、异构技术和资源环境中混合使用[multi-domain_5GEx]。
For the specific use case of 'Network as a Service', it becomes even more important to ensure that Cross Domain Orchestration also takes care of hierarchy of networks and their association, with respect to provisioning tunnels and overlays.
对于“网络即服务”的特定用例，更重要的是确保跨域编排还考虑到网络的层次结构及其与供应隧道和覆盖的关联。
Multi-domain orchestration is currently an active research topic, which is being tackled, among others, by ETSI NFV ISG and the 5GEx project <https://www.5gex.eu/> [MULTI-NMRG] [multi-domain_5GEx].
多域编排目前是一个活跃的研究课题，ETSI NFV ISG和5GEx项目正在解决这一问题<https://www.5gex.eu/>[MULTI-NMRG][MULTI-domain_5GEx]。
Another side of the multi-domain problem is the integration/ harmonization of different management domains. A key example comes from Multi-access Edge Computing, which, according to ETSI, comes with its own MANO system and would require integration if interconnected to a generic NFV system.
多领域问题的另一个方面是不同管理领域的集成/协调。一个关键的例子来自多接入边缘计算，根据ETSI的说法，它有自己的MANO系统，如果与通用NFV系统互连，则需要集成。
From the beginning of all 5G discussions in the research and industry fora, it has been agreed that 5G will have to address many more use cases than the preceding wireless generations, which first focused on voice services and then on voice and high-speed packet data services. In this case, 5G should be able to handle not only the same (or enhanced) voice and packet data services, but also emerging services like tactile Internet and the Internet of Things (IoT). These use cases take the requirements to opposite extremes, as some of them require ultra-low latency and higher-speed, whereas some others require ultra-low power consumption and high-delay tolerance.
从研究和行业论坛的所有5G讨论开始，人们就一致认为5G必须解决比前几代无线技术更多的使用案例，前几代无线技术首先关注语音服务，然后关注语音和高速分组数据服务。在这种情况下，5G应该不仅能够处理相同（或增强）的语音和分组数据服务，还能够处理触觉互联网和物联网（IoT）等新兴服务。这些用例将需求推向了相反的极端，因为其中一些用例需要超低延迟和更高的速度，而另一些用例则需要超低功耗和高延迟容忍度。
Because of these very extreme 5G use cases, it is envisioned that selective combinations of radio access networks and core network components will have to be combined into a given network slice to address the specific requirements of each use case.
由于这些非常极端的5G用例，可以预见，无线电接入网络和核心网络组件的选择性组合必须组合到给定的网络片中，以满足每个用例的特定需求。
For example, within the major IoT category, which is perhaps the most disrupting one, some autonomous IoT devices will have very low throughput, will have much longer sleep cycles (and therefore high
例如，在主要物联网类别（可能是最具破坏性的类别）中，一些自主物联网设备的吞吐量将非常低，睡眠周期将更长（因此较高）
latency), and a battery life time exceeding by a factor of thousands that of smartphones or some other devices that will have almost continuous control and data communications. Hence, it is envisioned that a customized network slice will have to be stitched together from virtual resources or sub-slices to meet these requirements.
延迟），电池使用时间超过智能手机或其他几乎可以连续控制和数据通信的设备的数千倍。因此，可以设想，定制的网络片必须从虚拟资源或子片缝合在一起，以满足这些需求。
The actual definition of a "network slice" from an IP infrastructure viewpoint is currently undergoing intense debate; see [COMS-PS], [NETSLICES], [SLICE-3GPP], and [ngmn_5G_whitepaper]. Network slicing is a key for introducing new actors in existing markets at a low cost -- by letting new players rent "blocks" of capacity, if the new business model enables performance that meets the application needs (e.g., broadcasting updates to many sensors with satellite broadcasting capabilities). However, more work needs to be done to define the basic architectural approach of how network slices will be defined and formed. For example, is it mostly a matter of defining the appropriate network models (e.g., YANG) to stitch the network slice from existing components? Or do end-to-end timing, synchronization, and other low-level requirements mean that more fundamental research has to be done?
从IP基础设施的角度来看，“网络片”的实际定义目前正在进行激烈的辩论；请参阅[COMS-PS]、[NetSlice]、[SLICE-3GPP]和[ngmn_5G_白皮书]。网络切片是以低成本在现有市场引入新参与者的关键——如果新的商业模式能够实现满足应用需求的性能（例如，向具有卫星广播功能的许多传感器广播更新），则允许新参与者租用“块”容量。然而，需要做更多的工作来定义如何定义和形成网络片的基本架构方法。例如，主要是定义适当的网络模型（如YANG）来缝合现有组件的网络切片吗？或者，端到端定时、同步和其他低级需求是否意味着必须进行更多的基础研究？
The widespread use/discussion/practice of system and network virtualization technologies has led to new business opportunities, enlarging the offer of IT resources with virtual network and computing resources, among others. As a consequence, the network ecosystem now differentiates between the owner of physical resources, the Infrastructure Provider (InP), and the intermediary that conforms and delivers network services to the final customers, the Virtual Network Operator (VNO).
系统和网络虚拟化技术的广泛使用/讨论/实践带来了新的商业机会，通过虚拟网络和计算资源等扩大了IT资源的供应。因此，网络生态系统现在区分了物理资源所有者、基础设施提供商（InP）和整合并向最终客户提供网络服务的中介机构——虚拟网络运营商（VNO）。
VNOs aim to exploit the virtualized infrastructures to deliver new-and-improved services to their customers. However, current network virtualization techniques offer poor support for VNOs to control their resources. It has been considered that the InP is responsible for the reliability of the virtual resources, but there are several situations in which a VNO requires a finer control on its resources. For instance, dynamic events, such as the identification of new requirements or the detection of incidents within the virtual system, might urge a VNO to quickly reform its virtual infrastructure and resource allocation. However, the interfaces offered by current virtualization platforms do not offer the necessary functions for VNOs to perform the elastic adaptations they need to conduct in dynamic environments.
VNO的目标是利用虚拟化基础设施，为客户提供新的和改进的服务。然而，当前的网络虚拟化技术对VNO控制其资源的支持较差。有人认为InP负责虚拟资源的可靠性，但有几种情况下，VNO需要对其资源进行更精细的控制。例如，动态事件，如识别新需求或检测虚拟系统内的事件，可能会促使VNO快速改革其虚拟基础设施和资源分配。但是，当前虚拟化平台提供的接口不提供VNO在动态环境中执行弹性调整所需的必要功能。
Beyond their heterogeneity, which can be resolved by software adapters, current virtualization platforms do not have common methods and functions, so it is difficult for the virtual network controllers used by the VNOs to actually manage and control virtual resources instantiated on different platforms, not even considering different InPs. Therefore, it is necessary to reach a common definition of the functions that should be offered by underlying platforms to give such overlay controllers the possibility to allocate and deallocate resources dynamically and get monitoring data about them.
除了可以通过软件适配器解决的异构性之外，当前的虚拟化平台没有通用的方法和功能，因此VNO使用的虚拟网络控制器很难实际管理和控制在不同平台上实例化的虚拟资源，甚至不考虑不同的INP。因此，有必要对底层平台应提供的功能达成一个通用定义，以使这些覆盖控制器能够动态分配和释放资源，并获取有关资源的监控数据。
Such common methods should be offered by all underlying controllers, regardless of being network-oriented (e.g., ODL, ONOS, and Ryu) or computing-oriented (e.g., OpenStack, OpenNebula, and Eucalyptus). Furthermore, it is important for those platforms to offer some "PUSH" function to report resource state, avoiding the need for the VNO's controller to "POLL" for such data. A starting point to get proper notifications within current REST APIs could be to consider the protocol proposed by the WEBPUSH WG [RFC8030].
无论是面向网络的（如ODL、ONOS和Ryu）还是面向计算的（如OpenStack、OpenNebula和Eucalyptus），所有底层控制器都应提供此类通用方法。此外，重要的是，这些平台提供一些“推送”功能来报告资源状态，从而避免VNO的控制器对此类数据进行“轮询”。在当前REST API中获取适当通知的起点可以考虑WebPress WG[RCF8030]提出的协议。
Finally, in order to establish a proper order and allow the coexistence and collaboration of different systems, a common ontology regarding network and system virtualization should be defined and agreed upon, so different and heterogeneous systems can understand each other without requiring reliance on specific adaptation mechanisms that might break with any update on any side of the relation.
最后，为了建立适当的秩序并允许不同系统共存和协作，应定义并商定关于网络和系统虚拟化的通用本体，因此，不同的异构系统可以相互理解，而不需要依赖于特定的适应机制，这种机制可能会随着关系任何方面的更新而中断。
The Internet of Things (IoT) refers to the vision of connecting a multitude of automated devices (e.g., lights, environmental sensors, traffic lights, parking meters, health and security systems, etc.) to the Internet for purposes of reporting and remote command and control of the device. This vision is being realized by a multi-pronged approach of standardization in various forums and complementary open-source activities. For example, in the IETF, support of IoT web services has been defined by an HTTP-like protocol adapted for IoT called "CoAP" [RFC7252]; and, lately, a group has been studying the need to develop a new network layer to support IP applications over Low-Power Wide Area Networks (LPWAN).
物联网（IoT）是指将大量自动化设备（例如，灯、环境传感器、交通灯、停车收费表、健康和安全系统等）连接到互联网，以便报告和远程指挥和控制设备。这一愿景是通过在各种论坛和补充性开源活动中采用多管齐下的标准化方法来实现的。例如，在IETF中，IoT web服务的支持已由一个适用于IoT的类似HTTP的协议定义，该协议称为“CoAP”[RFC7252]；最近，一个小组一直在研究开发新的网络层以支持低功耗广域网（LPWAN）上的IP应用的必要性。
Elsewhere, for 5G cellular evolution, there is much discussion on the need for supporting virtual network slices for the expected massive numbers of IoT devices. A separate virtual network slice is considered necessary for different 5G IoT use cases because devices will have very different characteristics than typical cellular
在其他地方，对于5G蜂窝演进，有很多关于支持虚拟网络片以满足预期的大量物联网设备需求的讨论。对于不同的5G物联网使用情况，单独的虚拟网络片被认为是必要的，因为设备将具有与典型蜂窝网络非常不同的特性
devices like smartphones [ngmn_5G_whitepaper], and the number of IoT devices is expected to be at least one or two orders of magnitude higher than other 5G devices (see Section 4.5).
智能手机等设备[ngmn_5G_白皮书]，物联网设备的数量预计至少比其他5G设备高一到两个数量级（见第4.5节）。
The specific nature of the IoT ecosystem, particularly reflected in the Machine-to-Machine (M2M) communications, leads to the creation of new and highly distributed systems which demand location-based network and computing services. A specific example can be represented by a set of "things" that suddenly require the setup of a firewall to allow external entities to access their data while outsourcing some computation requirements to more powerful systems relying on cloud-based services. This representative use case exposes important requirements for both NFV and the underlying cloud infrastructures.
物联网生态系统的特殊性质，特别是反映在机器对机器（M2M）通信中，导致创建了新的高度分布式系统，需要基于位置的网络和计算服务。一个具体的例子可以用一组“东西”来表示，这些东西突然需要设置防火墙，以允许外部实体访问其数据，同时将一些计算需求外包给依赖于云服务的更强大的系统。这个具有代表性的用例揭示了NFV和底层云基础设施的重要需求。
In order to provide the aforementioned location-based functions integrated with highly distributed systems, the so-called fog infrastructures should be able to instantiate VNFs, placing them in the required place, e.g., close to their consumers. This requirement implies that the interfaces offered by virtualization platforms must support the specification of location-based resources, which is a key function in those scenarios. Moreover, those platforms must also be able to interpret and understand the references used by IoT systems to their location (e.g., "My-AP" or "5BLDG+2F") and also the specification of identifiers linked to other resources, such as the case of requiring the infrastructure to establish a link between a specific Access Point (AP) and a specific virtual computing node. In summary, the research gap is exact localization of VNFs at far network edge infrastructure, which is highly distributed and dynamic.
为了提供上述与高度分布式系统集成的基于位置的功能，所谓的fog基础设施应能够实例化VNF，将其放置在所需的位置，例如，靠近其消费者。这一要求意味着虚拟化平台提供的接口必须支持基于位置的资源规范，这是这些场景中的关键功能。此外，这些平台还必须能够解释和理解物联网系统对其位置的引用（例如，“我的AP”或“5BLDG+2F”），以及链接到其他资源的标识符规范，例如要求基础设施在特定接入点（AP）之间建立链接的情况以及特定的虚拟计算节点。综上所述，研究缺口在于VNF在高度分布式和动态的远端网络边缘基础设施上的精确定位。
Current network services deployed by operators often involve the composition of several individual functions (such as packet filtering, deep-packet inspection, load-balancing). These services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within a network, not necessarily on the direct data path. This requires traffic to be steered through the required service functions, wherever they are deployed [RFC7498].
运营商部署的当前网络服务通常涉及几个单独功能的组合（例如包过滤、深度包检查、负载平衡）。这些服务通常由部署在网络内不同点（不一定在直接数据路径上）的多个服务功能的有序组合来实现。这需要通过所需的服务功能控制流量，无论这些功能部署在何处[RFC7498]。
For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called "Service Function Chaining" (SFC) [sfc_challenges], which is called "Network Function Forwarding Graph" (NF-FG) in ETSI. SFC is instantiated through the selection of specific service function instances on specific network nodes to form a service graph: this is
对于给定的服务，所需服务功能及其应用顺序的抽象视图称为“服务功能链接”（SFC）[SFC_挑战]，在ETSI中称为“网络功能转发图”（NF-FG）。通过选择特定网络节点上的特定服务功能实例来实例化SFC，以形成服务图：这是
called a "Service Function Path" (SFP). The service functions may be applied at any layer within the network protocol stack (network layer, transport layer, application layer, etc.).
称为“服务功能路径”（SFP）。服务功能可应用于网络协议栈内的任何层（网络层、传输层、应用层等）。
Service composition is a powerful means that can provide significant benefits when applied in a softwarized network environment. However, there are many research challenges in this area; for example, the ones related to composition mechanisms and algorithms to enable load-balancing and improve reliability. The service composition should also act as an enabler to gather information across all hierarchies (underlays and overlays) of network deployments that may span across multiple operators for faster serviceability, thus facilitating accomplishing aforementioned goals of "load-balancing and improving reliability".
当应用于软件化网络环境时，服务组合是一种强大的手段，可以提供显著的好处。然而，在这一领域存在许多研究挑战；例如，与组合机制和算法相关的机制和算法可以实现负载平衡并提高可靠性。服务组合还应起到使能器的作用，以便跨网络部署的所有层次结构（底层和覆盖层）收集信息，这些网络部署可能跨越多个运营商，以实现更快的可维护性，从而促进实现上述“负载平衡和提高可靠性”的目标。
As described in [dynamic_chaining], different algorithms can be used to enable dynamic service composition that optimizes a QoS-based utility function (e.g., minimizing the latency per-application traffic flows) for a given composition plan. Such algorithms can consider the computation capabilities and load status of resources executing the VNF instances, either deduced through estimations from historical usage data or collected through real-time monitoring (i.e., context-aware selection). For this reason, selections should include references to dynamic information on the status of the service instance and its constituent elements, i.e., monitoring information related to individual VNF instances and links connecting them as well as derived monitoring information at the chain level (e.g., end-to-end delay). At runtime, if one or more VNF instances are no longer available or QoS degrades below a given threshold, the service selection task can be rerun to perform service substitution.
如[dynamic_chaining]中所述，可以使用不同的算法来实现动态服务组合，从而优化给定组合计划的基于QoS的效用函数（例如，最小化每个应用程序的延迟流量）。这样的算法可以考虑执行VNF实例的资源的计算能力和负载状态，或者通过历史使用数据的估计或通过实时监控（即上下文感知选择）来收集。因此，选择应包括对服务实例及其组成元素状态的动态信息的引用，即与单个VNF实例和连接它们的链接相关的监控信息，以及链级别的派生监控信息（例如，端到端延迟）。在运行时，如果一个或多个VNF实例不再可用或QoS降低到给定阈值以下，则可以重新运行服务选择任务以执行服务替换。
There are different research directions that relate to the previous point. For example, the use of Integer Linear Programming (ILP) techniques can be explored to optimize the management of diverse traffic flows. Deep-machine learning can also be applied to optimize service chains using information parameters, such as some of the ones mentioned above. Newer scheduling paradigms, like co-flows, can also be used.
与前一点相关的研究方向各不相同。例如，可以探索使用整数线性规划（ILP）技术来优化各种交通流的管理。深度机器学习还可以应用于使用信息参数优化服务链，例如上面提到的一些参数。也可以使用较新的调度范例，如co-flows。
The SFC working group is working on an architecture for SFC [RFC7665] that includes the necessary protocols or protocol extensions to convey the SFC and SFP information to nodes that are involved in the implementation of service functions and SFCs as well as mechanisms for steering traffic through service functions.
SFC工作组正在研究SFC[RFC7665]的体系结构，该体系结构包括必要的协议或协议扩展，以将SFC和SFP信息传递给参与服务功能和SFC实现的节点，以及通过服务功能控制流量的机制。
In terms of actual work items, the SFC WG has not yet considered working on the management and configuration of SFC components related to the support of SFC. This part is of special interest for
就实际工作项目而言，证监会工作小组尚未考虑就与支持证监会有关的证监会组成部分的管理和配置开展工作。这一部分对我们特别有意义
operators and would be required in order to actually put SFC mechanisms into operation. Similarly, redundancy and reliability mechanisms for SFC are currently not dealt with by any WG in the IETF. While this was the main goal of the VNFpool BoF efforts, it still remains unaddressed.
为了使证监会的机制真正运作起来，运营商和监管机构将被要求。同样，IETF中的任何工作组目前都没有处理SFC的冗余和可靠性机制。虽然这是VNFOOL转炉工作的主要目标，但仍未解决。
So far, most of the network softwarization efforts have focused on virtualizing functions of network elements. While virtualization of network elements started with the core, mobile-network architectures are now heavily switching to also virtualize Radio Access Network (RAN) functions. The next natural step is to get virtualization down at the level of the end-user device (e.g., virtualizing a smartphone) [virtualization_mobile_device]. The cloning of a device in the cloud (central or local) bears attractive benefits to both the device and network operations alike (e.g., power saving at the device by offloading computational-heaving functions to the cloud, optimized networking -- both device-to-device and device-to-infrastructure) for service delivery through tighter integration of the device (via its clone in the networking infrastructure). This is, for example, being explored by the European H2020 ICIRRUS project <https://www.icirrus-5gnet.eu>.
到目前为止，大多数网络软件化工作都集中在网元功能的虚拟化上。虽然网络元素的虚拟化从核心开始，但移动网络体系结构现在正大量转向虚拟化无线接入网（RAN）功能。下一个自然步骤是在最终用户设备（例如，虚拟化智能手机）[虚拟化\移动\设备]级别上实现虚拟化。在云中克隆设备（中央或本地）对设备和网络运营都具有诱人的好处（例如，通过将计算提升功能卸载到云中，在设备上节省电力，优化网络——设备到设备和设备到基础设施）通过更紧密地集成设备（通过网络基础设施中的克隆）来提供服务。例如，欧洲H2020 ICIRUS项目正在对此进行探索<https://www.icirrus-5gnet.eu>.
Similar to any other situations where resources are shared, security and privacy are two important aspects that need to be taken into account.
与共享资源的任何其他情况类似，安全和隐私是需要考虑的两个重要方面。
In the case of security, there are situations where multiple service providers will need to coexist in a virtual or hybrid physical/ virtual environment. This requires attestation procedures amongst different virtual/physical functions and resources as well as ongoing external monitoring. Similarly, different network slices operating on the same infrastructure can present security problems, for instance, if one slice running critical applications (e.g., support for a safety system) is affected by another slice running a less critical application. In general, the minimum common denominator for security measures on a shared system should be equal to or higher than the one required by the most-critical application. Multiple and continuous threat model analysis as well as a DevOps model are required to maintain a certain level of security in an NFV system. Simplistically, DevOps is a process that combines multiple functions into single cohesive teams in order to quickly produce quality software. Typically, it relies on also applying the Agile development process, which focuses on (among many things) dividing large features into multiple, smaller deliveries. One part of this
就安全性而言，在某些情况下，多个服务提供商需要在虚拟或混合物理/虚拟环境中共存。这需要不同虚拟/物理功能和资源之间的认证程序，以及持续的外部监控。类似地，在同一基础设施上运行的不同网络片可能会出现安全问题，例如，如果运行关键应用程序的一个片（例如，对安全系统的支持）受到运行不太关键应用程序的另一个片的影响。通常，共享系统上安全措施的最小公分母应等于或高于最关键应用程序所需的公分母。为了在NFV系统中保持一定程度的安全性，需要进行多个和连续的威胁模型分析以及DevOps模型。简单地说，DevOps是一个过程，它将多个功能组合到一个有凝聚力的团队中，以便快速生成高质量的软件。通常，它还依赖于应用敏捷开发过程，该过程关注（在许多事情中）将大型功能划分为多个小型交付。其中一部分
is to immediately test the new smaller features in order to get immediate feedback on errors so that if present, they can be immediately fixed and redeployed.
就是立即测试新的较小的功能，以便获得错误的即时反馈，这样，如果出现错误，就可以立即修复和重新部署。
On the other hand, privacy refers to concerns about the control of personal data and the decision of what to reveal to whom. In this case, the storage, transmission, collection, and potential correlation of information in the NFV system, for purposes not originally intended or not known by the user, should be avoided. This is particularly challenging, as future intentions and threats cannot be easily predicted and still can be applied on data collected in the past. Therefore, well-known techniques, such as data minimization using privacy features as default and allowing users to opt in/out, should be used to prevent potential privacy issues.
另一方面，隐私指的是对个人数据控制和向谁披露内容的决定的关注。在这种情况下，应避免NFV系统中信息的存储、传输、收集和潜在关联，以达到用户最初不打算或不知道的目的。这尤其具有挑战性，因为未来的意图和威胁无法轻易预测，而且仍然可以应用于过去收集的数据。因此，应该使用众所周知的技术，例如使用隐私功能作为默认值的数据最小化，以及允许用户选择加入/退出，以防止潜在的隐私问题。
Compared to traditional networks, NFV will result in networks that are much more dynamic (in function distribution and topology) and elastic (in size and boundaries). Thus, NFV will require network operators to evolve their operational and administrative security solutions to work in this new environment. For example, in NFV, the network orchestrator will become a key node to provide security policy orchestration across the different physical and virtual components of the virtualized network. For highly confidential data, for example, the network orchestrator should take into account if certain physical HW of the network is considered to be more secure (e.g., because it is located in secure premises) than other HW.
与传统网络相比，NFV将导致网络更加动态（功能分布和拓扑）和弹性（大小和边界）。因此，NFV将要求网络运营商改进其运营和管理安全解决方案，以适应这种新环境。例如，在NFV中，网络编排器将成为关键节点，以跨虚拟化网络的不同物理和虚拟组件提供安全策略编排。例如，对于高度机密的数据，如果认为网络的某些物理硬件比其他硬件更安全（例如，因为它位于安全的前提下），则网络编排器应考虑。
Traditional telecom networks typically run under a single administrative domain controlled by (exactly) one operator. With NFV, it is expected that in many cases, the telecom operator will now become a tenant (running the VNFs), and the infrastructure (NFVI) may be run by a different operator and/or cloud service provider (see also Section 4.4). Thus, there will be multiple administrative domains involved, making security policy coordination more complex. For example, who will be in charge of provisioning and maintaining security credentials such as public and private keys? Also, should private keys be allowed to be replicated across the NFV for redundancy reasons? Alternatively, it can be investigated how to develop a mechanism that avoids such a security policy coordination, thus making the system more robust.
传统的电信网络通常在一个由（恰好）一个运营商控制的单一管理域下运行。对于NFV，预计在许多情况下，电信运营商现在将成为租户（运行VNFs），基础设施（NFVI）可能由不同的运营商和/或云服务提供商运行（另见第4.4节）。因此，将涉及多个管理域，使得安全策略协调更加复杂。例如，谁将负责提供和维护安全凭据（如公钥和私钥）？此外，出于冗余原因，是否应允许在NFV上复制私钥？或者，可以研究如何开发一种机制来避免这种安全策略协调，从而使系统更加健壮。
On a positive note, NFV may better defend against denial-of-service (DoS) attacks because of the distributed nature of the network (i.e., no single point of failure) and the ability to steer (undesirable) traffic quickly [etsi_gs_nfv_sec_001]. Also, NFVs that have physical HW that is distributed across multiple data centers will also provide
从积极的方面来看，NFV可以更好地抵御拒绝服务（DoS）攻击，因为网络的分布式特性（即无单点故障）和快速引导（不需要的）流量的能力[etsi_gs_NFV_sec_001]。此外，具有分布在多个数据中心的物理硬件的NFV也将提供
better fault isolation environments. Particularly, this holds true if each data center is protected separately via firewalls, Demilitarized Zones (DMZs), and other network-protection techniques.
更好的故障隔离环境。特别是，如果每个数据中心都通过防火墙、非军事区（DMZ）和其他网络保护技术进行单独保护，则这一点是正确的。
SDN can also be used to help improve security by facilitating the operation of existing protocols, such as Authentication, Authorization and Accounting (AAA). The management of AAA infrastructures, namely the management of AAA routing and the establishment of security associations between AAA entities, can be performed using SDN, as analyzed in [SDN-AAA].
SDN还可以通过促进现有协议（如身份验证、授权和记帐（AAA））的操作来帮助提高安全性。AAA基础设施的管理，即AAA路由的管理和AAA实体之间安全关联的建立，可以使用SDN执行，如[SDN-AAA]中所分析。
NFV environments offer two possible levels of SDN control. One level is the need for controlling the NFVI to provide connectivity end-to-end among VNFs or among VNFs and Physical Network Functions (PNFs). A second level is the control and configuration of the VNFs themselves (in other words, the configuration of the network service implemented by those VNFs), taking advantage of the programmability brought by SDN. Both control concerns are separated in nature. However, interaction between both could be expected in order to optimize, scale, or influence each other.
NFV环境提供两种可能的SDN控制级别。一个层次是需要控制NFVI，以提供VNF之间或VNF与物理网络功能（PNF）之间的端到端连接。第二个层次是VNF本身的控制和配置（换句话说，这些VNF实现的网络服务的配置），利用SDN带来的可编程性。两个控制关注点本质上是分离的。然而，可以预期两者之间的相互作用，以优化、扩大或影响彼此。
Clear mechanisms for such interactions are needed in order to avoid malfunctioning or interference concerns. These ideas are considered in [etsi_gs_nfv_eve005] and [LAYERED-SDN].
为了避免出现故障或干扰问题，需要明确的交互机制。[etsi_gs_nfv_eve005]和[LAYERED-SDN]中考虑了这些想法。
Network function placement is a problem in any kind of network telecommunications infrastructure. Moreover, the increased degree of freedom added by network virtualization makes this problem even more important, and also harder to tackle. Deciding where to place VNFs is a resource-allocation problem that needs to (or may) take into consideration quite a few aspects: resiliency, (anti-)affinity, security, privacy, energy efficiency, etc.
在任何类型的网络电信基础设施中，网络功能布局都是一个问题。此外，网络虚拟化增加的自由度使得这个问题更加重要，也更加难以解决。决定在何处放置VNF是一个资源分配问题，需要（或可能）考虑很多方面：弹性、（反）亲和力、安全性、隐私、能源效率等。
When several functions are chained (typical scenario), placement algorithms become more complex and important (as described in Section 4.6). While there has been research on the topic ([nfv_piecing], [dynamic_placement], and [vnf-p]), this still remains an open challenge that requires more attention. The use of multi-domains adds another component of complexity to this problem that has to be considered.
当多个功能链接（典型场景）时，布局算法变得更加复杂和重要（如第4.6节所述）。虽然已经有关于这个主题的研究（[nfv_拼图]、[dynamic_placement]和[vnf-p]），但这仍然是一个需要更多关注的开放挑战。多域的使用为这个问题增加了另一个必须考虑的复杂因素。
The impacts of network virtualization on testing can be divided into three groups:
网络虚拟化对测试的影响可分为三类：
1. Changes in methodology
1. 方法的变化
2. New functionality
2. 新功能
3. Opportunities
3. 机会
The largest impact of NFV is the ability to isolate the System Under Test (SUT). When testing PNFs, isolating the SUT means that all the other devices that the SUT communicates with are replaced with simulations (or controlled executions) in order to place the SUT under test by itself. The SUT may be comprised of one or more devices. The simulations use the appropriate traffic type and protocols in order to execute test cases.
NFV的最大影响是隔离被测系统（SUT）的能力。在测试PNF时，隔离SUT意味着SUT与之通信的所有其他设备都将被模拟（或受控执行）所取代，以便将SUT单独置于测试之下。SUT可以由一个或多个设备组成。模拟使用适当的通信量类型和协议来执行测试用例。
As shown in Figure 2, NFV provides a common architecture for all functions to use. A VNF is executed using resources offered by the NFVI, which have been allocated using the MANO function. It is not possible to test a VNF by itself, without the entire supporting environment present. This fundamentally changes how to consider the SUT. In the case of a VNF (or multiple VNFs), the SUT is part of a larger architecture that is necessary in order to run the SUTs.
如图2所示，NFV为所有要使用的功能提供了一个通用的体系结构。VNF是使用NFVI提供的资源执行的，这些资源是使用MANO函数分配的。如果没有整个支持环境，就不可能单独测试VNF。这从根本上改变了如何考虑SUT。对于VNF（或多个VNF），SUT是运行SUT所需的更大体系结构的一部分。
Therefore, isolation of the SUT becomes controlling the environment in a disciplined manner. The components of the environment necessary to run the SUTs that are not part of the SUT itself become the test environment. In the case of VNFs that are part of the SUT, the NFVI and MANO become the test environment. The configurations and policies that guide the test environment should remain constant during the execution of the tests, and also from test to test. Configurations such as CPU pinning, NUMA configuration, the SW versions and configurations of the hypervisor, vSwitch and NICs should remain constant. The only variables in the testing should be those controlling the SUT itself. If any configuration in the test environment is changed from test to test, the results become very difficult, if not impossible, to compare since the test environment behavior may change the results as a consequence of the configuration change.
因此，SUT的隔离成为以一种有纪律的方式控制环境。运行SUT所需的环境组件（不属于SUT本身）将成为测试环境。对于作为SUT一部分的VNF，NFVI和MANO将成为测试环境。指导测试环境的配置和策略应该在测试执行期间保持不变，也应该在测试之间保持不变。CPU固定、NUMA配置、虚拟机监控程序、vSwitch和NIC的软件版本和配置等配置应保持不变。测试中唯一的变量应该是那些控制SUT本身的变量。如果测试环境中的任何配置从一个测试更改到另一个测试，结果将变得非常难以比较（如果不是不可能的话），因为测试环境行为可能会由于配置更改而更改结果。
Testing the NFVI itself also presents new considerations. With a PNF, the dedicated hardware supporting it is optimized for the particular workload of the function. Routing hardware is specially
测试NFVI本身也提出了新的考虑因素。有了PNF，支持它的专用硬件针对功能的特定工作负载进行了优化。路由硬件是专门设计的
built to support packet forwarding functions, while the hardware to support a purely control-plane application (say, a DNS server, or a Diameter function) will not have this specialized capability. In NFV, the NFVI is required to support all types of potentially different workload types.
构建用于支持数据包转发功能，而用于支持纯控制平面应用程序（例如，DNS服务器或Diameter功能）的硬件将不具备这种专门功能。在NFV中，NFVI需要支持所有类型的可能不同的工作负载类型。
Therefore, testing the NFVI requires careful consideration about what types of metrics are sought. This, in turn, depends on the workload type the expected VNF will be. Examples of different workload types are data forwarding, control plane, encryption, and authentication. All these types of expected workloads will determine the types of metrics that should be sought. For example, if the workload is control plane, then a metric such as jitter is not useful, but dropped packets are critical. In a multi-tenant environment, the NFVI could support various types of workloads. In this case, testing with a variety of traffic types while measuring the corresponding metrics simultaneously becomes necessary.
因此，测试NFVI需要仔细考虑所寻求的指标类型。这又取决于预期VNF的工作负载类型。不同工作负载类型的示例包括数据转发、控制平面、加密和身份验证。所有这些类型的预期工作负载将决定应该寻求的度量的类型。例如，如果工作负载是控制平面，那么抖动之类的度量是无用的，但丢弃的数据包是关键的。在多租户环境中，NFVI可以支持各种类型的工作负载。在这种情况下，有必要在同时测量相应度量的同时对各种流量类型进行测试。
Test beds for any type of testing for an NFV-based system will be largely similar to previously used test architectures. The methods are impacted by virtualization, as described above, but the design of test beds are similar as in the past. There are two main new considerations:
基于NFV系统的任何类型测试的测试台都将与以前使用的测试架构非常相似。如上所述，这些方法受到虚拟化的影响，但测试台的设计与过去类似。有两个主要的新考虑：
o Since networking is based on software, which has lead to greater automation in deployment, the test system should also be deployable with the rest of the system in order to fully automate the system. This is especially relevant in a DevOps environment supported by a Continuous Integration and Continuous Deployment (CI/CD) tool chain (see Section 4.11.3 below).
o 由于网络是基于软件的，这使得部署更加自动化，因此测试系统也应该可以与系统的其余部分一起部署，以便完全自动化系统。在由持续集成和持续部署（CI/CD）工具链支持的DevOps环境中，这一点尤其重要（参见下面的第4.11.3节）。
o In any performance test bed, the test system should not share the same resources as the SUT. While multi-tenancy is a reality in virtualization, having the test system share resources with the SUT will impact the measured results in a performance test bed. The test system should be deployed on a separate platform in order not to impact the resources available to the SUT.
o 在任何性能测试台中，测试系统都不应与SUT共享相同的资源。虽然多租户在虚拟化中是一种现实，但让测试系统与SUT共享资源将影响性能测试床中的测量结果。测试系统应部署在单独的平台上，以免影响SUT可用的资源。
NFV presents a collection of new functionality in order to support the goal of software networking. Each component on the architecture shown in Figure 2 has an associated set of functionality that allows VNFs to run the following: onboarding, life-cycle management for VNFs and Network Services (NS), resource allocation, hypervisor functions, etc.
NFV提供了一系列新功能，以支持软件联网的目标。图2所示的体系结构上的每个组件都有一组相关的功能，允许VNFs运行以下各项：VNFs和网络服务（NS）的安装、生命周期管理、资源分配、虚拟机监控程序功能等。
One of the new capabilities enabled by NFV is VNF Forwarding Graphs (VNFFG). This refers to the graph that represents a network service by chaining together VNFs into a forwarding path. In practice, the forwarding path can be implemented in a variety of ways using different networking capabilities: vSwitch, SDN, and SDN with a northbound application. Additionally, the VNFFG might use tunneling protocols like Virtual eXtensible Local Area Network (VXLAN). The dynamic allocation and implementation of these networking paths will have different performance characteristics depending on the methods used. The path implementation mechanism becomes a variable in the network testing of the NSs. The methodology used to test the various mechanisms should largely remain the same; as usual, the test environment should remain constant for each of the tests, focusing on varying the path establishment method.
NFV启用的新功能之一是VNF转发图（VNFFG）。这是指通过将VNF链接到转发路径中来表示网络服务的图形。实际上，可以使用不同的网络功能以多种方式实现转发路径：vSwitch、SDN和带有北向应用程序的SDN。此外，VNFFG可能使用隧道协议，如虚拟可扩展局域网（VXLAN）。根据所使用的方法，这些网络路径的动态分配和实现将具有不同的性能特征。路径实现机制成为NSs网络测试中的一个变量。用于测试各种机制的方法应基本保持不变；通常，每个测试的测试环境都应该保持不变，重点是改变路径建立方法。
"Scaling" refers to the change in allocation of resources to a VNF or NS. It happens dynamically at run-time, based on defined policies and triggers. The triggers can be network, compute, or storage based. Scaling can allocate more resources in times of need, or reduce the amount of resources allocated when the demand is reduced. The SUT in this case becomes much larger than the VNF itself: MANO controls how scaling is done based on policies, and then allocates the resources accordingly in the NFVI. Essentially, the testing of scaling includes the entire NFV architecture components into the SUT.
“扩展”是指资源分配到VNF或NS的变化。它在运行时根据定义的策略和触发器动态发生。触发器可以是基于网络、计算或存储的。扩展可以在需要时分配更多的资源，或者在需求减少时减少分配的资源量。在这种情况下，SUT变得比VNF本身大得多：MANO控制如何根据策略进行扩展，然后在NFVI中相应地分配资源。从本质上讲，扩展测试将整个NFV体系结构组件包括在SUT中。
Softwarization of networking functionality leads to softwarization of the test as well. As PNFs are being transformed into VNFs, so are the test tools. This leads to the fact that test tools are also being controlled and executed in the same environment as the VNFs. This presents an opportunity to include VNF-based test tools along with the deployment of the VNFs supporting the services of the service provider into the host data centers. Therefore, tests can be automatically executed upon deployment in the target environment, for each deployment, and each service. With PNFs, this was very difficult to achieve.
网络功能的软件化也会导致测试的软件化。当PNF被转换成VNF时，测试工具也是如此。这导致测试工具也在与VNF相同的环境中被控制和执行。这提供了将基于VNF的测试工具与支持服务提供商服务的VNF部署到主机数据中心的机会。因此，在目标环境中部署时，可以为每个部署和每个服务自动执行测试。有了PNFs，这是很难实现的。
This new concept helps to enable modern concepts like DevOps and Continuous Integration and Continuous Deployment in the NFV environment. The CI/CD pipeline supports this concept. It consists of a series of tools, among which immediate testing is an integral part, to deliver software from source to deployment. The ability to deploy the test tools themselves into the production environment stretches the CI/CD pipeline all the way to production deployment, allowing a range of tests to be executed. The tests can be simple,
这一新概念有助于实现DevOps等现代概念以及NFV环境中的持续集成和持续部署。CI/CD管道支持这一概念。它由一系列工具组成，其中即时测试是不可或缺的一部分，用于将软件从源代码交付到部署。将测试工具本身部署到生产环境的能力将CI/CD管道一直延伸到生产部署，从而允许执行一系列测试。测试可以很简单，
with a goal of verifying the correct deployment and networking establishment, but can also be more complex, like testing VNF functionality.
其目标是验证正确的部署和网络建立，但也可能更复杂，如测试VNF功能。
Table 1 correlates the open network virtualization research areas identified in this document to potential IETF and IRTF groups that could address some aspects of them. An example of a specific gap that the group could potentially address is identified as a parenthetical beside the group name.
表1将本文件中确定的开放网络虚拟化研究领域与潜在的IETF和IRTF小组相关联，这些小组可以解决这些领域的某些方面。组可能解决的特定间隙的一个示例被标识为组名旁边的括号。
+-------------------------+-----------------------------------------+
| Open Research Area | Potential IETF/IRTF Group |
+-------------------------+-----------------------------------------+
| 1) Guaranteeing QoS | IPPM WG (Measurements of NFVI) |
| | |
| 2) Performance | SFC WG, NFVRG (energy-driven |
| improvement | orchestration) |
| | |
| 3) Multiple Domains | NFVRG (multi-domain orchestration) |
| | |
| 4) Network Slicing | NVO3 WG, NETSLICES bar BoF (multi- |
| | tenancy support) |
| | |
| 5) Service Composition | SFC WG (SFC Mgmt and Config) |
| | |
| 6) End-user device | N/A |
| virtualization | |
| | |
| 7) Security | N/A |
| | |
| 8) Separation of | NFVRG (separation between transport |
| control concerns | control and services) |
| | |
| 9) Testing | NFVRG (testing of scaling) |
| | |
| 10) Function placement | NFVRG, SFC WG (VNF placement algorithms |
| | and protocols) |
+-------------------------+-----------------------------------------+
+-------------------------+-----------------------------------------+
| Open Research Area | Potential IETF/IRTF Group |
+-------------------------+-----------------------------------------+
| 1) Guaranteeing QoS | IPPM WG (Measurements of NFVI) |
| | |
| 2) Performance | SFC WG, NFVRG (energy-driven |
| improvement | orchestration) |
| | |
| 3) Multiple Domains | NFVRG (multi-domain orchestration) |
| | |
| 4) Network Slicing | NVO3 WG, NETSLICES bar BoF (multi- |
| | tenancy support) |
| | |
| 5) Service Composition | SFC WG (SFC Mgmt and Config) |
| | |
| 6) End-user device | N/A |
| virtualization | |
| | |
| 7) Security | N/A |
| | |
| 8) Separation of | NFVRG (separation between transport |
| control concerns | control and services) |
| | |
| 9) Testing | NFVRG (testing of scaling) |
| | |
| 10) Function placement | NFVRG, SFC WG (VNF placement algorithms |
| | and protocols) |
+-------------------------+-----------------------------------------+
Table 1: Mapping of Open Research Areas to Potential IETF Groups
表1：开放研究领域到潜在IETF群体的映射
Table 2 correlates the currently identified NFVRG topics of interest / focus areas to the open network virtualization research areas enumerated in this document. This can help the NFVRG in identifying and prioritizing research topics. The current list of NFVRG focus points is the following:
表2将当前确定的NFVRG感兴趣的主题/重点领域与本文档中列举的开放网络虚拟化研究领域相关联。这有助于NFVRG确定研究主题并确定其优先级。NFVRG焦点的当前列表如下：
o Re-architecting functions, including aspects such as new architectural and design patterns (e.g., containerization, statelessness, serverless, control/data plane separation), SDN integration, and proposals on programmability.
o 重新架构功能，包括新的架构和设计模式（例如，集装箱化、无状态、无服务器、控制/数据平面分离）、SDN集成和可编程性建议等方面。
o New management frameworks, considering aspects related to new OAM mechanisms (e.g., configuration control, hybrid descriptors) and lightweight MANO proposals.
o 新的管理框架，考虑与新的OAM机制（例如，配置控制、混合描述符）和轻量级MANO建议相关的方面。
o Techniques to guarantee low latency, resource isolation, and other data-plane features, including hardware acceleration, functional offloading to data-plane elements (including NICs), and related approaches.
o 保证低延迟、资源隔离和其他数据平面功能的技术，包括硬件加速、功能卸载到数据平面元素（包括NIC）以及相关方法。
o Measurement and benchmarking, addressing both internal measurements and external applications.
o 测量和基准测试，解决内部测量和外部应用。
+-------------------------------------+-------------------------+
| NFVRG Focus Point | Open Research Area |
+-------------------------------------+-------------------------+
| 1) Re-architecting functions | - Performance improvem. |
| | - Network Slicing |
| | - Guaranteeing QoS |
| | - Security |
| | - End-user device virt. |
| | - Separation of control |
| | |
| 2) New management frameworks | - Multiple Domains |
| | - Service Composition |
| | - End-user device virt. |
| | |
| 3) Low latency, resource isolation, | - Performance improvem. |
| etc. | - Separation of control |
| | |
| 4) Measurement and benchmarking | - Guaranteeing QoS |
| | - Testing |
+-------------------------------------+-------------------------+
+-------------------------------------+-------------------------+
| NFVRG Focus Point | Open Research Area |
+-------------------------------------+-------------------------+
| 1) Re-architecting functions | - Performance improvem. |
| | - Network Slicing |
| | - Guaranteeing QoS |
| | - Security |
| | - End-user device virt. |
| | - Separation of control |
| | |
| 2) New management frameworks | - Multiple Domains |
| | - Service Composition |
| | - End-user device virt. |
| | |
| 3) Low latency, resource isolation, | - Performance improvem. |
| etc. | - Separation of control |
| | |
| 4) Measurement and benchmarking | - Guaranteeing QoS |
| | - Testing |
+-------------------------------------+-------------------------+
Table 2: Mapping of NFVRG Focus Points to Open Research Areas
表2:NFVRG焦点到开放研究领域的映射
This document has no IANA actions.
本文档没有IANA操作。
This is an Informational RFC that details research challenges; it does not introduce any security threat. Research challenges and gaps related to security and privacy have been included in Section 4.8.
这是一份详细说明研究挑战的信息RFC；它不会带来任何安全威胁。与安全和隐私相关的研究挑战和差距已包含在第4.8节中。
[COMS-PS] Geng, L., Slawomir, S., Qiang, L., Matsushima, S., Galis, A., and L. Contreras, "Problem Statement of Common Operation and Management of Network Slicing", Work in Progress, draft-geng-coms-problem-statement-04, March 2018.
[COMS-PS]Geng，L.，Slawomir，S.，Qiang，L.，Matsushima，S.，Galis，A.，和L.Contreras，“网络切片的常见操作和管理问题声明”，正在进行的工作，草稿-Geng-COMS-Problem-Statement-042018年3月。
[dynamic_chaining] Martini, B. and F. Paganelli, "A Service-Oriented Approach for Dynamic Chaining of Virtual Network Functions over Multi-Provider Software-Defined Networks", Future Internet Vol. 8, No. 2, DOI 10.3390/fi8020024, June 2016.
[动态链接]Martini，B.和F.Paganelli，“多提供商软件定义网络上虚拟网络功能动态链接的面向服务的方法”，未来互联网第8卷，第2期，DOI 10.3390/fi8020024，2016年6月。
[dynamic_placement] Clayman, S., Maini, E., Galis, A., Manzalini, A., and N. Mazzocca, "The dynamic placement of virtual network functions", 2014 IEEE Network Operations and Management Symposium (NOMS) pp. 1-9, DOI 10.1109/NOMS.2014.6838412, May 2014.
[dynamic_placement]Clayman，S.，Maini，E.，Galis，A.，Manzalini，A.，和N.Mazzocca，“虚拟网络功能的动态布局”，2014年IEEE网络运营和管理研讨会（NOMS）第1-9页，DOI 10.1109/NOMS.2014.6838412，2014年5月。
[etsi_gs_nfv_003] ETSI NFV ISG, "Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1 NFV 003, December 2014, <http://www.etsi.org/deliver/etsi_gs/ NFV/001_099/003/01.02.01_60/gs_NFV003v010201p.pdf>.
[etsi_gs_nfv_003]etsi nfv ISG，“网络功能虚拟化（nfv）；nfv中主要概念的术语”，etsi gs nfv 003 V1.2.1 nfv 003，2014年12月<http://www.etsi.org/deliver/etsi_gs/ NFV/001\U 099/003/01.02.01\U 60/gs\U NFV003v010201p.pdf>。
[etsi_gs_nfv_eve005] ETSI NFV ISG, "Network Functions Virtualisation (NFV); Ecosystem; Report on SDN Usage in NFV Architectural Framework", ETSI GS NFV-EVE 005 V1.1.1 NFV-EVE 005, December 2015, <http://www.etsi.org/deliver/etsi_gs/NFV-EVE/001_099/ 005/01.01.01_60/gs_NFV-EVE005v010101p.pdf>.
[etsi_gs_nfv_eve005]etsi nfv ISG，“网络功能虚拟化（nfv）；生态系统；关于nfv架构框架中SDN使用情况的报告”，etsi gs nfv-EVE 005 V1.1.1 nfv-EVE 005，2015年12月<http://www.etsi.org/deliver/etsi_gs/NFV-EVE/001_099/ 005/01.01.01_60/gs_NFV-EVE005V01010101P.pdf>。
[etsi_gs_nfv_per_001] ETSI NFV ISG, "Network Functions Virtualisation (NFV); NFV Performance & Portability Best Practises", ETSI GS NFV-PER 001 V1.1.2 NFV-PER 001, December 2014, <https://www.etsi.org/deliver/etsi_gs/nfv-per/ 001_099/001/01.01.02_60/gs_nfv-per001v010102p.pdf>.
[etsi_gs_nfv_per_001]etsi nfv ISG，“网络功能虚拟化（nfv）；nfv性能和可移植性最佳实践”，etsi gs nfv-per 001 V1.1.2 nfv-per 001，2014年12月<https://www.etsi.org/deliver/etsi_gs/nfv-per/ 001_099/001/01.01.02_60/gs_nfv-per001v010102p.pdf>。
[etsi_gs_nfv_sec_001] ETSI NFV ISG, "Network Functions Virtualisation (NFV); NFV Security; Problem Statement", ETSI GS NFV-SEC 001 V1.1.1 NFV-SEC 001, October 2014, <http://www.etsi.org/deliver/ etsi_gs/NFV-SEC/001_099/001/01.01.01_60/ gs_NFV-SEC001v010101p.pdf>.
[etsi_gs_nfv_sec_001]etsi nfv ISG，“网络功能虚拟化（nfv）；nfv安全；问题陈述”，etsi gs nfv-sec 001 V1.1.1 nfv-sec 001，2014年10月<http://www.etsi.org/deliver/ etsi_gs/NFV-SEC/001_099/001/01.01.01_60/gs_NFV-SEC001v010101p.pdf>。
[etsi_nfv_whitepaper_3] ETSI, "Network Functions Virtualisation (NFV) - White Paper #3: Network Operator Perspectives on Industry Progress", Issue 1, SDN & OpenFlow World Congress Dusseldorf, Germany, October 2014, <http://portal.etsi.org/NFV/NFV_White_Paper3.pdf>.
[etsi_nfv_白皮书_3]etsi，“网络功能虚拟化（nfv）-白皮书#3：网络运营商对行业进步的看法”，第1期，德国杜塞尔多夫SDN和OpenFlow世界大会，2014年10月<http://portal.etsi.org/NFV/NFV_White_Paper3.pdf>.
[google_sdn_wan] Jain, S., et al., "B4: experience with a globally-deployed Software Defined WAN", SIGCOMM '13: Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM, pp. 3-14, Hong Kong China, DOI 10.1145/2486001.2486019, August 2013.
[BoGeLaySdnWangWang] Jain，S，等，“B4:全球部署软件定义WAN的经验”，SIGCOMM 13：SIGCOMM的ACM Sigcom 2013会议录，中国香港3-DO14，DOI 101145/248600 1.2486019，2013年8月。
[intel_10_differences_nfv_cloud] Torre, P., "Discover the Top 10 Differences Between NFV and Cloud Environments", November 2015, <https://software.intel.com/en-us/videos/discover-the-top-10-differences-between-nfv-and-cloud-environments>.
[intel_10_差异_nfv_云]Torre，P.，“发现nfv和云环境之间的十大差异”，2015年11月<https://software.intel.com/en-us/videos/discover-the-top-10-differences-between-nfv-and-cloud-environments>.
[itu-t-y.3300] ITU-T, "Y.3300: Framework of software-defined networking", ITU-T Recommendation Y.3300, June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
[itu-t-y.3300]itu-t，“y.3300：软件定义网络框架”，itu-t建议y.3300，2014年6月<http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
[itu-t-y.3301] ITU-T, "Y.3301: Functional requirements of software-defined networking", ITU-T Recommendation Y.3301, September 2016, <http://www.itu.int/rec/T-REC-Y.3301-201609-I/en>.
[itu-t-y.3301]itu-t，“y.3301：软件定义网络的功能要求”，itu-t建议y.3301，2016年9月<http://www.itu.int/rec/T-REC-Y.3301-201609-I/en>.
[itu-t-y.3302] ITU-T, "Y.3302: Functional architecture of software-defined networking", ITU-T Recommendation Y.3302, January 2017, <http://www.itu.int/rec/T-REC-Y.3302-201701-I/en>.
[itu-t-y.3302]itu-t，“y.3302：软件定义网络的功能架构”，itu-t建议y.3302，2017年1月<http://www.itu.int/rec/T-REC-Y.3302-201701-I/en>.
[LAYERED-SDN] Contreras, L., Bernardos, C., Lopez, D., Boucadair, M., and P. Iovanna, "Cooperating Layered Architecture for Software Defined Networking (CLAS)", Work in Progress, draft-contreras-layered-sdn-03, November 2018.
[LAYERED-SDN]Contreras，L.，Bernardos，C.，Lopez，D.，Boucadair，M.，和P.Iovanna，“软件定义网络（CLAS）的合作分层体系结构”，正在进行的工作，草稿-Contreras-LAYERED-SDN-032018年11月。
[LIGHT-NFV] Sriram, N., Krishnan, R., Ghanwani, A., Krishnaswamy, D., Willis, P., Chaudhary, A., and F. Huici, "An Analysis of Lightweight Virtualization Technologies for NFV", Work in Progress, draft-natarajan-nfvrg-containers-for-nfv-03, July 2016.
[LIGHT-NFV]Sriram，N.，Krishnan，R.，Ghanwani，A.，Krishnaswamy，D.，Willis，P.，Chaudhary，A.，和F.Huici，“NFV轻量级虚拟化技术分析”，在建工程，草稿-natarajan-nfvrg-containers-for-NFV-032016年7月。
[multi-domain_5GEx] Bernardos, C., Gero, B., Di Girolamo, M., Kern, A., Martini, B., and I. Vaishnavi, "5GEx: Realizing a Europe-wide Multi-domain framework for software-defined infrastructures", Transactions on Emerging Telecommunications Technologies Vol. 27, No. 9, pp. 1271-1280, DOI 10.1002/ett.3085, July 2016.
[multi-domain_5GEx]Bernardos，C.，Gero，B.，Di Girolamo，M.，Kern，A.，Martini，B.，和I.Vaishnavi，“5GEx：实现全欧洲软件定义基础设施的多域框架”，新兴电信技术交易卷27，第9期，第1271-1280页，DOI 10.1002/ett.3085，2016年7月。
[MULTI-NMRG] Bernardos, C., Contreras, L., Vaishnavi, I., Szabo, R., Li, X., Paolucci, F., Sgambelluri, A., Martini, B., Valcarenghi, L., Landi, G., Andrushko, D., and A. Mourad, "Multi-domain Network Virtualization", Work in Progress, draft-bernardos-nmrg-multidomain-00, March 2019.
[MULTI-NMRG]Bernardos，C.，Contreras，L.，Vaishnavi，I.，Szabo，R.，Li，X.，Paolucci，F.，Sgambelluri，A.，Martini，B.，Valcarenghi，L.，Landi，G.，Andrushko，D.，和A.Mourad，“多域网络虚拟化”，正在进行中，草稿-Bernardos-NMRG-MULTI-domain-00，2019年3月。
[NETSLICES] Galis, A., Dong, J., Makhijani, K., Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network Slicing - Introductory Document and Revised Problem Statement", Work in Progress, draft-gdmb-netslices-intro-and-ps-02, February 2017.
[NETSLICES]Galis，A.，Dong，J.，Makhijani，K.，Bryant，S.，Boucadair，M.，和P.Martinez Julia，“网络切片-介绍性文件和修订后的问题陈述”，正在进行的工作，草稿-gdmb-NETSLICES-intro-and-ps-022017年2月。
[NFV-COTS] Mo, L. and B. Khasnabish, "NFV Reliability using COTS Hardware", Work in Progress, draft-mlk-nfvrg-nfv-reliability-using-cots-01, October 2015.
[NFV-COTS]Mo，L.和B.Khasnabish，“使用COTS硬件的NFV可靠性”，在建工程，草稿-mlk-nfvrg-NFV-Reliability-using-COTS-01，2015年10月。
[nfv_piecing] Luizelli, M., Bays, L., Buriol, L., Barcellos, M., and L. Gaspary, "Piecing together the NFV provisioning puzzle: Efficient placement and chaining of virtual network functions", 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM) pp. 98-106, DOI 10.1109/INM.2015.7140281, May 2015.
[nfv_piecing]Luizelli，M.，Bays，L.，Buriol，L.，Barcellos，M.，和L.Gaspary，“拼凑nfv供应难题：虚拟网络功能的有效布局和链接”，2015年IFIP/IEEE国际综合网络管理研讨会（IM）第98-106页，DOI 10.1109/INM.2015.7140281，2015年5月。
[nfv_sota_research_challenges] Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De Turck, F., and R. Boutaba, "Network Function Virtualization: State-of-the-art and Research Challenges", IEEE Communications Surveys & Tutorials Volume: 18, Issue: 1, pp. 236-262, DOI 10.1109/COMST.2015.2477041, September 2015.
[nfv_sota_research_challenges]Mijumbi，R.，Serrat，J.，Gorricho，J-L.，Bouten，N.，De Turck，F.，和R.Boutaba，“网络功能虚拟化：最新技术和研究挑战”，IEEE通信调查与教程卷：18，第1期，第236-262页，DOI 10.1109/COMST.2015.2477041，2015年9月。
[NFVRG-TOPO] Bagnulo, M. and D. Dolson, "NFVI PoP Network Topology: Problem Statement", Work in Progress, draft-bagnulo-nfvrg-topology-01, March 2016.
[NFVRG-TOPO]Bagnulo，M.和D.Dolson，“NFVI PoP网络拓扑：问题陈述”，正在进行的工作，草稿-Bagnulo-NFVRG-Topology-01，2016年3月。
[ngmn_5G_whitepaper] NGMN Alliance, "NGMN 5G White Paper", Version 1.0, February 2015, <https://www.ngmn.org/fileadmin/ngmn/content/ images/news/ngmn_news/NGMN_5G_White_Paper_V1_0.pdf>.
[ngmn_5G_白皮书]ngmn联盟，“ngmn 5G白皮书”，版本1.0，2015年2月<https://www.ngmn.org/fileadmin/ngmn/content/ images/news/ngmn_news/ngmn_5G_白皮书V1_0.pdf>。
[omniran] IEEE, "Recommended Practice for Network Reference Model and Functional Description of IEEE 802 Access Network", P802.1CF IEEE Draft, December 2017.
[omniran]IEEE，“IEEE 802接入网络的网络参考模型和功能描述的推荐实施规程”，P802.1CF IEEE草案，2017年12月。
[onf_tr_521] Open Networking Foundation, "SDN Architecture", ONF TR-521 TR-521, Issue 1.1, February 2016, <https://www.opennetworking.org/images/stories/downloads/ sdn-resources/technical-reports/ TR-521_SDN_Architecture_issue_1.1.pdf>.
开放网络基础，“SDN架构”，ONF TR—521 TR—521，第1.1期，2016年2月，<https://www.opennetworking.org/images/stories/downloads/ sdn资源/技术报告/TR-521\u sdn\u体系结构\u问题\u 1.1.pdf>。
[OpenFlow] Open Networking Foundation, "OpenFlow Switch Specification", ONF TS-025, Version 1.5.1 (Protocol version 0x06), March 2015.
开放网络基础，“OpenFLASH交换机规范”，ONF TS-025，版本1.5.1（协议版本0x06），2015年3月。
[openmano_dataplane] Lopez, D., "OpenMANO: The Dataplane Ready Open Source NFV MANO Stack", March 2015, <https://www.ietf.org/ proceedings/92/slides/slides-92-nfvrg-7.pdf>.
[openmano_dataplane]Lopez，D.，“openmano：数据平面就绪的开源NFV MANO堆栈”，2015年3月<https://www.ietf.org/ 会议记录/92/slides/slides-92-nfvrg-7.pdf>。
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, DOI 10.17487/RFC5810, March 2010, <https://www.rfc-editor.org/info/rfc5810>.
[RFC5810]Doria，A.，Ed.，Hadi Salim，J.，Ed.，Haas，R.，Ed.，Khosravi，H.，Ed.，Wang，W.，Ed.，Dong，L.，Gopal，R.，和J.Halpern，“转发和控制元件分离（部队）协议规范”，RFC 5810，DOI 10.17487/RFC5810，2010年3月<https://www.rfc-editor.org/info/rfc5810>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<https://www.rfc-editor.org/info/rfc7252>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7426]Haleplis，E.，Ed.，Pentikousis，K.，Ed.，Denazis，S.，Hadi Salim，J.，Meyer，D.，和O.Koufopavlou，“软件定义网络（SDN）：层和架构术语”，RFC 7426，DOI 10.17487/RFC7426，2015年1月<https://www.rfc-editor.org/info/rfc7426>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>.
[RFC7498]Quinn，P.，Ed.和T.Nadeau，Ed.，“服务功能链接的问题陈述”，RFC 7498，DOI 10.17487/RFC7498，2015年4月<https://www.rfc-editor.org/info/rfc7498>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665]Halpern，J.，Ed.和C.Pignataro，Ed.，“服务功能链（SFC）架构”，RFC 7665，DOI 10.17487/RFC7665，2015年10月<https://www.rfc-editor.org/info/rfc7665>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, <https://www.rfc-editor.org/info/rfc8030>.
[RFC8030]Thomson，M.，Damaggio，E.，和B.Raymor，Ed.，“使用HTTP推送的通用事件交付”，RFC 8030，DOI 10.17487/RFC80302016年12月<https://www.rfc-editor.org/info/rfc8030>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<https://www.rfc-editor.org/info/rfc8040>.
[RFC8172] Morton, A., "Considerations for Benchmarking Virtual Network Functions and Their Infrastructure", RFC 8172, DOI 10.17487/RFC8172, July 2017, <https://www.rfc-editor.org/info/rfc8172>.
[RFC8172]Morton，A.“对虚拟网络功能及其基础设施进行基准测试的注意事项”，RFC 8172，DOI 10.17487/RFC8172，2017年7月<https://www.rfc-editor.org/info/rfc8172>.
[SDN-AAA] Lopez, R. and G. Lopez-Millan, "Software-Defined Networking (SDN)-based AAA Infrastructures Management", Work in Progress, draft-marin-sdnrg-sdn-aaa-mng-00, November 2015.
[SDN-AAA]Lopez，R.和G.Lopez Millan，“基于软件定义网络（SDN）的AAA基础设施管理”，正在进行的工作，草稿-marin-sdnrg-SDN-AAA-mng-00，2015年11月。
[sfc_challenges] Medhat, A., Taleb, T., Elmangoush, A., Carella, G., Covaci, S., and T. Magedanz, "Service Function Chaining in Next Generation Networks: State of the Art and Research Challenges", IEEE Communications Magazine vol. 55, no. 2, pp. 216-223, DOI 10.1109/MCOM.2016.1600219RP, February 2017.
[sfc_challenges]Medhat，A.，Taleb，T.，Elmangoush，A.，Carella，G.，Covaci，S.，和T.Magedanz，“下一代网络中的服务功能链：最新技术和研究挑战”，IEEE通信杂志第55卷，第2期，216-223页，DOI 10.1109/MCOM.2016.1600219RP，2017年2月。
[SLICE-3GPP] Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", Work in Prgoress, draft-defoy-netslices-3gpp-network-slicing-02, October 2017.
[SLICE-3GPP]Foy，X.和A.Rahman，“网络切片-3GPP用例”，在Prgoress工作，draft-defoy-netslices-3GPP-Network-SLICE-022017年10月。
[virtualization_mobile_device] Sproule, W. and A. Fernando, "Virtualization of Mobile Device User Experience", US Patent 9.542.062 B2, filed October 2013 and issued December 2014, Current Assignee: Microsoft Technology Licensing LLC.
[virtualization_mobile_device]Sproule，W.和A.Fernando，“移动设备用户体验的虚拟化”，美国专利9.542.062 B2，2013年10月提交，2014年12月发布，当前受让人：微软技术许可有限责任公司。
[vnf-p] Moens, H. and , "VNF-P: A model for efficient placement of virtualized network functions", 10th International Conference on Network and Service Management (CNSM) and Workshop pp. 418-423, DOI 10.1109/CNSM.2014.7014205, November 2014.
[vnf-p]Moens，H.和，“vnf-p：有效部署虚拟化网络功能的模型”，第十届网络和服务管理国际会议（CNSM）和研讨会，第418-423页，DOI 10.1109/CNSM.2014.7014205，2014年11月。
[VNF-VBAAS] Rosa, R., Rothenberg, C., and R. Szabo, "VNF Benchmark-as-a-Service", Work in Progress, draft-rorosz-nfvrg-vbaas-00, October 2015.
[VNF-VBAAS]Rosa，R.，Rothenberg，C.，和R.Szabo，“VNF Benchmark-as-a-Service”，正在进行的工作，草稿-rorosz-nfvrg-VBAAS-00，2015年10月。
[vnf_benchmarking] Rosa, R., Rothenberg, C., and R. Szabo, "A VNF Testing Framework Design, Implementation and Partial Results", NFVRG IETF 97, November 2016, <https://www.ietf.org/proceedings/97/slides/ slides-97-nfvrg-06-vnf-benchmarking-00.pdf>.
[vnf_基准测试]Rosa，R.，Rothenberg，C.，和R.Szabo，“vnf测试框架设计、实施和部分结果”，NFVRG IETF 972016年11月<https://www.ietf.org/proceedings/97/slides/ 幻灯片-97-nfvrg-06-vnf-benchmarking-00.pdf>。
Acknowledgments
致谢
The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez, Ramki Krishnan, Kostas Pentikousis, Rana Pratap Sircar, Alfred Morton, Nicolas Kuhn, Saumya Dikshit, Fabio Giust, Evangelos Haleplidis, Angeles Vazquez-Castro, Barbara Martini, Jose Saldana, and Gino Carrozzo for their very useful reviews and comments to the document. Special thanks to Pedro Martinez-Julia, who provided text for the network slicing section.
作者要感谢德克·冯·雨果、拉法·马林、迭戈·洛佩兹、拉姆基·克里希南、科斯塔斯·彭蒂库西斯、拉娜·普拉塔普·瑟卡尔、阿尔弗雷德·莫顿、尼古拉斯·库恩、萨乌米·迪克希特、法比奥·朱斯特、伊万杰洛斯·哈莱普利斯、洛杉矶·巴斯克斯·卡斯特罗、芭芭拉·马蒂尼、何塞·萨尔达纳和吉诺·卡洛佐对该文件的非常有用的评论。特别感谢Pedro Martinez Julia，她为网络切片部分提供了文本。
The authors want to also thank Dave Oran and Michael Welzl for their very detailed IRSG reviews.
作者还想感谢Dave Oran和Michael Welzl对IRSG的详细评论。
The work of Carlos J. Bernardos and Luis M. Contreras is partially supported by the H2020 5GEx (Grant Agreement no. 671636) and 5G-TRANSFORMER (Grant Agreement no. 761536) projects.
Carlos J.Bernardos和Luis M.Contreras的工作得到H2020 5GEx（第671636号赠款协议）和5G-TRANSFORMER（第761536号赠款协议）项目的部分支持。
Authors' Addresses
作者地址
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
卡洛斯·J·贝尔纳多斯大学卡洛斯三世马德里大道。西班牙马德里勒冈30号大学28911
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada
Akbar Rahman InterDigital Communications，LLC加拿大魁北克省蒙特利尔谢布鲁克西街1000号10楼H3A 3G4
Email: Akbar.Rahman@InterDigital.com
URI: http://www.InterDigital.com/
Email: Akbar.Rahman@InterDigital.com
URI: http://www.InterDigital.com/
Juan Carlos Zuniga SIGFOX 425 rue Jean Rostand Labege 31670 France
胡安·卡洛斯·祖尼加·西格福克斯法国让·罗斯坦德·拉贝格街425号31670
Email: j.c.zuniga@ieee.org
URI: http://www.sigfox.com/
Email: j.c.zuniga@ieee.org
URI: http://www.sigfox.com/
Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, S/N Madrid 28050 Spain
路易斯M.孔特雷拉斯电信公司I+D隆达通讯社，西班牙马德里S/N 28050
Email: luismiguel.contrerasmurillo@telefonica.com
Email: luismiguel.contrerasmurillo@telefonica.com
Pedro Aranda Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
马德里卡洛斯三世佩德罗·阿兰达大学。西班牙马德里勒冈30号大学28911
Email: pedroandres.aranda@uc3m.es
Email: pedroandres.aranda@uc3m.es
Pierre Lynch Keysight Technologies 800 Perimeter Park Dr, Suite A Morrisville, NC 27560 United States of America
Pierre Lynch Keysight Technologies 800美国北卡罗来纳州莫里斯维尔周边公园Dr套房A 27560
Email: pierre.lynch@keysight.com
URI: http://www.keysight.com
Email: pierre.lynch@keysight.com
URI: http://www.keysight.com