NFV的技术发展现状和未来展望
NFV技术简介
NFV的全称是Network Function Vitiualized,中文翻译是“网络功能虚拟化”,简单理解就是把电信设备从目前的专用平台迁移到通用的X86 COTS(Commercial Off-The-Shelf,商用现成品或技术)服务器上。
深入理解一下,发现真相并不是这样:
在专业领域,通用化设备如果要达到专用设备的处理能力,则成本是无法接受的。例如渲染一定要靠GPU而不是CPU,例如专业网卡一定要靠自己的处理芯片而不是CPU。PCI本身的带宽就确定不能用于网络设备。PCIE的话一般简单用途是OK的,到了万兆以上吞吐就已经需要3.0版的4通道(3.938GB/s,服务器板子上8通道基本是存储专用,16通道基本看不到)才能达到。而同样的网卡用卡载芯片实现的,至少也是双接口甚至4接口,也就是你这一块卡可能需要8﹣16通道的带宽才能搞定。而企业核心网已经都是聚合40G或者80G的通讯量了,电信级的更是大的多,所以作为核心网络设备,这个体系结构本身就承受不了。CPU方面,由于它的设计是用来处理少量复杂任务而不是简单重复的大负载任务,干这事就跟渲染视频一样──不靠谱。
从趋势来看,虚拟化已经从概念走向实际使用。在推进过程中,虚拟化已经开始摒弃所谓的低成本策略(实际上现在的虚拟化方案如果单独从软硬件投资来看,比非虚拟化并不具有价格优势,通常会更贵),而重点强调 灵活、集中管理 等优势。举例:NFV性能优化——架构性并行加速算法思想。
越位于底层,基础设施属性越强,标准化程度越高,灵活性越差;越位于上层,情况则相反。所以可以看到,NFVI标准程度远高于MANO,NFV的灵活性和集中管理更多地体现在MANO上,而不是NFVI上。
在技术上,虚拟化也已经从软件开始向硬件过渡。也就是说,并不是把硬件抽象出来,而是把抽象的业务重新交给专业的硬件去做。比如服务端虚拟化方案中,主板开始支持硬件IO虚拟化,网卡已经可以直接使用硬件为虚拟机提供支持。
在实际的产品中,目前也有一种虚拟化的趋势,是融合方案,以思科为代表。即把所有的交换业务都集中到专业的网络交换机上,代替原来的计算中控、存储网络的交换设备。因为算下来,网络设备的单位价格处理能力,是最经济的,应该是被发展和利用的对象,而不是被取代的对象。
如下图所示:当前电信网络使用的各种设备,均是基于私有平台部署的,这样各种网元都是一个个封闭的盒子,各种盒子间硬件资源无法互用,每个设备扩容必须增加硬件,缩容后硬件资源闲置,耗时长,弹性差,成本高;在NFV方法中,各种网元变成了独立的应用,可以灵活部署在基于标准的服务器,存储,交换机构建的统一平台上,这样软硬件解耦,每个应用可以通过快速增加或减少虚拟资源来达到快速扩缩容的目的,大大提升网络的弹性。
为了实现上述目标,NFV的技术基础就是目前IT业界的云计算和虚拟化技术,通用的COTS计算/存储/网络硬件设备通过虚拟化技术可以分解为多种虚拟资源,供上层各种应用使用,同时通过虚拟化技术,可以使得应用与硬件解耦,使得资源的供给速度大大提高,从物理硬件的数天缩短到数分钟。
通过云计算技术,可以实现应用的弹性伸缩,从而实现了资源和业务负荷的匹配,即提高了资源利用效率,又保证了系统响应速度。
根据NFV的思想,一个虚拟的4G EPC系统部署方式如下图:
图中,一个vEPC系统由4个虚拟网元组成(2个P/SGW,1个MME,1个HSS),分别部署在4个数据中心中,这4个虚拟网元完成EPC网络规定的功能,提供EPC网络服务。
NFV的收益:
- 降低运营商采购/运维成本及能耗。
- 快速业务部署,缩小创新周期:包括提升测试与集成效率,降低开发成本。软件的快速安装取代新的硬件部署。
- 网络应用能实现多版本及多租户。支持不同的应用、用户、租户共享统一的平台。网络共享的支持水到渠成。
- 使能不同物理区域以及用户群的业务个性化,业务规模能够快速方便得伸缩。
- 使能网络开放,业务创新。可能孵化新的利润增长点。
引入NFV前
- 产业链:相对单一,核心成员主要包括设备制造商、芯片制造商等
- 传统设备制造商销售模式:软硬件一体化
- 网络架构:封闭
- 接口:杂乱
引入NFV后
- 产业链:核心成员主要包括通用硬件设备制造商、芯片制造商、虚拟化软件提供商、网元功能软件提供商、管理设备提供商等
- 传统设备制造商销售模式:通用硬件、虚拟化平台和网元功能软件三部分的销售模式
- 网络架构:开放
- 接口:统一且标准化
传统设备制造商的优劣势
- 优势:在网元功能软件上有技术壁垒,主要体现在对网络业务知识的积累上,具有较强的系统集成能力,向第三方系统集成商演进阻力较小
- 劣势:在通用硬件和虚拟化平台软件方面将面临来自IT领域的强大竞争
NFV技术当前发展现状
NFV定义的技术架构如下图所示:
同当前网络架构(独立的业务网络+OSS系统)相比,NFV从纵向和横向上进行了解构。
从纵向看分为三层
基础设施层:NFVI是NFV Infrastructure的简称,从云计算的角度看,就是一个资源池。NFVI映射到物理基础设施就是多个地理上分散的数据中心,通过高速通信网连接起来。 NFVI需要将物理计算/存储/交换资源通过虚拟化转换为虚拟的计算/存储/交换资源池。
虚拟网络层:虚拟网络层对应的就是目前各个电信业务网络,每个物理网元映射为一个虚拟网元VNF,VNF所需资源需要分解为虚拟的计算/存储/交换资源,由NFVI来承载,VNF之间的接口依然采用传统网络定义的信令接口(3GPP+ITU-T),VNF的业务网管依然采用NE-EMS-NMS体制。
运营支撑层:运营支撑层就是目前的OSS/BSS系统,需要为虚拟化进行必要的修改和调整。
从横向看分为两个域
业务网络域:就是目前的各电信业务网络。
管理编排域:同传统网络最大区别就是,NFV增加了一个管理编排域,简称MANO,MANO负责对整个NFVI资源的管理和编排,负责业务网络和NFVI资源的映射和关联,负责OSS业务资源流程的实施等,MANO内部包括VIM,VNFM和Orchestrator三个实体,分别完成对NFVI,VNF和NS(NetworkService:即业务网络提供的网络服务)三个层次的管理。
NFV技术原理
一个业务网络可以分解为一组VNF和VNFL(VNFL:VNFLink),表示为VNF-FG(VNF Forwarding Graph),然后每个VNF可以分解为一组VNFC(VNF Componet)和内部连接图,每个VNFC映射为一个VM;对于每个VNFL,对应着一个IP连接,需要分配一定的链路资源(流量,QoS,路由等参数)。
通过这样的编排流程,一个业务网络可以通过MANO来自顶向下分解,直到可分配的资源,然后对应VM等资源由NFVI来分配,对应VNFL资源需要同承载网网管系统交互,由IP承载网来分配。
采用NFV部署一个网络服务的示意图如下所示:
NFV技术存在问题
NFV定义的标准虽然从技术上看是可行的,但距离商用还有一定的距离,主要问题如下:
标准成熟度问题:NFV由于目标过大,第一阶段即将到期时,也只完成了4个总体规范,其他工作组定义的相关规范尚未完成。很多问题都被推迟到第二阶段实现,因此目前标准距离成熟尚有一定距离。
兼容性问题:NFV定义的架构很庞大,定义了多个新增接口,将原来封闭的电信设备商分解为多个层次:硬件设备供应商,虚拟化管理软件供应商,虚拟化电信网络软件供应商,NFVO(NFV Orchestrator)软件供应商,NFV系统集成商;这样电信网络从一个厂家完成的软硬件集成的事情转换为多个厂家的软硬件集成,复杂度大大提升;同时NFV只是定义架构层次,对应各个接口的具体定义和实现是协调其他开源或技术组织来实现,这样同一个组织制定标准相比,技术标准的严密性就会差一些,未来如何保证多厂家设备兼容就成为很大风险。
业务网络级的SON(Self-Organization Network)技术滞后,影响网络级弹性伸缩:按照NFV架构,虽然一个新的VNF所需资源是由MANO自动部署的,但业务网络的运维架构依然依靠传统的EMS/NMS机制,各VNF之间的连接和话务路由还是由人工来配置的,无法实现一个VNF的即插即用;因此要实现业务网络级的弹性伸缩,还需要发展业务网络的SON技术,实现VNF的即插即用,并且需要SON技术同VNF厂家解耦,可以对多厂家VNF进行SON,这在技术和管理上都是比较困难的。
虚拟化的可靠性技术:传统电信应用通常都要求5个9的可靠性,虚拟化后并不能降低电信应用的可靠性要求,传统电信硬件通过特殊设计,可靠性通常较高,而虚拟化采用的COTS设备可靠性相对降低了,需要通过提升软件可靠性来补偿。
网络虚拟化技术相对滞后:同计算和存储虚拟化技术相比,网络虚拟化技术还比较落后,SDN尚不成熟,目前网络虚拟化技术类型繁多,如何整合到NFVI中是一个较大风险。对于电信业务网络来说,由于通常是一个分布式网络,因此需要配置较大的网络资源来承载,这种网络资源需要分解到数据中心内部的局域网络资源和数据中心间的承载网络资源,业务网络与接入网络间的承载网络资源等,承载网络资源分配又可能涉及到传送网络资源分配;这些资源的分配都需要做到虚拟化,自动化,目前这种分配尚需要通过承载网/传送网网管来进行,距离自动化尚有较大距离;现在最有希望的技术就是SDN了,等待SDN在这些领域中应用后与NFV配合。
系统集成问题:NFV本身解决的是业务网络的自动部署问题,从架构看也是一个巨型的ICT系统集成工程,分解一下包括NFVI的集成,VNF的集成,和业务网络的集成,涉及的系统,厂家,地域,接口都非常多,工程难度比目前公共云/私有云更高;虽然是自动部署,但目前电信网络部署的各环节(规划,实施,调测,升级,优化,运维等)都会涉及并执行,将来如何进行实施部署将是一个很复杂的问题,对集成商的技术要求非常高。
NFV技术未来展望
从上面各小节我们看出,NFV是一个宏大的架构,对传统网络部署方式是颠覆性的变化。NFV拓展了运营商基础设施范围,将数据中心设备/承载网设备/虚拟化软件系统/MANO系统均转化为基础设施,业务部署均转化为软件部署,业务网络资源与负荷实时匹配,资源利用效率得到最大提升。
采用NFV架构后,电信网络的自动化管理和敏捷性将大为提升,一个电信设备的部署周期从几个月缩短为几个小时,扩容周期从几周扩展到几分钟,电信网络新业务部署周期将从数月级缩短到数周级,电信运营商将真正具备“大象跳舞”的能力。
NFV将率先在五大应用场景落地
- vBRAS(Virtual Broadband Remote Access Server)虚拟化宽带远程接入服务器
- vCPE (Virtual Customer Premise Equipment) 虚拟化用户预制设备
- vEPC (Virtual Evolved Packet Core) 虚拟化演进分组核心网
- vIMS (Virtual IP Multimedia Subsystem) 虚拟化IP多媒体子系统
- vSR (Virtual Service Router) 虚拟化业务路由器
NFV关键技术问题
- VNF生命周期管理:MANO,NFVO、VNFM、VIM
- 性能:
- 网络I/O能力(现有解决方案)
- Single root I/O virtualization (SR-IOV):一种基于硬件的虚拟化通道技术。虚拟机直接连接到物理网卡上,获得等同于物理网卡的I/O性能和低时延,且多个虚拟机之间高效共享物理网卡
- Data Plane Developers Kit (DPDK): 一种内核旁路机制。为了提高包处理的速度,允许虚拟交换机旁路内核并直接与兼容的网卡通信
- 计算能力(现有解决方案)
- 超线程技术。要求COTS硬件支持超线程技术提高CPU的并发处理数,使得单个处理器可使用线程级并行计算,减少CPU的闲置时间
- 硬件加速机制。目前业界主流的专用硬件加速技术包括通用加速资源池、专用PCI加速卡或CPU内置加速芯片等,但具体采用何种专用硬件加速技术仍有待进一步研究评估
- 中间件性能损耗
- 网络I/O能力(现有解决方案)
- 可靠性:传统电信设备99.999%的可靠性,通用设备只能达到99.9%的可靠性
- 安全:
- 新的潜在安全问题
- 引入新的高危区域——虚拟化管理层
- 弹性、虚拟网络使安全边界模糊,安全策略难于随网络调整而实时、动态迁移
- 用户失去对资源的完全控制以及多租户共享计算资源,带来的数据泄漏与攻击风险
- 存在安全风险的关键组件
- VNF组件实例
- 绑定到VNF组件实例的本地网络资源
- 远程设备上对本地VNF组件实例的参考
- VNF组件实例占用的本地、远程以及交换存储
- 安全事故处理
- 如何保证关键组件所涉及的硬件、内存不被非法访问
- 如何保证VNF上应用的现有授权不被改变
- 本地和远程资源彻底清除崩溃的VNF资源及授权不被滥用
- 现有解决方案
- 对于物理硬件资源
- COTS硬件需要提供基于硬件芯片的可信环境,以便于虚拟层及业务软件层可基于硬件可信环境构筑信任根,实现安全启动和安全存储
- 目前通过使用可信赖的平台模块(Trusted Platform Module,TPM)来完成加密、签名、认证、密钥生成等功能
- 对于接口的访问,COTS硬件需要进行访问控制和认证鉴权,防止非法访问
- 对于虚拟化平台资源
- 要求提供租户、虚拟机以及不同业务的安全隔离,避免虚拟机之间的数据窃取或恶意攻击
- 对于虚拟化平台及其所管理的虚拟资源的访问,要求提供访问控制和认证鉴权,防止非法访问对系统的影响
- 在存储方面,对物理存储实体的直接访问具备禁止或限制的能力,提供虚拟存储数据清除、虚拟存储数据审计、虚拟存储数据访问控制和冗余备份功能;在计算方面,能利用加密算法协处理器,高效实现VNF内部的机密性和完整性保护
- 对于网络资源
- 应具备对虚拟机的隔离和访问控制能力,虚拟机之间需要授权和鉴权后才能建立通信连接
- 通过在线的深度报文检测、虚拟防火墙技术以及基于Netflow采集的流量溯源与关联分析等综合技术,可以建立基本的NFV网络安全防护体系,能够支持抵御畸形报文攻击、DoS攻击和仿冒攻击等
- 对于物理硬件资源
- 新的潜在安全问题
- 集成部署:多厂商软硬件集成、标准和开源的混合
- 开放互联:如何规范开放API编程接口
标准和开源项目进展
- 开源方式:通过开源项目构建产业生态,以迭代开发模式加速产品应用并形成事实标准,影响技术和产品的发展方向
- 标准方式:传统电信领域的标准化更多是通过文稿制充分讨论后达成共识,再在产品中实现
参考资料
文档信息
- 本文作者:Yu Peng
- 本文链接:https://www.y2p.cc/2017/01/14/nfv-white-paper/
- 版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)