城域网系列 – 5 ALU新ME的前世今生（MPLS/TE）

作者 | 2010-04-28 20:30 | 类型 行业动感 | 19条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列目录 城域网系列

  1. 城域网系列1 – 前传（上）
  2. 城域网系列1 – 前传（下）
  3. 城域网系列2 – ATM插曲
  4. 城域网系列 – 3：大片之前的加片（上）
  5. 城域网系列 – 3：大片之前的加片（下）
  6. 城域网系列 – 4 AL ME大片前以太网的总结
  7. 城域网系列 – 5 ALU新ME的前世今生（上）
  8. 城域网系列 – 5 ALU新ME的前世今生（中1）
  9. 城域网系列 – 5 ALU新ME的前世今生（中2）
  10. 城域网系列 – 5 ALU新ME的前世今生（中3）
  11. 城域网系列 – 5 ALU新ME的前世今生（中4）
  12. 城域网系列 – 5 ALU新ME的前世今生（中5）
  13. 城域网系列 – 5 ALU新ME的前世今生：L2VPN
  14. 城域网系列 – 5 ALU新ME的前世今生（VOIP和IPTV）
  15. 城域网系列 – 5 ALU新ME的前世今生（IPTV 2）
  16. 城域网系列 – 5 ALU新ME的前世今生（IPTV 3）
  17. 城域网系列 – 5 ALU新ME的前世今生（IPTV 4）
  18. 城域网系列 – 5 ALU新ME的前世今生（MPLS/TE）
  19. 城域网系列 – 5 ALU新ME的前世今生（下）
  20. 城域网系列 – 6 另类玩法PBT
  21. 城域网系列 – 7：FMC 决战城域网（1）
  22. 城域网系列 – 7：FMC 决战城域网（2）
  23. 城域网系列 – 7：FMC 决战城域网（3）- 又见ATM
  24. 城域网系列 – 7：FMC 决战城域网（4）- 3G、IP和数据
  25. 城域网系列 – 7：FMC 决战城域网（4）- 3G、IP和数据（continue）

最后讲一下MPLS/TE，这是整个MPLS网络架构基础，但是以技术为主，涉及业务较少，所以放在最后提一下，这个技术完整的本身是比较复杂的，所以李（劲松）大师的MPLS江湖恩仇录才会那么受欢迎和推崇，这个复杂糅合了OSPF/ISIS/BGP这些复杂的路由协议，以及跨域等等，虽有意思，但不好玩，当然有很多书讲这个东西，我基本上没怎么看过，因为我曾经看的时候我还不懂，很糊涂，所以基本上没有留下什么印象，所以有限的知识都是在有限的实践中的一点积累

先简单说一下MPLS，为什么要MPLS，是因为路由域和量不断增大带来的麻烦太多，有两个问题：一个是路由域的问题，一个是IP QOS没有面向连接的问题。大家就想减少这些麻烦，方法是借鉴传统的面向链接的技术，增加面向连接的QOS；减少路由在核心域PE/P上的扩散，把承载和接入的路由分离开，这个和ATM很像，所以早期主要是从ATM交换机开始做MPLS，当然，现在早就完全脱离了ATM。MPLS面向连接的QOS和减少路由的好处，认可程度有限，以致早期那么多FEC，后来还是只剩下基于路由的FEC了，MPLS之所以能发展得那么好，在早期就是得益于L3VPN这个killer，虽然因为路由域的原因带来了复杂的三个option的inter-AS，但瑕不掩瑜。L3VPN有效的隔离了路由，增加了网络的安全性，在现在仍然是主流的VPN技术，至于面向连接可以带来的QOS的好处，并没有引起更多的关注，也很少有人去关心什么L-LSP/E-LSP的区别

