论文部分内容阅读
【摘要】为满足移动互联网时期市场和业务快速上线、频繁迭代、定制化的需求，电信运营商引入核心网NFV成为必然选择，也成为实现网络建设低成本、高效运营的主要策略之一。本文分析了运营商部署NFV 需要解决的关键问题，并对VNF 组网、MANO 部署和资源池部署方案进行研究；最后对NFV 后续发展进行展望。
【关键词】VNF 組网；VNF 部署；核心网
Discussion of NFV deployment and networking scheme of core network
Li Xin-ming
（Tianyuan Ruixin Communication Technology Co.， LtdXi'anShaanxi710075）
【Abstract】In order to meet the mobile Internet market and business during the period of rapid on-line， frequent iteration and customization demand， telecom operators into core network NFV become inevitable choice， also become the network construction of low cost， high efficient operation of one of the main strategy. This paper analyzes the key problems that the operators need to solve in order to deploy NFV， and studies the deployment plan of VNF group network， MANO deployment and resource pool. Finally， the future development of NFV is prospected.
【Key words】VNF networking；VNF deployment；Core network
1. 前言
NFV 标准化中的需求和架构已确定，关键流程也基本具备， 但协议级接口流程尚未完成。截止到2014 年底，ETSI 已经完成了第一阶段的工作，定义了NFV、MANO 框架和功能，提供参考性的粗略流程。目前正在开展第二阶段的工作，主要的工作内容包括：MANO 接口规范、加速技术、NSD 及VNF package 定义、Hypervisor Domain 需求。NFV 体系架构如图1 所示。
运营商均认可NFV 是未来发展方向， 但商用进程存在很多困难，AT&T、Vodafone、SKT 等运营商仅进行少量VoLTE IMS 和物联网专网EPC 的商用部署。
2. NFV 部署过程中的关键问题
2.1与现有IT 云的差异。
NFV 电信云资源池与现有IT 云在硬件、虚拟层、管理架构、管理维护需求、可靠性等方面均不同，满足电信级要求的基础设施构建难度大，对于电信级云管平台的要求也更严格。
（1）承载的应用不同，应用特性也不同。
（2）硬件配置要求不同。
（3）对虚拟层要求不同。
（4）可靠性要求不同。
（5）云管理平台要求不同。
（6）资源隔离。
2.2MANO 和网管需要协同。
现有网管侧重网元FCAPS 的管理，NFV 的重点在于管理和编排（资源动态管理、VNF 的编排）以及VNF 生命周期管理，NFV 云化使得对网元的管理分为虚拟网元功能的管理和云化资源管理两部分，对网管体系提出全新的要求。为实现未来对虚拟网络的端到端管理， 需MANO 和OSS 进行协同。
同时虚拟化网络和传统网络会长期共存，需要由OSS对虚拟化网络和传统网络进行协同管理，由NFVO 实现虚拟化网络和传统网络业务编排。
MANO 和网管协同示意如图2 所示。
2.3标准化和接口IoT。
除了传统的通信标准组织（ETSI、3GPP），NFV 标准还涉及一些开源组织， 如OpenStack、OPNFV 以及与SDN 相关的ONF、ODL、ONOS 等。与传统电信标准侧重通信协议交互不同，NFV 更强调API 调用的软件交互。由于涉及标准组织较多，各组织间需要配合协作，标准整体推进困难，目前厂商产品及其商用进展已快于标准化进程，厂商为满足部分运营商商用需求， 部分接口及流程采用私有方案；同时NFV 只是定义架构层次， 通过协调其他开源或技术组织来实现对应各个接口的具体定义，这样与一个组织制定标准相比，技术标准的严密性会差一些，在保证多厂商设备兼容方面面临很大风险。
运营商应根据具体部署和运营需求，积极推动国际标准和厂商产品实现，并考虑在开源社区中发挥作用。
2.4多厂商集成。
传统电信设备由电信运营商统一提供软硬件一体设备及集成服务， 引入NFV 后将原来封闭的电信设备商分解为多个层次：硬件设备商、虚拟化软件供应商、VIM 软件供应商、VNF 软件供应商、NFVO（NFV orchestrator）软件供应商、NFV 系统集成商。传统网元软硬一体，无需纵向集成，而NFV 无论采用软硬解耦还是三层解耦方式部署， 都需要有集成商来进行纵向分层的集成工作， 复杂度大大提升。NFV 部署采用不同解耦方式时所需的集成工作有所不同。
2.4.1采用软硬件解耦方式部署。 软硬件解耦方式部署如图3 所示。
软硬件解耦方式， 即硬件资源层由运营商统一采购，有多个硬件厂商；Hypervisor、VIM、VNF、EMS、VNFM 由VNF 厂商提供并集成；NFVO 与OSS 可能单独采购， 也可能由同一厂商提供。
2.4.2采用3 层解耦方式部署。
（1）3 層解耦方式部署如图4 所示。
（2）3 层解耦方式， 即硬件资源层由运营商统一采购，有多个硬件厂商；Hypervisor、VIM 由VIM 厂商提供；VNF、EMS、VNFM 由VNF 厂商提供；NFVO 与OSS 可能单独采购，也可能由同一厂商提供。运营商选定NFV 系统软件集成商或自主实现三层的集成。与软硬件解耦方式相比，增加VNF 与虚拟层之间的软件集成以及VNFM 与VIM 之间的接口集成，集成角色也有所变化。
2.5核心网NFV 的电信级可靠性。
2.5.1核心网元虚拟化后并不能降低电信应用的可靠性要求，仍需要满足“5 个9”的可靠性，提供与电信网络同样的服务质量和安全等级。传统电信硬件通过定制化的、针对电信需求的硬件来提供高可靠性， 而NFV 整体业务端到端可靠性受限于VNF、虚拟化、硬件每一层的可靠性级别，虚拟化采用的COTS 设备（“3 个9”）和开源社区软件的可靠性相对降低。且解耦模型下传统电信硬件-ATCA 的故障通知机制（实时精确）不复存在，故障的实时监测和上报将依赖于各层间的交互（HA（high available）机制）。
2.5.2为保证核心网元虚拟化后电信级可靠性，有下述要求。
（1）对各层提出可靠性可用性要求
（2）通过冗余配置来提高可靠性
（3）进行VNF 软件架构优化
（4）各层故障处理联动
3. NFV组网方案
3.1VNF 组网方案。
3.1.1VNF 与PNF 混合组网。
引入核心网NFV 后，对于传统网络不可能“一刀切”，全部替换，运营商应采用先增量后存量替换的方式建设，因此在较长时期内会存在云化网元（virtual network function，VNF） 和非云化网元（physical network function，PNF）共存的情况，以初期引入云化IMS 为例，其组网有如下两种方案。
（1）PNF 与VNF 混合组pool。
A.在pool 中PNF 与VNF 无差别，pool 组网方案、容灾流程与现网完全一致。未来扩容时，可对pool 中VNF 进行扩容或增加VNF 数量， 通过调整DNS 中的权重进行流量分类。
B.需要同一套OMC 对VNF 和PNF 进行管理， 支持对VNF 和PNF 不同软件版本的管理和配置核查功能； 需要同一套OSS 实现对VNF 和PNF 的管理，在原OSS 与OSS/NFVO 之间同步网元的告警和性能信息。PNF 与VNF 混合组pool 如图5 所示。
（2）PNF 与VNF 独立组网。
PNF 与VNF 分别组pool，负责不同业务区域的业务，未来进行容量扩容时， 优先对VNF pool 进行扩容。随着VNFpool 的容量比例增加， 可能需要在扩容时调整业务划分，将部分用户从传统网元管辖区割接到虚拟网元管辖区。建议独立设置VNF 和PNF 的OMC； 对于OSS， 根据网管架构而定，可以分设也可以合设。PNF 与VNF 独立组网如图6 所示。
3.1.2VNF pool 相对于传统网元pool 的优化特性。
3.1.2.1网元自动扩缩容。
VNF 具备自动扩缩容特性，pool 内网元为负荷分担工作，因此pool 内网元的弹性伸缩策略有如下两种方式。
（1）pool 内网元扩缩容联动：该方式对MANO 的要求较高，要求收集pool 内网元的统计指标后，根据预设的扩缩容策略和算法，对pool 内网元同步进行扩缩容。目前标准尚未定义，厂商产品也不支持。
（2）pool 内网元独立进行扩缩容：同时要求pool 内VNF配置相同扩缩容策略，包括采用的统计指标和扩缩容阈值等。由于pool 内网元的负载不是百分之百相同，存在微小差异，因此该方式会存在pool 内网元弹性扩缩容不同步、短时间内pool 内网元容量不均衡的情况，但在较短时间内可重新达到均衡，不影响网络运行。
3.1.2.2网元重生。
（1）VNF 组pool 机制与基于VM HA 的VNF 重生机制结合，可提高可用性。pool+VNF 重生的倒换机制为：先启动pool 内倒换，与故障VNF 有连接的网元检测到故障，发起倒换流程，将业务倒换到pool 内其他网元。再进行VNF 重生， 服务器出现故障时，VIM 自动将虚拟机迁移到其他空闲VM 上， 保持VM 的配置（如亲和性） 和数据不变，使VNF 快速重生（单VM 的重建时间为3～5 min）。其他网元检测到故障网元恢复，可发起倒回流程，或由网管人员手工倒回。VNF 重生示意如图7 所示。
（2）与传统网元相比， 对于单纯硬件故障引起的网元故障，不需人工更换硬件，通过VNF 重生大大缩短网元恢复时间；对于软件故障，仍需要人工排查后进行网元重启。
3.1.2.3负荷分担策略。
（1）以IMS 域为例，IMS 域传统网元pool 的负荷分担是通过DNS 对pool 域名的解析实现的，DNS 将pool 域名解析为带优先级和权重的pool 内网元IP 地址列表，DNS 中的容灾数据为静态配置。
（2）引入NFV 后，由于网元有自动扩缩容特性，网元的容量会动态变化，因此有动态负荷分担的需求。 3.2MANO 部署方案。
核心网云管理平台系统组网架构如图8 所示。
虽然VNF 所需资源是由MANO 自动部署的， 但业务网络的运维架构依然依靠传统的EMS/OSS 机制， 因此MANO 与EMS/OSS 之间需要协调交互， 共同完成对云化网元的管理。同时MANO 部分功能与现有OSS 功能有交叉。因此运营商在部署MANO 时应先做好新网管架构的规划，明确OSS 与NFVO 的功能定位和未来演进目标。
3.2.1NFVO 部署。
（1）NFVO 实现NSD，VNFFG、VNFD 的管理及处理， 网络服务生命周期的管理， 和VNFM 配合实现VNF 的生命周期管理和资源的全局视图功能。NFVO 在网络中所处的位置与OSS 相当，因此建议部署位置也与OSS 相同，根据运营商未来网管架构的规划和维护管理需求，NFVO 可定制化新建或由现有OSS 改造支持。
（2）NFVO 要求连接多厂商VNFM、多厂商VIM。
3.2.2VNFM 部署。
（1）VNFM 实现虚拟化网元VNF 的生命周期管理， 包括VNFD 的管理及处理、VNF 实例的初始化、VNF 的扩容/缩容、VNF 实例的终止。支持接收NFVO 下发的弹性伸缩策略，实现VNF 的弹性伸缩。
（2）目前VNFM 与VNF、EMS 之间的接口为厂商私有接口，无标准化计划，因此建议VNFM 与VNF、EMS 同厂商部署。部分MANO 厂商也可提供genric VNFM，支持连接异厂商的VNF、EMS。
（3）同厂商EMS 与VNFM 通常数量为1∶1，软硬解耦部署时，VNFM 要求支持连接同厂商多个VIM；3 层解耦部署时，VNFM 要求连接多厂商VIM。
3.2.3VIM 部署。
（1）VIM 是虚拟化基础设施管理系统，主要负责基础设施层硬件资源、虚拟化资源的管理，监控和故障上报，面向上层VNFM 和NFVO 提供虛拟化资源池。同时，VIM 提供虚拟机镜像管理功能。
（2）一般来说， 一个VIM 对应一套OpenStack/一个区域，区域内部根据部署需求可划分AZ 和HA， 区域内实现资源共享、热迁移，区域之间可以实现资源隔离。
（3）同一DC 内根据管理的硬件规模， 可部署多个VIM，多个VIM 可以同厂商也可以异厂商， 多个VIM 所管理的物理服务器、存储资源独立，多个VIM 所管理的资源可以共用组网设备。
（4）同一DC 内不同VIM/region、多个DC 多个VIM/区域可以通过多区域实现共享访问账号和管理界面（目前是同厂商VIM 可共享）。
（5）VIM 要求支持管理多厂商硬件； 软硬解耦部署时，VIM 要求支持连接同厂商多个VNFM；3 层解耦部署时，VIM 要求支持连接多厂商VNFM。
3.3资源池组网方案。
3.3.1相对于传统网元的站点组网， 核心网NFV 资源池组网存在各类流量共用物理端口逻辑隔离、网元内部流量需要站点组网设备疏通等特点。
3.3.2核心网NFV 资源池组网与IT 资源池组网架构类似，采用层次化组网架构。网络出口层负责网络内部路由信息和外部路由信息转发和维护。对外完成与外网设备高速互联，对内负责与数据中心的核心层交换设备互联。网络核心层部署核心交换机，负责接入层交换设备的汇聚，核心交换机上联网络出口层路由设备，完成与外网设备高速互联。接入层包括接入交换机和接入终端设备，接入终端设备包括机架式服务器、刀片式服务器以及存储设备。资源池分层组网架构如图9所示。
3.3.3IT 云资源池对于站点内流量一般分两个物理平面：基础设施平面、业务平面， 物理平面内的不同流量采用VLAN 隔离。但NFV 资源池相比IT 云资源池更复杂，除基础设施流量、业务流量、存储流量外，还有网元生命周期管理流量，且为保证电信级可靠性，核心网NFV 平面隔离要求比IT 云更严格。
3.3.4根据核心网NFV 站点内各类流量特点， 可分为以下几类。
（1）基础设施管理流量。
包括OpenStack 管理节点与各服务器上的代理通信的流量，对资源池虚拟资源进行管理，在管理流量中优先级最高；另外还有硬件管理接口，也采用独立的物理接口。
（2）其他管理流量。
包括VIM 与NFVO、VNFM 之间的资源管理接口；VNFM 与EMS、VNF、NFVO 之间的网元生命周期管理接口；EMS 与VNF、OSS 之间的网元应用层网管接口。管理流量的流量带宽需求较小，实时性不高，但安全级别要高于业务流量，以便于业务端口发生异常时，可以从管理端口进行相应的维护操作。
（3）业务流量。
包括VNF 内部虚拟机之间、VNF 之间的流量，VNF 的计费和业务开通流量。业务流量的带宽和实时性要求较高，且有信令监测的需求。
（4）存储流量。
包括VNF、MANO、EMS 与存储设备之间的流量。流量带宽在万兆级别，实时性要求较高。
3.3.5管理流量、业务流量、存储流量的特点不同，考虑电信网络可靠性，为避免相互影响，建议进行平面物理隔离，每个平面采用独立的服务器物理网口和交换机，平面内不同流量采用VLAN 逻辑隔离，平面之间通过防火墙或承载网进行互通。物理平面划分示意如图10 所示。
（1）管理平面：OpenStack 管理节点与各服务器上的代理通信的流量； 根据维护管理要求，MANO 和网管相关流量也可以走管理平面， 但需通过虚拟交换机，对于网元和虚拟层有配置要求；
（2）业务平面：虚拟机之间及虚拟机对外的业务流量； （3）存储平面：虚拟机与存储设备之间的流量。
进行物理平面隔离可以提升资源池组网的可靠性和安全性， 但也会增加服务器网口数量和交换机的配置数量，增加一定的组网复杂度。
4. 结束语
（1）传统电信核心网引入NFV 实现云化， 将增强网络功能和容量的灵活性， 以更好地应对市场和业务的快速变化。但对运营商来说，在技术、维护管理架构、管理流程等各方面都存在挑战， 对于产业链也需要进行重新定位。
（2）NFV 技术和产品也在逐步成熟过程中， 运营商应先做好NFV 部署架构设计， 基于产品成熟度和业务驱动引入NFV，同时考虑云化网元和传统网元长期共存下的组网方案；应根据具体部署和运营需求，积极推动NFV 相关技术标准的成熟；加强与产业链的合作，探索新的合作模式和商业模式。
参考文献
[1]ETSI. Network functions virtualisation （NFV）； infrastructureoverview： GS NFV-INF 001[S]. 2015.
[2]ETSI. Network functions virtualisation （NFV）； architecturalframework： GS NFV 002[S]. 2014.
[3]ETSI. Network functions virtualisation （NFV）； accelerationtechnologies； report on acceleration technologies & use cases：GS NFV-IFA 001[S]. 2015.
[4]ETSI. Network functions virtualisation （NFV）； managementand orchestration： GS NFV-MAN 001[S]. 2014.
[5]ETSI. Network functions virtualisation（NFV）； accelerationtechnologies； VNF interfaces specification： GS NFV-IFA002[S]. 2016.
[6]ETSI. Network functions virtualisation （NFV）； managementand orchestration； Or-Vi reference point -interface and informationmodel specification： GS NFV-IFA 005[S]. 2016.
[7]ETSI. Network functions virtualisation （NFV）； managementand orchestration； Vi-Vnfm reference point-interface and informationmodel specification： GS NFV-IFA 006[S]. 2016.
[8]趙慧玲， 史凡. SDN/NFV的发展与挑战[J]. 电信科学， 2014，30（8）： 13-18.
[9]翟振辉，邱巍，吴丽华，吴倩. NFV基本架构及部署方式. 电信科学，2017（6）：180-185.
【关键词】VNF 組网；VNF 部署；核心网
Discussion of NFV deployment and networking scheme of core network
Li Xin-ming
（Tianyuan Ruixin Communication Technology Co.， LtdXi'anShaanxi710075）
【Abstract】In order to meet the mobile Internet market and business during the period of rapid on-line， frequent iteration and customization demand， telecom operators into core network NFV become inevitable choice， also become the network construction of low cost， high efficient operation of one of the main strategy. This paper analyzes the key problems that the operators need to solve in order to deploy NFV， and studies the deployment plan of VNF group network， MANO deployment and resource pool. Finally， the future development of NFV is prospected.
【Key words】VNF networking；VNF deployment；Core network
1. 前言
NFV 标准化中的需求和架构已确定，关键流程也基本具备， 但协议级接口流程尚未完成。截止到2014 年底，ETSI 已经完成了第一阶段的工作，定义了NFV、MANO 框架和功能，提供参考性的粗略流程。目前正在开展第二阶段的工作，主要的工作内容包括：MANO 接口规范、加速技术、NSD 及VNF package 定义、Hypervisor Domain 需求。NFV 体系架构如图1 所示。
运营商均认可NFV 是未来发展方向， 但商用进程存在很多困难，AT&T、Vodafone、SKT 等运营商仅进行少量VoLTE IMS 和物联网专网EPC 的商用部署。
2. NFV 部署过程中的关键问题
2.1与现有IT 云的差异。
NFV 电信云资源池与现有IT 云在硬件、虚拟层、管理架构、管理维护需求、可靠性等方面均不同，满足电信级要求的基础设施构建难度大，对于电信级云管平台的要求也更严格。
（1）承载的应用不同，应用特性也不同。
（2）硬件配置要求不同。
（3）对虚拟层要求不同。
（4）可靠性要求不同。
（5）云管理平台要求不同。
（6）资源隔离。
2.2MANO 和网管需要协同。
现有网管侧重网元FCAPS 的管理，NFV 的重点在于管理和编排（资源动态管理、VNF 的编排）以及VNF 生命周期管理，NFV 云化使得对网元的管理分为虚拟网元功能的管理和云化资源管理两部分，对网管体系提出全新的要求。为实现未来对虚拟网络的端到端管理， 需MANO 和OSS 进行协同。
同时虚拟化网络和传统网络会长期共存，需要由OSS对虚拟化网络和传统网络进行协同管理，由NFVO 实现虚拟化网络和传统网络业务编排。
MANO 和网管协同示意如图2 所示。
2.3标准化和接口IoT。
除了传统的通信标准组织（ETSI、3GPP），NFV 标准还涉及一些开源组织， 如OpenStack、OPNFV 以及与SDN 相关的ONF、ODL、ONOS 等。与传统电信标准侧重通信协议交互不同，NFV 更强调API 调用的软件交互。由于涉及标准组织较多，各组织间需要配合协作，标准整体推进困难，目前厂商产品及其商用进展已快于标准化进程，厂商为满足部分运营商商用需求， 部分接口及流程采用私有方案；同时NFV 只是定义架构层次， 通过协调其他开源或技术组织来实现对应各个接口的具体定义，这样与一个组织制定标准相比，技术标准的严密性会差一些，在保证多厂商设备兼容方面面临很大风险。
运营商应根据具体部署和运营需求，积极推动国际标准和厂商产品实现，并考虑在开源社区中发挥作用。
2.4多厂商集成。
传统电信设备由电信运营商统一提供软硬件一体设备及集成服务， 引入NFV 后将原来封闭的电信设备商分解为多个层次：硬件设备商、虚拟化软件供应商、VIM 软件供应商、VNF 软件供应商、NFVO（NFV orchestrator）软件供应商、NFV 系统集成商。传统网元软硬一体，无需纵向集成，而NFV 无论采用软硬解耦还是三层解耦方式部署， 都需要有集成商来进行纵向分层的集成工作， 复杂度大大提升。NFV 部署采用不同解耦方式时所需的集成工作有所不同。
2.4.1采用软硬件解耦方式部署。 软硬件解耦方式部署如图3 所示。
软硬件解耦方式， 即硬件资源层由运营商统一采购，有多个硬件厂商；Hypervisor、VIM、VNF、EMS、VNFM 由VNF 厂商提供并集成；NFVO 与OSS 可能单独采购， 也可能由同一厂商提供。
2.4.2采用3 层解耦方式部署。
（1）3 層解耦方式部署如图4 所示。
（2）3 层解耦方式， 即硬件资源层由运营商统一采购，有多个硬件厂商；Hypervisor、VIM 由VIM 厂商提供；VNF、EMS、VNFM 由VNF 厂商提供；NFVO 与OSS 可能单独采购，也可能由同一厂商提供。运营商选定NFV 系统软件集成商或自主实现三层的集成。与软硬件解耦方式相比，增加VNF 与虚拟层之间的软件集成以及VNFM 与VIM 之间的接口集成，集成角色也有所变化。
2.5核心网NFV 的电信级可靠性。
2.5.1核心网元虚拟化后并不能降低电信应用的可靠性要求，仍需要满足“5 个9”的可靠性，提供与电信网络同样的服务质量和安全等级。传统电信硬件通过定制化的、针对电信需求的硬件来提供高可靠性， 而NFV 整体业务端到端可靠性受限于VNF、虚拟化、硬件每一层的可靠性级别，虚拟化采用的COTS 设备（“3 个9”）和开源社区软件的可靠性相对降低。且解耦模型下传统电信硬件-ATCA 的故障通知机制（实时精确）不复存在，故障的实时监测和上报将依赖于各层间的交互（HA（high available）机制）。
2.5.2为保证核心网元虚拟化后电信级可靠性，有下述要求。
（1）对各层提出可靠性可用性要求
（2）通过冗余配置来提高可靠性
（3）进行VNF 软件架构优化
（4）各层故障处理联动
3. NFV组网方案
3.1VNF 组网方案。
3.1.1VNF 与PNF 混合组网。
引入核心网NFV 后，对于传统网络不可能“一刀切”，全部替换，运营商应采用先增量后存量替换的方式建设，因此在较长时期内会存在云化网元（virtual network function，VNF） 和非云化网元（physical network function，PNF）共存的情况，以初期引入云化IMS 为例，其组网有如下两种方案。
（1）PNF 与VNF 混合组pool。
A.在pool 中PNF 与VNF 无差别，pool 组网方案、容灾流程与现网完全一致。未来扩容时，可对pool 中VNF 进行扩容或增加VNF 数量， 通过调整DNS 中的权重进行流量分类。
B.需要同一套OMC 对VNF 和PNF 进行管理， 支持对VNF 和PNF 不同软件版本的管理和配置核查功能； 需要同一套OSS 实现对VNF 和PNF 的管理，在原OSS 与OSS/NFVO 之间同步网元的告警和性能信息。PNF 与VNF 混合组pool 如图5 所示。
（2）PNF 与VNF 独立组网。
PNF 与VNF 分别组pool，负责不同业务区域的业务，未来进行容量扩容时， 优先对VNF pool 进行扩容。随着VNFpool 的容量比例增加， 可能需要在扩容时调整业务划分，将部分用户从传统网元管辖区割接到虚拟网元管辖区。建议独立设置VNF 和PNF 的OMC； 对于OSS， 根据网管架构而定，可以分设也可以合设。PNF 与VNF 独立组网如图6 所示。
3.1.2VNF pool 相对于传统网元pool 的优化特性。
3.1.2.1网元自动扩缩容。
VNF 具备自动扩缩容特性，pool 内网元为负荷分担工作，因此pool 内网元的弹性伸缩策略有如下两种方式。
（1）pool 内网元扩缩容联动：该方式对MANO 的要求较高，要求收集pool 内网元的统计指标后，根据预设的扩缩容策略和算法，对pool 内网元同步进行扩缩容。目前标准尚未定义，厂商产品也不支持。
（2）pool 内网元独立进行扩缩容：同时要求pool 内VNF配置相同扩缩容策略，包括采用的统计指标和扩缩容阈值等。由于pool 内网元的负载不是百分之百相同，存在微小差异，因此该方式会存在pool 内网元弹性扩缩容不同步、短时间内pool 内网元容量不均衡的情况，但在较短时间内可重新达到均衡，不影响网络运行。
3.1.2.2网元重生。
（1）VNF 组pool 机制与基于VM HA 的VNF 重生机制结合，可提高可用性。pool+VNF 重生的倒换机制为：先启动pool 内倒换，与故障VNF 有连接的网元检测到故障，发起倒换流程，将业务倒换到pool 内其他网元。再进行VNF 重生， 服务器出现故障时，VIM 自动将虚拟机迁移到其他空闲VM 上， 保持VM 的配置（如亲和性） 和数据不变，使VNF 快速重生（单VM 的重建时间为3～5 min）。其他网元检测到故障网元恢复，可发起倒回流程，或由网管人员手工倒回。VNF 重生示意如图7 所示。
（2）与传统网元相比， 对于单纯硬件故障引起的网元故障，不需人工更换硬件，通过VNF 重生大大缩短网元恢复时间；对于软件故障，仍需要人工排查后进行网元重启。
3.1.2.3负荷分担策略。
（1）以IMS 域为例，IMS 域传统网元pool 的负荷分担是通过DNS 对pool 域名的解析实现的，DNS 将pool 域名解析为带优先级和权重的pool 内网元IP 地址列表，DNS 中的容灾数据为静态配置。
（2）引入NFV 后，由于网元有自动扩缩容特性，网元的容量会动态变化，因此有动态负荷分担的需求。 3.2MANO 部署方案。
核心网云管理平台系统组网架构如图8 所示。
虽然VNF 所需资源是由MANO 自动部署的， 但业务网络的运维架构依然依靠传统的EMS/OSS 机制， 因此MANO 与EMS/OSS 之间需要协调交互， 共同完成对云化网元的管理。同时MANO 部分功能与现有OSS 功能有交叉。因此运营商在部署MANO 时应先做好新网管架构的规划，明确OSS 与NFVO 的功能定位和未来演进目标。
3.2.1NFVO 部署。
（1）NFVO 实现NSD，VNFFG、VNFD 的管理及处理， 网络服务生命周期的管理， 和VNFM 配合实现VNF 的生命周期管理和资源的全局视图功能。NFVO 在网络中所处的位置与OSS 相当，因此建议部署位置也与OSS 相同，根据运营商未来网管架构的规划和维护管理需求，NFVO 可定制化新建或由现有OSS 改造支持。
（2）NFVO 要求连接多厂商VNFM、多厂商VIM。
3.2.2VNFM 部署。
（1）VNFM 实现虚拟化网元VNF 的生命周期管理， 包括VNFD 的管理及处理、VNF 实例的初始化、VNF 的扩容/缩容、VNF 实例的终止。支持接收NFVO 下发的弹性伸缩策略，实现VNF 的弹性伸缩。
（2）目前VNFM 与VNF、EMS 之间的接口为厂商私有接口，无标准化计划，因此建议VNFM 与VNF、EMS 同厂商部署。部分MANO 厂商也可提供genric VNFM，支持连接异厂商的VNF、EMS。
（3）同厂商EMS 与VNFM 通常数量为1∶1，软硬解耦部署时，VNFM 要求支持连接同厂商多个VIM；3 层解耦部署时，VNFM 要求连接多厂商VIM。
3.2.3VIM 部署。
（1）VIM 是虚拟化基础设施管理系统，主要负责基础设施层硬件资源、虚拟化资源的管理，监控和故障上报，面向上层VNFM 和NFVO 提供虛拟化资源池。同时，VIM 提供虚拟机镜像管理功能。
（2）一般来说， 一个VIM 对应一套OpenStack/一个区域，区域内部根据部署需求可划分AZ 和HA， 区域内实现资源共享、热迁移，区域之间可以实现资源隔离。
（3）同一DC 内根据管理的硬件规模， 可部署多个VIM，多个VIM 可以同厂商也可以异厂商， 多个VIM 所管理的物理服务器、存储资源独立，多个VIM 所管理的资源可以共用组网设备。
（4）同一DC 内不同VIM/region、多个DC 多个VIM/区域可以通过多区域实现共享访问账号和管理界面（目前是同厂商VIM 可共享）。
（5）VIM 要求支持管理多厂商硬件； 软硬解耦部署时，VIM 要求支持连接同厂商多个VNFM；3 层解耦部署时，VIM 要求支持连接多厂商VNFM。
3.3资源池组网方案。
3.3.1相对于传统网元的站点组网， 核心网NFV 资源池组网存在各类流量共用物理端口逻辑隔离、网元内部流量需要站点组网设备疏通等特点。
3.3.2核心网NFV 资源池组网与IT 资源池组网架构类似，采用层次化组网架构。网络出口层负责网络内部路由信息和外部路由信息转发和维护。对外完成与外网设备高速互联，对内负责与数据中心的核心层交换设备互联。网络核心层部署核心交换机，负责接入层交换设备的汇聚，核心交换机上联网络出口层路由设备，完成与外网设备高速互联。接入层包括接入交换机和接入终端设备，接入终端设备包括机架式服务器、刀片式服务器以及存储设备。资源池分层组网架构如图9所示。
3.3.3IT 云资源池对于站点内流量一般分两个物理平面：基础设施平面、业务平面， 物理平面内的不同流量采用VLAN 隔离。但NFV 资源池相比IT 云资源池更复杂，除基础设施流量、业务流量、存储流量外，还有网元生命周期管理流量，且为保证电信级可靠性，核心网NFV 平面隔离要求比IT 云更严格。
3.3.4根据核心网NFV 站点内各类流量特点， 可分为以下几类。
（1）基础设施管理流量。
包括OpenStack 管理节点与各服务器上的代理通信的流量，对资源池虚拟资源进行管理，在管理流量中优先级最高；另外还有硬件管理接口，也采用独立的物理接口。
（2）其他管理流量。
包括VIM 与NFVO、VNFM 之间的资源管理接口；VNFM 与EMS、VNF、NFVO 之间的网元生命周期管理接口；EMS 与VNF、OSS 之间的网元应用层网管接口。管理流量的流量带宽需求较小，实时性不高，但安全级别要高于业务流量，以便于业务端口发生异常时，可以从管理端口进行相应的维护操作。
（3）业务流量。
包括VNF 内部虚拟机之间、VNF 之间的流量，VNF 的计费和业务开通流量。业务流量的带宽和实时性要求较高，且有信令监测的需求。
（4）存储流量。
包括VNF、MANO、EMS 与存储设备之间的流量。流量带宽在万兆级别，实时性要求较高。
3.3.5管理流量、业务流量、存储流量的特点不同，考虑电信网络可靠性，为避免相互影响，建议进行平面物理隔离，每个平面采用独立的服务器物理网口和交换机，平面内不同流量采用VLAN 逻辑隔离，平面之间通过防火墙或承载网进行互通。物理平面划分示意如图10 所示。
（1）管理平面：OpenStack 管理节点与各服务器上的代理通信的流量； 根据维护管理要求，MANO 和网管相关流量也可以走管理平面， 但需通过虚拟交换机，对于网元和虚拟层有配置要求；
（2）业务平面：虚拟机之间及虚拟机对外的业务流量； （3）存储平面：虚拟机与存储设备之间的流量。
进行物理平面隔离可以提升资源池组网的可靠性和安全性， 但也会增加服务器网口数量和交换机的配置数量，增加一定的组网复杂度。
4. 结束语
（1）传统电信核心网引入NFV 实现云化， 将增强网络功能和容量的灵活性， 以更好地应对市场和业务的快速变化。但对运营商来说，在技术、维护管理架构、管理流程等各方面都存在挑战， 对于产业链也需要进行重新定位。
（2）NFV 技术和产品也在逐步成熟过程中， 运营商应先做好NFV 部署架构设计， 基于产品成熟度和业务驱动引入NFV，同时考虑云化网元和传统网元长期共存下的组网方案；应根据具体部署和运营需求，积极推动NFV 相关技术标准的成熟；加强与产业链的合作，探索新的合作模式和商业模式。
参考文献
[1]ETSI. Network functions virtualisation （NFV）； infrastructureoverview： GS NFV-INF 001[S]. 2015.
[2]ETSI. Network functions virtualisation （NFV）； architecturalframework： GS NFV 002[S]. 2014.
[3]ETSI. Network functions virtualisation （NFV）； accelerationtechnologies； report on acceleration technologies & use cases：GS NFV-IFA 001[S]. 2015.
[4]ETSI. Network functions virtualisation （NFV）； managementand orchestration： GS NFV-MAN 001[S]. 2014.
[5]ETSI. Network functions virtualisation（NFV）； accelerationtechnologies； VNF interfaces specification： GS NFV-IFA002[S]. 2016.
[6]ETSI. Network functions virtualisation （NFV）； managementand orchestration； Or-Vi reference point -interface and informationmodel specification： GS NFV-IFA 005[S]. 2016.
[7]ETSI. Network functions virtualisation （NFV）； managementand orchestration； Vi-Vnfm reference point-interface and informationmodel specification： GS NFV-IFA 006[S]. 2016.
[8]趙慧玲， 史凡. SDN/NFV的发展与挑战[J]. 电信科学， 2014，30（8）： 13-18.
[9]翟振辉，邱巍，吴丽华，吴倩. NFV基本架构及部署方式. 电信科学，2017（6）：180-185.