C114中国通信网: 门户(微博 微信) 论坛(微博) 人才(微博) 百科 | C114客户端 | English | IDC联盟 与风网

技术 - 行业技术 - 互联网 - 正文 运营商投稿当日通信资讯

从60分到85分——SD-WAN进阶教程(下)

http://www.c114.com.cn ( 2018/4/16 15:51 )

本文为《从60分到85分——SD-WAN进阶教程》的下篇,上篇请跳转http://www.c114.com.cn/tech/175/a1048761.html

(续上文)Enterprise Oriented SD-WAN给企业带来的价值非常明显,在北美讯速地抢占了银行、零售、连锁等行业,包括很多世界500强的大型客户,2015年下半年开始,SD-WAN成为了业界炙手可热的新宠。由于SD-WAN对于上述一系列关键技术的利用,能够显著地提高Internet线路的QoE,这使得Internet线路在某些场景中,得以部分地代替MPLS线路在企业组网中的作用,因此降低了企业对于MPLS的依赖性。

因此,当时业界谈论最多的话题,就是“SD-WAN能否取代传统的MPLS VPN?”。MPLS VPN是全球各大运营商的支撑性业务,SD-WAN的突然崛起,迫使着大T们开始思考应对之策。

本文作为下篇将对“SP Oriented SD-WAN”进行介绍。首先,会介绍厂家给出的SDN-Gateway的方案。其次,将对运营商青睐的vCPE方案进行介绍。最后,简单地聊下MPLS VPN的优化问题。

二、SP Oriented SD-WAN

关于“SD-WAN能否取代传统的MPLS VPN”,其实这个问题的答案很明显。SD-WAN最大的价值之一,就是在Hybrid WAN的场景下更有效地去管理与使用WAN线路,帮助企业提高在WAN这一块的ROI。因此,SD-WAN的出发点并不是要对抗MPLS VPN,因此就谈不上要取代MPLS VPN,因为两者并不在一个层面上。

无论是从纸面上来看设计,还是从实践中看效果,SD-WAN确实实现了它所承诺的价值。运营商也很快地就看清楚了问题的本质,尽管SD-WAN客观上会降低企业对于MPLS VPN的需求,但这是技术演进的自然结果,另外SD-WAN在灵活性、自动化、应用感知、上云等方面相比于传统的技术方案,也有着不可比拟的优势。权衡之下,与其把SD-WAN放到对立面,倒不如想办法把其拉到统一的战线上,作为一个新的业务增长点。因此,运营商并没有排斥SD-WAN,而是对其表现出了相当开放的态度,这与很多人的设想是恰恰相反的。

SD-WAN的厂家们心里也很清楚,要做大事情就一定得把生态搞好,运营商作为生态中最关键的环节,有必要建立起一个融洽的合作模式。首先,纯Overlay的方案存在着一定的局限性,虽然说是Transport Independent,但是如果Transport的线路质量确实不行,那也是巧妇难为无米之炊,另外对于跨国企业来说,如果不用MPLS纯走Internet,那么基本上就约等于不能用。其次,运营商拥有着广泛的客户基础,业务的覆盖范围更广,无论在运营还是运维方面都有着巨大的优势,这正是SD-WAN厂家们最为欠缺的环节,一些大型的客户动辄就几千个分支,虽然技术上是ZTP + Cloud Managed,但是从渠道和服务的角度来说,就完全是另外一回事了。

双方一拍即合。第一种合作的思路是,运营商把厂家的方案买下来,然后自己来做渠道和服务,除了能够分一部分SD-WAN的利润外,更关键地是可以把各种WAN线路打包到方案中,为企业提供一站式、差异化的WAN解决方案。如果有足够实力的话,还可以对产品进行一些定制,把SD-WAN的能力嵌入到自己的业务系统当中。第一种思路,不需要对Enterprise Oriented SD-WAN的技术架构进行改动,同时有着清晰的盈利模式,对于厂家来说是零成本,对于运营商来说是一种快速进入市场的有效手段。

