NFV大规模商用部署前的回顾和反思

【 导读 】： NFV是运营商下一代云化可编程网络的关键支撑技术，是构筑未来开放式电信网络及业务生态环境的基础。ETSI NFV标准作为NFV的核心框架，随着互联网、云计算技术的发展在不断的演进之中，是全球运营商实现多厂商、分层解耦的NFV商用系统以及建立开放式NFV生态环境的基础。纵观全球，NFV技术仍处于相对初级的虚拟化阶段，有很多现实的问题需要解决。近两年国内运营商加快了NFV落地试点及商用部署的步伐，2018年可以预见到更多的规模化商用部署落地。在大规模商用部署之前，有必要对NFV的整个发展历程、国内外运营商整体情况、存在的问题以及后续发展思路进行系统性的梳理和反思，以帮助解决商用部署中的问题、指导NFV从虚拟化到云化发展的突破、建立一个运营商以及IT/CT厂商共赢的良性NFV生态环境。

NFV发展历程

NFV是云化可编程网络的关键技术

纵观整个通信发展史可以发现(参见图1)，通信网络的发展变革关键在于新技术的驱动。数字程控交换技术的发展使得我们从传统的模拟电路交换时代进入了通信2.0时代，IP技术在通信领域的运用，以及4G网络架构的演进，使得我们进入了全IP网络的通信3.0时代。而NFV则是我们即将进入的通信4.0 – 云化可编程网络的关键技术之一(未来我们是否会借助人工智能和机器学习进入自组织网络的通信5.0时代?)。

　技术驱动的通信网络发展变革

ETSI NFV的产生及发展

2012年10月，借在德国召开的SDN及OpenFlow世界大会之机，13家网络运营商聚集在一起，首次发布了NFV的介绍性白皮书，第一次正式提出了NFV的构想。这部白皮书成为指导NFV后续行动的纲领性文件。

2013年初，在ETSI总部-法国的索菲亚·安蒂波利斯召开了ISG NFV(NFV行业标准工作组)第一次全体大会，这标志着NFV正式成为全球电信产业关注、并致力于通过标准化工作快速发展的领域。截止到目前，ISG NFV会员已达到三百多家(其中包含38家运营商)，是ETSI参与会员最多的工作组。

多年以来，电信运营商饱受专属硬件网络设备的困扰。提出NFV的初衷旨在利用IT虚拟化技术来解决这些问题，通过网络功能软件化，将不同类型的网络设备整合到工业标准的大容量服务器、交换机和存储设备上，并能根据需要在网络不同位置部署运行。

从2012年首部NFV白皮书至今，ETSI在NFV标准化方面做了大量的工作，为NFV产业发展奠定了坚实的理论基础。关键的里程碑(参见图2)包括2013年提出NFV参考框架、2014年的NFV MANO框架等。从2015年开始，ETSI一直致力于在功能、模型、接口及互操作标准方面进行标准化定义及完善。 2017年8月，ETSI SOL工作组发布了可落地的互操作RESTful协议接口和TOSCA模型的部分关键成果，成为解决多厂商互操作问题的关键里程碑!

　ETSI ISG NFV标准化关键里程碑

图3展示了ISG NFV标准化工作的主要内容。自2013年起，ETSI基本上每隔两年发布一次NFV标准成果版本(Release)。各版本相关的主要工作内容如下：

　ETSI ISG NFV标准化工作主要内容

- 版本1 (2013-2014)：重点研究 NFV 的概念及可行性。主要工作包括：提供基线研究和规范、定义NFV 体系结构(基础设施NFVI、虚拟网络功能VNF、网络服务NS、NFV管理及编排MANO)等

- 版本 2 (2015-2017)：重点研究 NFV解决方案的互操作性。主要工作包括：功能需求、架构、参考点的详细要求和定义、基于 NFV 体系结构的互操作性标准定义( 包括VNF 包、 VNF / NS 描述符、信息模型/数据模型、接口及协议规范等)

- 版本3 (2016-2018)：重点研究针对NFV投入运作(商用化)如何丰富NFV架构框架和功能特性。主要完善的功能特性包括：计费管理、软件许可管理、策略管理、多站点编排部署、DevOps及云原生支持等。同时版本3还进一步完善了与接口和描述符相关的新需求和规范。

蓬勃发展的NFV产业

