城域网系列 – 5 ALU新ME的前世今生：L2VPN

作者 | 2010-04-18 08:56 | 类型 行业动感, 通讯产品 | 14条用户评论 »

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）

前面的QOS可以算情色QOS，有人说情色不是色情，不过后面的章节熟套或流水帐可能多一些，不一定有意思。大片重映观众的高潮更多在中段，没有悬念的尾声还不如夕阳红，第二次高潮，在大片后新气象里可能会有一些。但是GMPLS/TMPLE/FOCE及之后更新的研究，因为和个人以商用为主的工作距离大一些，一时可能难以有时间去仔细一点的关注了，所以相关章节会拖的较久

6、 L2VPN。这本是AL的EoMPLS新ME的核心转发和业务支撑技术，可分为点到点的VLL和多点到多点的VPLS，MEF的称谓有所不同，并略有细化，分为E-LINE/E-LAN和E-TREE，E-TREE其实是VLL和VPLS结合的产物，也有叫SPOKE PW的。E-LINE/E-LAN的名字写起来很清楚，但读起来很麻烦，类似在做presentation中常用的cost和QOS，读起来较易混淆。

VLL是很简单实用的管道，对于点到点管道业务，很好，主要问题是
（1） CE/PE间的HA不好处理，当然可以租两条VLL，但是就怕提钱
（2） 对于中大型企业网的多点需求，有点麻烦，一个是钱的问题，还有多条VLL带来的VLL资源浪费
（3） 广播/组播业务难以支持，每个PW都复制的方式显然不爽

VPLS很灵活，理论上可以做任何业务，对多点业务，节省PW资源，CE双归的HA容易，支持组播，但问题如下：
（1） 广播/组播/未知单播抑制：要基于接口/VSI/chassis，要基于packet和带宽，要绝对数值和percentage，都是trouble
（2） 环路：VPLS的CE接入的HA方案，要解决L2环路问题，这里花样繁多，有AL的MAC flapping局部方案，有STP in VPLS的方案，还有其他厂商的私有方案，也是trouble
（3） MAC容量限制：因为VPLS要学习MAC，自然涉及到学习的性能，还有容量问题，对tier1运营商，在汇聚的中心节点，甚至有million机的MAC地址需求，这么多MAC，管理等都是trouble
所以VPLS带来的好处相比于同时带来的这么多麻烦，个人观点是尽量不用，谁用谁知道麻烦在哪？甚至还有客户为解决一些VPLS的问题引入PBB over VPLS，faint。当然，在组播场景下，如果用L2组播，还是不得不用VPLS，所以是用L3组播还是L2组播，个人倾向于前者，只是设备商也很苦，不能总是便宜运营商，所以对于便宜的ME接入和汇聚节点，L3经常要单独出来收钱

E-TREE：是很实用的模型，现实的商用网络，full meshed/half full mesh的多在核心，而在接入汇聚层面，更多的是TREE形，比如DSLAM和BRAD的关系模型；另外就是dual-homing的Y形，中文翻译成丫形，这是E-TREE的最简单的形式，可以用VLL redundancy，也可用这种spoke VPLS，简单的实现双归HA，但是protection switching的性能有限，要提高，还需要BFD/TE FRR和MAC地址快速withdrawal配合，HA的解决，好像就很少简单过

L2VPN在一些时候需要透传所有报文，包括L2协议报文，尤其是VLL的时候，可以叫E-PIPE。L2VPN的透传需求带来一个QOS问题，就是拥塞的时候如何保证L2/L3协议报文的优先级，按说应该保证才好，但实际上好像没有这样配置，其实如果扩展起来，是不是L4以上的协议报文也要保证？那可能要DPI了。但是对于路由器本身主机的协议报文，一般是要配置一个默认的高优先级队列，否则拥塞的时候就会导致协议中断

这章更多是一些常事，水一些，下一章要介绍一下最近的热门话题女王：IPTV

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

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

雁过留声