第二种思路,是对原有方案的架构进行调整。最初所设计的SD-WAN方案是Enterprise Oriented的,从技术上来看是找不到运营商位置的,如果要做一个SP Oriented的SD-WAN,就需要在方案中引入SP的角色。那么SP Oriented SD-WAN该怎么做呢?

1、SD-WAN Gateway

厂家给出的方案,是在运营商的POP点里面放SD-WAN Gateway,负责终结企业侧CPE发起的隧道,然后转发到运营商的IP/MPLS网络。在这种方案中,Enterprise SD-WAN中的CPE上所有能力都被保留了,不过端到端的Overlay变成了,两头的Last Mile用Overlay而Middle Mile交给运营商去做,如果运营商有能力的话就可以把MPLS VPN集成进去,如果短期集成不了MPLS VPN,Middle Mile这段用Overlay打过去也不是不可以。

实际上这是种很不错的思路,各方接受起来都很自然。从客户的角度来看,不需要去额外地购买的设备,而且传统的WAN设备也可以通过隧道接进去了,另外SD-WAN的运维也转交给运营商去做了。从厂家的角度来看,Enterprise Oriented的特色得以被保留,CPE仍然是高价值的产品,同时有效地解决了纯Overlay的局限性,另外通过SD-WAN Gateway也得以参与到运营商的组网中。从运营商的角度来看,SD-WAN Gateway不仅提供了对接MPLS的入口,另外也提供了更加灵活的接入方式,对于Last Mile不可达的Off-Net Customer,走Overlay做接入能够省去很多的麻烦事儿。

以SD-WAN Gateway为核心的SP Oriented SD-WAN,保留了Enterprise Oriented SD-WAN的所有能力。在此基础上,主要是提供了对多租户的支持,并在控制逻辑方面进行了相应的加强。

1.1 整体设计

对于运营商来说,SD-WAN Gateway作为业务的接入设备,在位置上和SR/PE并没有本质上的区别。对于Pure Play的SD-WAN厂家来说,他们在POP里面并没有存量的SR/PE,所以就只能推新的设备进去。形态上就是x86的盒子,相比于Enterprise Oriented SD-WAN方案中的CPE,SD-WAN Gateway作为不同客户流量的汇聚点,接口的速率和数量都会做相应的增强,而且由于它要负责大量隧道的终结,因此对CPU和内存的要求高很多,通常会需要专用的Crypto Accelerator。而对于传统的设备厂商来说,比如Juniper、ALU和华为,他们在POP里面有存量的SR/PE,这时候可以选择把SD-WAN Gateway以板卡的形式插到SR/PE的机框上,以避免多引入一个物理设备的麻烦。随着CORD在运营商中的推进,SD-WAN Gateway的形态开始逐渐向vCPE进行靠拢,关于vCPE等到后面CORD的部分再来做介绍。

控制器。从宏观的架构来看,除了Staging Server、Controller和Analytics以外,可能会需要AAA来专门做鉴权。从细节来看,由于多租户需求的出现,以及设备、拓扑复杂度的提高,使得控制器所用的数据模型以及业务流程都会发生一定的变化。从位置来看,On-Premise是不可行的,需要放到运营商自己的机房当中。通常是在地市级的核心机房里面,负责控制下属的各个接入机房中的SD-WAN Gateway,以及本地企业分支的CPE。

Portal也要做相应的调整,而且运营商很可能要自己来做定制,部署的位置也取决于运营商站在什么层面上来看待SD-WAN的业务,所以这里就不多说了。

1.2 多租户是怎么实现的?

企业侧接入SD-WAN Gateway的流量,需要能够与VRF进行关联。按厂家的意思就是用IPSec直接打进来,把接入网这一段OTT掉。在这种方式中,需要能够对IPSec流量关联VRF,大概有下面这几种办法:(1)用GREoverIPSec,为GRE口关联VRF;(2)用MPLSoverGREoverIPSec,用MPLS来关联;(3)用VxLANoverIPSec,通过VNI来关联VRF;(4)通过VTI口来关联VRF;(5)用ISAKMP Profile绑定VRF,识别SPI后直接关联VRF;(6)用私有的IPSec封装,在IPSec后面单独加VPN的字段。比较而言,从标准化程度来讲(1)是最好的,从封装效率上来讲(3)和(4)要好一些,不同厂家的实现中会有不同的选择。

