【IT168 资讯】11月 29日消息，以 " 新技术 · 新架构 · 新网络 " 为主题的 "GNTC 全球网络技术大会 " 第二天，NFV网络功能虚拟化专场，中国联通网络技术研究院NFV解决方案经理(OPNFV EUAG创始成员)童俊杰发表了主题演讲。

　　▲中国联通网络技术研究院NFV解决方案经理(OPNFV EUAG创始成员)童俊杰

　　演讲实录如下：

　　中国联通在2015年北展上提出来自己未来网络转型的一个目标架构，并且做了一系列的工作，今天我给大家分享一下，主要是近期中国联通在NFV解耦方面做的工作。

　　刚才提到我们逐步的在2015年就发布了QBDS的一个整个转型的目标网络架构，在2016年做了相关的规范，并且做了一些试点认证，2016年主要是对一些单厂家，一些设备，那时候还处于一个测试验证的过程，它可能跟实际部署相差比较远。2017年联通主要建了两个，一个是NBLT，一个物联网的商用，一个VMS的试点商业用，这两块在实际部署过程，我们2017年为了推动商用部署做了这方面的解耦的实践。

　　我们目前的实践是业务驱动的部署方式，这两个业务一方面是物联网产业的一个不断地规模化的发展，全球物联网的连接速度不断地增加，市场的前景为了满足未来业务的需求，这方面的部署是这么考虑的。还有一块是未来语音业务的支撑。做解耦测试另外一个重要的支撑是标准和产业的不断成熟，主要是三个方面，一个是标准，还有一个是开源，还有一个是产业，标准方面ETSI现在进展第二版本已经发布了，正在准备第三版本的工作。第二个方面是开源的进展，不断地在支撑和演进。第三个方面是产业，产业包括国内的厂家和第三方组织，他们成立了一些联盟和工作组的形式，不断地推动它的发展，在联通也成立了产业联盟，来推动这样一个网络的不断的重构和演进。并且联通已经在2016年的时候做了很多工作的积累，这些主要是2016年的工作，包括应用试点、软件的开发和开源，还有网络架构的演进。通过2016年的积累，我们形成了一个NFV、SDN在内的一些规范的制订工作，还有厂家产品的初步验证工作，可以说在标准规范和技术储备上，已经做好了比较完善的准备。

　　大概三层解耦的一个实践情况，三层解耦我们分为两步走，第一步是软件解耦，软件层和下面的通用服务器的解耦。第二层是三层解耦，主要是关注于中间层和上面网源的解耦。具体上面的VFM和O的解耦现在暂时没有考虑，整个测试大概情况是持续了将近10个月左右，包括从测试规范的准备、软硬的功能结构，包括后面的VBC和VMS的三层解耦，我们总共在答应方面10多个厂家，这方面可能硬件厂家备货周期大概一个月，在今年2月份才正式启动解耦测试。引入的时候当时是引入了少量的IT厂家，虚拟化层还是以CT厂家为主。

　　在VPC领域测试的时候，我们做网源测试的时候，包括VMS，我们考虑必须端到端的打通，因为运营商主要考虑整体业务的开通和业务的可靠性。在VMS三层解耦的时候，我们是逐步引入了ID厂家来作为虚拟化层，整个解耦测试中，是把虚拟化厂家作为集成厂家来考虑的。我们测试中也碰到很多问题，虽然我们要求每个组合，每个三层解耦组合需要打通端到端环节，但是每个组打通，它的打通过程包括打通时候的网络配置，包括跟底层的网源的接口，这个标准都是不统一的。通过我们大概的小结，主要分为三个方面的问题，一个是安全认证的问题，第一个是GPS，现在很多厂家都在用SAP去做MANO之间的认证，包括认证时候证书的问题，包括证书的要求、格式、流程，它们差异性还是很多，目前来看主要是V2和V3的区别。

　　同时还有一块是资源获取和监控，对于资源的获取和监控，OPENSDK本身去做虚拟化层做监控，但是从运营商的角度说，它对设备可能有一个监控，这方面是缺失了。OPENSDK的特性和配置，包括开启可能会开启一些网络的加速、SIV、DBK这种，这种开启是不是支持，有部分厂家虚拟化层并不支持加速特性，还有的厂家支持的时候，差异性会存在，但是我们这次主要测试是功能性，基本上支持能够测起来，但是性能方面我们现在还没有测试，性能方面由于兼容性，还存在一些差异性。还有关于MTO的配置，各个厂家的各个网源在布局的时候，对MTO的设置是不一样的，虚拟机部署的时候如果厂家有可能用HET模板布，也可能调用OPENSDK原生接口，如果采用模板布的话，里面可能会涉及到参数的问题。

