网络功能虚拟化技术研究综述

周伟林 杨 芫 徐明伟

1(北京邮电大学网络技术研究院 北京 100876) 2(清华大学计算机科学与技术系 北京 100084) 3 (北京信息科学与技术国家研究中心 北京 100084) (zhou_weilin@bupt.edu.cn)

当前全球互联网的发展持续加速，一方面表现在用户数量急剧增长和接入数据速率越来越快，另一方面也呈现出应用多样化的趋势：机器对机器连接数量增加，视频、直播服务的流行，虚拟现实、增强现实的推广，移动智能可穿戴技术、物联网技术蓬勃发展等.为了满足用户对网络的多样化需求，在网络中通常以专用设备来实现各式各样的网络功能，这些设备被称为中间盒(middlebox)，有时也被称为网络电器(network appliance)或网络功能(network function).根据RFC3234[1]，Middlebox是执行任何网络功能的中间设备，这里的网络功能不包括IP路由器对从源主机到目的主机间的数据报文执行正常、标准的功能.典型的Middlebox包括提升网络安全性的设备，如防火墙、入侵检测系统、入侵防御系统、深度包检测等，也包括提升网络性能的设备，如Web代理、缓存、广域网加速器、协议加速器、负载均衡器等.

Middlebox大量应用于数据中心网络，在电信网络、企业网、互联网中也起着十分重要的作用.在典型的企业网中，Middlebox的数量甚至与路由器的数量基本相当[2].然而，由于Middlebox多采用专用设备，其提供的网络服务与硬件具有很强的耦合性，因此导致了很多问题:1)网络升级换代需要巨大的开销，尤其是在移动互联网等技术更新较快的场景下，从2.5 G到3 G，再到4 G,5 G，每过几年都需要运营商投入巨额资金来更换新设备.2)当前Middlebox的可管理性较差，随着Middlebox种类和数量越来越多，为了在机房布置整个网络拓扑，接线越来越复杂，网络管理员进行网络配置和排错也越来越困难.3)当前Middlebox体系结构缺乏可扩展性，每台设备固定容量，不能按需分配资源，不同设备间更不能实现资源共享.4)新服务上线周期较长，为了增加一个新的网络服务，不仅要重新开发软件，还得专门设计新硬件、新设备，定制化的服务难以实现.综合以上4点可以看出，当前这种软硬件强耦合的Middlebox架构难以满足现有需求，已经成为互联网发展的瓶颈之一，技术变革势在必行.

为了解决当前Middlebox所面临的开放性和通用性低、灵活性不强、缺乏高效统一的管理、运营成本高、利用率低等问题，全球几大电信运营商在2012年的SDN和OpenFlow大会上首次提出了网络功能虚拟化(network function virtualization, NFV)的概念.NFV的基本思想是改变将网络功能实现在专用平台上的现状，而将网络功能实现到通用的x86平台上，从而帮助运营商和数据中心更加灵活地为客户创建和部署网络特性，降低设备投资和运营费用.如图1所示，对计算、存储和网络资源进行分离，通用服务器负责提供计算资源，商用交换机负责流量在网络环境路由，存储器负责高速缓存.NFV允许独立的软件开发商基于大容量的标准服务器、存储器和交换机等商用现成(commercial off-the-shelf, COTS)设备进行网络功能的实现和部署，利用云数据中心的规模经济效应[3]，大大降低生产开销、提高产能.同时使得网络功能软件支持协同、自动、远程安装，有利于打造一个有竞争力、创新开放的网络功能生态系统[4].

Fig. 1 NFV vision图1 NFV愿景

自NFV首次提出之后，涌现了很多相关的研究工作，推动了技术的发展.然而，由于NFV涉及标准化服务器、虚拟化、软件定义网络等诸多方面，这对认识和理解各项研究工作之间的关联性以及认清未来的研究方向带来了挑战，尤其是这些已有研究既包括对已有技术的应用扩展或性能优化，如NFV云平台管理等，也包括新的技术挑战，如网络功能动态迁移等.另一方面，NFV的标准化工作主要是由电信运营商而非设备制造商主导的，这使得NFV技术研究的进展与NFV体系结构的标准化进程难以完全匹配，其中出现的不一致会导致不同的研究者在理解和认识上出现偏差.本文将对NFV技术的研究现状进行综述.在总结了欧洲电信标准化协会((European Telecommunications Standards Institute， ETSI)和国际互联网工程任务组(The Internet Engineering Task Force， IETF)等标准化组织所提出的NFV体系结构和相关技术的基础上，本文创造性地提出了一种四象限的方法对已有的NFV研究进行分类，对每一类研究的代表性方案做了分析、比较和总结，并提出了尚未解决的技术挑战和未来的研究方向.

1 NFV概述

1.1 NFV标准化组织

开展NFV标准化工作的主要组织是ETSI所领导的NFV行业规范组(industry specification group， ISG).NFV ISG包括多个工作组：负责基础设施的NFV INF(infrastructure)、负责管理与编排的NFV MAN(management and orchestration)、负责软件体系结构的NFV SWA(software architecture)、负责性能优化的NFV PER(performance)、负责可靠性的NFV REL(reliability)，以及负责安全的NFV SEC(security).它们的主要成果包括白皮书、相应的标准文档以及概念验证(proof of concept)系统.

ETSI NFV ISG并未涵盖NFV技术研究的所有方面，一部分与互联网关系较为密切的标准化工作是由IETF完成的.其中，服务功能链(service function chaining， SFC)工作组[5]成立于2013年，主要任务是设计方案来解决如何在虚拟网络中将虚拟化的服务功能连接起来的问题，同时通过在NFV域中传递元数据来对灵活的网络功能提供支持.源分组路由(source packet routing in networking， SPRING)工作组[6]与SFC工作组合作，设计完全基于网络层的服务功能链实现方案.此外，IETF中还成立了名为VNFPool的讨论群(birds of a feather, BoF)，不过由于其任务与其他工作组存在重复，最终没有成为工作组.

1.2 NFV体系结构

ETSI NFV ISG所提出的NFV体系结构[7]如图2所示，它包括了以下4个组成部分.

Fig. 2 NFV architecture图2 NFV体系结构

1) 运营和业务支持系统(operations support systembusiness support system， OSSBSS)是负责支撑端到端的电信服务的主要管理系统，服务包括订单、账单、续约、排错等.同时，需要与NFV编排器(NFV orchestration， NFVO)协同交互完成网络服务描述、网络服务生命周期管理、虚拟资源故障、性能信息交互以及策略管理等功能.该模块设计可基于已有云管理系统，同时需要支持与现有OSSBSS进行交互，以保证兼容性，与现有系统协同工作.