当今的互联网时代是一个协作的时代。协作能够使得各参与方更快、更可承受、更有效地推进技术的进步。NFV作为电信网络从全IP网络到云化可编程网络的关键技术，得到了产业界的热烈响应。鉴于在NFV领域有很多关键问题和技术需要解决，因此各方协作成为广泛的共识。

以ETSI的NFV参考框架为核心，从标准化组织、产业联盟到开源社区，从科研机构、厂商到运营商，相关各方在需求、验证、研究、规范、实现、部署等多个维度展开协同工作，有力地推动了NFV技术的进步和成熟，形成了蓬勃发展的NFV产业。图4展示了NFV产业的主要相关参与方(标准化和开源角度比较著名的有TM Forum的ZOOM、MEF的LSO、ONAP以及OPNFV等)。

蓬勃发展的NFV 产业

　不断演进中的NFV框架

NFV是IT虚拟化及云计算技术在通信领域的应用。然而，这里的应用不是简单的、一成不变的应用，而是随着技术的不断创新和发展，将最新的虚拟化、云计算理念和技术持续不断运用到NFV理论和技术框架的过程。

随着技术的发展，NFV框架在不断丰富和完善之中。例如，早期的虚拟化技术是基于Hypervisor、以VM为主的技术。2013年，随着Docker的正式开源，基于容器的虚拟化技术以其独特的技术优势，逐渐成为互联网应用主流的部署方式。

鉴于容器化技术的迅速发展和其独特的技术优势，ETSI标准化组织也对将其纳入NFV框架进行了重点研究。例如，《 NFV-EVE 004 ：关于在NFV框架中运用不同虚拟化技术的报告》中，明确提出了NFV框架包括对Hypervisor与容器等虚拟化技术的支持，如图5所示：

　NFV框架对Hypervisor 与容器等虚拟化技术的支持

除了容器技术之外，随着微服务技术的发展，将庞大的单体应用拆分为由不同微服务组件组合而成的云原生应用，可以在基础设施可靠性相对较低的情况下实现应用及业务的高可靠性，并能根据业务量大小按需动态实现水平容量扩展，在IT及互联网界逐渐成为主流的应用设计模式。

云原生应用设计模式在NFV框架中也得到了体现。例如：在ETSI 版本3的《NFV –EVE 011：云原生VNF实现分类描述》规范中，描述了云原生VNF需要满足的各类非功能性需求以及在设计实现上的考虑。其中，关键的云原生非功能性需求包括：可恢复性(Resiliency)、弹性(Scaling)、可组合性、位置无关性、状态管理、能力开放、零接触管理和负载均衡等。与此相关，版本3目前也在研究如何针对云原生及PaaS需求对NFV架构进行增强等。相关的进展参见NFV-IFA 029报告。

随着对NFV认识的进一步加深，人们逐渐意识到，NFV的本质不是简单的软硬件分离(Separation of software from hardware)，而是功能与容量的分离(Separation of functionality from capacity)。这一点与Google等互联网云计算公司近1-2年提出的Cloud 3.0架构- 无服务器计算(Serverless compute)和FaaS(Function as a Service)模式等在本质认识上越来越接近。随着云计算领域更多新技术的不断涌现，NFV必将不断扩展其内涵。

　NFV发展的四个阶段

NFV并非是一个单一的解决方案，NFV的发展是一个不断演进的分阶段过程。它的每一个阶段都代表了不同的技术创新，都是向着更快地交付应用和业务、驱动更多的创新方向发展。当然，随着技术的成熟，运营商在部署NFV的时候，也可以跨越不同的阶段。

基于业界共识，目前可以将NFV的发展分为以下四个阶段(参见图6)：

　NFV发展的四个阶段

1. 解耦阶段：网络功能与底层硬件的分离，从CT厂商专属、封闭的解决方案中解放出来，以软件形式部署在标准化硬件平台之上和数据中心网络环境中，可以提升部署灵活性，同时降低成本和管理复杂性。

2. 虚拟化阶段：网络功能部署在基于Hypervisor的虚拟化基础设施资源之上。可以有效地提高资源利用率/密度，并可以通过编排器实现简单的管理能力，如扩缩容等。

