NFV在运营商网络三大用武之地

尽管NFV是一个非常理想的模式,但是如何将NFV逐渐在运营网中引入进来,才是最重要、最需要思考的问题。其实很多运营商都已经开始实践在运营商网络中引用NFV架构。到底运营网的哪些部分更为适合首先NFV化呢?

一方面不断在专用硬件设备、基础设施上加大投资,另一方面用户所支付的通信费用却逐年降低,这就是通信业界所谓的“剪刀差”。运营商已经意识到,如果想要在这个移动互联网时代不被边缘化、管道化,从商业模式、业务内容、服务方式,甚至是建网模式上需要进行革新。以运营商为主导的NFV组织,就是要将NFV引入到运营商网络,让传统的运营商网络逐渐演进到面向业务的新运营网,快速将新业务带向网络用户的同时,降低采购成本和运维成本,拉通用户和第三方形成新的生态圈。

一、 如何在新运营网中引入NFV

运营商的网络经过多年的发展,多种业务不断叠加、错综复杂。NFV的引入,可以从网络或者网络节点对转发能力和计算能力两方面去权衡。针对运营商网络中的主要部分对于转发能力和计算能力的要求(如图1所示),可以对全网有一个整体结论:越是对CPU要求高,越是对转发能力要求低的系统,在当前阶段最适合率先进行NFV化。

在运营商的当前实践中,确实也是根据这个基本原则去进行试点选择的。目前主要进行NFV化的IP网络位置有:数据中心的L4-L7业务网关、城域网核心层路由反射器RR、城域网多业务边缘网关和虚拟客户端等。那么运营商在现网具体是如何实践的呢?

二、运营商IP网典型的NFV应用场景

1. 数据中心L4-L7业务网关

运营商的数据中心面向使用者可以分为IDC、业务数据中心、支撑数据中心等等。在最近一轮的资源池化和云化的热潮中,也把运营商的数据中心分为公有云、私有云和混合云数据中心。无论是哪一类数据中心,一方面,越来越看重快速部署和开通业务,响应用户需求;另一方面,要求L4-L7(例如防火墙、负载均衡等)业务能够根据不同的业务或者不同的租户进行灵活部署,更灵活的满足用户需求。所以,快速、灵活成为NFV是数据中心的NFV演进中的两大关注点。

毫不夸张的说,任何传统专用硬件能够做的,VNF(虚拟网络功能)都可以做到。但是最为关键的不是把网络功能复现,而是将网络功能通过编排与云业务灵活耦合起来。NFV在数据中心的典型部署模式如图2所示。

随着云业务的交付,尤其是面向多租户的环境,网络业务越来越复杂化。数据报文在网络中传递时,需要经过各种各样的业务节点,才能保证网络能够按照设计要求,提供给用户安全、快速、稳定的网络服务。这些业务节点(Service Node),典型的有防火墙、负载均衡、入侵检测等。通常,网络流量需要按照业务逻辑所要求的既定的顺序,穿过这些业务点,这就是所谓的服务链(Service Chain)。为了实现各种业务逻辑,Service Chain需要可编程实现灵活组合。而随着SDN以及NFV的不断推进,服务链变得更加重要。传统的网络用专业硬件承载单独功能,再将其部署在物理网络中,作为一种固化的网络拓扑。随着业务编排和服务链的引入,网络可以被抽象。运营商可以面向业务流定义所需要的网络功能以及业务流处理方式。

多租户公有云(VPC)或者私有云业务资源池的L4-L7能力向NFV演进时,业务可以基于Controller部署。Controller根据业务/租户需求,创建服务链,部署服务链上每个节点的业务逻辑,根据报文特征将需要进入服务链处理的用户报文引入服务链,从而完成面向业务需求的网络功能部署,突破物理拓扑的制约,让网络部署更为灵活。

国内运营商已经迈出了数据中心NFV化的第一步。2014年,各运营商都在以实验室测试和现网试点相结合的方式逐渐推进NFV的运营商网络商用。在私有云和政企云方面,已经将最新的NFV技术引入了商用。最典型的是公有云VPC业务(如图3所示),通过在x86架构的虚拟机上部署防火墙、VPN网关等,将企业网络扩展到公有云中,为企业进行统一的网络管理,包括:网络配置、安全策略、管理策略等。通过部署QoS、WAN优化等,提供一致的业务体验。不仅让企业员工通过VPN安全、快捷的访问公有云,而且企业公有云和私有云二层安全互联,实现资源统一管理、动态调配、应用灵活部署和自由迁移。

2. 骨干网路由反射器