2) 网元管理(element management system， EMS)与虚拟网络功能(virtual network function， VNF)共同构成了NFV域，其中EMS对VNF进行管理，包括VNF的安装、监控、错误日志记录、配置、记账、性能和安全等.VNF运行于NFV基础设施(NFV infrastructure， NFVI)之上，以软件形式实现各种特定的网络功能.

3) NFV基础设施(NFV infrastructure， NFVI)为VNF提供虚拟的计算、存储和网络资源，以及VNF部署、管理和执行的环境.NFVI可以利用已有的云计算技术来构建，如基础设施即服务(infrastructure as a service， IaaS)以及网络即服务(network as a service， NaaS).NFVI自下而上包括硬件资源层、虚拟层和虚拟资源层，其中虚拟层是连接上下2层的纽带，典型的技术包括hypervisor方案和container方案.使用hypervisor的方案基于虚拟机技术，其优点在于系统之间隔离性强、灵活可变、配置方便、兼容性好、技术较为成熟；不足之处在于消耗的资源较多，且系统启动速度和性能都有一定的损失.基于container的方案是最近提出的一项新兴技术，它通过共享内存等资源来减小虚拟化的开销，提供更高的启动速度和性能.不过container方案在安全隔离、灵活性、兼容性等方面还需要进一步的研究.

4) NFV管理与编排(management and orches-tration， MANO)包括NFV编排器(NFVO)、VNF管理器(VNFM)、虚拟化基础设施管理器(VIM)三部分.其中NFVO负责网络服务的生命周期管理以及相应策略，并提供跨数据中心、跨厂家协同管理能力.VNFM负责对虚拟化资源的创建和生命周期方面进行管理，包括VNF实例化、缩放、更新、终止.VIM负责对NFVI资源的管理和监控，包括对硬件资源、虚拟机的管理和监控、故障排查、状态上报、向上层提供部署接口等.

正如引言所述，NFV的标准化工作是由用户(运营商)而非设备制造商来主导的，ETSI所提出的NFV体系结构在很大程度上参考了一些比较成熟的开源技术如OpenStack.然而，随着大量开源项目的出现和技术的进步，真实的系统可能会与上述体系结构出现不一致的情况，未来NFV体系结构标准也可能会随着实际情况进行修改.

1.3 NFV的优势

1) 站在网络功能使用者的角度看.NFV可以提供良好的可扩展性(或伸缩性)和弹性服务.随着用户需求的增加，网络功能不仅可以扩展到同一数据中心的其他服务器，还可以扩展到网络中的其他数据中心中，以满足变化的服务请求.通过优化的软件设计方案，可以保证伸缩过程中服务的连续性，并尽力减少伸缩所花的时间和网络带宽.类似地，NFV还可以通过自动重建或预留备份的方式来支持故障下的服务保障.

2) 站在运营商的角度看.NFV可以节约大量的采购支出和运营开销，可以实现方便灵活的管理与配置，更快地升级和更新软件，并有效提高资源利用率.通过网络功能在多厂商环境中加载、执行和迁移，NFV可以实现资源的实时整合，从而应对可用资源不足、服务质量下降等问题.

3) 站在设备提供商和软件市场的角度看.NFV虽然会对传统的专用设备制造带来巨大的冲击，但其带来的好处也是显而易见的.更加通用、高效的商用服务器将受到青睐，避免了大量专用、低效设备的研发带来的资源浪费，为设备提供商提供了从出售设备转型为出售服务的契机：能提供灵活配置、智能管理等一系列优化功能的管理软件和平台将受到运营商的追捧.尤其是不同厂商的VNF、虚拟软件、通用硬件设备可能会存在兼容性和互操作性的问题，且存在虚拟网络功能与原有的专用Middlebox共存的时期，这无疑为设备提供商开发高效的解决方案提供了商机.同时，NFV还降低了网络功能开发的门槛，加快了新兴网络功能投入应用的时间，使网络功能软件生态更加活跃.

1.4 NFV面临的技术挑战

1) 在性能方面.在通用硬件上实现专用设备级的性能是一大挑战.NFV环境中考虑的性能可以从链路利用率、流量处理延迟、系统吞吐率等方面来衡量.在虚拟环境中，处理器架构、虚拟机架构、硬软件数据传输方式等都会对VNF性能产生很大影响.

2) 在管理编排方面.如何高效地将各网络功能组织成服务功能链是一大挑战，此外，由于不同用户之间可能共享网络功能，因此，传统云计算场景中的差错、配置和计费管理也会面临新的问题.

3) 在可靠性和可用性方面.为了提供与原有网络功能同等的故障恢复能力，需要考虑网络功能和流量迁移所带来的影响，这一点与已有的云平台技术也有本质的不同.

4) 在安全性方面.除了传统的云计算和虚拟网络中已经存在的拓扑验证、虚拟化实体间的隔离等问题之外，NFV还面临网络动态迁移中针对状态一致性的安全攻击等问题.

5) 在可编程性方面.需要设计出一套方便开发新兴网络功能的编程接口，能灵活地适应各种可能出现的应用需求，并能高效地对底层的硬件资源进行操作.

2 相关技术背景

NFV是在一定的技术背景下提出的，可以说没有当前服务器、云计算、软件定义网络等技术的发展就不会诞生NFV.因此，在分析NFV领域的研究工作之前，有必要对相关的技术进行必要的阐述，以明确它们与NFV的联系，从而有助于更深入地把握NFV的具体细节和各组件的功能.

2.1 标准化服务器

COTS服务器由标准IT组件构成，服务器内组件可替换.由于规模经济效用，COTS标准化服务器生产成本大大降低，服务器内部组件可替换的性质，非常有助于其形成一个有充分竞争的硬件供应市场.价格低功耗低的特性，使COTS服务器非常适合大规模部署，这些特性为NFV的商用推广奠定了坚实的基础.

随着x86架构、高级精简指令集机器(advanced RISC machine, ARM)架构的快速发展，多核、多线程技术日益成熟，SR-IOV网卡广泛应用，业务加速芯片(加密、压缩等)技术支持性发展，通用芯片的计算能力正变得越来越高，通用网卡的转发能力越来越强.Intel的DPDK[8](data plane development kit)专为Intel处理器提供的一套多核CPU数据平面开发套件，用于快速包处理，支持最新网卡的硬件虚拟化技术，而且开放源码，利用DPDK技术可显著提升网络设备的转发能力，类似的软件技术还包括NAPI[9].