3. 云化阶段：基于统一控制和编排的电信云化环境及云原生VNF能力，能更好地实现全网络范围内的资源共享和弹性部署。同时能根据网络流量模式及客户需求变化，以自动化的方式动态地响应并创建/变更业务。新的业务可以采用DevOps模式开发并以敏捷弹性的方式部署。

4. 分解重构阶段：对网络功进行分解重构，以更科学、更灵活的基本构件块形式存在。运营商可以利用这些更细粒度的子功能，像拼接乐高积木一样，更快地动态拼接出全新的业务。为提高客户体验，部分子功能组件可以智能化地推送到客户侧或者网络边缘，一些更为通用的子功能组件可以下沉到云化基础设施层，以PaaS能力部署。

从技术角度看，这四个阶段基本上都不存在难以逾越的障碍。从国内外运营商的PoC及现网部署所采用的技术角度看，目前全球NFV发展整体上处于虚拟化阶段，尚未进入到云化阶段。

有一种观点认为NFV已经过时了，因为它只是实现了虚拟化，未来将是NFC (Network Functions Cloudification)- 网络功能云化的时代。对这个观点，我觉得值得商榷。从上文分析可以看出，云化只是NFV走向发展成熟的一个中间阶段，现有以ETSI为核心的NFV标准体系在其持续的演进和完善的过程中，已经覆盖到了云化阶段的需求，从整个NFV产业健康发展角度，完全没有必要推倒重来、为吸引眼球另起炉灶鼓吹一个全新的概念和体系。

全球运营商NFV整体情况

2017年，从整体上讲，全球主流运营商在NFV商用部署上大多采取相对稳健的做法，大规模的NFV商用化部署尚未开始。

主要的虚拟化商用部署集中在以下几个方面：

- 核心网，主要包括vEPC、vIMS、vPCRF等

- 边缘及汇聚网络设备，如vBNG/vBRAS、vSBC、vCDN等

- 面向客户的创新业务，如vCPE、 SD-WAN、Live-TV(瑞士电信)等

尽管多数运营商希望网络尽快演进到NFV/SDN，但许多电信运营商发现，NFV的实施过程比他们最初以为的更为困难，有些进展甚至比预期的更慢。纵观全球，NFV技术仍处于相对初级的阶段，有许多问题有待解决。

主要的问题包括：

- NFV技术的可靠性和稳定性还有待验证;

- 虚拟化及传统网络共存给网络运维带来的挑战;

- 多厂商环境使得厂商和运营商的网络虚拟化更加复杂，厂商定位和解决网络问题的责任范围方面存在不确定性，NFV集成部署和管理能力成为关键;

- 互操作性相比预期面临着更大的挑战，因为标准缺乏成熟度，现有的 ETSI规范(不含2017年8月份新发布的SOL规范)不足以实现多厂商之间无二义性的对接，测试也由于缺乏完整的规范实现而受到阻碍;

- 运营商不仅希望摆脱私有功能和专用硬件，还希望能够动态扩展这些网络功能，实现云规模的灵活性和效率。但目前大部分VNF只是从旧的平台移植到虚拟机中运行，并非基于云原生设计，不能带来真正的云效益;

- 从垂直烟囱到水平职能的转换造成各部门缺乏问责制和责任，许多企业缺乏明确的框架来定义这些概念，造成职责模糊。

经过这一两年的实践摸索，运营商针对解决上述问题已经积累了一定的经验。在2018年，预期将有更多NFV规模化商用部署，除了虚拟化部署之外，运营商在今年也会进一步探索对NFV进行云化商用部署。

典型海外运营商NFV发展思路

部分运营商从NFV发展之初就开始着手考虑基于NFV的整体战略和思路，在NFV发展过程中，根据自身的实际情况，主导制定了相对明确的顶层设计思路、技术架构与商用路线，并通过与厂商、开源软件/开源硬件社区的广泛合作等方式，扎实地推进了NFV的落地和商用化部署。这些运营商为我们提供了在NFV实践方面很好的参考，典型的如AT&T和SKT等。

　AT&T

在NFV/SDN等创新技术的驱动下，AT&T率先于2013年提出了Domain 2.0(D2)转型战略。AT&T的D2计划聚焦于运用云技术和网络虚拟化技术来提供服务，以降低基础建设与运营费用，显著提升运营的自动化能力。通过D2战略，AT&T计划在2020年网络虚拟化达到75%，并最终转型为一家软件公司。截止到2017年底，AT&T宣称其网络虚拟化程度已经达到55%。