在MPLS获得成功好，大家在考虑路由优化的问题和MPLS原来没有解决的面向连接的QOS保证问题，所以TE技术很快就开始和MPLS融合，称为MPLS TE
如何定义MPLS TE？我的定义是MPLS TE是一种提供精确路由控制下的面向连接的QOS保证的具有HA的技术。三个特点：
（1） 首先是提供精确控制的路由路径，之前的IGP/.BGP包括基于路由的LDP，只能根据有限的几个路径metric控制流量的路径，最多强制做一下PRB，这种路由架构在复杂网络情况下会出现左支右绌的情况，使路由CCIE成为这个时候的抢手货。TE首先是要解决这个问题，通过引入动态的带宽参数已经更多的链路属性，比如链路的color，比如C的SLRG来防止光纤共bundle问题等，在这个功能上，在实际的路由规划中的一些场景确实是需要的，因为我们在做路由规划的时候很难做到精准的未来预测，所以在网络建设完毕后的运行中就可能出现要做一点点优化，这在一个复杂一点的路由metric设置中，更高metric是非常麻烦的事，路由是路由器的基础，这个一点点变动都可能产生不好预料的蝴蝶效应，客户希望是这个变动的影响越小越好，要可控，而TE正好提供的这个功能，当然付出的代价是很大的，尤其是控制平面，需要对IGP做TE扩展，需要新的路由计算模块，这对已有路由是一个大手术，不是小手术，医保福利并不总是那么容易，像这种手术就不在医保范围，免费的午餐是有限的，支持TE设备的价格当然要和不支持的有区别，客户要考虑是否值得吃这顿不免费的午餐
（2） 面向连接的带宽保证：MPLS提供了面线连接的路由，但在提供真正的有QOS保证的连接上是难以继续发挥作用的，所以TE来了，方法就是在建立TE TUNNEL/LSP的时候在每个经过的节点进行带宽申请，选择最合适带宽需求的路径建立tunnel，那么此时是否还需要做QOS调度的保证呢？需要的话要到什么粒度呢？还是需要的，当然如果做到每个节点上的每个tunnel都做QOS调度最好，但实际实现中，可以不这样做，只在PE节点的ingress做基于tunnel的QOS，而在中间P节点还是做differ-serv，因为在带宽请求的时候对中间节点已经对申请的带宽类型做了处理，所以可以保证这种类型带宽的的质量。在这种带宽模型处理中，有3个基本型还有一些变种，比如俄罗斯木偶什么的，次次记次次忘，可见TE的这个特性实际应用有限，这个模型的复杂不一定是大问题，重要的是不好处理TE流量和非TE流量的带宽共享问题，当然全业务TE可以一定程度上解决这个问题，但是如果要提供这样精确的带宽保证，还是要付出带宽效率的代价，并且带宽的限制条件，对路由的灵活调整，尤其是手动调整，又带来很多麻烦，当然，如果有一个非常好的网管能解决很多问题，但是TE作为美妙的技术，在商用之初是很少去考虑网管问题的，这是思科给IP定下的通病，即使现在，在TE这个特性方面，也没有很好的网管，这个特性，是TE三个特性中最不常用的一个
（3） 最后一个是TE的HA功能，主要是FRR和hot standby，FRR用于解决局部的可靠性：链路/节点，可以自动也可以手工，各有利弊。Hot standby用于解决E2E path的可靠性，比如路径上有同时两个故障的时候，一般来说是非常罕见的，还有TE protection group做TE隧道间的保护，功能和hot standby类似，区别是这里的备份是TE TUNNEL间的备份，以为着备份隧道是可以有带宽保证的，而hot standby是基于一个TE TUNNEL内两条LSP间的备份，备份LSP可以做路由约束，但不能有TE的带宽保证，虽然看起来TE protection group要美一些，但是因为消耗TE tunnel资源过多，已经一些比hot standby复杂一些的原因，比如一些实现需要MPLS OAM配合，还有上面提到大家并不CARE TE本身的带宽分配保证技术，所以hot standby比protection group用得要多得多。这里备份还涉及1:1和N:1，以及在hot standby的时候，如果对备份LSP做了explicit路径限制，那么在一些组网情况下还需要逃生路径，同时需要注意的是TE的HA技术并不能提供头节点PE的保护，要做到这个，需要VPN相关的甚至CE相关的VPN可靠性方案，比如PW REDUNDANCY，VPN FRR, MC-APS, MC-LAG, E-VRRP等等，同时，快速故障检测BFD/OAM,也是一个必要的基础，那么整个方案部署下来，这一套东西是相当的累人，以致成了俗套鸡肋，讲多了都开始不相信这套方案的必要性了。所以这里，思科作为路由起家的在路由方面最强的vendor，较早的做了路由快速收敛技术，包括IGP/BGP/IP FRR，具体有增量路由计算、路由下一条分离、BGP独立选路、可选路由优先等一些内容，虽然也不那么简单但还是比上面简单了不少，当然，一些局限也必不可少：IP FRR的环路问题、性能在sub second级别、和LDP/RSVP同步困难、同样不能单独做头节点保护等问题。所以具体是用TE HA还是路由快速收敛，甚或同时支持，要具体对象具体选择了。里面还有一个LDP FRR的技术，用的更少，所以也没仔细去了解其来龙去脉，相比是不大好用，HA的东西太多了，影响大脑运作，索性忘了算了。
ALU新ME的核心部分终于完成了，累了，休息一下。
下一章收收尾，然后要谈点新东西了，别忘了最后的谢幕主角是why L3，希望能在2010年的上半年完成