不过,按运营商现有的接入网络来看,除IPSec以外,VLAN/QinQ/L2TP/GRE/MPLS VPN甚至是传输专线都有是有可能的,这对于SD-WAN Gateway的要求就比较高了。此时,传统的设备厂商相比于Pure Play的厂商就有明显的优势了

经过特定VRF的路由后,这里考虑跨地区的流量,流量要被送到目的站点所接入的SD-WAN Gateway上。根据实际情况,又有不同的方式:(1)如果SD-WAN Gateway间要走GRE/IPSec,就还是用上面刚刚所介绍的方法;(2)如果SD-WAN Gateway间要走MPLS VPN,且SD-WAN Gateway自己具备MPLS VPN的能力,这时可以直接给出向流量标记Service Label;(3)如果SD-WAN Gateway间要走MPLS VPN,但是SD-WAN Gateway并不具备MPLS VPN的能力,那么SD-WAN Gateway就要通过接口/子接口和PE做连接,同时与PE间起IGP多实例,或者BGP/MP-BGP打通路由,然后由PE来完成MPLS VPN的工作,这实际上可以看作是VRF-Lite的方案。

不仅是SD-WAN Gateway,整个系统实际上都需要进行多租户的改造。对于CPE来说,要接入SD-WAN Gateway,可能需要对特定的封装提供支持。对于控制器来说,要明确CPE所属的租户,以及SD-WAN Gateway上所接入的租户列表,然后在分发策略和路由的时候,需要能带着租户的信息下去。对于Portal来说,则要提供RBAC的能力,对不同账号的权限进行区分与隔离。多租户所带来的细节问题,还有很多很多,无法逐一而述了。

1.3 端到端的控制如何实现?

在Enterprise Oriented的方案中,控制器看待站点间的连接的角度很简单,两个设备+双向的隧道。在SP Oriented的方案中,由于控制器不仅要控制企业侧的CPE,还要控制运营商的SD-WAN Gateway,另外SD-WAN Gateway的引入还将路径切分成了多段,路由的控制上也很为复杂了。这些都对SP Oriented的控制器提出了很大的挑战,甚至可能需要在集中式和分布式间重新进行决策。

首先,端到端的拓扑就十分的复杂。简单来想,可能是(SD-WAN CPE—SD-WAN Gateway—SD-WAN CPE)做本地中继,可能是(SD-WAN CPE—SD-WAN Gateway—SD-WAN Gateway—SD-WAN CPE)做跨地区的隧道拼接,也不排除会做(SD-WAN CPE—N*SD-WAN Gateway—SD-WAN CPE)的POP点组网。如果有Non SD-WAN的设备打隧道接进来,这个设备的控制是不归控制器来管的,虽然控制的设备少了,但实际上控制器的建模却变得更加复杂了。如果Non SD-WAN设备接入SD-WAN Gateway,而SD-WAN CPE间不走SD-WAN Gateway直接打隧道,就更加混乱了。和路由目前来看,SP Oriented SD-WAN还没有一个标准的路由控制逻辑,只能是摸着石头过河。

在实际的部署中,SD-WAN Gateway不可能会是单点,相比于主备运营商更喜欢负载分担,那么还要考虑HA下的均衡问题。而且一个地区的POP点会有很多个,如何在POP点间进行流量的优化,也是一个重要的问题。

另外一个现实的问题是,运营商不可能完全OTT接入网和MPLS。Overlay在Internet上做接入,虽然在灵活性上有很大的优势,便于接入Off-Net的客户,但是对于本地的On-Net客户这种方式却不见得合适。对于一些运营商来说,CPE—BRAS—SD-WAN Gateway—SR/PE的流量模型并不符合路由的规范,而且BRAS、SD-WAN Gateway、SR/PE这三者间的形态关系也是千差万别,现网部署起来会遇到很多麻烦。所以说对于On-Net的客户,SD-WAN Gateway接入这一端更习惯于over在专线上。这样的话还要协同接入网的网管/控制器,如果再考虑与MPLS VPN网管/控制器的协同,整个SP Oriented SD-WAN的编排/控制系统会变得无比复杂。全场景、端到端的编排/控制,目前来看还有相当大的差距。

