Labs 导读
NFV技术从诞生起，从根本上来说就是为了解决运营商网络演进中部署成本高，迭代更新慢，架构僵化等痛点问题。同时，在引入NFV技术前，旧有产业链相对单一，核心成员主要包括设备制造商、芯片制造商等，而NFV引入后拉长了整体通信产业链条，传统设备制造商面临严峻的挑战，原本软硬件一体化设备销售模式被拆解为通用硬件、虚拟化平台和网元功能三部分销售模式。这也直接决定了运营商期望的多层解耦部署模式推行困难。同时，在NFV的转发性能提升、MANO管理模式选型、VNFM选型和NFVO部署等方面也多多少少存在影响电信云落地的问题。
1 NFV部署模式选型
NFV通过软硬件解耦，使得网络设备开放化，软硬件可以独立演进，避免厂家锁定。基于NFV分层解耦的特性，根据软硬件解耦的开放性不同，可将集成策略分为单厂家、共享资源池、硬件独立和三层全解耦4种方案，如下图所示。
方案1：单厂家方案，优点就是可以实现快速部署，整体系统的性能、稳定性与可靠性都比较理想，不需要进行异构厂商的互通测试与集成。缺点是与传统网络设备一样，存在软硬件一体化和封闭性问题，难以实现灵活的架构部署，不利于实现共享；与厂商存在捆绑关系，不利于竞争，会再次形成烟囱式部署，总体成本较高，也不利于自主创新以及灵活的迭代式部署升级。目前，中国电信的4G/VoLTE/IMS网络就是采用这种方式，在短期内对中国移动的业务发展形成较大压力。
方案2：倾向于IT化思路，选择最好的硬件平台和虚拟机产品，要求上层应用向底层平台靠拢。只对VNF与NFVI层解耦，VNF能够部署于统一管理的虚拟资源之上，并确保功能可用、性能良好、运行情况可监控、故障可定位；不同供应商的VNF可灵活配置、可互通、可混用、可集约管理。其中，VNFM与VNF通常为同一厂商（即“专用VNFM”），这种情况下VNF与VNFM之间的接口不需标准化；特殊场景下采用跨厂商的“VNFM”（即“通用VNFM”）。VMware的解决方案就是典型的方案二厂商A的定位，考虑到中国移动苏州研发中心与VMware的战略合作情况，可以预期不远的将来中国移动的NFV网络架构中会出现类似部署方案。
方案3：倾向于电信思路，通用硬件与虚拟化层软件解耦，基础设施全部采用通用硬件，实现多供应商设备混用；虚拟化层采用商用/开源软件进行虚拟资源的统一管理。可以由电信设备制造商提供所有软件，只是适配在IT平台上。目前，中国移动大区集中化网络建设就是采用此部署方案。
方案4：全解耦的好处是可以实现通用化、标准化、模块化、分布式部署，架构灵活，而且部分核心模块可选择进行定制与自主研发，也有利于形成竞争，降低成本，实现规模化部署；不利的地方是需要规范和标准化，周期很长，也需要大量的多厂商互通测试，需要很强的集成开发能力，部署就绪时间长，效率较低，后续的运营复杂度高，故障定位和排除较为困难，对运营商的运营能力要求较高。该模式是中国移动一直不遗余力推广的模式，目前在陕西移动已初步完成苏研VIM+分布式存储、华为VNFM和研究院NFVO+的标准三层部署模式验证，并打通了标准三层组网下FirstCall。
另外，以上各方案都涉及MANO的解耦，涉及运营商自主开发或者第三方的NFVO与不同厂商的VNFM、VIM之间的对接和打通，屏蔽了供应商间的差异，统一实现网络功能的协同、面向业务的编排与虚拟资源的管理。但是，NFVO+的解耦目前还停留在实验验证阶段，在中国移动的电信云一阶段还是采用NFVO与VNFM同厂商捆绑的模式。
2 NFV转发性能的提升
NFV设计的初衷是针对部分低转发流量类业务功能，x86服务器在配备高速网卡（10Gbit/s）后，业务应用不经特殊优化，基本也可以满足大多数低速率转发业务的处理要求（即使后续随着SDN技术的推动，引入了40Gbit/s的高速转发能力，但目前也只是实验验证阶段，并未实际部署）。
传统硬件网元能够通过专用芯片实现高转发性能，而x86环境下的虚拟化网元尚不具备万兆以上端口的小包线速转发能力，在同等业务量的情况下，虚拟化网元和传统设备相比存在一定的性能差距。x86服务器采用软件转发和交换技术，报文在服务器各层面间传递，会受到CPU开销等多方面因素的影响，因此服务器的内部转发性能是NFV系统的主要瓶颈。
NFV中的网络业务应用运行于服务器的虚拟化环境中，单个应用业务流量的收发要经过虚拟化层、服务器I/O通道、内核协议栈等多个处理流程，而多个应用业务之间又可以用复杂的物理或虚拟网络相连接。因此，NFV系统的整体性能取决于单服务器转发性能与业务组链转发性能两个方面。如下所示：
业务应用流量的收发I/O通道依次包括物理网卡、虚拟交换机、虚拟网卡3个环节（见上图左半部分）；从软件结构上看，报文的收发需要经过物理网卡驱动、宿主机内核网络协议栈、内核态虚拟交换层、虚拟机网卡驱动、虚拟机内核态网络协议栈、虚拟机用户态应用等多个转发通道（见上图右半部分），存在着海量系统中断、内核上下文切换、内存复制、虚拟化封装/解封等大量CPU开销操作过程。
2.1 影响NFV转发性能的主要因素
2.1.1 网卡硬件中断
目前大量流行的PCI/PCIe（Peripheral Component Interconnect，外设部件互连标准/PCI-Express）网卡在收到报文后，一般采用DMA（Direct Memory Access，直接存储器存取）方式直接写入内存并产生CPU硬件中断，在低速转发应用中此方法十分有效。
但是，当网络流量激增时，CPU的大部分时间阻塞于中断响应。在多核系统中，可能存在多块网卡绑定同一个CPU核的情况，使其占用率达到100%。中断处理方式在低速网络I/O场景下非常有效。然而，随着高速网络接口等技术的迅速发展，10Gbit/s、40Gbit/s甚至100Gbit/s的网络端口已经出现。随着网络I/O速率的不断提高，网卡面对大量高速数据分组引发频繁的中断，中断引起的上下文切换开销将变得不可忽视，造成较高的时延，并引起吞吐量下降。因此，网卡性能改进一般采用减少或关闭中断（如轮询取代中断、零复制技术、大页内存技术等）、多核CPU负载均衡等优化措施。
2.1.2 内核网络协议栈
在Linux或FreeBSD系统中，用户态程序调用系统套接字进行数据收发时，会使用内核网络协议栈。这将产生两方面的性能问题：一是系统调用导致的内核上下文切换，会频繁占用CPU周期；二是协议栈与用户进程间的报文复制是一种费时的操作。
NFV系统中，业务应用报文处理从物理网卡到业务应用需要完成收发操作各1次，至少经过4次上下文切换（宿主机2次以及VM内2次）和4次报文复制。将网络协议栈移植到用户态是一种可行的思路，但这种方法违反了GNU协议。GNU是GNU GPL（GNU General Public License，通用公共许可证）的简称，Linux内核受GNU GPL保护，内核代码不能用于Linux内核外。因此，弃用网络协议栈以换取转发性能，是唯一可行的办法，但需要付出大量修改业务应用代码的代价。
2.1.3 虚拟化层的封装效率
业务应用中存在两类封装：服务器内部的I/O封装和网络层对流量的虚拟化封装。前者是由于NFV的业务应用运行于VM中，流量需要经历多次封装/解封装过程，包括：宿主机虚拟化软件对VM的I/O封装、虚拟交换机对端口的封装、云管理平台对虚拟网络端口的封装；后者是为实现NFV用户隔离，在流量中添加的用户标识，如VLAN、VxLAN（Virtual Extensible Local Area Network，可扩展虚拟局域网）等。这两类封装/解封均要消耗CPU周期，会降低NFV系统的转发效率。
2.1.4 业务链网络的转发效率
NFV的业务链存在星形和串行两种组网方式，如下图所示。
星形连接依赖于物理网络设备的硬件转发能力，整体转发性能较优，但当应用的数量较大时，会消耗大量网络设备端口。因此，在业务链组网范围不大时，如在IDC内部，为简化组网和节约端口，更多地采用串行连接。
当串行连接时，NFV控制器需要在多个业务应用中选择合适位置的应用进程或进程组来处理流量，以均衡各应用负荷并兼顾业务链网络性能。不合适的负载均衡算法会造成流量在不同进程组的上下行链路之间反复穿越，严重降低业务链网络的带宽利用率。
2.1.5 其他开销
缓存未命中开销：缓存是一种能够有效提高系统性能的方式，然而，由于设计的不合理造成频繁的缓存未命中，则会严重削弱NFV数据平面的性能。
锁开销：当多个线程或进程需要对某一共享资源进行操作时，往往需要通过锁机制来保证数据的一致性和同步性，而加锁带来的开销会显著降低数据处理的性能。
上下文切换开销：NFV的扩展需要多核并行化的支持，然而在该场景下，数据平面需要进行资源的分配调度，调度过程中涉及多种类型的上下文切换。在网卡中断、系统调用、进程调度与跨核资源访问等上下文切换过程中，操作系统均需要保存当前状态，而这一类的切换开销往往相当昂贵，严重影响系统性能。
以上3种开销对于NFV转发性能的影响较大，在实际的转发过程中，开销不止这3种。
2.2 NFV引入的开源技术
针对以上影响转发性能的挑战，NFV在落地过程引入不同开源技术进行应对，具体的实现原理会在第二部分《NFV关键技术》中详细阐述，这里只是做一个简单的介绍，使初学者有个概念性的了解。
2.2.1 轮询取代中断
作为I/O通信的另一种方式，轮询不存在中断所固有的开销。以网卡接收分组为例，在轮询模式下，系统会在初始化时屏蔽收发分组中断，并使用一个线程或进程来不断检测收取分组描述符中的收取分组成功标志是否被网卡置位，以此来判断是否有数据分组。整个收取过程没有发生上下文切换，因此也就避免了相应的开销。
当I/O速率接近CPU速率时，中断的开销变得不可忽略，轮询模式的优势明显；相反，如果数据吞吐率很低，中断能有更好的CPU利用率，此时不宜采用轮询模式。基于以上分析，针对网络流量抖动较大的场景，可以选用中断与轮询的混合模式，即在流量小时使用中断模式，当遇到大流量时切换为轮询模式。目前Linux内核与DPDK都支持这种混合中断轮询模式。
2.2.2 零复制技术
零复制技术主要用以避免CPU将数据从一个内存区域复制到另一个内存区域带来的开销。在NFV数据平面操作的场景下，零复制指的是除网卡将数据DMA复制进内存外（非CPU参与），从数据分组接收到应用程序处理数据分组，整个过程中不存在数据复制。零复制技术对于高速网络而言是十分必要的。
DPDK、Netmap、PF-ring等高性能数据分组处理框架都运用了零复制技术，可以实现在通用平台下高效的网络处理，大幅提升单服务器内的报文转发性能。进一步地，DPDK不仅实现了网卡缓冲区到用户空间的零复制，还提供虚拟环境下的虚拟接口、兼容OpenvSwitch虚拟交换机、专为短小报文提供的hugepage访问机制等实用技术。
上述开源方案能很好地满足NFV中DPI（Deep Packet Inspection，深度数据包检测）、防火墙、CGN（Carrier-Grade NAT <Network Address Translation>，运营商级网络地址转换）等无需协议栈的网络业务功能，但存在着大量改写原有业务应用套接字的问题，应用中需要在性能提升与代码改动之间进行取舍。
2.2.3 高效虚拟化技术
目前在NFV领域常用的高效虚拟化技术大致可以归为以下两类。
基于硬件的虚拟化技术
I/O透传与SR-IOV是两种经典的虚拟化技术。I/O透传指的是将物理网卡直接分配给客户机使用，这种由硬件支持的技术可以达到接近宿主机的性能。不过，由于PCIe设备有限，PCI研究组织提出并制定了一套虚拟化规范——SR-IOV，即单根I/O虚拟化，也就是一个标准化的多虚机共享物理设备的机制。完整的带有SR-IOV能力的PCIe设备，能像普通物理PCIe设备那样被发现、管理和配置。
SR-IOV主要的应用还是在网卡上，通过SR-IOV，每张虚拟网卡都有独立的中断、收发队列、QoS等机制，可以使一块物理网卡提供多个虚拟功能（VF），而每个VF都可以直接分配给客户机使用。
SR-IOV使虚拟机可以直通式访问物理网卡，并且同一块网卡可被多个虚拟机共享，保证了高I/O性能，但SR-IOV技术也存在一些问题。由于VF、虚端口和虚拟机之间存在映射关系，对映射关系的修改存在复杂性，因此除华为外，大部分厂商目前还无法支持SR-IOV场景下的虚拟机迁移功能。另外，SR-IOV特性需要物理网卡的硬件支持，并非所有物理网卡都提供支持。
半虚拟化技术
半虚拟化无需对硬件做完全的模拟，而是通过客户机的前端驱动与宿主机的后端驱动一同配合完成通信，客户机操作系统能够感知自己处在虚拟化环境中，故称为半虚拟化。由于半虚拟化拥有前后端驱动，不会造成VM-exit，所以半虚拟化拥有更高的性能。主流虚拟化平台Xen就使用了半虚拟化的驱动，半虚拟化比起SR-IOV的优势在于支持热迁移，并且可以与主流虚拟交换机对接。但是，在大流量转发场景下，前后端驱动中Domain0也是最大的瓶颈。
2.2.4 硬件分流CPU能力
CPU具有通用性，需要理解多种指令，具备中断机制协调不同设备的请求，因此CPU拥有非常复杂的逻辑控制单元和指令翻译结构，这使得CPU在获得通用性的同时，损失了计算效率，在高速转发场景下降低了NFV的转发性能。
业界普遍采用硬件分流方法来解决此问题，CPU仅用于对服务器进行控制和管理，其他事务被卸载到硬件进行协同处理，降低CPU消耗，提升转发性能。
网卡分流技术是将部分CPU事务卸载到硬件网卡进行处理，目前大多数网卡设备已经能够支持卸载特性。网卡卸载的主要功能有：数据加解密、数据包分类、报文校验、有状态流量分析、Overlay报文封装和解封装、流量负载均衡，以及根据通信协议最大传输单元限制，将数据包进行拆分或整合。
除此之外，CPU+专用加速芯片的异构计算方案也是一种硬件分流思路。异构计算主要是指使用不同类型指令集（X86、ARM、MIPS、POWER等）和体系架构的计算单元（CPU、GPU、NP、ASIC、FPGA等）组成系统的计算方式。在NFV转发性能方面，使用可编程的硬件加速芯片（NP、GPU和FPGA）协同CPU进行数据处理，可显著提高数据处理速度，从而提升转发性能。
2.2.5 整体优化方案DPDK
PCI直通、SR-IOV方案消除了物理网卡到虚拟网卡的性能瓶颈，但在NFV场景下，仍然有其他I/O环节需要进行优化，如网卡硬件中断、内核协议栈等。开源项目DPDK作为一套综合解决方案，对上述问题进行了优化与提升，可以应用于虚拟交换机和VNF。DPDK是Intel提供的数据平面开发工具集，为Intel处理器架构下用户空间高效的数据包处理提供库函数和驱动的支持。它不同于Linux系统以通用性设计为目的，而是专注于网络应用中数据包的高性能处理。有关DPDK的详细介绍，大家可参见《深入浅出DPDK》这本书。
一般来说，服务器上的每个CPU核会被多个进程/线程分时使用，进程/线程切换时，会引入系统开销。DPDK支持CPU亲和性技术，优化多核CPU任务执行，将某进程/线程绑定到特定的CPU核，消除切换带来的额外开销，从而保证处理性能。
同时，DPDK支持巨页内存技术。一般情况下，页表大小为4KB，巨页技术将页表尺寸增大为2MB或1GB，使一次性缓存内容更多，有效缩短查表消耗时间。同时，DPDK提供内存池和无锁环形缓存管理机制，加快了内存访问效率。
报文通过网卡写入服务器内存的过程中，会产生CPU硬件中断，在数据流较大的情况下，硬件中断会占用大量时间。DPDK采用轮询机制，跳过网卡中断处理过程，释放了CPU处理时间。服务器对报文进行收发时，会使用内核网络协议栈，由此产生内核上下文频繁切换和报文拷贝问题，占用了CPU周期，消耗了处理时间。DPDK使用户态进程可直接读写网卡缓冲区，旁路了内核协议栈处理。
DPDK以用户数据I/O通道优化为基础，结合Intel虚拟化技术（主要是VT-d技术）、操作系统、虚拟化层与虚拟交换机等多种优化方案，形成了完善的转发性能加速架构，并开放了用户态API供用户应用程序访问。DPDK已逐渐演变为业界普遍认可的完整NFV转发性能优化技术方案。但目前DPDK还无法达到小包线速转发，仍需进行性能提升研究和测试验证工作。
3
运营商如何推动三层解耦落地？
在NFV方面，解耦是首当其冲的问题，目前业界有不解耦、软硬件解耦和三层解耦这3种思路，其中软硬件解耦又分为共享虚拟资源池和硬件独立两种方案，不同方案的对比介绍在本文的NFV部署模式部分已有介绍，这里不再赘述。
不解耦无法实现硬件共享，运营商依赖厂商，网络开放能力弱，不支持自动化部署，显然不符合NFV技术的初衷；而仅硬件解耦不支持多厂商VNF在同一云平台部署，运营商仍旧依赖厂商；三层解耦可以解决上述问题，但其涉及多厂商垂直互通，系统集成和维护难度大，部署周期长。NFV三层解耦要求在部署NFV时不同组件由不同的厂商提供，需要比传统电信网络更复杂的测试验证、集成和规划部署工作。
NFV分层解耦的方式由于缺乏主集成商（苏研努力的目标，陕西目前试点的主要目的）和完整验证，距离开放的全解耦目标还有相当距离，运营商会面临一定的运维风险和技术挑战。NFV分层解耦的技术挑战主要有以下几点：
（1）不同厂商的硬件设备之间存在管理和配置的差异，如存储设备管理配置、安全证书、驱动、硬件配置等方面的问题，会导致统一资源管理困难、自动化配置失效；另一方面，各类VNF和虚拟化软件部署于不同的硬件设备上，在缺乏预先测试验证的情况下，硬件板卡或外设之间，如PCIe网卡、RAID卡硬件、BIOS，存在兼容性不一致问题。因此，NFV三层解耦规模商用前，需要运营商细化服务器安全证书、硬件选型方面的规范要求，重点关注硬件可靠性和兼容性问题，在商用前进行软硬件兼容性和可靠性验证。以上问题需要通过大量的适配、验证和调优来解决。
（2）不同基础软件之间存在兼容性问题，如操作系统与驱动层之间、虚拟交换机与操作系统之间、虚拟化软件与VNF之间，不同的模块和不同的版本，以及不同的配置参数、优化方法，都会造成性能、稳定性、兼容性的较大差异，有待进一步测试与验证。为此，需要尽量减少虚拟化层类型，适时引入自主研发虚拟化层软件，减少持续不断的三层解耦测试工作量。采用集中的云管平台（统一VIM），降低NFVO与VIM集成的复杂度。
（3）分层之后，从NFV各层之间的接口定义与数据类型，到层内功能的实现机制，乃至层间的协同处理均需要运营商去推动和完善。如VNF在发生故障时，涉及VM迁移与业务倒换机制以及NFVI、NFVO和VIM的处理流程；又如VNF对配置文件管理和存储设备使用不当，同样会导致VM实例化失效。因而，在VNF多厂家集成过程中，集成方或者运营商需要需要有角色对问题定界、定位进行裁决，在集成和运维的过程中，对技术问题进行端到端的管理，对各层的功能进行详细定义或者详细规范。
（4）NFV系统集成涉及多厂商、多软硬组件的高度集成，由于虚拟化环境的存在，在初期的测试验证、中期的系统部署、后期的运维过程中，进行系统评测与管理部署都较为困难。这就要求运营商在提升DevOps能力的基础上，依托持续集成与持续部署和运维自动化技术，形成NFV系统的持续集成、测试和部署能力，大白话就是要求运营商亟待需要提升自主开发、自主集成和自主测试能力。同时，MANO架构需要全网统一。由于目前VNFM通常与VNF是绑定的厂商组件，而实际上真正的VIM也是厂商提供的，因此VNFM、VIM仍然是与VNF、NFVI就近部署。所以需要尽早明确NFVO的架构（例如，采用集团NFVO+区域NFVO两层架构），明确VNFM和VIM的跨专业、跨地域部署能力和部署位置，明确已部署的云管平台与VIM架构的关系，以及已有的EMS、NMS与VNFM架构的关系。
对于运营商来说，三层解耦会是一个较长的过程，与厂商的博弈也需要时间，再加上自主能力（研发、测试、集成）也需要时间，在实现最终目标之前可以先选择过渡方案，例如厂商一体化方案（不适合作为商业化规模部署方案）、部分解耦方案（硬件与软件解耦、MANO中的NFVO解耦出来）等，在试点和小规模部署过程中培育能力，逐渐实现最终的解耦目标，并在解耦基础上逐步提升自主研发比例，增强对网络NFV化的掌控力。
4
MANO管理模式利弊分析
EISI NFV对MANO的资源管理提出直接模式和间接模式两种方案。NFV-MANO允许NFVO和VNFM两者都能管理VNF生命周期所需的虚拟化资源，直接和间接是相对VNFM而言的。
直接（Direct）模式：VNFM直接通过VIM分配VNF生命周期管理所需的虚拟化资源。VNFM向NFVO提出对VNF的生命周期管理操作进行资源授权，NFVO根据操作请求及整体资源情况返回授权结果；VNFM根据授权结果直接与VIM交互完成资源的调度（分配、修改、释放等）；VNFM向NFVO反馈资源变更情况。如下图所示：
间接（Indirect）模式：VNFM向NFVO提出对VNF的生命周期管理操作进行资源授权，NFVO根据操作请求及整体资源情况返回授权结果；VNFM根据授权结果向NFVO提出资源调度（分配、修改、释放等）请求，NFVO与VIM交互完成实际的资源调度工作；NFVO向VNFM反馈资源变更情况。如下图所示：
总体而言，两者都由VNFM提供VNF生命周期管理。在执行VNF生命周期管理操作之前，无论该操作新增资源，还是修改或者释放已分配的资源，VNFM都需要向NFVO请求资源授权；资源容量和状态等信息由NVFO统一维护管理。两种模式的不同主要体现在：直接模式下，VNFM和NFVO都需要与VIM交互，将VIM的虚拟资源管理接口暴露给VNFM使用；间接模式下，VFNM不需要和VIM进行交互，NFVO需要提供VIM代理能力。
两种模式在架构、业务成效、性能、集成复杂度以及安全性方面的对比分析如下所示：
综合以上分析，从功能、落地部署、安全性、未来演进角度考虑，间接模式较好；性能方面，直接模式占优；系统集成复杂度两者相当。考虑网络的未来发展，从运营商对网络的自主掌控能力出发，要求厂商必须支持间接模式，以推进分层解耦、实现对虚拟资源的统一管控。
5
VNFM如何选型？
通用VNFM和专用VNFM是ETSI定义的两种架构选项。
通用VNFM：通用VNFM可以服务于不同类型或不同厂商提供的VNF，对它所管理的多种类型、多厂商VNF的操作没有依赖性，但它必须能够在VNF包中定义的不同VNF的特定脚本。按照管理要求，可能有多个通用VNFM，每个VNFM管理一定VNF的子集。在这种情况下，NFVO需要同时处理多个通用VNFM。下图展示了通用VNFM的架构。
专用VNFM：专用VNFM与它所管理的VNF之间具有依赖性，一般管理由同一厂商提供的VNF。NFV架构框架同时也允许一个或多个专用VNFM连接到单个NFVO。在VNF生命周期管理过程复杂，且一些管理特性与这些VNF紧耦合的场景下，就需要使用专用VNFM。下图展示了专用VNFM的架构。
两种架构选项具有相同的VNFM功能要求，如VNFD解析，获得部署VNF所需资源要求及所需部署的业务软件；NFVI告警与VNF告警关联、VNF弹性策略执行；VNF生命周期管理，包括实例化、查询、扩/缩容、终止等。但是，两种架构在技术实现难度、运维复杂度等方面却存在着差异。
6
NFVO如何部署？
目前，ETSI NFV进一步细化了NFVO功能模块的具体功能要求。按照MANO规范，NFVO可以分解为网络服务编排（Network Service Orchestrator，NSO）和资源编排（Resource Orchestrator，RO）。网络服务生命周期的管理功能，即NSO功能；跨VIM的NFVI资源编排功能，即RO功能。NFVO作为MANO的一个功能实体，在部署时，可以有如下两种部署形态。
6.1 NFVO功能不分解部署
NFVO作为一个独立的实体部署，可采用级联的方式来部署。如下图所示，每个管理域可以被当作一个或多个数据中心，在该管理域中部署一套独立的NFVO，以及VNFMs、VIMs，用来管理该域中的网络服务。另外，再部署一套顶层NFVO，用来管理域间的网络服务，它并不管理下层管理域中的网络服务，不过它可以接收下层管理域中网络服务实例化、弹性伸缩，以及终止操作的请求，并将此请求直接传递给下层管理域中的NFVO，由下层管理域的NFVO来完成实际的操作。
6.2 NFVO功能分解部署
NFVO可以分为两个独立的实体来部署，NSO主要完成NS的生命周期管理，包括NS模板以及VNF包的管理，如下图所示。NSO不再关注资源的状态以及资源所在的管理域，仅关注资源的额度。RO主要完成管理域内资源的管理和编排，如资源的预留、分配、删除等操作，以及支持资源的使用率和状态的监控。
NFVO功能不分解部署时，资源申请效率高；集成难度相对较低；若NFVO故障，则只会影响该NFVO管理域的业务和资源。NFVO分解后，VNFM访问或申请资源的效率会降低；如果RO出现故障，则只会影响该RO管理的资源；但是，一旦NSO出现故障，则将影响所有整个NFV的业务功能；NFVO分解为NSO、RO之后，或增加NSO-RO之间的接口，增加系统集成难度。
根据分析比较，在一定的业务规模下，将NFVO分解为NSO、RO难以带来明显的优势或收益，反而会导致性能降低、集成复杂。因此，建议NFVO采用不分解架构。另外，考虑后续的演进和发展，在技术架构上可将NSO和RO进行内部功能解耦，并实现微服务化，以增强未来NFVO部署的灵活性。