Fig. 3 Four quadrant classification图3 “四象限”分类

2.2 虚拟化和云计算

1959年，克里斯托弗发表题为《大型高速计算机中的时间共享》的学术报告.1965年，IBM公司发布IBM7044以及System360 Model 67和TST分时共享系统，第1次在商业系统中实现虚拟化.随着x86处理器性能提升和应用普及，1999年VMware公司推出商用虚拟化软件VMware Workstation，虚拟化技术来到PC世界.随后，虚拟化技术持续发展，Xen，Hyper-V，KVM，Docker技术相继出现.

虚拟化技术是把计算、网络、内存、存储等实体资源抽象出来的一种资源管理技术，打破了实体之间的不可切割障碍，用户可以不受资源实现、地理位置、物理包装以及底层物理设备的限制.Hypervisor也叫虚拟机监视器(virtual machine monitor)，是运行在物理服务器和操作系统之间的中间软件层，允许多个操作系统和应用共享硬件.NFV利用虚拟化技术，实现软硬件解耦，从而做到把用软件实现的网络功能运行在标准化的物理服务器上.

基于虚拟化技术的云计算，具有快速部署资源、获取服务的能力，可实现动态、按需提供资源、按使用量计费、通过互联网提供海量信息、用户方便交互、降低用户使用门槛的特点.这些特点与NFV要实现的目标一致.

2.3 软件定义网络

软件定义网络(software defined networking， SDN)最早出现于园区网络[10]，目的是提供可编程的网络应用，实现更加灵活的流量控制能力.SDN的基本特点包括分离控制和转发的功能、控制集中化(或集中化的控制平面)、使用广泛定义的(软件)接口使得网络可以执行程序化行为.SDN提出之后在云数据中心取得了巨大的成功[11].数据中心的范围和规模的扩展使得虚拟机呈爆炸式增长，更好地连接和控制这些虚拟机成为数据中心的明确需求.而SDN的集中式控制思想，大大增强了对数据中心的控制能力.

在实现网络应用或网络功能可编程方面，SDN与NFV十分类似，然而二者的对象有所不同.SDN的设计目标在于使传统的交换机更加灵活，其涉及的协议主要位于互联网体系结构的第2,3,4层；而NFV的目标在于使专用的Middlebox变得通用、灵活，虽然这些Middlebox本身处理的协议可以位于互联网体系结构的第2～5层，但NFV的实现需要用到很多应用层的技术，如网络管理和配置等.SDN和NFV代表了未来可编程网络的2个方面.另一方面，SDN提供的灵活的转发能力为NFV服务功能链的实现提供了一种可行的方法.

3 已有研究分析

3.1 方案分类

NFV技术近5年来发展迅速，对NFV存在的一系列问题，学术界已提出诸多解决方案.虚拟技术包括虚拟机技术和容器技术，本文统一使用虚拟中间盒(virtual middlebox， VMB)来表示硬件虚拟化后运行VNF的宿主环境.

图3对NFV技术实现进行了“四象限”分类，左右分别为数据平面和控制平面，上下分别为逻辑实现和物理实现.借鉴SDN技术的“数据平面与控制平面分离”的思想，数据平面负责数据处理、转发和状态收集，控制平面负责网络的配置和管理、基础资源的分配.逻辑实现指抽象出来的VNF、VNF-FG、SFC、管理和编排算法，是NFV的上层设计.物理实现指通用的商用服务器、存储器和交换机经过虚拟化后，提供的NFV基础环境NFVI，物理实现具有高效的资源管理能力.为使行文简洁，下文使用第1,2,3,4象限来描述这4个象限.

4个象限与ETSI的NFV体系结构[7]相对应.第1象限是逻辑实现与管理层的交汇，对应体系结构中的NFVO和VNFM，负责对VNF连接方式、生命周期，以及模型求解运算和下发送指令等；第2象限是逻辑实现与数据平面的交汇，对应NFV体系结构中的BSSOSS，EMS，VNFs，属于NFV的功能逻辑和业务输入部分；第3象限为数据平面与物理实现的交汇，对应体系结构张的NFVI，负责资源虚拟化和流量处理；第4象限为管理层与物理实现的交汇，对应体系结构中的VIM，负责系统资源的管理和分配.

基于“四象限”分类，解决方案归纳为4类：

1) 逻辑实现向物理实现的映射

该类解决方案研究的逻辑实现主体SFC属于第2象限，物理实现主体NFVI属于第3象限，资源分配策略属于第4象限，管理和编排算法属于第1象限.故该类解决方案对应4个象限.

用户流量具有SFC和SLA两大需求.SFC要求流量经过的VNF顺序可以保证，SLA要求流量具有足够高的带宽和吞吐量、足够低的时延等.要达到用户流量被及时和高效地处理这一目标，逻辑实现向物理实现的映射要解决的关键性问题包括：①确定每个服务节点申请的处理、存储和网络资源量；②确定服务节点实例化VNF的种类、数量；③用户流量在服务节点之间路由；④服务的可用性.

2) SFC管理与性能提升

该类解决方案着眼于逻辑实现方面的管理与优化.SFC管理性提升对应第1象限；SFC性能提升对应第2象限；而不涉及物理实现方面的考虑.故该类解决方案对应第1和第2象限.

服务功能链的长度与执行方式会影响用户流量被处理的效率.SFC管理与性能提升要解决的关键性问题包括：①根据服务链的特点，对SFC本身进行优化；②使SFC具备动态调整和管理VNF生命周期的能力.

3) NFV硬件平台管理

该类解决方案重点考虑硬件平台的数据处理、存储和路由能力.计算、存储和网络资源的虚拟化，VNF内部物理实现的模块化和流水化对应第3象限；计算、存储和网络资源的分配与回收，对应第4象限.故该类解决方案对应第3和第4象限.

NFV硬件平台为上层提供高效的处理能力和资源管理能力.NFV硬件平台管理要考虑的方面包括：①高效的包处理机制；②高效的资源分配算法；③对网络状态的感知能力，以及利用这些网络信息辅助决策；④向用户提供可编程性；⑤系统故障容忍能力，可靠性和可用性足够高.

4) VMB的分裂、合并及节点间迁移

