MPLS VPN的优化

2019-08-29 10:58:01 云杰-mplsvpn-sdwan 106

  从SD-WAN厂家的角度来看,只要把流量做好标记送给PE上就行了,PE间的打通并不属于SD-WAN要考虑的问题。不过对于运营商来说,MPLS VPN是企业广域网业务的基础,也是能够体现服务差异化的最关键环节。因此,运营商在设计SD-WAN业务的时候,一定会带上MPLS VPN一起做考虑。不过,传统的MPLS VPN所存在的一些局限性,使得它在与SD-WAN进行集成时显得很不协调。首先,开通周期太长,交付速度远远跟不上业务的需求。其次,带宽难以按需调整,客户只能按照峰值带宽的水平进行超买。另外,无法与云进行联动,企业入云的流量难以纳入到服务体系中。

  快速开通的问题,并非单纯地引入SDN控制器对两端PE/ASBR做自动化配置那么简单。在运营商的传统体系下开通一个MPLS VPN,周期保守估计在45-90天,从开始填写订单到最后完成交付,其间要流转数十个步骤,其中向设备下发配置这个环节已经是由MPLS VPN网管一类的角色自动完成的,换上SDN控制器来配也没有任何本质的区别。真正的问题在于,传统的BOSS系统太过于臃肿,为保证系统的稳定运转,不仅流程复杂繁琐,而且很多步骤需要人工介入。因此破题的关键在于,运营商要对BOSS的架构和业务流程进行精简,否则任何网络层面的改进都是杯水车薪。

  带宽按需调整,在BOSS层面也面临着同样的现实问题。单纯从网络的层面来讲,调带宽的方法要看MPLS VPN的QoS模型,如果是Diff-Serv的就是在PE上做限速和Mark,如果是Int-Serv恐怕就要去搞RSVP了。想法是好的,但在现实中运营商可能会遇到一些头疼的问题。首先,是调带宽这个动作极容易使网络变得不稳定,一旦客户调的时候影响了别人,很难去界定责任。其次,按需的粒度很难掌握,细了的话太影响收入,粗了很多时候对客户就失去吸引力了。另外,按需服务的模式对计费系统冲击太大,风险性需要进行谨慎的评估。

  与云的联动不足,需要运营商与云提供商双方来共同解决。云机房通常会建设在城域网核心或者骨干网这一层面,通过DC Edge来接入运营商的Internet。随着云计算的逐步成熟,一些高价值的企业流量开始流向云端,然而Internet却难以为这部分流量提供足够的连接质量,引入MPLS VPN来解决这一问题是很自然的需求。对于运营商而言,如果不是市场策略上有什么额外的考虑,单纯从技术上来讲事情是很简单的,DC Edge就是CE,只要搞定它与PE间的接入和路由就可以了。

  接入上没什么说的,裸纤/专线/VPN都可以,对于几个大的公有云,甚至可以直接把PE搬到DC Edge的机房去做直连,通过物理接口或者子接口来隔离租户。如果由于一些现实的因素,运营商和公有云间做接入存在困难,还可以通过第三方的IXP/CXP来进行中继。

  路由这一块,由于要跨域一般就是静态路由或者BGP,如果是用静态路由,就是由控制器把路由配到DC Edge和PE上,如果是用BGP,那就需要控制器去配好Peering和Policy。从分工界面来看,DC Edge和云内部的网络由公有云提供商来负责,PE和企业侧的接入由运营商来负责,双方的控制器各自封装好API提供出来,上面的Portal或者编排器拆单后直接调用就可以了。对于IaaS流量来说,企业侧和云侧的网络在同一地址空间内,路由直接拉通就行了,但是对于SaaS流量来说,云一侧是公网的IP地址,因此路由是没法直接通的。因此,对于企业侧访问SaaS的流量,运营商还需要在PE送到DC Edge前做NAT,这是一个很容易被忽略的问题,特此进行提示。