1.4 公网访问如何实现?

如果是要做Local DIA,那么分流在分支的CPE本地就完成了,流量模型是Branch CPE—BRAS—Internet。如果是要做Backhaul,是由总部/数据中心的CPE统一分流,流量模型的一种可能是Branch CPE—SD-WAN Gateway—HQ/DC CPE—Internet,另一种可能是直接Branch CPE—HQ/DC CPE—Internet。关于DIA和Backhaul,在Enterprise Oriented SD-WAN部分已经介绍过了,这里就不再赘述。

除了Local DIA和Backhaul以外,SP Oriented还提供了Regional Break Out的方式,流量模型是Branch CPE—SD-WAN Gateway—Internet,由SD-WAN Gateway完成公网和VPN流量的分流,公网流量可能还需要进一步地对国内流量和国际流量进行区分,以提供不同的路由策略。Regional Break Out要求SD-WAN Gateway能够提供NAT、安全和HQoS的相关能力,同时要求SD-WAN Gateway具有Internet的连通性。对于客户来说,Regional Break Out的优势在于,既可以避免Internet流量绕行总部/数据中心,降低了时延与带宽消耗,又可以通过SD-WAN Gateway为本地的多个分支集中地提供安全、WAAS这些服务,避免了以分支为单位去使用这些服务的成本。对于运营商来说,客户在本地所有分支的Internet业务可以集中地管理起来,比如对上下行带宽的统一分配。

至于公网流量如何才能从Branch CPE送到SD-WAN Gateway上,还是要看接入的方式是怎么样的。如果要Overlay在Internet上,那么控制器就要下发路由把公网流量通过隧道送给SD-WAN Gateway,此时流量模型实际上是Branch CPE—BRAS—SD-WAN Gateway—Internet,在现网中运营商不一定会愿意提供这种连接方式,这取决于运营商如何去看待BRAS和SD-WAN Gateway两者的关系。如果是over在专线上,路径上就不会出现BRAS,这时相当于一根线上同时跑了宽带和VPN两种业务,需要在计费方式上做好考虑。

2、vCPE

在运营商传统的POP点中,为了支撑话音、宽带、专线等不同专业的业务,需要采购大量专用的硬件设备,开放性和灵活性很差。在Cloud/NFV/SDN等新型架构的驱动下,全球各大运营商纷纷投身于POP点云化的重构进程中。POP点云化后,各类专用的硬件设备在形态上将被基于通用x86平台的VNF所替代,在架构上转发和控制得以分离解耦,这对于运营商具有巨大的价值。一方面在于开放性、灵活性等方面的提高,长期来看能够有效地降低成本。另一方面,运营商得以将各种增值服务的VNF以服务的形式提供给客户,这将是一笔相当可观的业务增收,也是破局“管道化”困境的有效方式。

在这一大背景下,SD-WAN的架构也得到了新的延伸,以vCPE为核心的解决方案开始占据SP Oriented SD-WAN的主流。这里有必要对vCPE的概念进行一下说明,从字面上来直观理解的话,vCPE应该是指一个与CPE具有相同功能的VNF,但实际上业界对于vCPE的定义并非如此。由于传统的CPE是一个泛指的概念,涉及路由、防火墙、WAAS等诸多技术,因此对CPE进行虚拟化的结果,通常并不是一个VNF,而是vRouter、vFW、vWAAS等多个VNF,它们各自完成一部分功能,然后通过服务链串接在一起,共同交付vCPE的能力。虽然在某些产品和语境下,vCPE可以指代一个特定的VNF,但是在通用语境下vCPE是指一套完整的解决方案。

