作者简介：山石网科资深技术专家，任亮

ETSI的NFV框架
ETSI的NFV工作组成立于2012年，在2017年9月完成了所有的Function规范以及部分Solution规范的发布。解耦，是这个框架的核心思想。

ETSI NFV工作组在2017年1月组织了第一次互操作测试，2018年1月组织了第二次互操作测试，第二次互操作测试已经开始关注VNF在生产环境中的NFV特性以及实际NFV业务应用场景的方案测试。

ETSI NFV第二次互操作测试过程详解

1、测试各个过程的主要内容和大概周期
互操作测试整体包括如下过程：
报名、签署NDA协议、参与每周的电话会议、远程接入HIVE网络、填写技术应答和Wiki、VNF厂商上传镜像文件、熟悉测试计划、预测试、现场测试、测试报告填写。
报名和签署NDA协议比较早，每周的电话会议大概开始于正式测试前3个月，期间覆盖了正式测试前的所有过程，而正式测试的周期是一个工作周。

2、各个过程的重要性及合理性分析
每次电话会议都有一个明确的重要信息要告知参与测试的厂商。一套稳定可靠的VPN+BGP互联网络（HIVE）保证了远程互操作测试的效率。厂商在线对自己的产品能力进行技术应答，并填写自己的Wiki，让厂商之间互相了解。测试用例和测试计划的提前公布，让厂商对自己能测哪些不能测哪些做到心中有数。进行预测试，让厂商之间熟悉互操作测试的具体过程，把阻塞的问题提前解决掉。正式测试过程中分两个阶段，官方指定分组和自由组合，达到广泛互操作的目的。有一个易用的测试报告在线收集工具，让厂商对自己的工作成果进行精细管理。

3、测试过程和思路给厂商带来的价值
ETSI NFV互操作测试的流程管理非常成熟且专业。无论是产品成熟度高的厂商，还是产品成熟度不高的厂商，都能在同一套整体被精细管理的流程里互相对接测试，厂商之间在被指定分组和自由分组的测试过程中互相熟悉，形成良好技术氛围，验证了自己已经做了的东西是否有用，同时也看到以后还要做哪些有用的东西，对ETSI NFV框架和标准有了更深刻的理解，增强了采用ETSI NFV框架和标准落地业务的信心。

互操作测试能够快速推动NFV标准的落地

1、将已发布的标准测试用例化，让厂商通过实践理解标准
在运营商行业，任何一种技术和业务的架构和标准，从定义到发布，都需要漫长的时间。即使已经发布的标准，厂商之间互相理解的程度也不同。ETSI就采用了将发布的标准测试用例化的方法，让厂商在实践过程中理解标准，让厂商在测试过程中验证，已经做了的是否合理，还有哪些没做的，应该怎么做，这样就能够进一步推动标准的落地，循序渐进，充分体现了ETSI的丰富经验和对新技术和业务架构和标准的把控能力。

2、让厂商自行在测试过程中找差距，回头跟进已发布标准
参与互操作测试的厂商之间的水平是不一样的，有的产品成熟度高，有的产品成熟度不高，大厂商的产品更专业，可用性更好一些，小厂商的产品更灵活一些。跟进标准的程度也不同，有的跟进的多，有的跟进的少。ETSI通过互操作测试让跟进的少或者未跟进的厂商自己亲身感受到跟其它厂商之间的差距，对跟进标准少的厂商做后续产品规划是一个更加直接的推动力，然后下次互操作测试把之前的重新测一遍，让厂商验证自己跟进的成果，形成良性循环。

3、生态圈式的组织管理，让厂商之间自发讨论未发布标准
从VPN+BGP互联网络（HIVE）的建立开始，就让厂商之间有了自发做互操作测试和沟通接口对接的条件，再通过现场测试，让厂商之间面对面互相了解和熟悉，相当于建立了一个生态圈，衍生出来的就是Slack工作群、微信工作群等具有社交属性的工作圈子，经过了互操作测试的相互熟悉，大家不仅仅就互操作测试过程中已发布标准的问题互相讨论，进一步就开始自发的对即将发布的标准进行探讨，提前做落地实现的准备，以便在下一次的互操测试时能够得到验证。

ETSI NFV第二次互操作测试

