屠嘉顺:面向电信应用的云原生NFV

大家上午好!我们知道,所谓的云化对于未来的网络架构和网络结构实际上并没有太大的变化,我今天的演讲是关于云或者是云环境如何给3GPP网络带来一些优化,带来一些好处。

电信网络可以打电话、发短信还有上网,我们都把它归结为英特网应用,但这些应用恰恰是网络最需要提供定制化服务的网络,比如自动驾驶对延迟有很高的要求,如果我们只有一张网络提供万物互联的业务,显然是不经济的。举个例子,大家知道我们可以抄表,这是万物互联一个很重要的方面,但是水表很关注延迟吗?显然不是,它关注的是什么?关注的是成本。我们知道水表大概一个月交20块钱,如果让你交20块钱给运营商,水表公司肯定不愿意,所以这个场景下,我们怎么样让网络去关注具体需求的特定要求是很关键的。

这边一个很好的观点就是Slice,我们针对某一个特定的需求提供一个特定的切片,来满足特定的要求。比如说抄表应用,它的要求是便宜,自动驾驶要求低时延,我们知道视频要求的是大带宽。但是目前的3GPP提供给我们的就是对所有的终端用户提供普遍服务,它是一致的,提供差不多一样的服务,一样的接入,基本平均的业务能力。

这边我们提了一个在云化环境下如何做网络,做NFV。我们知道,我们今天的主题是网络功能虚拟化,我们今天主要讲一下网络功能。以前有一个很好的概念叫ATCA,也是基于英特尔X86架构下的架构,我认为在ATCA下做虚拟化相对容易。第二个是IaaS,我们要协调各个网元,我们需要有一些MANO来做一些分配和协调。今天主要讲的是第三阶段PaaS,像我们刚刚提到了,我们在3GPP中有一些标准的网元,运营商完全可以实现不同的采购来实现。但是,我们可以想像,这么多网元中,它有大量的特性,大多数网元中都会有一些通用的协议,或者说我们有些函数,这些函数是可以重用的。我们提出了一个云化的通用的组建,也就是提出了所谓的组件化,而这些组件化我认为在一定程度上是云化环境可以提供给我们的。这个组件可以运行在虚机上,这是PaaS环境很重要的一个方向。我们可以根据很多的组件库来构建我们自己特定的网络,我们刚刚提到了,我们在3GPP有一些标准的BOSS,基于这些,我们在不同的运营商构建的场景基本类似,如果我们把这些BOSS上一些特别的功能,可以让运营商以细粒度的去构建自己的网络。比如抄表网络,还有一些视频的延迟,完全可以有一些CDN的功能。我们认为在提供了这些云化的通用组件的场景下,特别是在提供编辑环境的场景下,我们为运营商提供了一个完全可以定制化的网络云环境,这就是我们所谓的PaaS平台。

当然还有一个很重要的方面,就是我们提供的这些是具有能力开放的,运营商总说自己的管道,实际上OTP也很困惑,因为他没有足够的能力进行协调。如果说我们的管道有很多开放的API开放给第三方,我们相信这是一个不得已而为之的说法。如果我们有足够的API开放给OTP,我相信我们的融合是很好的场景。任何东西都可以作为一种Services,这是一个比较远期的愿景。

具体探讨一下在环境下如何做到网络功能虚拟化。这边提了一个网络功能虚拟化的架构,可以看到最上面有C-Plane,还有U-Plane,传统网元设备要有数据区,每个数据区会关注每一个用户的状态。这些用户数据区是每个网元独立的,我们知道在核心网络中有一个网元存储是网络静态数据,我们能不能把动态数据提取出来让所有的网元共享。有什么好处?我们下面来讲。

前面也介绍了,对于网元进行的虚拟化,我们仍然对性能进行追求,比如说我们最早的基础上有了很大的性能上的提升。第二个,虽然我们是虚化的,虽然我们基于标准的架构,但是仍然可以采用一些标准的基于PCIE的标准。比如说我们做了FPGA的包转发的性能提升了很多,同时我们也做了GPU的性能提升,这是在目前阶段,我们做了一个成本性能和方案的折中。当然这些标准的PCIE的不仅仅是中兴的IT服务器上可以用,在通用的服务器都可以用。