系列前一篇 系列下一篇
(5个打分， 平均：3.00 / 5)

工具箱
本文链接 | | 打印此页 | 19条用户评论 »

雁过留声

“城域网系列 – 5 ALU新ME的前世今生（MPLS/TE）”有19个回复

  1. ikewu83 于 2010-04-29 1:08 上午

    请问，现在MPLS推广的怎么样？

  2. manjusri 于 2010-04-29 6:27 上午

    IP网络的基本功能

  3. malabas 于 2010-04-30 4:50 上午

    对IP理解还挺深刻的，是个H老专家，IP技术好啊值钱能养老。

  4. fpeking 于 2010-04-30 5:23 上午

    国外一些大的运营商FRR还是比较常用的，因为设备比较统一，不牵扯7国8制的问题，历史遗留的包袱少。不过TE的其他应用非常不多，因为部署规范的确是非常困难。
    至于IP/LDP-FRR就更不用说了，新，支持的力度有限。
    IGP对TE的扩展虽然多，但是真正用的，尤其是同时用的很少阿

  5. manjusri 于 2010-04-30 7:14 上午

    听到malabas说“IP技术好啊值钱能养老”，如果是真的该多好，这年头，能养老的东西可是让人安心的好东西
    fpeking对IP网络也是很精

  6. southbayer 于 2010-08-08 5:39 下午

    个人感觉还缺了一个重要部分 — IEEE 1588 clock distribution, 这对Wirelss backhaul Network还是很重要的

  7. CCC 于 2010-08-14 11:55 下午

    1588要放在移动回环章节讲了，没看连首席对这个东东最近好像也非常感兴趣啊，可以找找是不是已经有帖子讲这个了。

  8. CCC 于 2010-08-15 12:10 上午

    说到这个，想起个问题：是不是AL的设备还不支持VPN的inter-AS啊，这个好像被人诟病好久了吧。想起个事：调AL设备互通问题时，发现AL做egress不能处理从tunnel来到协议报文，哈哈，这个事情还让我郁闷了好一段时间。

  9. ss 于 2010-08-15 12:25 上午

    在一篇关于国内运营的帖子里看到别人说，国内的运营商都没怎么使用TE这个东西，TE基本都在国外使用。

  10. ea 于 2010-08-15 12:29 上午

    cisco在04年就推出了TE这个特性，也就是说，这个东西很早就有了，可不怎么卖座啊。

  11. 邪哥 于 2010-08-16 10:00 下午

    TE其实用起来太麻烦,用起来就是给客户制造麻烦啊。

  12. river_stone 于 2010-11-03 11:37 下午

    HSB貌似不能达到50ms的切换时间，TE保护组的话，部署起来也是比较麻烦，但时间好一些。这些虽然实际部署也不是很多，但可能有人执拗于“电信级保护”。如果是IP FRR的话T-cam资源会不会占用过多？LZ对ME的理解很令在下佩服！继续学习中！！

  13. 理客 于 2010-11-03 11:44 下午

    看故障检测的性能和是否直接在forwarding engine做switching，HSB也是可能的。
    50MS电信保护在传输等观点可能很执拗，但IP本身不是特别care，IP FRR和T-cam应该没有直接关系

  14. river_stone 于 2010-11-04 7:35 下午

    IP FRR的话，备份的路由是存在T-cam中还是就在内存？？THX

  15. 理客 于 2010-11-04 11:50 下午

    搜索引擎，可能是T-CAM，也可能是其他类型的引擎，你的理解也是有道理的

  16. to-river_stone 于 2010-11-10 5:48 上午

    IP/MPLS FRR的备份路由都不用放到TCAM中，这是因为主备路由的切换时间主要取决于故障检测时间，而下路由表项的时间是很少的。

  17. L&L 于 2010-11-10 11:04 下午

    H公司的专业术语很多。。H的老专家

  18. L&L 于 2010-11-10 11:16 下午

    转发表象还是要放在TCAM里面吧，根据以前经验来看TCAM里面应该是存了两份的，只是根据标志位去选取哪一份

  19. manjusri 于 2010-11-10 11:47 下午

    具体实现上，不用TCAM，用其他查找引擎也可以，因为TCAM太贵，而容量有限，考虑到性价比，一般用于复杂分类的查找