该类解决方案考虑NFV的可扩展性.VMB是VNF的宿主环境，需要对其实现分裂、合并和迁移操作，对应第3象限；对其分裂、合并和迁移过程中的状态管理和资源重分配对应第4象限.故该类解决方案对应第3和第4象限.

VMB的分裂、合并与迁移需要保证操作前后的一致性，需要考虑的关键性因素包括：①流状态转移的一致性；②对数据的处理粒度选择，包括流粒度、数据包粒度等；③处理VMB内部的流处理状态与剩余流路由的竞态条件问题；④迁移的效率；⑤迁移过程中的安全性.

SFC管理与性能提升立足于对逻辑实现方面进行优化，提高NFV的性能、管理和编排能力；NFV硬件平台管理立足物理实现方面的资源管理与平台整合，提高NFV性能、可靠性和可用性、可编程性；VMB分裂、合并与迁移立足于物理实现方面的3类动态操作，提高NFV的可扩展性；逻辑实现向物理实现的映射是逻辑实现与物理实现相联系的纽带，提高NFV的性能、管理和编排能力.4类方案各司其职，相辅相成.

3.2 逻辑实现向物理实现的映射

逻辑实现与物理实现映射包含2个映射场景.逻辑实现的虚拟机向物理硬件的映射，称为VM放置；逻辑实现的VNF向物理硬件的映射，称为VNF放置.

除了被映射的对象不同，二者考虑的侧重点也不同：VM放置需要结合用户流量，从满足用户SLA方面考虑；VNF放置需要考虑SFC特点，如VNF本身特点、先后顺序.需要说明的是，若限定一台VM内部运行且只运行一个或同一类VNF，VM放置等价于VNF放置.

映射模型中，物理硬件通常被抽象为拓扑节点，一个节点可以对应一个数据中心内的通用硬件设备，也可以对应一个数据中心.节点对应的内容需要看模型是否跨数据中心.

3.2.1 VM放置

VM放置关键要解决虚拟机分配硬件资源和流量在VM之间路由2个子问题.路由协议选择方面，目前文献中大多使用Openflow协议控制VMVNF之间进行网络流量路由.由IETF Spring工作组规范的分段路由(segment routing， SR)[12]技术，也具有控制VMVNF间网络流量路由的能力.

VNF聚合能提高处理器效率.文献[2]对CoMb架构进行了网络全局优化.该文考虑了把VM放置到硬件上的方案，创新地提出了HyperApp的概念.HyperApp把不同种类的VNF聚合，集中放置到同一个CPU核心上运行，以达到减少CPU上下文切换开销的目的.

一种VM放置策略是，通过建立和求解线性规划模型来实现VM间流量负载均衡.文献[2]考虑了流量路径固定场景下，网络流量分配到CoMb Box节点的映射问题.建立线性规划模型，优化目标为负载均衡.利用最小化最大节点负载的数学描述节点间的负载均衡.控制器使用CPLEX工具[13]，求解出流量分配到CoMb Box的结果.

VM放置还常常联合考虑流量在VM间的路由.文献[14]考虑了一个数据中心内部，虚拟机映射到服务节点以及放置后的网络流量路由的联合优化问题，优化目标是使各服务节点的总开销最小.该文使用了马尔可夫近似方法来求解该问题.实验结果表明，无论是低负载还是高负载，该方法的流完成时间比顺序和随机选择虚拟机都快好几倍.

3.2.2 VNF放置

VNF放置也可称为SFC映射，需要考虑如下因素.一是VNF自身特点，如按照资源消耗情况可分为：①计算密集型VNF、IO密集型VNF；②流量经过VNF的先后顺序；③不同SFC之间共享VNF、SFC长度、路径负载均衡等.另外，SFC映射的一大重要挑战是用户流量的SLA到硬件资源规模的需求对应关系，SLA会对流量带宽、吞吐量、时延、丢包率等有一定要求，NFV系统需要合理为VNF分配CPU、内存、带宽等硬件资源.

图4描述了VNF放置.图4的上半部分是逻辑实现的5个VNF和两条流；图4的下半部分是6个服务节点，每个服务节点是一个具有计算、存储和网络资源的通用硬件设备集合.一批用户流量需要按照SFC顺序处理并满足SLA需求，VNF放置即确定服务节点实例化的VNF种类和数量.

Fig. 4 VNF placement图4 VNF放置

VNF放置的关键性问题在于综合考虑以上因素.建立高效的映射模型，构建启发式算法计算出资源分配结果是一个通用的解决方法.SLA到资源规模的映射是模型中要考虑的关键性问题,通常体现在模型的启发式算法中.

部分VNF放置模型的目标是VNF数量最少.文献[15]设定，一条流允许被分割为多条子流，被后续依次流径的同类型的VNF处理，这一设定使得原解向量的每一维度由0和1扩展为0～1.该文还进行了如下设定：节点位置不可变，数据流要依次经过的节点和链路固定，只存在一种类型的VNF，一个VNF消耗固定数量的计算和存储资源.该模型设定与实际场景偏离较大.该文建立模型后，把映射问题转化为了“类集合覆盖问题”，它利用了2步贪心算法求解得到近似最优的VNF放置策略.

一些VNF放置模型的目标是开启硬件设备数量最少.文献[16]设定，节点位置固定；每个节点的NFVI资源存在上限；用户的流量和每条流的SFC固定.该文指出，对于小规模VNF问题，可利用其建立的整数线性规划模型求得最优解，通过CPLEX工具求解；而对于更大规模场景，该文给出了启发式算法，相比最优解，性能在1.3倍以内.仿真实验表明，能降低4倍以上的设备开销.文献[17]考虑了无线接入网场景下的VNF编排问题.该场景下，每个虚拟无线节点需要3种基本NFVI资源来支持转发、包处理和无线接入三大功能.该文建立了优化模型，并提出解决方案：小规模网络采用整数线性规划，大规模部署情况则采用启发式解法.

一些VNF放置模型目标是使放置后消耗的系统资源最少.而服务可用性是另一个需要保证的目标，以降低服务故障引起的用户体验下降.文献[18]考虑了服务可用性，它系统地探索了VNF冗余策略，选择一条SFC中最需要冗余的VNF.它提出了一种在线SFC映射算法，保障可用性的同时，最小化系统资源分配.

3.3 SFC管理与性能提升

用户流量按照一定的VNF顺序被依次处理，我们把该VNF序列称为SFC.该解决方案针对SFC优化，一方面为了提高SFC性能，包括降低流量处理时延和链路负载；另一方面为了提高SFC可管理性，包括SFC的动态调整能力以及解决动态包修改问题.