目前主流运营商的骨干网流量都是已经达到T级别,骨干网关注的也主要是大容量高速转发。骨干网上基本不涉及业务部署,因此在骨干网部署的设备也以大容量专业硬件芯片的核心路由器为主。尽管城域出口及骨干网设备一旦流量超过一定的阈值就开始设备扩容,但是近年的流量猛增总是与流量不均衡相伴出现。一边是不断扩容,一边却出现资源闲置。对于出口流量宝贵的运营商而言,这是一种极大的浪费。在传统网络中,通过写大量的策略路由可以在一定程度上缓解流量不均衡的问题,但是需要运维人员手工维护策略路由配置的现实又给管理和维护带来了极大的挑战。

另一方面,经典且成熟的传统的TCP/IP协议有时又成为我们网络规划的最大限制:我们无法超越这个协议规范,因为业界的统一标准制约着芯片商、设备商和使用者。在整个产业链最下游的使用者,不能轻易改变技术规则,网络的建设运营和维护无法完全按照实际需要去进行。

在骨干网全连接的架构中,有一对或者多对路由器承担着向全网设备反馈路由信息的功能,这就是路由反射器(RR),一般由专用硬件芯片架构的高端核心路由器来做全网RR,除非更改软件版本中的相关协议。但是主流厂商的高端核心路由器的软件版本,都有一定的版本维护周期,无法随意增加改动版本,因此对现网使用的新需求也无法快速响应,甚至有的时候受限于芯片原因,导致无法改动。有没有可能将一部分控制平面的路由计算功能剥离出来,按照使用者的需求来设计呢?海外一些领先的运营商已经在实践将RR这个设备角色功能部署在x86服务器上(如图4所示),由于RR的最主要功能是计算路由,而非转发流量,因此在大型骨干网中,RR可以率先迁移到x86架构上,能够更快适应使用者需求的变化和差异。例如,改变BGP路由下一跳的机制,引入源地址等综合信息进行选路,能够通过智能的方式实现骨干网流量负载均衡的初级阶段。在这个阶段,骨干网高端核心路由器不需要做任何改变,按照传统标准的方式去接受RR反射的路由信息。所以现阶段,具备极高的可实施性。

海外运营商引入x86架构的RR的目标绝不仅止于此。在完成骨干网流量负载均衡的初级阶段部署后,运营商希望能够从现有骨干路由器上提取到更丰富的流量信息,通过部署Controller来搜集全网流量信息,Controller通过综合计算和策略匹配,来精确调度骨干网络流量,实现理想的流量工程。相较于初级阶段的RR x86化及协议增强,理想目标阶段需要现网的设备升级或者更换才能够支持相关标准控制协议,而控制协议的标准化和完善本身也需要一些时间去积累。

3. 城域网业务边缘新POP

在以带宽贩卖为主要运营模式的传统运营网中,业务边缘节点设备基本能够满足运营需求,但在部分发达地区,传统的业务边缘节点设备已经出现了计算能力和转发能力的不匹配。当传统城域网边缘路由器10GE接口使用率才到20%,CPU的利用率却已达到70%~80%。并且随着增值业务的部署,传统的城域网边缘路由器越来越凸显出其业务特性开发响应周期长、L4-L7业务能力偏弱的问题。

运营商在思考将x86这种具有更高计算能力和更标准灵活的硬件架构引入到传统城域网的业务边缘层的可能性。通过部署x86架构下的虚拟CPE(VCPE)、虚拟BRAS(VBRAS)和虚拟NAT(VCGN)等资源池,使得业务边缘的用户接入控制能力得以灵活扩展(如图5所示)。

运营商首先在VCPE方向上进行实践,将原来散落在用户家庭的接入网关的高级功能上收到汇聚节点,在家庭侧只需要部署最简单的二层接入设备,大大的降低客户端的投资和维护成本。这种部署模式绝不仅仅在于替代现有的家庭网关,而在于盯准智能家庭路由器市场,建立城市千万家庭的网络业务门户。海外运营商已经在VCPE上开展智能家居业务、视频云、存储云等业务,与家居解决方案商、内容提供商、虚拟运营商以及品牌小区实现合作运营,实现前后向业务增值。

进一步,BRAS和CGN也在尝试向x86方向发展。在国内运营商城域网中,BRAS是最为关键的网络设备和角色类型。以BRAS及其以下的接入网为模块,不断复制模块扩容的方式建设城域网是最为典型模式。这种模式网络配置相对固定,可以很好的实现简单业务的网络扩容,但是也存在非常明显的问题:城域网内各个BRAS之间各自为政,无法实现资源共享。这使得用户多的地方只能多部署几台BRAS,多从接入网拉连一些光纤链路到BRAS机房,BRAS和链路的利用率都不高。在x86的架构下,BRAS和CGN作为VNF部署在标准服务器上,标准服务器可以通过平滑扩展的方式增强计算和转发能力,并且能够更好地适应L4-L7业务能力。在城域网业务边缘层形成一个新的VPOP,将各种VNF相对集中部署形成资源池,资源池内可以面向用户、面向业务灵活调整资源,从而提升全网使用效率。同时在城域网范围内集中部署VPOP的Controller,实现资源状态的查看、配置、维护、调整等功能。