为支持其向软件公司转型的战略，AT&T在NFV实践中一直坚持以开源软件为主的自主研发战略。其Domian 2.0计划包含4大支柱，如图7所示：

　AT&T NFV战略Domain 2.0的4大支柱

1. ECOMP/ONAP：在实现AT&T D2的主要目标方面，ECOMP具有关键作用。通过ECOMP可以快速地部署新业务(由AT&T或第三方创建)，创建云消费者业务和企业级业务的新型生态系统，提升运营效率，增强网络为客户提供的价值。ECOMP是AT&T基于开源软件的自主研发平台，已在AT&T内部使用了2年多的时间，并于2017年2月与Open-O合并为著名的开源ONAP社区。AT&T致力于通过ECOMP/OANP的开源，将其打造为运营商下一代网络管理及编排的核心与事实标准，成为未来网络的Android系统。目前，已经有多家运营商，如Orange和Bell Canada等正在部署ECOMP/ONAP并进行业务测试。

2. AIC：AT&T集成云(AT&T Integrated Cloud)是AT&T网络转型的基础，是其创建可以运行多种虚拟网络功能的云化基础设施的关键。AT&T基于开源社区的OpenStack版本，自主研发了ORM等资源集中管控机制，采用DevOps方式开发和部署AIC。目前，AT&T已经在全球部署了接近100个AIC节点。在2018年推出的AIC下一个版本中，将支持基于Kubernetes的容器云，以更好地实现云原生VNF的部署。

3. VNF需求及指南：这些文档定义了VNF在电信云环境下的通用需求、对云原生VNF在设计层面、弹性、安全性以及DevOps支持上的要求以及与ECOMP进行交互实现自动化管理的相关要求。AT&T旨在通过这一系列关键文档的定义，支撑不同厂商的VNF在AIC云环境和ECOMP管理平台的无缝集成，更好地打造多厂商开放式的生态环境。

4. D2 ICE：VNF孵化与认证环境(Incubation & Certification Environment)。ICE提供了一组流程和自动化工具，使得VNF厂商可以基于VNF需求及指南，在ECOMP及AIC架构下实现VNF的快速孵化、验证，自动化完成VNF上架(Onboarding)的整个过程。2016年，AT&T通过D2 ICE对238个不同的VNF进行了验证(实际认证通过了132个)。随着工具的不断完善，单个VNF的验证时间也在逐渐递减。AT&T计划未来在1天之内完成单个VNF的集成验证工作。另外，AT&T还计划在不久的将来，在ICE平台内集成ECOMP API，从而使得VNF供应商、云提供商和其他第三方可以在ECOMP平台和AIC参考架构下以DevOps方式快速集成解决方案。D2 ICE于2017年5月已经在ONAP社区开源，用于实现VNF厂家在ONAP环境下的快速集成验证。

在NFV业务创新方面，AT&T重点打造的是其随选网络品牌 – Flexware。Flexware通过在客户侧部署定制化x86终端，为客户提供vRouter、 vSec以及vWAN等多种网络特性。用户可以通过自助服务界面对其业务进行控制。Flexware采用DevOps方式开发及部署业务，并通过对用户行为的大数据分析，完善用户故事点，实现业务功能的后续迭代。Flexware vCPE解决方案目前支持在全球200多个国家进行vCPE部署，2018年一季度将支持SD-WAN能力，并能通过应用层策略驱动实现智能边缘能力，实现从物理到虚拟到智能化的业务能力演进。

近期，AT&T还在以下两个NFV相关领域发布了创新成果：

1. 发布了开源AI平台 – Acumos。基于该平台，软件厂家可以方便地编辑、集成、打包及部署不同的AI微服务，并基于这些微服务快速开发上线AI应用。这些AI应用可以帮助更好地对NFV网络进行智能化管理。

2. 提出了开源白盒硬件的战略构想。AT&T致力于通过该战略，将传统封闭网络设备网元解构，除芯片层保留专属接口之外，建立芯片抽象层、架构层及网络操作系统层的开放式标准，形成新兴生态系统。开源白盒硬件解构的具体思路如图8所示：

AT&T 提出开源白盒硬件解构新思路

SKT