3.3.1 性能提升

1) 降低时延

流量时延包括VNF的处理时延和流量通过链路的时延，缩短服务链的长度是降低流量时延的有效方法之一.

一种常见的处理方法是并行化.具体方法是并行化部分VNF序列，复制多份流量经过不同的分支，遇到SFC分支合并时同时合并流量.文献[19]和文献[20]使用了并行化VNF的方法.文献[19]使用异或的方法合并流量，并通过仿真实验证明并行化能有效降低流量时延.文献[20]系统地探索了不同VNF之间的依赖关系，建立了VNF的依赖模型，得出了多种VNF的依赖表格.实验发现，并行化能降低30%以上的时延，而仅需增加8.8%的额外负载和一些复制与合并的处理能力.

另一种缩短SFC长度的方法是VNF聚合.VNF运行在应用层，如果把多个VNF聚合到同一个VMB内部，能有效减少数据流量通过协议栈的开销，从而降低时延.文献[21]在模型优化的第一阶段部分提出整合的服务链(consolidated service chain, CSC)的概念，通过计算流最坏情况执行时间，建模求解出功能邻近的VNF，把功能临近的几个VNF整合为一个VNF，以此来降低流量处理时延.

2) 降低链路负载

一种方法是调整VNF的顺序.把缩小流量的VNF放在靠前的位置、放大流量的VNF放在靠后的位置能减小链路负载.例如，假设一条速率为tbps的流进入一条SFC〈A，B，C〉，A会放大流为原来3倍，B会缩小流为原来的一半，C不会改变流大小，则经过3个VNF——A，B，C后的3条链路该流的速率分别为(3t,1.5t,1.5t)bps.若调整SFC顺序为〈B，C，A〉的链路速率为(0.5t,0.5t，1.5t)bps,能较大程度降低链路开销.

VNF重排序法是目前最常用的降低链路负载的方法.文献[22]提出了近似最优的VNF位置部署算法，使链路负载最小，但对VNF之间的依赖性考虑不充分.文献[23]则在调整VNF顺序过程中，考虑VNF之间的依赖性.该文把依赖性分成了3类，建立了NF先后顺序的依赖模型，证明了问题是NP难的，把问题等价为“最大团问题”的变种之一，利用启发式方法把问题等价为完全确定服务顺序的SFC顺序优化问题.

3.3.2 管理性增强

1) SFC动态调整能力

考虑以下场景：随着数据流量被处理完毕或新的流量到来，SFC经常会出现空闲或满载状态；租户需求发生变化，需要修改SFC或SLA；硬件设备发生故障或其他原因，需要切换部分VNF到新的服务器.为了应对上述突发情况，SFC需要具备动态调整能力.提高SFC的动态管理能力包括SFC动态修改和VNF生命周期管理.

一种解决方法是设计协议来实现整套流程的管理.文献[24]实现了一个会话级协议，实现了SFC的生命周期管理、SFC的动态调整能力.SFC的动态调整，包括增加、撤销、替换VNF，并重新调度锚节点之间的流量完成工作切换.其技术细节包括:对VNF增加Dysco agent守护进程;增加全局的控制器进行全局管理.协议支持主机移动性和多租户流量隔离的特点，但协议本身会增加一些协议栈处理时延开销.

2) 解决动态包修改问题

许多VNF会修改流量包头或包内容，例如，NAT对内外网IP映射时，会修改数据包的源IP地址；广域网优化器会发起新连接等.而防火墙或入侵检测等VNF可能需要根据源地址执行相应策略，导致防火墙处理被NAT后的流量产生错误结果.

一种解决方法是标签法.文献[25]和文献[24]通过标签对被修改的流量标记，后续VNF则根据标签来确定要执行的策略.打标签会占用数据包内字段，且需要进行标签管理.

另一种解决方法是载荷相似度匹配.文献[26]采用了该方法，匹配修改前后的流量，并对流量溯源.该方法会消耗较多计算资源，准确率大约为95%.

3.4 NFV硬件平台管理

NFV平台硬件方面由通用服务器、交换机、存储器组成，软件方面由虚拟化系统、资源管理系统组成.高效的包处理和系统资源管理是NFV的实现基础；网络感知能帮助NFV平台决策资源分配与回收；系统可编程性向用户提供统一的编程接口，实现VNF生态化；系统可靠性和可用性保障用户体验.NFV硬件平台与系统联系紧密，这方面研究更偏向架构创新和工程实现.

3.4.1 提高包处理效率

数据包处理是VNF的基本能力，高效的包处理方式能提高系统吞吐量.

数据包的批处理机制是数据包的处理方法之一.文献[27]是基于可编程路由器[28]编写的软件虚拟平台，通过减少系统调用的次数、引入批处理、减少不必要的软件层代码和数据经过路径等手段能有效提高包处理效率.

并行处理是一种加快包处理的方法.文献[28]探索了并行和串行的处理方式，并提出整合网络功能模块、利用OpenFlow分离不同大小的流、转发到VNF模块处理的方法.

模块化VNF内部处理流程是一种更为创新的方法.文献[29]提出，传统不同种类的Middlebox之间存在一些通用模块，如VPN、Web服务器、邮件服务器、IDS、代理服务器对进入的流量都需要先经过协议解析器，而几乎所有Middlebox都有一个会话管理器进行流量会话的生命周期管理，并行化和组合这些模块有助于提高包处理效率.文献[30]系统地研究了防火墙、负载均衡器和入侵防御系统3类VNF的模块化处理流程，利用模块间的并行性和复用，降低了流量要经过的路径长度，从而降低了数据时延，提高了系统吞吐量.另外，还利用了SDN技术进行VNF的中心化管理.

3.4.2 提高系统资源利用率

系统资源管理包括资源分配和回收2方面.高效的系统资源管理能为企业节省设备采购开销和运营开销.文献[2]统计一家公司的机房内流量后发现，一天内的不同时间段，该企业网对不同NF数量和负载的需求量有很大差异.设想这样一个场景，在时间段X内，一家企业需要N1台支持NFa的设备满载，N2台支持NFb的设备满载；而在时间段Y内，需要N3台NFa设备满载，N4台NFb设备满载.则要满足2个时段网络负载，该公司需要Max(N1,N3)台设备来支持NFa，Max(N2,N4)台设备来支持NFb.即至少需要Max(N1+N2,N3+N4)台NF设备才能满足X,Y两个时间段的网络需求.在实际环境中，总是出现N1>N2,N3