这个是我们刚刚提到的,Cloud Redundancy Solution Wuarantees High System Reliability。由于引进了异地容灾,我们有75%的设备是不工作的,但是你需要花钱购买硬件和虚机,需要配占地水电空调,这是没有办法的,因为这是我们传统的方法。右边我们引入了中央数据库,在这个场景下,它不需要处理器,你要做一个可靠性的工作,这个成本会小很多,效率也高很多。我想这就是我们提取了一个组建的一个很大的好处。

再来看看这个,我们现在知道,这个中央数据库要可靠,云化的环境为我们做可靠性的中央数据库提供了一个很好的环境,从右边的POOL是一个很基本的概念,从逻辑上来看,我就是一个可靠的中央数据库,至于数据库内部做可靠性的容灾、备份和处理,这是它内部的机制,我们这个可以继续讨论。这个实际上就把大量的每个网元自己需要做的工作全部放到中央数据库去了,我们知道中央数据库的规模和性能比整个网元占用的资源小很多,这就是一个基本的概念。

这个就是我们在提取一些公用网元方面做的一些考虑,特别是在做NFV的时候,不单纯是把它移到一个虚拟化的环境。

再说一下Security,随着PaaS平台的引入,我们引入了容器,我们从物理上或者软件上没法做到前面两种场景的隔离,这个是我们需要考虑的,我前面提到了很多的思路和方案,就不详细展开。

总结一下,前面提到了虚拟化,我相信很多运营商特别是中国的三大做了很多有益的尝试,我们已经实现了3GPP网络从一堆厂家不同大小的盒子移到了云环境,但是逻辑上来说,它还是3GPP的环境,这是第一个阶段。

第二个阶段,目前我们正在尝试做的,我们希望在这些案例中提取出一些常见的颗粒度,从运营商可见的颗粒度来说,它是相对独立的重用的组件,而不是常见的3GPP盒子。我们正在做的或者正在试图推广的一个是Cloud Native,我们坚信云环境会给我们3GPP的逻辑网络带来好处,在第二个阶段我可以看到,要让这些所谓的通用的设备有一些开放的API出来,可以让这些通用的设备之间互相调用。我们这些开放的API也可以开放给第三方,从而实现云网融合,让我们的网络、我们的管道要和应用、甚至是终端进行一个无缝融合,他们的融合是采用开放的API进行互相调用,从而实现真正的融合。

网络功能的重构,前面说了,从ATCA到我们要把标准的3GPP的网元分成或者提取出很多公用的组件,让第三方调用,这是我们网络功能重构的重要方面,也就是说中兴公司是一个传统的电信设备制造商,我们有很多的传统盒子在运营商里有销售。我们现在的网络仍然卖这些盒子,比如说EPC,内部架构在进行大量深刻的变化,我们要进行提取,从而实现整个网元的重构。

这个讲的是环境,因为我们提取架构是基于PaaS平台的,当然从IaaS到PaaS是有一个过程的,我们必须要有一个环境支持联合组网,或者说基于PaaS的EPC要能和基于IaaS进行互通,也就是说我们提供的整套环境是平滑演进和延续性的,这是一个基本的诉求。

我下面再简单介绍一下几个典型的例子,这是中兴公司的几个简单诉求,这是一个典型的vBARS的场景,这是我们的路线图。看一下我们公司做的实践,这是我们在欧洲和奥地利电信的合作,基于标准的云环境下的融合虚拟化核心网的部署,已经实现了商用。第二个环境是基于Vodafone,我们做了一个性能和功能的测试,现在还在继续合作。这是我们一个不错的进展,这是我们跟Telefunica的合作,在南美的七个国家会构建一个这样的环境。

我们总说电信是很不错的,很可靠,如果说把你的电信的案例放在亚马逊上是什么样的?我们做了一下实验,好像还不错,虽然它的云并没有像我们这样有一个强大的MANO进行管理和自动化处理,但目前看来项目进行得很顺利。我们在今年夏天得到了一个5G WORLD的奖项,谢谢大家!


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/18198.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于16-12-08
2