　　最后一个是HET问题，HET我们发现在VMSN结构里我们引入了很多IT厂家，IT厂家对接的时候发现HET问题比较多。我们对于测试方面，给大家一个参考，第一个是统筹规划，在做测试之前，应该对整个测试的目标或者目的性，我们会有一个统一的规划，这样才能说我们到底要测哪些东西，并且对测试环境可能需要一个准备，包括我们准备多少物理资源上需要多少设备，包括实验室机房的规划，包括人员的规划。自动化测试方面，由于三层解耦按照以前的全排列的组合做，有些企业虚拟化以后，对于虚拟化层，IT、CT数量比较多，可能我们这次大概将近10个，这种组合数起来是成倍增长的。这种组合数非常多，虽然每个规范数并不多，但是其实组合起来总量非常大，可能需要引入一些自动化的测试工具。

　　第三个是规范标准，在测试时候，因为现在还说标准开源，厂家还是有差异性的，大家没有完全的统一，所以到时候对于用力来说，或者对于测试结果的评判来说，需要一个公正的评定标准，这时候作为规范来说非常重要。

　　第四个是总结讨论，在三层解耦不仅仅是在联通，很多厂商、运营商在自己的实验室或者线网都会做一些实验，但里面的问题挺多的，这方面需要定期的进行总结，并且可能会在后续的演进，包括后续的厂家开发中考虑这些事情。

　　上次NBLT的招标情况介绍一下，从测试厂家来说，我们虚拟化层可以看出，引入IT厂家比较少，解耦测试刚才说的两个阶段，其实从招标情况来看，我们基本上没有IT厂家去中虚拟化层的标，端到端的招标比例比较重，还有一个运维管理的不完善。分开具体来讲，一个没有IT厂家中标，当时在测试的时候，一方面是因为IT厂家对CT有部分厂家并不熟悉，它在做集成的时候，做向上对接的时候，没有经验的话，有的时候经验不足导致进度有延后。端到端的比例，还有一个是运维管理的不完善，主要体现在硬件管理方面，包括虚拟化层往上报的性能告警的性能接口的不完善。

　　对于践行后，大概有三个思考，第一个是NFV技术是一把双刃剑，一方面它会降低进入CT的门槛，很多IT厂家可以把虚拟化层作为一个放在NFV里作为虚拟化层，整个会导致对于运营商测试工作量成倍增加，这方面需要运营商为了节省工作量，一方面要用自动化的工具做，另一方面要考虑有一个准入门槛，这个准入门槛根据本身各个网站的需求划一条线，也可能运营商通过公开的第三方组织通过他们来源做一个公正的测试。开源生态十分丰富，软件化的时代百花齐放，也导致各个接口标准难以统一，除了的时候非常难以说有一个标准的去衡定。

　　虚拟化带来的很大的灵活性，这种灵活性体现在商家的功能实现上，或者厂家的接口的设计上，其实对于一个功能，各个厂家都可以实现，但是具体实现的流程和接口不一样，这个时候可能需要运营商把接口统一规范，还有流程可能会稍微定的细致一些。这个是管理架构的问题，管理架构是我们今年做的一个通信云的规划，说未来通信云大概分几个管理，第一个是基础设施层的管理，第二个是网源的管理，还有一个网络的管理。基础设施管理不仅仅是考虑现在VIM对于资源的管理，还包括考虑对于硬件的管理，同时还有一个统一云管，跟VIM、PM有个对接，统一云管能够做虚拟资源的统一管理。还有一个网源层的管理，两个部分，一个是EMS对网源正常的配置，跟传统的EMS基本保持相同，还有一个是VEFM是生命周期的管理，网络层管理主要两个，一个是LVO，是整网资源的管理，同时包括OS生命周期管理，包括整个网络的运维都在OSBS上。

　　还有一个是建设模式，这里面构建模式上，里面主要两个方面，一个方面是建设模式，另外一个方面是集成模式，建设模式通过业务驱动网络的建设，自己向上，通过我们先构建好整个基础设施平台，来把业务逐步的按步骤的部署在公共的基础设施上。这两个各有优劣。今天的建设模式是从下到上，这样比较快速。第二种是自下而上，有利于基础设施建设向多多业务共平台方向演进，但是由于运营商的业务比较多，网源比较复杂，未来的需求，包括厂家的产品实现也是不断实现的，对于上层的网源，对于虚拟化层的需求具有很大的不确定性，所谓建设时候可能对基础设施一方面是需要不断地演进迭代，还有一种是集成模式，在测试中主要让虚拟化集成厂家做集成，特别是在IT厂家发现，在做集成的时候，他们可能对CT领域并不是特别熟悉，导致在集成时间进度上难以保证。还有一种是NFV做集成，主要优势对CT领域比较熟悉，集成起来相对快一些，但是通过O集成，它会在O和VIM之间存在一些耦合性。