目前的解决方案通常在资源管理算法上创新.文献[2]把自己设计的Middlebox平台称为CoMb，把运行统一的通用硬件设备称为CoMb box.该文设计了一个集中式的NFV设备管理体系结构，由控制器集中式管理CoMb box，在CoMb box内部构建了资源的整数线性规划模型对计算和内存资源管理，以最大设备负载最小化为优化目标，减少总CoMb box数量为目标，以提高整个系统的资源利用率.文献[21]构建了在线阶段的资源模型和分配算法，根据当前网络状态和用户请求的流数据，把固定流量分配到硬件设备.

3.4.3 增加网络感知能力

网络感知能力是NFV硬件平台获取网络状态的能力，这些感知到的数据可以帮助提前预知未来网络状态变化，辅助NFV平台进行资源分配和回收决策.

一种方法是建立一套完整的系统反馈机制.文献[31]提出的Stratos系统，是一种方便用户部署、管理和配置网络功能设备的框架，并且具备网络监测和反馈功能，能自主地检测到网络瓶颈链路进行反馈，调整负载均衡.然而，由于整个反馈过程的滞后性，具有不够实时、不具有预防性能瓶颈的能力等缺点.

另一方面，网络感知能力不仅与模型、算法与调节系统相关，更灵敏的传感器、更细粒度和有效及时的测量方法同样有助于提升系统的网络感知能力.

3.4.4 提高网络功能的可编程性

实现NFV的可编程性需要从软件和硬件2方面着手.软件方面，需要向用户开放标准统一的编程接口，以方便个人用户和其他VNF厂商自定义网络功能.硬件方面，Intel DPDK、Linux NAPI、向量报文处理(vector packet processing， VPP)[32]等开源技术，以及通用的x86架构处理器有助于从更底层支持可编程性.

目前的学术研究主要从软件方面，提供一定的可编程性.文献[30]实现了开放的NFV系统平台，定义了标准的南北向接口，是一个开放、易部署的软件定义框架.文献[33]在使用C++实现xOMB平台的10个标准网络处理模块代码.

系统标准化地实现网络功能的可编程性，是一项繁杂的工作.目前的研究中，只是简单地实现了少数一些API.要实现NFV的可编程性，还需要标准化组织制定详细清晰的标准.

3.4.5 提高系统的可用性

提高NFV系统平台的可用性可以通过提高系统平均故障间隔时间或减少系统平均故障恢复时间2种手段实现[18,34].增加冗余、实现故障发生时快速切换技术、提高系统平台本身的稳定性等方式能有效提高系统的可用性.

一种常用的方法是冗余备份.文献[33]部署控制器时，使用了保持状态机副本技术等技术，确保控制器发生故障时，拥有备份状态用于快速恢复，降低故障恢复时间.

另一种常用的方法是部署过程，对流量进行分布式放置，以具备故障预防能力.文献[31]采用把流量跨机架放置的策略，降低单点故障对租户流量的影响面积，提高服务的可用性.

3.5 VMB分裂、合并及节点间转移

NFV具有可移植性和可扩展性.可移植性体现在VMB可以在节点间迁移，这里的节点指通用的硬件服务器；可扩展性体现在VMB可分裂、合并，以满足流量大小变化时硬件资源的分配和回收.

3.5.1 VMB在网络节点间迁移

与3.3.2节中提到的VNF迁移不同，其迁移对象是VNF而不迁移其宿主环境，它的主要工作是迁移流状态和路由剩余流量.而VMB迁移的对象是VNF宿主环境，主要工作是拷贝VMB内存数据和处理器状态.

VMB在网络节点间迁移通常发生在下述场景：1)某节点的硬件故障或操作系统故障导致系统宕机；2)更换某节点旧设备为新设备.VMB在节点间迁移需要考虑迁移效率和安全性等方面.

1) 提高迁移效率

VMB迁移过程涉及多次内存拷贝、流状态转移、系统状态转移，整个过程中消耗的带宽资源比较大，整个过程耗时也较长，提高迁移效率能大大提高用户体验.

一种方法是使用压缩算法.文献[35]考虑虚拟机的实时迁移，迁移过程使用压缩算法.实质上是消耗计算资源来节省带宽资源，压缩率会根据实际带宽情况动态调整，实现了一个更具网络带宽情况，动态变换压缩率，提高VMB迁移效率的算法.该文献并未考虑迁移过程的流状态转移.

2) 增加迁移过程的安全性

由于VMB在节点间迁移过程对网络资源消耗较大，若迁移期间遭受网络黑客的DDoS攻击，将大大增加网络收敛时间.

隐藏迁移的流量特征是增加迁移安全性的一种预防性方案，一种方法是加入冗余流量.文献[36]提出隐性迁移VMB，使用了该方法.使黑客无法通过监测流量模式确定网络是否在进行VMB迁移，即使迁移过程透明化.

Fig. 5 VMB scale in图5 VMB收缩

3.5.2 VMB的分裂与合并

图5反映了2种VMB需要收缩的情况，图5中VMB的灰色部分表示其工作负载，一般情况下，VMB处理的流量越多，其工作负载越大.图5(a)表示2台负载不均衡的VMB；图5(b)表示3台负载较轻的VMB；这2种情况都需要进行VMB的收缩，收缩方式如图5(c)，收缩后将减少VMB的数量，节省电能.另外，当一台VMB开销过大，一旦新的流量到来使该VMB负载继续增加，而负载过高会导致流量处理时间过长甚至系统崩溃，为防止以上情况发生，VMB需要及时分裂，以保持VMB具有少数空闲容量.把VMB的这种分裂与合并能力称为横向可扩展性.

VMB的分裂与合并前，如果原VMB已经处理了一部分流量且未处理完，此时需要对VMB内部状态和流状态进行迁移，二者存在竞态条件问题.

一种常见的策略是“鸵鸟策略”，即先转移VMB内部状态，再路由之后到来的流量，而对转移过程中丢失的流量则不采用应对机制.文献[37]针对NFV的横向可扩展性，提出了系统性的解决方案——SplitMerge，考虑了分裂合并过程中的流状态转移.在VMB转移后，利用SDN交换机OpenFlow协议，进行分裂后的流量的细粒度调度.采用的是先转移VMB内部流状态，再转移流的顺序，而并未考虑二者的竞态条件问题.