“城域网系列 – 5 ALU新ME的前世今生：L2VPN”有14个回复

  1. aaa 于 2010-04-18 9:07 下午

    E-TREE可没有这么简单，目前还没看到有哪家MPLS设备能支持E-TREE，她需要根节点和所有根节点与叶子节点互通。

  2. bbb 于 2010-04-18 9:08 下午

    VPLS不会节省一点PW资源。。。

  3. manjusri 于 2010-04-18 11:51 下午

    E-TREE也是一种基本形式，利用H-VPLS和水平分割的控制应该就可以了
    如果不使用H-VPLS，PW不能节省，但CE侧逻辑接口资源可以节省

  4. iversondb 于 2010-04-19 12:12 上午

    一楼，
    E-TREE目前是可以做的了。
    楼主总结的不错。

  5. aaa 于 2010-05-27 8:58 下午

    E-Tree是PTN必测项。

    移动马上启动第二批至少50亿的集采，AL用的是什么设备去的?

  6. 理客 于 2010-05-27 10:43 下午

    AL应该是7705系列。一楼说的E-TREE不是普通的树，是一种怪树，叫多根树，具体英文忘了

  7. aaa 于 2010-05-28 7:01 上午

    问下，AL的设备支持E-TREE的方案怎样的啊，能不能具体说说。E-TREE的draft是基于芯片实现的，难道AL的芯片之前已经看到这个问题，并采用了该方案？

  8. ABC 于 2010-05-28 7:51 下午

    AL的芯片是基于自己的，不是商用芯片。所以AL可以自己根据标准的进程进行更新。

  9. 理客 于 2010-05-28 11:50 下午

    普通的简单的E-TREE并不复杂。一楼提的是Root-Multipoint EVC形式的E-TREE，实现的不多，可能思科在一些交换机做了，好像目前也没什么商用，具体参见http://www.ieee802.org/1/files/public/docs2010/new-haddock-E-TREE-support-0110-v01.pdf

  10. Wayneqiu 于 2010-06-18 5:00 上午

    楼主能否讲讲MPLS-TP的来龙去脉，为什么要搞一个简化版饿MPLS？

  11. manjusri 于 2010-06-18 10:04 上午

    抱歉，MPLS-TP我基本没有学习，不好乱说，等有机会学习了，一定解释一下

  12. aaa 于 2010-06-20 6:59 上午

    呵呵，研究了一段时间的mpls-tp，分析一下我的看法，如果有不对的地方，请大侠们不吝赐教.
    技术方面：
    1 mpls-tp是mpls在传输网应用中的简化，把很多mpls的复杂信令革命掉了，提供了一套类似于sdh的控制管理机制。（美其名曰使用mpls-tp是为了更好的与core的mpls更好的互通，但事实上互通相对于qinq来说变得更难了）
    2 类似sdh的oam和aps（对于基于gach的oam，绝大部分现有的asic不能通过软件平滑升级，基于np可以搞一下），提供电信级的保护

    政治方面：
    ip/mpls是cisco和juniper的地盘，已经在core不可动摇了，其他厂商很难有机会进入，于是一些传输网很强势的厂商就在分组传输网上作文章，mpls又正好是个很好的噱头，所以就有tmpls，后来各大组织又妥协一下，一起搞mpls-tp了

    个人在对比mpls-tp和qinq技术的时候，发现好像除了业务数量外，mpls-tp也没有什么优势。

  13. ABC 于 2010-06-21 6:10 下午

    技术有一个优势就足以吸引眼球了。

  14. southbayer 于 2010-08-08 5:05 下午

    QinQ有下面一些问题:

    1. Traffic Engineering基本没啥支持
    2. 使用QinQ的Node必须要learn MAC address, 这样会有scalability的问题, 靠近核心的接点的L2 table的容量需要很大.
    3. 因为为要做L2 learning, 所以只支持一个MAC address space, 这样service isolation也要差一些.
    4. 另外VID只有12 bit, 这也带来scalability方面的concern.

    暂时就只想起来这么多, hoho