至于SD-WAN与vCPE间的关系,从SD-WAN的角度来看:

  • 如果SD-WAN CPE是基于x86的白盒,而且自身具备单独作为vCPE载体的能力,这时SD-WAN CPE就可以被称为vCPE,vCPE就是SD-WAN方案中的一个组件。
  • 如果SD-WAN CPE以虚拟机的形态存在,那么可以作为vCPE方案中的一类VNF,这时可以说vCPE是SD-WAN方案中的一种实现手段。
  • 如果在vCPE方案中,只提供vRouter、vFW等传统的VNF,并不提供SD-WAN VNF,那么vCPE和SD-WAN两者并无直接的联系。

如果理解起来仍然比较晦涩,那么换作vCPE的角度来看就清楚很多:

  • 如果所有的能力都在企业边缘提供,称为Distributed vCPE,无论企业边缘的设备是不是SD WAN CPE。
  • 如果所有的能力都在POP点提供,称为Centralized vCPE,无论提不提供SD-WAN VNF。
  • 如果一部分能力在企业边缘提供,一部分能力在POP点提供,称为Hybrid vCPE,无论是否存在SD WAN CPE或者SD-WAN VNF。

可以看到的是,SD-WAN和vCPE并不存在严格的包含于被包含的关系。以这篇文章的出发点来说,可暂且把vCPE看作是SP-Oriented SD-WAN中的一种实现形式。下面就来对vCPE进行一个简单的介绍。

2.1 整体架构

一套完整的vCPE方案的实现需要Cloud、NFV和SDN技术的紧密协同。首先,要有一个x86的平台来提供虚拟化的能力,可以是在Distributed vCPE中的SD-WAN CPE上,也可以是在Centralized vCPE中的x86资源池中。其次,要有一套虚拟化的中间件+云管平台,如开源的KVM+OpenStack。然后,需要一套VNFM+NFVO,对VNF进行管理和编排。SDN这块,云POP点的控制器、SD-WAN的控制器,可能是同一套,也可能是两套,另外一些方案中还会包括接入网的网管/控制器。Portal就很难说了,完全取决于厂家的实现和运营商的集成。

vCPE是否要做成多租户的?除了厂家的实现以外,其实还取决于运营商的销售策略。如果是卖VNF的模式,那么一个实例只就能属于一个租户,这时不强制要求多租户。如果并不直接卖VNF,而是包装成网络能力来卖,这时做成多租户就比较划算了,不过要考虑好性能、容量、配额和扩缩容的问题。

实际上,vCPE就是POP点云化的一个企业级用例,上述vCPE的架构也就是POP点云化的架构。关于这套大的架构,本身就可以独立成一篇长文,这里不做深入的展开。

2.2 Distributed vCPE和Centralized vCPE

之前提到过,所有能力都在企业边缘提供的方式被称为Distributed vCPE,实际上Enterprise Oriented SD-WAN中的CPE很可能就是Distributed vCPE的一种表现形式,本地集成VNF,然后通过一些引流手段把它们串在一起。与之相对应的是Centralized vCPE,所有能力都位于POP点中,并由运营商以服务的形式来集中提供。那么,哪种方式更好一些呢?

先来看看市场方面的因素。从厂商的角度来看,如果其产品的能力比较全,就会倾向于Distributed的方式,把所有的功能都自己做在盒子里,如果其产品能力上有较大的缺口,那不可避免地就要做第三方集成,倾向性就会稍弱一些。从运营商的角度来看,一般会更倾向于Centralized的方式,一方面有利于运维,另一方面能够增强自身在企业组网中的地位。从客户的视角来看,Distributed是买硬件+服务,Centralized只需要买服务,如果Distributed和Centralized的使用体验一致,从成本来说自然是Centralized更好一些

不过,Centralized并不会完全地压倒Distributed。一来,目前运营商的POP点云化还处在早期的阶段,技术上距离成熟还有相当的一段距离。再者,一些VNF部署在企业边缘会获得更好的使用体验,比如WAAS。Hybrid vCPE在两者间取了一个平衡,一部分能力在企业边缘的盒子上,一部分能力在POP点中,由客户根据实际情况来自行订购。Hybrid的方式固然灵活,但是VNF的分散性对于运维来说是一个不小的挑战。