一种创新性的解决竞态条件问题的方法是利用控制器缓存.文献[38]则考虑了竞态条件问题，它认为文献[37]的方法转移的流量状态并不完整，会导致部分VNF计算出错误结果.因为部分VNF要求处理完整流量(如：IDS检测恶意软件，需要计算整条流的Hash值)，于是，该文重点考虑了流的完整性转移.它利用了以下解决方法：1)流分类，并定义get,put,delete这3类处理流的API；2)迁移过程中的流量缓存到控制器中，避免包丢失问题；3)加锁机制避免缓存包与包乱序；4)该文通过将正在迁移时间段到达的流量缓存到SDN控制器内的方法，保证了VNF流量的完整性.

4 方法总结

表1对4种方案进行了总结.

Table 1 NFV Solutions表1 NFV解决方案

逻辑实现向物理实现的映射，分为VM放置和VNF放置.通常思路是建立模型和寻找启发式求解算法.模型需要考虑多样性的拓扑、用户流量大小、SLA、链路可用带宽和负载等多种因素.模型的目标函数和约束条件可选范围很广，包括负载均衡、开启设备数量最少、流完成时间最短、虚拟资源消耗最低、链路负载最小、服务可用性最高等，需要根据实际需求设定.该类解决方案中，启发式算法对计算资源消耗较多.

SFC的管理性与性能提升.性能提升方面，并行化、VNF聚合有助于降低时延，但需要消耗网络和存储资源；VNF重排序有助于降低链路负载，重排序算法需要消耗部分计算资源.管理性方面，设计协议进行VNF生命周期管理，以及定义SFC动态修改的操作工作流有助于提高SFC的可自主性和管理性，需要一些处理开销；打标签和载荷相似度匹配是解决SFC“动态包修改”的2种方法，前者需要进行标签管理并需要占用包内字段，后者准确率不足.

NFV硬件平台管理.软件包处理能力方面，并行化和模块化是2种常用方法，需要更底层的支持；系统资源利用率的提高需要靠良好的资源管理模型来决策虚拟计算、存储和网络资源的分配和回收；网络感知数据则可作为资源分配和回收的决策数据之一，提高系统的自我调节能力；系统可编程方面，软件方面需要提供标准的可编程接口支持，同时需要底层硬件与驱动技术的支持；系统可用性方面，分配流量时，把同一租户的流量尽量分散，以防止单点故障，运行过程中加入模块冗余技术，以便于快速恢复.

VMB在节点间迁移是实现NFV灵活性的基础.提高迁移效率方面，引入压缩算法是一种有效做法.迁移的安全性方面，加入冗余流量隐藏VM迁移过程的流量特征是一种有效的预防措施.VMB的分裂与合并是NFV的可扩展性基础，需要处理好VMB内部处理状态的迁移和剩余流量的路由，利用控制器对状态转移过程中的少量流量缓存是解决竞态条件问题的方法之一，但需要消耗控制器的存储资源.

5 进一步需要研究的问题

尽管NFV技术领域已经取得许多科研成果，但要实现商业化，仍面临诸多挑战.我认为，NFV需要进一步研究的方向包括3方面:

1) SFC映射和放置策略

理想的管理和编排方案下，VNF与用户流量完美匹配，利用最少的开销达到最及时无延迟的流量处理.结合边缘计算和CDN的思路，把使用频率高、功能单一的、与数据中心相关性低的VNF放置到距离用户比较近的网络边缘或许对降低流量时延有积极作用.

目前已有许多放置模型，通过VNF顺序、SFC长度、用户流量的SLA、路径负载等多个输入参数来确定硬件资源分配这一输出参数，或许能利用当前热门的机器学习来获取更优解，但产生训练数据集是一个难点.

2) NFV硬件平台性能提升

硬件加速技术，有助于从底层提升NFV平台性能.但同时也要注意保持底层x86硬件与VNF的低耦合性，以符合NFV的灵活性和通用化硬件的目标.多核心信息共享，非统一内存访问(non-uniform memory access， NUMA)[39]技术，Cisco捐赠的已商用的VPP库，有助于从驱动、系统、网络处理层面提升平台性能.

3) NFV安全性提升

NFV技术要实现商用，必然面临安全性问题.拓扑验证、网络性能隔离、NFV系统的准入、域内多管理员隔离等安全方面研究目前还较少，并且需要结合NFV的特性进行安全性加强，如迁移过程中的状态一致性等方面.

6 结束语

本文对NFV技术的发展现状和已有研究成果进行了综述.结合NFV体系架构，提出“四象限”分类方法，并归纳出了4个研究方向.详细分析和比较了典型的解决方案，总结了各方案的优势和开销.最后从3个方面讨论了进一步需要研究的问题.

[1]Carpenter B, Brim S. RFC3234: Middleboxes: Taxonomy and issues[EBOL]. [2018-02-04]. https:tools.ietf.orghtmlrf c3234

[2]Sekar V, Egi N, Ratnasamy S, et al. Design and implementation of a consolidated middlebox architecture[C]Proc of USENIX NSDI’12. Berkeley，CA: USENIX Association, 2012: 24-24

[3]Greenberg A, Hamilton J, Maltz D A, et al. The cost of a cloud: Research problems in data center networks[J]. ACM SIGCOMM Computer Communication Review, 2008, 39(1): 68-73

[4]Han Bo, Gopalakrishnan V, Ji Lusheng, et al. Network function virtualization: Challenges and opportunities for innovations[J]. IEEE Communications Magazine, 2015, 53(2): 90-97

[5]IETF SFC. Service function chaining[EBOL]. [2018-02-04]. https:datatracker.ietf.orgwgsfcdocuments

[6]IETF SPRING. Source packet routing in networking[EBOL]. [2018-02-04]. https:datatracker.ietf.orgwgspringdocuments

[7]ETSI GS NFV. Network Function Virtualization(NFV) Architectural Framework[EBOL]. [2018-02-04]. http:www.etsi.orgdeliveretsi_gsnfv001_09900201.01.01_60gs_nfv002v010101p.pdf

[8]DPDK Project. Intel DPDK: Data plane development kit project[EBOL]. [2018-02-04]. http:www.dpdk.orgdoc

[9]Linux Foundation. Linux Foundation Wiki: NAPI[EBOL]. [2018-02-04]. https:wiki.linuxfoundation.orgnetworkingn api

[10]McKeown N, Anderson T, Balakrishnan H, et al. OpenFlow: Enabling innovation in campus networks[J]. ACM SIGCOMM Computer Communication Review, 2008, 38(2): 69-74