VPOP对于运营商而言,是一种可以承载新的商业模式的城域网新边缘节点(如图6所示)。电信运营商不仅可以根据自身业务发展需要在VPOP对前向用户提供差异化的增值业务,也可以与SP、虚拟运营商等第三方合作,为其提供差异化的用户体验,体现在互联网时代,电信运营商在产业链中的整合价值。

当然,当前运营商的城域网庞大程度让演进的过程无法一蹴而就,更无法将城域网推翻重来。在现网部署新的VPOP模式一定会对光纤链路、网络规划、网络运维等带来压力。最关键的问题包括:接入网与VPOP的连接、VLAN资源重新规划或者面临不够用、后台系统需要根据新的规划方式进行调整、VPOP集中控制器的部署位置、运维人员适应新的业务部署方式等等。或许一些新的技术,例如数据中心解决VLAN扩展的技术,需要被引入到城域网中来解决这些新的问题。目前,无论是运营商还是各解决方案商都在进行最初步的探索与尝试。

三、 结束语

NFV在运营商IP网络的引入将促进运营网向新的业务模式演进,能够实现更高效的部署、更便利的维护、更快速的灵活满足业务变更需求和动态的资源调整。运营商在IP网的初期实践主要在以上几个典型场景,这几个场景从业务需求推动和可行性方面都更为适合率先NFV化。尽管在现网演进的过程中会遇到这样或者那样的问题,但是运营网向面向业务的方向转变的目标是不会变的,时间和技术发展会逐步解决这些问题,未来将会是一张全新的运营网。

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2014-11-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序你好

DevSecOps的三种解读

1081
来自专栏SDNLAB

ONF开源白皮书:SDN解决方案案例——SDN/NFV

译者简介:蒋暕青@上海宽带技术及应用工程研究中心:SDN技术实践者,大四北上思博伦实习半年,现工作地点上海 6.1 CORD:将交换中心重新设计为数据中心 世...

2937
来自专栏云计算D1net

想开发云应用程序?先选择合适的PaaS!

从一个方面来分析,开发云应用程序的平台即服务模式有两种:一种是专用模式,托管在本地或私有云中;另一种是公共模式,由第三方提供商来托管,并采用订阅支付模式。那只是...

4166
来自专栏云计算D1net

存储虚拟化想法好!但改造传统系统能力仍受质疑

传统存储解决方案的弊病很多,这些弊病多由异构存储和SAN孤岛造成。异构存储是说在企业IT系统中,存储设备往往来自不同供应商。不同的供应商意味着不同的底层架构、不...

34212
来自专栏SDNLAB

VMware:离了NFV,5G或将失败

一般而言,很少会有人能把VMware与5G联系到一起。但在本次MWC 2017上,VMware联手系统集成商Atos宣布,通过NFV将VMware与5G联系到一...

3419
来自专栏麦应用专栏

麦应用小程序 | App可直接打开小程序!微信到底想要干嘛?

未来,用户可以从APP跳转至某一微信小程序的指定页面,完成服务以后再跳转回原APP,多场景使用更加方便。

61114
来自专栏WeTest质量开放平台团队的专栏

锤子发布会,天知道服务器都经历了什么!

对于任何的活动,产品来说,服务器往往是最后一关,也是必须要过的一关,对于众多企业来说,为了不要让自己的汗水白流,为了让自己的产品顺利发布,一定要在上线之前对自己...

1674
来自专栏程序员互动联盟

【答疑释惑】linux学习线路图

随着android的大热,基于linux的开发也更热了。linux的开发包括driver的开发以及应用程序的开发。 由于我们习惯了windows,在开始使用l...

3164
来自专栏猿人谷

开发项目的简单流程(需求、数据库、编码)

今天是星期天,仔细回想一下以前的工作,心 里大致的想了一段时间,对我这段时间的工作算是做一个总结吧,因为,在周五的时候就是我们的需求有点小变化,弄得我都不知道该...

2197
来自专栏Java面试通关手册

说几件小事

熟悉我的朋友应该知道,从大概3个月前,我开源了一个后端(偏Java方向)的学习/指南文档。Github地址为:https://github.com/Snailc...

881

扫码关注云+社区