作为 NFV及5G网络的先驱者之一，SKT希望基于NFV/SDN重构的网络实现“平台服务提供商”战略，重点打造生活方式增强平台、先进媒体平台及IoT业务平台等，建立开放式的生态系统。为满足平台型业务战略发展要求，SKT于2016年7月首次提出基于NFV/SDN的ATSCALE顶层设计框架，作为其未来电信基础设施的创新方向和网络重构的目标(如图9所示)。

　SKT NFV/SDN顶层技术架构 - ATSCALE

ATSCALE采用按技术域划分的不同项目群方式进行验证及实施，目前包含SDRAN、vCore、uCTN、Unified-O以及NG-OSS等5大技术领域共16个项目。

在NFV商用方面，SKT从2015年开始就实现了vEPC及vIMS网络的商用部署，在2017年新上线EPC网元的80%都是vEPC方式(同时计划从2019年开始，100%全面部署vEPC产品)。另外，SKT于2017年7月上线了基于自研的商用T-MANO产品，用于对其部署的NFV网络进行统一管理。SKT计划在未来发布T-MANO的API接口，以更好地支持VNF厂商在T-MANO环境下的开发集成。

国内运营商NFV发展情况

国内三大运营商都高度重视NFV发展，均分别规划了面向NFV的顶层战略思路，如中国移动的NovoNet2020愿景、中国联通的CUBE-Net战略以及中国电信的CTNet2025网络架构白皮书。在此基础上，各运营商分别制定了阶段性工作重点，同时一直积极参与相关国际组织工作、推进标准和开源成熟，促进NFV产业链发展，主动迎接网络转型和演进。

这其中最有代表性的是中国移动。

中国移动

在推进 NFV 技术成熟的过程中，中国移动从整体上部署了两条工作主线。一个是面向商用的 NFV 现网试点，另一个是面向未来网络目标架构的 NovoNet试验网。一方通过 NFV现网试点，有序推动 NFV 商用的落地;另一方面利用NovoNet试验网，进行新技术的实验和验证，验证未来网络的目标架构(如三层解耦的技术要求、ONAP 的自主开发等等)。这两条工作线相辅相成，交替前行。

· NovoNet试验网

NovoNet试验网工作有三个主要目的：第一是重构电信网络的基础设施，即利用电信集成云TIC基于云化构建整个电信网络的基础设施;第二是重构网络的新功能，面向5G利用微服务以及SBA架构重新设计未来网络功能(即前文NFV发展的第4阶段-分解重构);第三个目的是以ONAP为核心组件，重构下一代网络的OSS系统。

整个NovoNet试验网工作分为三个阶段。2017年，中国移动在北京、上海、浙江和广东四个省启动了NovoNet试验网一阶段工作，主要目的是和厂商联合主导进行面向多业务的统一资源池TIC集成部署以及三层解耦下的部分业务场景(vEPC、vCPE以及E-BoD等业务)测试。为了深入研究TIC的关键能力和技术，中国移动在一阶段几乎对所有主流 IT 厂家的虚拟层进行了摸底测试，并且实现了这些 IT厂商虚拟层与 CT 厂家网元的功能层对接测试。

目前一阶段工作已经基本完成。即将启动的NovoNet二阶段试点工作，将重点开展以ONAP为主的跨厂商TIC平台系统集成与协同编排，同时新增vCDN、vBRAS等业务场景。

· 现网试点测试

针对NFV商用部署，中国移动很早就进行了相关规划和准备工作。从2015年10月份核心网NFV云化试点正式开始，到2017年11月试点结束为止，中国移动组织九个厂商在六省市进行了三个阶段的外场试点测试工作。这三个阶段的试点测试工作各有侧重：第一阶段以验证NFV关键能力为主;第二阶段全面聚焦软硬解耦的技术架构、细化虚拟层的功能、性能和可靠性要求、细化 MANO 的流程接口的要求;第三阶段则是针对NB-IoT、VoLTE以及短信中心等业务，进行NFV端到端的业务能力验证。

为配合外场试点测试工作，中国移动组织总部、研究院、计划院等单位，联合相关厂家成立了硬件、虚拟层、VNF、MANO以及组网规划等五大NFV专题工作组，针对NFV商用相关的100多个关键基础问题进行了联合攻关，制定并完善了一系列技术规范和测试规范，为实验室及外场试点测试奠定了良好的基础。