[11]Jain S, Kumar A, Mandal S, et al. B4: Experience with a globally-deployed software defined WAN[J]. ACM SIGCOMM Computer Communication Review, 2013, 43(4): 3-14

[12]Filsfils C, Nainar N K, Pignataro C, et al. The segment routing architecture[C]Proc of IEEE GLOBECOM’15. Piscataway, NJ: IEEE, 2015: 1-6

[13]IBM. User’s Manual for CPLEX[EBOL]. [2018-02-04]. https:www.ibm.comsupportknowledgecenterenSSSA5P_12.6.0ilog.odms.cplex.helpCPLEXhomepagesusrmancplex.html

[14]Jiang Joe Wenjie, Lan Tian, Ha Sangtae, et al. Joint VM placement and routing for data center traffic engineering[C]Proc of IEEE CNSM’12. Piscataway, NJ: IEEE, 2012: 2876-2880

[15]Sang Yu, Ji Bo, Gupta G R, et al. Provably efficient algorithms for joint placement and allocation of virtual network functions[C]Proc of IEEE INFOCOM’17. Piscataway, NJ: IEEE, 2017: 829-837

[16]Bari M F, Chowdhury S R, Ahmed R, et al. On orchestrating virtual network functions[C]Proc of IEEE CNSM’15. Piscataway, NJ: IEEE, 2015: 50-56

[17]Riggio R, Bradai A, Rasheed T, et al. Virtual network functions orchestration in wireless networks[C]Proc of IEEE CNSM’15. Piscataway, NJ: IEEE, 2015: 108-116

[18]Fan Jingyuan, Guan Chaowen, Zhao Yangming, et al. Availability-aware mapping of service function chains[C]Proc of IEEE CNSM’17. Piscataway, NJ: IEEE, 2017: 1-9

[19]Zhang Yang, Anwer B, Gopalakrishnan V, et al. ParaBox: Exploiting parallelism for virtual network functions in service chaining[C]Proc of ACM SOSR’17. New York: ACM, 2017: 143-149

[20]Sun Chen, Bi Jun, Zheng Zhilong, et al. NFP: Enabling network function parallelism in NFV[C]Proc of ACM SIGCOMM’17. New York: ACM, 2017: 43-56

[21]Li Yang, Phan L T X, Loo B T. Network functions virtualization with soft real-time guarantees[C]Proc of IEEE INFOCOM’16. Piscataway, NJ: IEEE, 2016: 1-9

[22]Ma Wenrui, Sandoval O, Beltran J, et al. Traffic aware placement of interdependent NFV middleboxes[C]Proc of IEEE INFOCOM’17. Piscataway, NJ: IEEE, 2017: 1-9

[23]Cohen R, Lewin-Eytan L, Naor J S, et al. Near optimal placement of virtual network functions[C]Proc of IEEE INFOCOM’15. Piscataway, NJ: IEEE, 2015: 1346-1354

[24]Zave P, Ferreira R A, Zou X K, et al. Dynamic service chaining with dysco[C]Proc of ACM SIGCOMM’17. New York: ACM, 2017: 57-70

[25]Fayazbakhsh S K, Sekar V, Yu M, et al. Flowtags: Enforcing network-wide policies in the presence of dynamic middlebox actions[C]Proc of ACM HotSDN’13. New York: ACM, 2013: 19-24

[26]Qazi Z A, Tu C C, Chiang L, et al. SIMPLE-fying middlebox policy enforcement using SDN[J]. ACM SIGCOMM Computer Communication Review, 2013, 43(4): 27-38

[27]Martins J, Ahmed M, Raiciu C, et al. ClickOS and the art of network function virtualization[C]Proc of USENIX NSDI’14. Berkeley，CA: USENIX Association, 2014: 459-473

[28]Kohler E, Morris R, Chen B, et al. The click modular router[J]. ACM Trans on Computer Systems, 2000, 18(3): 263-297

[29]Greenhalgh A, Huici F, Hoerdt M, et al. Flow processing and the rise of commodity network hardware[J]. ACM SIGCOMM Computer Communication Review, 2009, 39(2): 20-26

[30]Bremler-Barr A, Harchol Y, Hay D. OpenBox: A software-defined framework for developing, deploying, and managing network functions[C]Proc of ACM SIGCOMM’16. New York: ACM, 2016: 511-524

[31]Gember A, Krishnamurthy A, John S S, et al. Stratos: A network-aware orchestration layer for middleboxes in the cloud[R]. Ithaca, NY: Cornell University Library, 2013

[32]Linux Foundation. Vector Packet Processing (VPP)[EBOL]. [2018-02-04]. https:fd.iotechnology

[33]Anderson J W, Braud R, Kapoor R, et al. xOMB: Extensible open middleboxes with commodity servers[C]Proc of ACMIEEE ANCS’12. Piscataway, NJ: IEEE, 2012: 49-60

[34]Yang Xu, Xiao Ziyu, Shao Yongping, et al. Discussion on the reliability of NFV[J]. Telecommunications Science, 2017, 33(7): 136-143 (in Chinese)(杨旭, 肖子玉, 邵永平, 等. NFV可靠性探讨[J]. 电信科学, 2017, 33(7): 136-143)

[35]Li Chunguang, Feng Dan, Hua Yu, et al. BAC: Bandwidth-aware compression for efficient live migration of virtual machines[C]Proc of IEEE INFOCOM’17. Piscataway, NJ: IEEE, 2017: 1-9

[36]Achleitner S, La Porta T, McDaniel P, et al. Stealth migration: Hiding virtual machines on the network[C]Proc of IEEE INFOCOM’17. Piscataway, NJ: IEEE, 2017: 1-9

[37]Rajagopalan S, Williams D, Jamjoom H, et al. SplitMerge: System support for elastic execution in virtual middleboxes[C]Proc of USENIX NSDI’13. Berkeley, CA: USENIX Association, 2013: 227-240

[38]Gember-Jacobson A, Viswanathan R, Prakash C, et al. OpenNF: Enabling innovation in network function control[C]Proc of ACM SIGCOMM Computer Communication Review. New York: ACM, 2014, 44(4): 163-174

[39]Lameter C. NUMA (non-uniform memory access): An overview[J]. Queue, 2013, 11(7): 40-52

ZhouWeilin, born in 1995. Master candidate of Beijing University of Posts and Telecommunications. His main research interest is network function virtualization.