2.3 Centralized vCPE的流量模型

Centralized vCPE的目标是最大程度地简化企业侧的设备,最好是只留下二层的功能,把路由也移到POP点里面去。对于运营商来说,自然希望借此获得对于企业业务更加完整的控制权,对于一些中小型的客户来说,这避免了自己去维护路由的工作,实现网络的即插即用。因此,目前在很多的vCPE应用案例中,都会见到这种二层接入的方式。这时VPN和公网的流量都会发给POP点中的vCPE,vCPE不仅仅是虚拟化了企业侧的终端,实际上把BRAS和SR的一部分活儿也都一起给做了。

Centralized vCPE主要包括vRouter、vFW和vWAAS,在实际的部署中会有不同的串接顺序。当然,某些厂商也会将不同的能力集成到一个VNF中去实现,比如SD-WAN VNF很可能就是一个集多种能力于一身,这时流量的模型就要简单很多。这里考虑最常见的串接顺序vRouter—vFW下的流量模型,vFW采用路由模式。vRouter对流量的处理主要包括:(1)对流量进行识别;(2)为企业侧的接入设备分配IP地址;(3)对流量进行限速;(4)将流量送给vFW。在vFW对流量的处理主要包括:(1)对流量进行识别;(2)对公网流量和VPN流量进行分流;(3)执行安全策略;(4)公网流量送给NAT设备,VPN流量送给PE。

具体来看数据面的转发。目前NSH的应用还非常少见,这里不做分析。

  • 客户接入vRouter这一段。可能的拓扑有很多,(L2 Switch—POP GW—vSwitch—vRouter)、(L2 Switch—POP GW—vRouter)、(L2 Switch—vSwitch—vRouter)、(L2 Switch—POP GW—vSwitch—vRouter)。由于要接入二层,因此可以选择VLAN/QinQ或者VxLAN,考虑到与物理拓扑解耦走VxLAN会稍好一些,一些节点上会需要做转换/拼接。
  • vRouter到vFW这一段。如果在同一个节点上,拓扑是(vRouter—vSwitch—vFW),直接VLAN不用走隧道。如果不在一个节点上,拓扑就是(vRouter—vSwitch—vSwitch—vFW),vSwitch间走VxLAN就行。少数情况下,拓扑会是(vRouter—vFW),可以选择MPLSoverGRE,如果不支持MPLS可以用VRF Aware GRE。
  • vFW到NAT/PE这一段。由于NAT/PE通常是物理设备,因此拓扑最好直接就是(vFW-NAT/PE),可以选择MPLSoverGRE,如果不支持MPLS可以用VRF Aware GRE。一些POP点中还会引入vNAT/vPE,这时就可以(vFW—vSwitch—vSwitch—vNAT/vPE)了。

可以看到的是,由于涉及到运营商的网络,因此底层的连接变得非常复杂,要针对现网的实际环境来做具体的方案设计。而且,由于拓扑没有一定固定的形态,因此对控制器的要求也很高,很可能需要做一些定制化的开发。

3. MPLS VPN的优化

从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,这是一个很容易被忽略的问题,特此进行提示。

   来源:SDNLAB

  免责声明:本文仅代表作者个人观点,与C114中国通信网无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。

支持作者观点

轻松参与

VS

表达立场

反对作者观点

本文关键字: MPLS33, VPN31, 运营商51, SP13, SDN6, IP3, 网络10, 接入设备2, SR7, Juniper1, 华为1, IPSec6, 接入网5, OTT2, VLAN3, 宽带2, NFV2, 广域网1, Qos1, 城域网1, 骨干网1, EDGE6

Copyright©1999-2018 c114 All Rights Reserved
上海荧通网络信息技术有限公司版权所有
南方广告业务部: 021-54451141,54451142 E-mail:c114@c114.net
北方广告业务部: 010-63533177,63533977 E-mail:shixinqi@c114.com.cn
编辑部联系: 021-54451141,54451142 E-mail:editor@c114.com.cn
服务热线: 021-54451141,54451142
沪ICP备12002291号