2018年1月15日—19日，ETSI在法国Sophia Antipolis总部组织了第二次NFV互操作测试，参与本次互操作测试的大小厂商最后统计下来一共有10家MANO，7家VIM，15家VNF，其中中国厂商有3家，刚好每个品类一家。据说参与厂商数量上整体上比第一次互操作测试增加了1/3，足以看出产业界对ETSI NFV框架和标准遵循和支持的态度。有一个很重要的特点是，小厂商占了相当的比例，说明NFV已经开始让运营商行业进入软件时代，不再是大厂商一统天下，小厂商在软件上的能力并不具有明显的劣势，当然从实际测试情况上看，目前还是大厂商的产品更专业，可用性更好一些。

两次ETSI NFV互操作测试功能对比

对比解析，ETSI NFV第二次互操作测试的重要变化

1、开始关注Solution定义的接口测试
第一次测试仅是象征性的做了NS生命周期管理以及VNF的手动伸缩等概念性测试，而第二次则明确了各组件之间互操作接口的实现方式，全面Rest API，符合业内的技术发展趋势，厂商们，尤其是MANO厂商，终于可以开始放开手脚落地产品了。

2、开始关注VNF在生产环境中的NFV特性测试
事实上，VNF不仅仅是虚拟机，其在NFV场景下还要具有三大能力，一是支持Cloud-Init用来做0 Day Configuration，二是支持利用NFVI & VIM提供的EPA特性提升自己的性能，三是支持Rest API来支持1 Day Configuration以及满足性能和故障管理需求。从第二次互操作测试上看，Cloud-Init基本上已经成为大家公认的0 Day Configuration标准；对于EPA特性的要求上，很多NFVI & VIM也能够提供CPU、内存、网卡等各种可提供硬件加速的能力，包括CPU Pinning，NUMA，Huge Pages，DPDK，甚至SR-IOV；定义Rest API接口的SOL002标准刚刚发布不久，已经落地的还不多。

3、开始关注实际NFV业务应用场景的方案测试
第二次互操作测试对两种应用场景进行了测试要求，一个是多VNF，另一个是多NFVI & VIM，前者比较简单，在一个NS里自动拉起至少两种VNF，且自动组网互联；后者是在同一个MANO统一编排下，自动拉起跨多个NFVI & VIM的Cross-Site VPN，让各NFVI & VIM的内部网络之间可以直接互访。这样的应用场景是非常典型且客户需求很强烈的NFV应用，不仅可以面向数据中心环境使用，还可以作为接入侧的SD-WAN场景应用，运营商之上的动态管道运营，可想象的商业空间相当大。

NFV业务落地还有多远？

1、OpenStack的成熟，为NFV业务落地提供了坚实基础
OpenStack已经成为事实上的标准。所有来参与测试的VIM都是OpenStack，包括VMware的VIO产品。OpenStack发展到Ocata版本以后已经在功能、稳定性、可靠性方面基本达到成熟商用的能力，不仅具有对计算、网络、存储等资源的强大且丰富的管理能力，而且OpenStack服务组件容器化后，可靠性能力又有了极大的提高。关键是，OpenStack被应用的越来越广泛，市场份额越来越大，其已经成熟稳定的管理API（Rest API）已经成为大多数私有云用户的刚需，我们看到，很多非OpenStack的云操作系统厂商专门为满足客户需求，特意在外面包装了OpenStack的标准API，再加上OpenStack对VNF进行硬件加速能力的成熟考虑，基本上在VIM这一层面用户无需再更多考虑。

2、各行业的NFV相关技术规范已基本上有了可参照的范围
NFV说到底的价值是自动化编排与快速部署，这并不是运营商行业的专有属性，ETSI定义的NFV框架本身也天生具有普适的IT特点。从标准层面上看，已经到了Solution发布的阶段，各组件之间互操作接口的实现方式已经定义完整，可以落地了。根据标准框架，解耦是关键，这会极大的节省和降低用户的投资成本和投资风险，基础设施层面的OpenStack已经落地，剩下的就是对MANO和VNF的考虑，大厂商的MANO质量高，小厂商的MANO灵活，开源的MANO产品都已经基本具备简单商用能力，用户的选择性还是很多的。基本上所有的传统硬件网络设备厂商都已经完成了产品的虚拟机化，用户可以根据实际需要进行多种VNF的选择和使用。