在现网试点过程中，由于NFV相关国际组织标准化工作进展缓慢，中国移动依托ETSI标准，同时根据未来商用要求，大胆地进行了功能上的完善，形成了一系列自主创新成果，例如：

- 自主完善设计了MANO等关键功能的数据模型和相关接口的RESTful协议，以实现多厂家之间的互操作

- 扩展了NFVO能力，通过将FCAPS能力与NFVO能力整合，形成NFVO+，以更好地满足商用网络的运维要求

- 在VIM功能之外，增加了PIM功能，以实现对硬件资源的统一管理，更好地满足商用网络的要求

- 提出了VNF与PNF混合组网的组网规划，以更加稳妥地方式推进商用落地

集成商是基于多厂商环境下的NFV网络部署的关键角色之一。中国移动历时两年多、三个阶段的外场测试工作的集成商角色不仅包括传统的CT厂商，也包括了HPE公司等IT 厂商。在这个过程中，相关厂商也积累了丰富的集成经验。

· 小业务平台网元试商用

2017年底，中国移动浙江公司成功地实现了小业务平台网元(包括IMS固网彩铃业务、一机双号业务等系统)的三层解耦试商用部署，以积累NFV商用的网络运行经验和人员培养储备，并为后续核心网网元的商用化部署做准备。

中国联通

中国联通在NFV发展早期就积极跟踪并开展了一系列前期研究，包括在2014-15年与HPE、中兴通讯合作完成ETSI PoC #27 项目-基于vEPC和vIMS的VoLTE业务。最近两年，重点推进了NFV相关的落地工作，并率先完成了国内NFV首例集采招标工作，具体包括：

- 以服务企业客户为聚焦点，构建基于NFV/SDN的产业互联网基础设施，发布了面向企业的随选网络产品

- 成立了中国的CORD的产业联盟，重构数据中心，推进电信云的基础设施和边缘云的建设

- 以固网城域网vBRAS，移动核心网元vEPC、vIMS功能虚拟化为切入点，开展网络云化的试点和试商用工作

- 2017年重点开展了vEPC分层解耦试点测试工作。基于测试成果，2017年8月启动了基于NFV的云化NB-IOT物联网核心专网分组网设备集采。这是全国首例NFV集采项目，本次集采中明确了由虚拟化层厂商负责NFV商用的系统集成工作

中国电信

中国电信在CTNet2025目标架构和转型3.0战略指导下，制定了在近期(2016-2019年)选择部分代表性网元和系统引入NFV的策略。

围绕部分网元引入NFV的网络云化工作策略，近两年中国电信做了多方面的工作，包括：

- 结合VoLTE的需求，部署了全球最大规模的两层解耦vIMS网络

- 面向城域网内大并发、小流量的场景，开展了vBRAS试点和试商用，完成了vBRAS三层解耦及面向vBRAS统一编排管理的NFV全解耦测试

- 由集团统一规划，中国电信广州研究院组织实施了vIMS 多厂商三层解耦暨NFVI技术测试。基于初期测试结果，中国电信于2017年9月发布了NFV基础设施层及MANO系统企业标准，并明确了今后NFV建设要遵循三层解耦、统一云管系统等原则要求。

相比其他国内运营商，中国电信最早明确了通过统一NFVI层标准建立三层解耦、避免NFV软烟囱，CT云与IT云采用统一的云管系统等重要原则，这对建立多厂商、开放的NFV生态环境至关重要。

存在的问题及后续发展思路

相比海外运营商而言，国内运营商整体NFV商用进程并不快。国内三大运营商通过近两三年的PoC、试验网、现网试点以及试商用等一系列工作，已经基本掌握了NFV虚拟化阶段的核心技术和能力，2018年可以预见到更多的规模化商用部署落地。然而从多厂商互操作、VNF云化能力、端到端自动化水平等角度考虑，还存在着一些明显的问题和不足，尚不能像乐高积木那样实现虚拟网络功能和业务的无缝拼接组装。

这些问题是NFV从虚拟化阶段迈向云化阶段必然面临的，后续需要进一步推进从虚拟化到云化能力的突破来解决。下文针对几个主要问题进行讨论，并尝试提出后续发展思路。

多厂商间的互操作

