注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

欢迎光临shaying110的博客

RSed-ISPing

 
 
 

日志

 
 

运营商在实施MPLS TE时需要关注问题  

2009-08-13 09:43:56|  分类: CISCO网络 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

运营商在实施MPLS TE时需要关注问题

发布时间:2008年1月10日                        作者:中国电信股份有限公司研究院 胡捷

        文章出自:http://bbs.tech-lab.cn/viewthread.php?tid=35893 (转载请注明出处)

 

    一、前言

 

    与MPLS技术相关的分支很多,例如MPLSRouting、L3VPN、L2VPN、MPLS Multi-cast、MPLS QoS等;其中的某些应用和技术,如基于RFC2547 bis的L3 VPN,在国内外多家ISP已经成功应用并大量部署,但是其它的技术和应用如组播和QoS正处在发展和成熟时期,另外也有些技术如MPLS TE已经基本成熟,在国外被部分运营商接受和采纳,而在国内几乎还没有应用。

 

    就网络流量工程而言,在MPLS技术出现之前,网络管理员就已经可以通过其他方式初步实现了,主要是通过调整IGP链路的Metric或者采用多个IGP平面来疏导不同POP之间的流量。MPLSTE带来的好处是克服了传统调整Metric方式的不足,这些不足包括:对IGPMetric的调整不像MPLSTE是站在全局角度综合考虑网络流量流向矩阵,对每条链路Metric的局部调整会影响整个网络的流量变化,即牵一发而动全身;而且这种对局部链路的调整带来的对全网变化可能是无法预知的,解决了这条链路的流量,却带来其他链路的拥塞,有“按下葫芦浮起瓢”般的感觉;此外对IGP Metric的调整没有有效的方法根据流量的来源控制传送路径,而只能根据它的去向;最后一点,调整Metric方式配置复杂,容易引起路由环路。

 

    当然,基于MPLS的流量工程在给了人们一个新的选择的同时也是有代价的。这一选择同其他任何新技术一样,会迫使人们学习新的操作方式,打破传统经验和思维按新的理论来配置网络以实现流量调节。

 

    另外,在引入MPLSTE时,需要清醒地认识到,任何技术都不是万能的,它可以解决一些关键问题,但是不能解决所有问题。每个运营商都会针对自身的网络情况,业务特点对是否采用各种新技术以及每种新技术带来的代价之间进行取舍。

 

    二、TE功能描述

 

    首先介绍一下MPLSTE的总体功能:

 

    1. 提高、优化带宽利用率,延缓对带宽的扩容;

 

    2. 可实现不同于传统IGP Metric方式对带宽、流量、流向、负载分担实现控制,避免基于IGP Metric实施负载分担会出现的针孔效应;

 

    3. 可应对突发事件、网络链路/节点故障导致拓扑变化造成的流量新格局;

 

    4. 对网络流量矩阵进行详细测量,及时了解带宽需求和网络资源状况,指导网络规划和链路升级;

 

    5. 基于TE的FRR可提供50ms级别的物理链路、设备节点保护;

 

    6. 端到端TE LSP Tunnel本身也可提供快速保护。

 

    在具体实施和部署TE时,由于不同的TE功能实现机制上存在差异和矛盾,因此很难在一个网络中同时提供全部功能,需要对TE及FRR分类进行详细了解,才能制定符合运营商网络实际需求的TE部署策略。

 

    三、战术式TE--NativeIP网络环境下的TE

 

    如果运营商的IP骨干网平时没有启用MPLS,属于一个“RowIP”或“NativeIP”网络,在这种网络结构中我们可以采用“战术TE”实现流量工程。所谓战术式就是在需要的时候临时配置,动态启用RSVP信令,采用CSPF计算TE路径,通过RSVP建立LSP。一旦TE的使命结束,再拆除TE隧道。这种TE主要解决网络链路利用率不均衡的问题,直接的利益是可以延缓网络带宽扩容,或者给带宽升级留出充足的时间。

 

    在“NativeIP”情况下,我们通常只能利用到TE提高带宽利用率这一优势,对网络流量流向矩阵的测量和统计,基本上还是需要通过其他方式解决,如Netflow、TMS或CEFAccounting等。因为战术式TE都是在网络的局部实施,没有对全网所有路由器间的流量进行采样,因此很难准确统计真实的网络流量。

 

    “NativeIP”网络下我们无法实现基于TE技术的快速重路由FRR来实现50ms级别的链路、节点故障恢复。

 

    四、战略式TE—适合各种网络环境下的TE

 

    1.战略式TE简介

 

    战略式TE就是预先配置好RSVP信令、计算好TE路径、并已经预先建立的TE隧道。从实施的范围角度它还可以细分为局部式、全局式两种。

 

    局部式通常在网络核心POP节点之间实现,因为网络核心是全网流量交汇中心,对核心实施TE可以在尽可能小地配置工作量下,尽可能大地提供TE功能。运营商在实施局部战略式TE中,外围通常为NativeIP或LDPEnabledIP,前者主要是没有在全网启用MPLS技术的运营商采用,后者主要是在全网提供MPLS VPN业务(2547 bis)的运营商采用。对于后者,需要注意穿越核心TE Domain的LDP LSP需要在TE Domain内部实现IP Over RSVP功能,才能保证端到端PE之间的LDP LSP互通,从而实现端到端VPN业务。

 

    全局战略式TE就是在全网所有路由器上配置实现RSVPTE,这是TE最理想的部属方式,可以实现TE的所有功能。此方式存在N方效应,扩展性很差。而且一旦全网新增任何一个节点甚至新增任何一台路由器,全网都需要重新配置新增的TELSP。据了解,在网络中所有路由器上配置TE实现Fullmesh TE LSP 隧道的运营商几乎没有,可能扩展性是其主要制约。

 

    无论局部式还是全局式TE,由于其预先配置的特性,可以实现TE的一个很具优势的功能—快速重路由FRR。

 

    2.FRR简介

 

    FRR的具体实现随厂家不同而不同,主要存在两大方式:Facility和Detour。

 

    Facility基于标记堆栈技术,可实现1:N的保护,主要实现对链路的保护,对节点进行保护需要额外的配置;Detour基于每一条TELSP单独进行保护,可同时实现对链路和节点的保护,但是由于其只能提供1:1方式,其扩展性不如Facility。由Facility方式延伸而产生的保护是“一跳式”保护,这在实际网络中已经有大量部署,是TEFRR应用最多的方式。在目前WDM系统没有实现对波长保护的情况下一跳式FRR的作用就显得更为重要。

 

    一跳式FRR保护原理如下:

 

    假设北京、上海两个POP,分别由两台路由器构成。其POP内部、POP之间以及P到PE的连接方式见图1。

 

 运营商在实施MPLS TE时需要关注问题 - shaying110 - shaying110的博客

 

 图1POP内部、POP之间以及P到PE的连接方式图

 

    在北京、上海两个POP节点的四个路由器之间配置FullmeshTE隧道,在北京、上海两个节点之间的广域网链路上配置Facility方式的FRR保护,提供广域网链路一跳式保护。以P2-P3之间的流量流向作为参考,P2路由器为本地修复点(PLR),P3路由器为汇合点(MP)。

 

    此范例在TEDomain内为FullmeshTE隧道,没有LDP信令存在,所有LDP邻接关系都是通过端到端TE隧道进行封装和承载的。当北京、上海两个核心节点之间的广域网链路发生故障,原先通过这条故障链路的端到端TE LSP会被FRR机制提供保护,隧道的首端(Headend)和尾端(Tailend)不会把这条隧道看作是“Down”了,因此LDP邻接关系继续建立并维持。

 

    发生在核心节点所构成的TEDomain内部的链路故障,会引起IGP收敛,但是TEDomain内没有LDP信令的存在,因此不会引起网络核心的LDP收敛。

 

    TEDomain内的IGP收敛,对ISP网络外围的LDP来说是透明的,不会引起网络外围LDP收敛,因为跨越核心TEDomain的LDP邻接建立在TELSP隧道上,而隧道通过FRR机制被实施了保护。

 

    当然,网络外围的路由器通过接收到的IS-ISLSPFlooding可以判断网络核心拓扑发生了变化(在TE隧道没有配置Forwarding adjacency参数的情况下),在IGP收敛结束后,在源端会对数据按照收敛后的路径进行转发。

 

    在具体采用何种FRR,提供何种保护的探讨中,仍然需要根据运营商网络的具体配置和网络结构设计。例如在北京和上海POP内部还可以同时启用RSVP和LDP信令,RSVP用于备份隧道的建立,LDP用于网络正常状态下在同一个POP内部不同路由器之间建立LDPLSP。

 

    3.FRR的其他特性和约束

 

    同TE一样,运营商部属FRR时,在利用其优势的同时还需要了解其局限。

 

    (1) FRR是临时措施,一旦FRR生效,保护隧道所在的物理路径带宽利用率会上升,为了确保备份TE隧道途径的物理路径中原有流量和保护流量的QoS,仍然需要轻载(Over Provisioning)来保障。FRR的保护机制决定了它的临时性,保护链路在起到流量迂回作用时,与其他正常链路共争带宽,为了避免此时的网络拥塞导致性能下降,因此要求网络正常情况下,链路的带宽利用率不能过高,低于50%为宜;

 

    (2) FRR保护链路只在很短的时间内有效,之后系统会分别进行IGP收敛和首端LSP重优化,采用make before break机制,并采用显式共享来进一步降低对带宽的占用,如果为备份隧道预留带宽不仅浪费网络资源,还会影像其他正常TE LSP的最优路径计算。因此不建议为FRR的保护链路提供预留带宽;

 

    (3) 经测试,FRR可以提供50ms级别的故障恢复,但是故障检测的时间是关键,如果故障检测耗时增加,FRR保护时间会相应增加;

 

    (4) FRR只在局部范围起作用,当链路或节点故障发生在TE Domain之外,系统的故障恢复需要IGP收敛实现;

 

    (5) 根据理论依据和配置试验,FRR的节点保护可扩展性低,而且目前节点设备的可靠性远远高于链路,因此不建议提供节点保护;

 

    (6) 部署TE需考虑设备兼容性,建议在TE Domain内采用同一厂家设备。虽然各个厂家都声称与主流设备可实现TE及FRR兼容,但根据测试结果和以往经验,在某些特性上的具体实现上仍有细微差别,需要不断调整各厂家设备的配置参数,达到最佳的协调状态,这在网络运行初期缺乏TE维护经验的情况下较难实现,容易导致网络性能不稳定。此外不同厂家设备在配合实现FRR时的保护恢复时间会延长,经实际测试,不同厂家设备位于隧道中不同位置(PLR或MP)也会对FRR性能带来影响。

 

    五、MPLSTE的相关问题

 

    正如MPLSTE是MPLS技术的一个分支一样,FRR也只是TE的一个分支,作为TE的整体部署策略,还需要考虑更多的问题:

 

    1. 在TE应用的初期,TE隧道的建立主要基于带宽使用情况,不根据链路属性和Affinity参数建立TE Tunnel,这些参数是TE应用的优化和深化,暂时不采用这些特性;

 

    2. TE的带宽保留机制通过RSVP信令在控制平面实施,没有转发平面的强制执行措施,需要在边界路由器对流量进行限制;

 

    3. TE的实现机制是基于网络设备对全网资源使用情况的了解,在路由器中建立状态数据库,从而在TE LSP的路径计算中进行最优化选择,这也是为什么在一个TE Domain中要求内部所有节点之间实现Full mesh TE LSP的根本原因。这样可以尽可能避免在一个链路上既有Native IP流量又有TE 隧道流量的情况,因为在这种情况下,TE及RSVP对网络资源使用状况的了解是不精确的。但是由于目前在构成TE 隧道的外层标记上没有对EXP置位,因此P路由器很难做到对TE 隧道的队列控制,所以没有在P路由器的转发平面实行强制带宽预留。目前的TE以汇聚后的流量进行疏导为主,对TE隧道内的流量通常不再进一步细分具体业务流量;

 

    4. 关于TE的QoS技术正在发展,包括E-LSP和L-LSP两类,但是目前还不成熟,在网络中暂不采用。

 

    六、其他需要引起重视的问题及后续实施建议

 

    TE毕竟在国内应用不多,积累的经验很少,在实际应用上,还需要密切关注其潜在的问题与解决方案,归纳如下:

 

    1. 基于TE的FRR对IGP收敛、CSPF收敛、RSVP收敛、LDP收敛等带来的影响,对网络流量因不同协议收敛而导致相互之间的作用及影响需要进一步研究;

 

    2. 与TE运行维护管理配置密切相关的后台支撑系统需要同期进行建设,才能在利用TE带来好处的同时,尽量降低运维复杂度和成本;

 

    3. 根据统计,了解流量需求,优化调整LSP的各项参数,除利用FRR提供链路保护外,逐渐使用TE的流量疏导功能;

 

    4. 逐步采用网管软件实现TE 隧道业务部署和管理,过渡到真正的离线、战略、局部式TE。结合技术进步,针对不同优先级业务配置不同的LSP,提供增强的差异化服务。

 

    总之,MPLSTE与这个行业中的其他新技术一样,都需要花费时间和精力来学习和实践,本文的目的是介绍MPLSTE的运行原理及其能够实现的功能,是否在网络中使用MPLSTE,以及如何使用,使用哪些功能,每个运营商根据自身的实际情况会有不同的选择

 

  评论这张
 
阅读(134)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017