IPRAN方案深度解析

.12/NUMPAGES17Doc.Code01DOCPROPERTYDocumentNameIPRAN承载方案的现状与未来分析IssueDOCPROPERTYDocumentVersion01DateDOCPROPERTYReleaseDate2015-08-10DOCPROPERTYConfidential.NopartofthisdocumentmaybereproducedortransmittedinanyformorbyanymeanswithoutpriorwrittenconsentofHuaweiTechnologiesCo.,Ltd.andotherHuaweitrademarksaretrademarksofHuaweiTechnologiesCo.,Ltd.Allothertrademarksandtradenamesmentionedinthisdocumentarethepropertyoftheirrespectiveholders.Thepurchasedproducts,servicesandfeaturesarestipulatedbythecontractmadebetweenHuaweiandthecustomer.Allorpartoftheproducts,servicesandfeaturesdescribedinthisdocumentmaynotbewithinthepurchasescopeortheusagescope.Unlessotherwisespecifiedinthecontract,allstatements,information,andrecommendationsinthisdocumentareprovided"ASIS"withoutwarranties,guaranteesorrepresentationsofanykind,eitherexpressorimplied.Theinformationinthisdocumentissubjecttochangewithoutnotice.Everyefforthasbeenmadeinthepreparationofthisdocumenttoensureaccuracyofthecontents,butallstatements,information,andrecommendationsinthisdocumentdonotconstituteawarrantyofanykind,expressorimplied.HuaweiTechnologiesCo.,Ltd.Address:HuaweiIndustrialBaseBantian,LonggangShenzhen518129People'sRepublicofChinaWebsite:Email:文档说明文档目的本文档旨在描述当前承载网主要解决方案的客观问题,以及针对客观问题提供简要的解决方案或者解决思路。通过对当前问题的描述,笔者期望能够更多的人参与承载网方案问题的共享。通过集体的智慧,把当前的不足点一一的发掘并解决。文档声明本文所发表的看法一定程度上仅代表个人看法,如有理解不到之处,请谅解。变更信息VersionDescriptionDate01第一次发布2015-08-10ContentsTOC\h\z\t"heading1,1,heading2,2,heading3,3,heading7,1,heading8,2,heading9,3,Heading1NoNumber,1"文档说明iii1背景与绪论1-11.1承载方案1-1HVPN1-1SeamlessMPLS1-21.2文档说明1-32方案解析2-42.1组网拓扑2-4问题描述2-4问题解决2-52.2地址规划2-5问题描述2-5问题解决2-82.3IGP规划2-9问题描述2-9问题解决2-92.4BGP规划2-10问题描述2-102.4.2解决思路2-102.5隧道规划2-11问题描述2-11问题解决2-112.6业务规划2-11问题描述2-12问题解决2-122.7规格能力2-14问题描述2-14问题解决2-142.8可靠性保护2-14问题描述2-14问题解决2-152.9运维管理2-15问题描述2-15解决思路2-152.10其他问题2-162.11本章小结2-16.背景与绪论IPRAN已经风风雨雨的走过了很多年,华为公司在IPRAN上的份额基本上是领先地位。承载方案对于承载网解决方案,华为提供的方案种类繁多,整体来说一共推出了五大基线方案,HVPN/MixedVPN/E2EVPN/NativeIP+L3VPN以及网关方案,另外,还有当前如火朝天的SeamlessMPLS方案。本文主要基于主流的HVPN与SeamlessMPLS方案进行简要分析对比。下面我们分别进行简要介绍。HVPNHVPN方案相对比较成熟,应用也最为广泛,是中国联通的主要方案。随着承载网发展,HVPN相继衍生出了多个子场景,分别是HoVPN,H-VPN以及HVPN+,三种子场景XX小异,这里不做赘述。对于HVPN方案,网络层次化,扩展性以及可靠性非常好,但一个比较尴尬的问题是海外接受度较差。对于主流的运营商或者C派运营商很难接受"H"分层的概念,因为对于他们而言,他们的需要是需要端到端的业务〔包括发放与管理,但是华为公司包装的"H"理念直接打破了他们的梦想,从而导致HVPN方案频频受阻。其实,随着HVPN方案的发展,后来的H-VPN以及HVPN+方案的业务下发,并不是分层的,这个与最早的HoVPN是明显有差异的。从技术本质上讲,H-VPN已经可以做到端到端业务下发,其唯一的特别点是ASG节点上对私网路由修改了下一跳〔业务转发时进行标签交换操作,采用类似OptionB的技术。当然,对于考虑LTE场景的X2业务互通,由于跨环X2业务采用默认路由方式,在ASG节点上是需要部署VRF,保证X2业务在ASG节点上进行IPGO操作,从而解析报文的IP地址再次查询VRF进行转发。但这是并不影响S1业务的部署。由此看来,一个好的概念也是一个方案成功的关键因素之一,而HVPN这个概念明显已经不适合它后续的发展。SeamlessMPLSSeamlessMPLS方案兴起于近几年,主要在海外应用,目前是比较主流且接受度较高的方案。华为此前将此方案包装为IDEAL方案,但"IDEAL"接受度较差,不易理解,本文对此不予赘述。何为SeamlessMPLS？另外,在典型的SeamlessMPLS基线场景中汇聚侧内ASG之间的专线业务是否是采用SeamlessMPLS技术呢？对于SeamlessMPLS,当前主要有两种理解。其一是狭义的：利用RFC3107,通过BGPLSP端到端承载VPN业务,这就是常说的SeamlessMPLS方案。另外就是广义的：从接入、汇聚以及核心区域,端到端进行MPLS转发的网络。RFC<SeamlessMPLSArchitecturedraft-ietf-mpls-seamless-mpls-07>描述：SeamlessMPLSextendsthecoredomainandintegratesaggregationandaccessdomainsintoasingleMPLSdomain<"SeamlessMPLS">.Thisenablesaveryflexibledeploymentofanendtoendservicedelivery.由此,笔者认为SeamlessMPLS的本身目前已经被侠义化了,尽管它的主流场景是通过RFC3107的方式进行隧道承载。SeamlessMPLS的主要设计思路延续了HVPN方案。类似于传统的HVPN方案,SeamlessMPLS方案衍生出两大场景,分别是SeamlessMPLS到边缘与SeamlessMPLS到汇聚〔由于HVPN的概念极度不受欢迎,另外澄清繁琐,本文统一采用SeamlessMPLS到汇聚替代。由于HVPN方案设计主要是面向中国区〔虽然海外也有众多应用,而SeamlessMPLS则是面向海外的众多具有C背景的运营商,传统的方案设计给新的SeamlessMPLS方案带来了较大的麻烦。当前,SeamlessMPLS历经了若干局点,比如罗马尼亚VDF、荷兰VDF、泰国DTAC、卡电科威特等,在方案上体现了一定的欠缺点,本文将给予详细描述。文档说明考虑到当前IPRAN承载方案的成熟性以及主流动向,本文着重介绍SeamlessMPLS方案。方案解析近期看到网上发了几个帖子,写的有些意思,比如,这个帖子简要描述了SeamlessMPLS方案在交付过程中的困难、问题、以及规避思路。本章节主要介绍IPRAN承载方案的主要考虑点以及主要问题点,按照笔者对IPRAN的了解以及与各运营商的接触情况,以下将按个各个模块进行阐述。组网拓扑问题描述传统的IPRAN方案组网拓扑统一层次化的结构,非常清晰,很容易理解。但是根据近期调查显示,对于海外的组网,仅有一半能满足华为基线定义的拓扑结构,主要的问题是华为的基线组网拓扑基本都是封闭的环形结构,但实际现网复杂,很多组网区域是开环的结构。目前开环分为两种：场景一：ASG之间无光纤场景二：ASG之间有光纤,但是未部署逻辑子接口将接入环闭环场景一很好理解,因为现网上接入环很可能会随机的接入到不同的两个ASG上,而很难保证任意两个ASG之间有光纤或者可以通过其他的ASG设备简单清晰的连通。场景二的存在主要是考虑到ASG之间逻辑子接口规划的复杂性,另外部分客户也并不认为具备部署的必要性,因此部分运营商不意愿进行闭环改造。当然,华为提供的基线组网可能还有其他的问题,但并不是主要的,本文不再提及。问题解决解决方案V6R6C20版本新增此场景,并对保护方案给予补充。地址规划对于承载网的地址规划,笔者认为主要是逻辑地址规划,不同的逻辑地址规划将赋予整个承载网络不同的灵魂。传统的IPRAN方案,有且仅有一个环回口地址〔Loopback0提供给正常的业务服务,该Loopback地址往往会被同时设置为LSR-ID〔MPLS,RouterID〔BGP以及演变为NE-ID〔IGP。问题描述[问题一]SeamlessMPLS场景LB规划问题随着SeamlessMPLS方案的提出,三层隧道模型应运而生,LB地址的规划也开始扑朔迷离,各大厂家延续传统作风采用单LB解决承载网问题,然而VDF集团的Optima架构中却明确定义了额外的LB单独分给RFC3107的BGPLSP。参考网络解决方案部V600R006C20版本SeamlessMPLS中对比分析：Item合并方式独立方式备注描述BGPLSP的地址与LSRID重合,共用一个。BGPLSP的地址与LSRID不重合,新建一个Loopback地址给BGPLSP使用。优点1网络规划工作量较少,部署简单。2较好的兼容了当前架构规划〔如HVPN+。层次清晰：LDPLSP/RSVP-TE不会跨IGP进程,清晰的隔离的LabeledBGP层面,扩展性较好。缺点[当前问题]多点故障场景,原始通过IGP可达的TCP连接会通过BGPLSP重新建立,导致路由重新选路收敛,BGP持续震荡,业务受损。1不夸IGP域的业务,走三层标签转发,转发效率相对低。〔比如同环X2业务走BGPLSP；2X2业务同环实现就近转发规划代价高,需要区分BGP路由〔ASG发布上是否修改下一跳,增大规划工作量；3多规划一个环回接口,另外部署配置更复杂〔BGP配置。4与HVPN+架构兼容性不好,从传统的HVPN方案升级到此方式网改代价高。技术超网路由NA扩展性较好,单IGP域内只存在IngressLDPLSP,无IngressBGPLSP.好,三层隧道天然隔离。案例泰国DTAC,卡电科威特等罗马尼亚VDF等总结规划部署简单,推荐采用。比较复杂,大多运营商不意愿多规划单独的接口。以上可以看出,采用合并方式的逻辑地址规划是明显有好处的,但值得思考的问题是,为何现在有一个明显致命缺点呢？这里,我们先回到问题的现象：问题描述：如图双点故障〔故障1,CSG与ASG1之间的IGP路由断开,但两者又通过BGP路由以及BGP隧道打通了TCP连接,并建立BGPPEER。当CSG与ASG1之间BGPpeer建立完成后,ASG1与CSG之间互发LB0路由,导致BGP又重新选路,原来被优选的BGP路由被次选,从而BGPLSP拆除,TCP连接中断。重复以上过程,此过程会BGP持续震荡,业务丢包。思考：通过BGPLSP绕行建立BGPPEER后,新发送BGP标签路由为何被优选？是否能够被优选？产品或者解决方案应该怎么考虑？不难理解,一条标签路由被优选的条件应该是它能够迭代到正确的隧道,那么该场景中的隧道是正确的吗？很明显答案是否定的！尽管绕行的BGPLSP是一条临时的有效的隧道,但并不是正确的隧道,产品必须要予以识别,这个才是阳光大道的解决方法。当然这个识别的代价可能是很高的,那么从方案场景需求的角度考虑,BGP标签路由是否具有迭代BGP隧道的必要性？目前看是没有这个必要〔短期也没有可视化诉求,因此这个可以成为备选解决方案。另外一个可以解决的思路自然是采用独立的LB给BGPLSP使用,但是这个方案会将端到端方案复杂化,因此也不应该推荐使用。[问题2]HVPN/SeamlessMPLS方案公网DCN方案LB规划问题公网DCN方案的引入,将分层的IGP设计进行了一次融合,从而导致LDP隧道的非预期拉通。问题场景如下：流程分析：1、A-ASBR1通过BFDFORLDPTunnel感知,底层〔转发平面进行BGPFRR；〔控制层面尚未切换2、A-ASBR1上LDP隧道收敛,算出了一条绕接入环的去往ASG1的隧道；〔公网DCN方案将接入侧32位路由引入到汇聚侧；3、A-ASBR1上BGP控制平面下一跳为ASG1,下发到转发平面。流量回切,并绕接入环,路径如图所示。4、BGPHoldtime超时,120~180s后,A-RR与ASG1的BGPPEER断开,并通知A-ASBR1,流量正常。影响：故障时,下行流量从10GE链路走向GE链路,可能会大量丢包〔极端情况90%丢包,并且导致基站掉线。问题解决对于问题一：解决思路以及方案已经提到。最优方案：BGP标签路由迭代隧道必须识别隧道的正确性,不正确的隧道禁止迭代。备选方案：禁止BGP标签路由迭代BGP隧道。非推荐方案：采用多个LB进行承载网地址规划。期望产品也仔细分析BGP设计实现的合理性,尽快给出预期的最优解决方案。对于问题二：对于新的SeamlessMPLS方案,DCN方案的LB已经规划隔离,因此已经解决此问题。对于传统HVPN的方案,解决方案也提供了规避措施,期望在RSG〔A-ASBR上基于IGPCost生成LDPLSP,但该需求尚未落地〔处于落地跟踪状态。IGP规划说到IGP的规划,总体来说分为两部分,其一是IGP区域划分,其二是IGP链路的COST规划。对于IGPDomain规划,各个厂家XX小异,目前看也看不清明显的问题点。主要是IGPCost的规划需要优化。问题描述对于IGPCost设计,主要存在如下问题：问题一：基线中的汇聚侧的RSG之间规划了一个动态的IGPCost,其值为汇聚环中其他链路Cost的N-1与N倍之间。由于网络的复杂性,RSG下挂的汇聚环的节点数明显不可能是相等的,因此一个动态的具有限制性的Cost明显是不满足实际场景的。问题二：接入侧中ASG之间的逻辑子链路采用了一个较大的COST设计,这个是有其历史原因的,基于传统LDP的能力,确实是合理的,本文也不纠结。但是考虑到方案的整体化以及未来的技术更新,Cost是否需要调整呢？问题解决如上图中所示：问题一已经规整,汇聚环调整为一致,这样简化了COST规划,同样的I能够使RLFA最大程度生效。问题二后续也会进行规整,在V6R6C20版本中已经刷新。另外,笔者认为,IGPCost不人工规划是另一种较有的方案,采用默认的基于带宽的Cost设计,这个是最简单的,而且是最清晰的,合理性也较高。当然,对于部分传统非规整的网络进行免规划,可能是存在问题的,因为传统网络中会存在不同带宽的链路位于同一层次〔比如汇聚环,因此在可靠性保护以及流量规划上可能并非预期。但是笔者相信,随着承载网的健壮与成熟,IGPCost的免规划应该会一个趋势。BGP规划问题描述近期不少项目持续提到华为承载网解决方案的复杂性以及难理解,这个很大程度上应该归功于华为方案的BGP规划。仔细分析其中的原因,主要有几个因素：华为的设备〔V5不支持Add-path功能,导致RR放射路由时需要规划主备才能形成VPNFRR/BGPFRR保护。基线方案考虑了较多因素,比如说负载分担等,基于此,对不同的网元设备规划了不同的选路策略。但是,不管是啥原因,那些都不能成为正确的未来。Add-path不能成为永远的阻塞点,未来是需要的。那么对于其他的特性是不是也需要呢？解决思路首选Add-path必须支持,当前V8R8已经支持商用,但是传统的V5确实前景渺茫。另外,针对负载分担等其他功能,笔者最近进行了研究,发现20XX8月份推出了RFC7311新标准,AIGP。AIGP特性〔RFC7311是BGP协议的春天,也是动态方案的精髓之一,此特性完全颠覆了传统BGP静态的选路方式,而是采用可以基于端到端的IGPCOST的方式进行选路,从而实现端到端就近转发,并且实现网络负载,提高带宽利用率。具体的设计方案与应用场景在解决方案V600R006C20的场景基线中已经提及,这里不做赘述。隧道规划对于隧道,从主流方案来看,主要是两种：LDP以及RSVP-TE隧道。当然,还有一种主流的BGP隧道,但由于该隧道的特殊性,本文不在此进行赘述。问题描述传统TE隧道的复杂性大家都很清楚,它相对于LDP的关键竞争力是高可靠性,另外一个是流量工程〔笔者认为这是次要原因。由于TE的复杂性,它难以full-mash部署,因此它无法保护全部的业务场景；在TE&LDP混跑方案中,选择TE主要保护S1业务,而选择LDP隧道保护其他业务。这样又引起了新的问题：随着FMC的融合,故障的业务LDP不满足可靠性需求怎么办？当前的方案能力明显不行。根据TE与LDP隧道的叠加,方案更加的复杂,部署难度更繁琐。另外,根据目前产品的能力,TE与LDP叠加在故障场景下,先后Down次序不一致,导致可靠性性能明显劣化。对于劣化的性能,无较好的解决方案,当前规避方案采用同时部署两种BFD分别检测不同的隧道。综上,笔者认为,TE与LDP的叠加是IPRAN承载网解决方案发展的一个插曲,是承载网不成熟的一种表现形式。随着新的技术的配套,未来会采用单一的功能更强的隧道保护技术。问题解决解决方案在V6R6C20版本中纳入了RLFA技术,增强了LDP隧道的保护能力,然而由于RLFA特性本身的局限性,依然在较复杂的网状拓扑中无法保护部分单点故障。像众多技术族一样,一直没有确切的明白MRT为啥没有落底？另外,近期部分局点提出了SmartTE的概念,笔者认为SmartTE技术拥有一定的竞争价值,但也无法解决100%的故障,因此对此技术的前景感到并不乐观。业务规划X2的互通问题是传统方案的主要问题。由于末端CSG盒子能力限制,必须进行网络隔离,保证CSG的承受性能。问题描述对于传统方案的隔离规划,笔者认为主要存在如下点：为了保证接入环私网路由隔离,每环采用唯一的RT进行标识,此设计需要全网进行规划。考虑到接入环的数量,可能数以千计,因此复杂度高、可行性差。SeamlessMPLS到边缘场景更加复杂,由于考虑到X2业务互通,需要规划识别哪些CSG之间公网隧道的互通,也就是要识别哪些CSG之间存在X2业务,此规划对于实施交付可行性较差。X2业务在ASG双上行故障场景下路由黑洞问题,当前采用的规避方案需要在上游RSG上规划额外的LB并绑定私网VPN,另外需要对默认路由进行隔离发布〔只发给下游CSG而不给上游发送,规划复杂,接受度较差。另外,默认路由的设计简化了方案规划,但同时使得部分X2业务无法完全就近转发〔当前只能保证同环的X2进行就近,必须将流量送到特定的AGG然后再转发。当然,笔者当前并没有看到X2必须完全就近转发的必要性,因此并不抨击X2业务采用默认方式的设计。问题解决对于问题一：通过ORF能力增强SOD技术解决ORF的功能在解决方案V600R003C01版本的时候就已经融入到了当时的基线HVPN+中,当时的目的是为了解决设备间BGP协议报文过量引起的震荡问题,可以说是对网络带宽问题或者设备能力缺陷加入的规避方案,但没有带来实质性的简化。笔者始终认为动态方案就需要融入动态的特性,但传统的ORF需要设计者提前的进行静态的规划,不能按照业务需求进行动态的路由协商。因此,BGP也需要动态按需的进行路由过滤。在解决方案V600R006C20的场景基线提到了新的ORF的功能SOD〔SendonDemand,此特性当前不支持。SOD是一个新的能力,完全可以简化整网RT的规划。通过对以往专利的查阅,笔者找到了一份由华为公司申请的专利,编号为H04L29/06<2006.01>IH04L12/56<2006.01>I,与SOD所需要的功能几乎完全匹配。可以想象,动态ORF的能力在一段时间内将成为华为解决方案的独特魅力。期望产品尽快落地！对于问题二：在解决方案V6R6C20版本设计中已经深入考虑了这个问题,跨环X2业务采用HVPN+的思想,通过默认路由进行转发。这将极度简化X2业务场景下BGPLSP的规划。对于问题三：最优方案：ASG给CSG发布私网路由时,基于条件发布〔如果本地存在或者学习到LTE的私网路由时通过团体属性匹配,就给CSG发布默认路由,命令行参考：peerCSGdefault-originatevpn-instanceLTE-RANconditional-based-policyxxx.备选方案：默认路由产生：在ASG上通过Aggregate方式将从远端EPC学习的私网路由〔团体属性匹配汇聚为0.0.0.0/0,然后与明细路由一起同时发给CSG。〔origin-policy次选方案：类似于方案2,在VPN实例中引入默认路由的时候,可以基于条件引入。命令行参考：Default-routeimportedconditional-based-policyxxx.笔者建议：按照方案一落地。尽管笔者并不认为此为最优的目标方案。对于方案四：笔者尚无较好思路。总之,X2业务的互通,当前设计与其他业务耦合性较差,还需要深入的探索解决之法。另外一个重要问题是未来的FMC的专线规划需求,BGPLSP具体如何规划？才能实现最简单的任意互通？目前这块需求还不明确,后续可能还需要针对具体的项目进行考虑分析,这里不再赘述。规格能力问题描述规格能力,华为SeamlessMPLS到接入方案本身并不存在问题,但存在竞争问题。本文之所以加入此小章节,主要是讨论下当前业界情况。Cisco宣称支持大网60K。RFC中给出的案例定义的大网规格为90K。华为当前的SeamlessMPLS到边缘场景的规格大概是40K〔由于核心节点MASG能力限制,只支持大约60K的BGPLSP。问题解决考虑到竞争,建议产品进行计划性扩容。可靠性保护可靠性是方案的关键竞争力之一,华为号称端到端可靠性亚秒级别,真的能够做到吗？问题描述众多的运营商一般都倾向于LDP隧道,部署简单,另外结合RLFA也能做到大部分场景的快速保护。然而,可以想象一个RLFA不生效的场景,这个时候的收敛过程是：IGP/LDP收敛完成>BGPLSP逐条收敛>VPN路由逐条收敛,随着网络路由量的增加,必定是秒级。当然,这个是基于我们当前不支持层次化的下一跳分离进行的分析,像友商C支持PIC的话,后两个阶段的收敛时间几乎可以忽略。另外,就是多点故障场景,这个始终是潜在的可靠性痛点,场景复杂,大部分根本无检测手段,只能通过硬收敛。综上,方案的可靠性依靠简单的BFD检测触发FRR快切提高端到端可靠性,这明显是不具有理论依据的！对于BFD,是一把双刃剑,可以作为亮点