NFV开放式生态系统发展所面临的最大挑战是如何实现互操作性。为了应对这一挑战，ETSI一直致力于在关键接口规范定义方面取得实质性的进展，这些规范是确保不同实现之间互操作性必不可少的。

如图10所示，互操作性需求的关键在于基于ETSI 定义的功能需求及模型驱动设计思路，实现接口的标准化及模型的标准化(VNFD、NSD、VNF包等)。

实现NFV多厂商之间互操作的关键

ETSI NFV规范定义分为三个成熟度阶段(参见图11)。2015年到2017年上半年，ETSI NFV发布的规范还主要集中在Stage 2层面，尚不能直接指导多厂商之间的互操作。直到2017年8月，SOL工作组发布了Stage 3阶段的部分关键成果，成为解决多厂商互操作问题的关键里程碑!

　ETSI NFV规范的三个阶段

ETSI SOL工作组针对NFV互操作层面主要发布和待发布的规范文档如图12所示。

　ETSI NFV Stage 3阶段支持互操作的关键标准规范

由于ETSI NFV在前一段时间的标准化工作进展缓慢，国内运营商在最近2年的现网试点过程中，基本上都是依托ETSI在Stage 2阶段的标准，自主完善设计了MANO等关键功能的数据模型和相关接口的RESTful协议，以实现多厂家之间的互操作。这和多数海外运营商的做法类似，是标准滞后于实践导致的折中办法。

对比国内三大运营商的MANO规范和最新的SOL Stage 3规范，我们可以看到存在着不少的问题，例如：

- 模型驱动的核心是模型本身的开放。受部分厂商影响，国内运营商规范目前基本不支持NFVO对VNFD模型的直接解析，而是变相增加了一个查询VNFD的接口。这有违模型驱动思想的本质，不利于未来基于乐高积木方式实现VNF快速验证与部署

- 从ETSI设计角度，授权接口本质上是对VNF生命周期管理操作的授权(例如：删除VNF的操作需要NFVO确认该VNF是否被某个实例化的NS所使用，没有被使用的情况下才有可能授权允许删除)，而目前国内运营商规范中仅仅是对虚拟资源的申请进行授权。单纯从资源角度考虑授权有违于ETSI设计初衷，会带来很多潜在问题

- ETSI规范定义了完善的扩缩容机制设计，包括Deployment Flavour、Scale Aspect, Instantiation Level等信息元素，同时支持Scale to Level以及Scale两个层面的操作，目前国内运营商规范完全没有体现出这种细粒度和精准的扩缩容设计思路，无法支持VNF云原生能力

- 国内运营商规范中，针对各类Notification的订阅通知接口不符合互联网程序设计管理，也不符合ETSI规范的设计思路

在NFV实践过程中，运营商最重要和基本的目标之一是实现将开放式生态系统内的不同组件快速组装在一起的互操作性能力。而在开放的环境中，实现互操作首先必须基于对ETSI定义的功能规范、模型驱动思路以及接口和模型规范的全面和完整的理解，而不是简化和曲解。

ETSI部分关键互操作标准在2017年8月份已经发布，后续如VNFD的TOSCA模型也即将在2018年初发布，这为解决开放式生态环境奠定了重要的基石。何时、以什么方式将现有运营商MANO规范过渡到标准的ETSI Stage 3规范，以彻底解决互操作这一基本问题，是国内各运营商在NFV后续发展过程中需要重点考虑和规划的。

VNF云化就绪能力

从这两三年国内运营商的NFV实践中可以发现，VNF的云化就绪能力一直没有得到系统性的研究和测试，而这正是NFV从虚拟化阶段到云化能力阶段突破的关键。

目前国内各大运营商在NFV实验室测试及现网试点过程中，并没有采用有效的手段了解厂商VNF是否按云化或者云原生进行设计与实现(更不用谈在这方面进行规范和约束)，例如：

- VNFC的设计是否合理?是否每个VNFC能提供单一能力并且相互独立(如：是否将依赖特定加速能力的功能组件设计为独立的VNFC)?

- VNFC组件在部署时是否存在单点故障?

- 关键组件的冗余备份模式是什么?多个并行处理组件之间的负载均衡是如何实现的?如何检测到组件故障并完成自动恢复?如果不能自动恢复，如何通知MANO介入?

- 微服务能力：VNF是否基于微服务架构进行设计?每个VNFC是否可以独立部署、配置、升级以及监控?