3、SD-WAN可能会成为最快落地的NFV业务应用
SD-WAN的技术本质是通过自动编排智能选路，减少用户的专线成本，提升用户的业务通路质量，不同行业的用户都有强烈的需求。SD-WAN的技术落地刚好跟NFV非常契合，自动化编排与快速部署，第二次互操作测试中的多NFVI & VIM的Cross-Site VPN场景其实就是一种SD-WAN应用，如果把VIM再外延到公有云，MANO具有同时对私有云VIM和公有云VIM统一编排的能力，则SD-WAN的范围就基本被覆盖了，考虑到公有云VIM并不具有标准的OpenStack API接口，外延MANO产品的开发上，可能互联网行业的厂商比较合适，我们可能会快就能看到具有同时对私有云VIM和公有云VIM统一编排的能力的MANO产品出来。

为什么OpenStack能够成为事实上的VIM标准

VIM的标准定义

VIM在ETSI NFV框架中的定义是虚拟基础设施管理组件，其主要的功能是对NFVI的管理，本质上就是一个云操作系统，对服务器的计算、存储、网络等资源进行管理，提供标准的API接口供NFVO和VNFM调用，来做VNF的编排管理。

OpenStack在云操作系统市场影响巨大

1、OpenStack被大多数厂商和用户作为VIM的不二选择
跟据权威SDN/NFV媒体SDX Central跟厂商和用户做出的调查，大部分的被调查者都会选择把KVM + OpenStack作为NFVI & VIM的不二选择，即使是排名第二的vSphere + VIO，也是通过OpenStack的包装，其它云操作系统被选择的比例都不到5%。

2、OpenStack作为VIM的成熟度被广泛认可
同样是来自权威SDN/NFV媒体SDX Central跟厂商和用户做出的调查，OpenStack作为VIM的成熟度已经得到大部分厂商和用户的广泛认可，尤其是从调查数据上能够看到OpenStack走向成熟这一事实被越来越多的厂商和用户所认同，2017年比2016年这一年的时间，就增长了10%。

OpenStack的成熟度解析

1、对计算、网络、存储等资源的强大且丰富的管理能力
OpenStack保持着每年两个版本的发布速度，发展到Ocata版本以后已经在功能、稳定性、可靠性方面基本达到成熟商用的能力，不仅具有对计算、网络、存储等资源的强大且丰富的管理能力，而且OpenStack服务组件容器化后，可靠性能力又有了极大的提高。尤其是，由于OpenStack的开源特点，其在中国就具有了特殊优势，能够看到OpenStack在运营商、金融、政府被应用的越来越广泛，市场份额越来越大。

2、对VNF进行硬件加速能力的成熟考虑
OpenStack已经支持很多EPA特性上的要求，能够非常容易配置和提供CPU、内存、网卡等各种可提供硬件加速的能力，包括CPU Pinning，NUMA，Huge Pages，DPDK， SR-IOV等。

3、已经成熟稳定的管理API（Rest API）
OpenStack从Ocata版本开始，管理API已经基本完全成熟且稳定了，包括了认证的Keystone，镜像的Glance，计算的Nova，存储的Cinder，网络的Neutron，以及用于编排的Heat，所有的API都统一到openstack服务下，易用且易记。API考虑了很多细节功能，让调用者很容易对虚拟化平台的计算、存储、网络进行个性化操作，例如在使用VNF的场景下，虚机的业务接口必须放开IP检查，OpenStack的Neutron API就提供了这样的能力。

直接选择既有的事实标准，能够加速NFV标准的快速落地

1、VIM提供的接口可以直接用OpenStack既有的来做解决方案定义
VIM在整个NFV框架中的位置十分重要，因为无论是NFVO还是VNFM都要调用VIM的接口来对服务器资源进行操作，以完成VNF的编排管理。因此VIM的管理接口API的标准化对NFV框架整体标准化的影响非常大。如果说，目前没有一个云操作系统的市场份额占的比例较大，或者占比例较大的云操作系统的管理接口没有开放的API，那么NFV框架标准的落地就会面临相当大的难题，即使标准定义的比较合理，等待云操作系统厂商跟进并落地就需要相当漫长的时间。因此，鉴于OpenStack的特点，各方面刚好满足了这个具有标准现成接口的VIM的需求，历史就必然选择了OpenStack。

2、无论是MANO厂商还是VNF厂商已具有对OpenStack互操作的基础
OpenStack作为云操作系统，已经被厂商和用户所熟知，无论是MANO厂商还是VNF厂商，早已在OpenStack下做产品开发以及做方案应用多年，OpenStack再作为VIM的角色出现，让大家都不觉得陌生，甚至都相当习惯。有了虚拟化、私有云的互操作基础，作为VIM来继续互操作的额外技术成本极低，这样就更加缩短了NFV框架中各组件之间接口对接的周期，加速了标准的快速落地。