- 部署及扩缩容机制：能否支持多种部署规格以满足不同的业务场景?能否针对与特定业务流量能力相关的一组VNFC进行独立扩缩容?是否可以按不同的等级和粒度对不同的VNFC组进行扩缩容?

- 状态管理：VNFC是否尽可能采用无状态方式设计和实现?针对有状态的VNFC，是否实现了逻辑与状态的分离，对状态是如何进行持久化的?

上述VNF云化就绪能力是否具备，将极大地影响VNF的可靠性、水平弹性扩展能力以及自动化管理能力，而这对基于VNF部署的业务运行至关重要。

云模式有别于传统企业计算模式的一个非常重要之处就在于假设基础设施是不牢靠的、无法提供足够的可靠性，需要从应用层角度，采用云化设计思路，确保应用具备高可用性能力。这样的应用可以部署在任何不可靠的基础设施环境中，同时确保业务的高度可靠运行。领先的运营商很早就在考虑这方面的工作，例如：上文提到，AT&T在Domain 2.0中，专门针对VNF的云化就绪等制定了一系列要求及指南，另外，ETSI在其规范EVE 011也专门定义了云原生VNF从实现角度需要考虑的一系列非功能性要求。

建议国内运营商在虚拟化阶段目标基本实现的基础上，尽快展开VNF云化就绪能力的规范性及测试工作。

自动化能力水平

从商用部署及业务创新角度看，仅仅具备虚拟化能力的NFV无法完全满足业务运维的自动化需求以及新业务快速上线的要求，需要在云化阶段重点打造和提升自动化能力水平。

自动化能力水平的提升涉及到多个方面，例如：

- 针对不同厂商的VNF(基于上文提到的VNF云化就绪要求和互操作规范)，建立统一的VNF认证与测试平台(类似于AT&T的ICE环境)，可以极大地提高VNF验证和测试的自动化水平，缩短认证时间，加速新业务网元的规范引入。将来还可以进一步考虑将该平台与运营商下一代OSS的DevOps平台打通，实现VNF厂家与运营商之间跨域的CI/CD流水线，这对多厂商NFV生态环境的建设有重要的促进作用。

- 端到端业务管理自动化能力的提升。ETSI规范以及国内针对NFVO+的实践中，即使是增加了对虚拟网元的FCAPS管理能力，也并未包含对VNF的业务配置以及业务管理控制能力。从自动化业务运维角度考虑，存在一定的缺陷。图13展示了一种可行的思路，即通过业务编排与NFV编排及EMS同时对接，通过综合网络业务相关的语义信息和虚拟化NFV环境的语义信息，对业务进行端到端的自动化编排和运维。

通过业务编排实现端到端业务管理自动化

目前几乎所有NFV相关的开源项目，如ONAP、OSM都在NFV架构基础上扩展了业务编排层，相关的标准化组织如：TM Forum ZOOM以及MEF LSO也都在进行这方面的研究。国内运营商在后期实践中可以借鉴这方面的成果。

小结

NFV是下一代云化可编程网络的关键支撑技术手段，ETSI制定的NFV核心框架及相关模型/接口是蓬勃发展的NFV产业的基石。随着互联网、云计算领域更多新技术的发展，NFV框架也在不断丰富和完善之中。从国内外运营商的PoC及现网部署情况综合起来看， NFV技术尚处于相对初级的阶段，有许多问题有待解决。目前全球NFV发展整体上处于虚拟化阶段之间，尚未进入到云化阶段。

国内三大运营商通过近两三年的PoC、试验网、现网试点以及试商用等一系列工作，已经基本掌握了NFV虚拟化阶段的核心技术和能力，2018年可以预见到更多的规模化商用部署落地。然而从互操作、VNF云化就绪、自动化水平等角度考虑，还存在着一些明显的问题和不足，需要进一步推进NFV从虚拟化到云化能力的突破。

NFV不仅是一项技术，更是不断涌现的IT创新技术和能力在通信行业源源不断应用的过程。NFV在发展过程中更加需要IT厂商的开源思想、创新思路和开放心态。

在NFV从虚拟化到云化砥砺前行的过程中，进一步加强运营商主导能力，优化NFV生态建设，营造一个IT与CT共同参与的良性NFV环境具有非常重要的战略意义。