城域网系列 – 6 另类玩法PBT

作者 | 2010-05-13 19:57 | 类型 互联网, 通讯产品 | 15条用户评论 »

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）

刚刚有人“踢馆”，遇到此类事情，难免不爽，我也远非非常大度的人，所以回复里也含讥讽，想来何必呢，所以在此篇开头正式向那些同学表示道歉。
应该总结一下AL新ME的问题：
1、 技术上个人认为主要是VPLS带来的问题，具体细节前面都分析过了，不在赘述
2、 成本上主要是过高：原因是AL支持的都是海量的MAC/FIB/queue等，加上复杂的功能，不可能迅速降低成本，这也是AL把同等产品软件阉割一下推出比7750低价的7450的一个内在驱动。这还是没有把MPLS到运营商最边缘的情况下，如果到了最边缘，会如何呢？这是个大问题答复比较复杂，后面再讨论
AL新ME的创新，其实并没有脱离IP网络本质的巢穴，在增加业务支持和可靠性的同时，不可避免的带来了网络的复杂性，这在具有多年传统网络概念的电信运营商来看，总是觉得其本质有问题，需要改造，所以很早就有人提出IPTN(IP电信网)的概念，当然也会有一些新的draft、专利出来，概念本身并不复杂，IP节点傻瓜化，所有路由集中控制集中下发，IP节点只管按照管理中心下发的路由指示去转发，包括QOS参数，别的不用管，这不是很简单吗？这种idea现在已经演变到FOCE的标准簇，但仍然没有得到广泛部署，很难说是什么原因？思科因设备简化导致卖不上好价而消极？背离IP节点自智能的基本原则？标准不成熟历史网络难以改造？
在AL新ME火热的时候，其设备贵，网络复杂的弊端也自然会暴露出来，这对运营商在降低成本的压力下，是有考虑一些可能解决方案的驱动的，其中BT就是最激进的代表，BT本身在tier1运营商里排名不高，但是确是较早提出下一代网络规划的运营商，称为21CN，北电在种种不幸里，在数通领域已经没有什么顾及了，两者组合在一起，提出PBB的L2网络，基本思想和IPTN类似，只是利用了MAC IN MAC代替IP/MPLS路由，MAC IN MAC是为了解决对客户MAC学习带来的MAC容量问题，通过PMAC隔离CMAC，这个专利就像铅笔上加一个橡皮头一样简单，所以被日本人发明了，并且成本基础专利，让喜欢专利的人很生气，还好，现在基本也没啥用了
PBB需要一套独立的网管，来学习所有的MAC地址，然后下发到各个L2节点，各个L2节点是各种size的傻瓜，除了和网管的通讯协议，别的什么协议都没有，是个傀儡，傀儡能卖多少钱？很明显，思科是绝对不会傻到大力支持这个方案的，其实除了一无所有的北电，借槡登槐的华为，没人真的喜欢PBB。PBT在BT表面的火热中，已经演进到了PBT(PBB TE)，有一些技术问题比如组播等还没有解决，当然，随着网络的真正商用，也许会有更多的需求，但未必是大问题。在风风火火了几年后，BT终结了PBT，几乎在一夜之间转向了AL的7750，并且一路扩展。想来是BT高层对PBT迟迟不能商用全面部署影响了这几年业务的迅速拓展十分不满，所以很快勒令下马，迅速开始AL 7750，这个结果让一些人真的很伤心，陪太子读书很多年，结果成了曹雪芹，不知道有没有红楼梦可以塞翁失马，聊作安慰。
目前还有类似思路的有T-MPLS/G-MPLS等，都不是IP vendor真正喜欢的，具体没有仔细研究。

顺便提一个城域网传输中的一朵小昙花：LDMS，无线光网，这种无线也就是微波类似的技术，无论怎么做，带宽都是有限的，所有偶尔有些特殊的情况用一下，没有任何规模化的可能

最近几章的内容都没什么大的亮点，再不聊点有意思的事，就更又长又臭了，下一章，我们玩玩决战城域网：FMC

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

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

雁过留声

“城域网系列 – 6 另类玩法PBT”有15个回复

  1. 海量有多海量？ 于 2010-05-13 10:38 下午

    AL的海量MAC、ACL、QoS有多海量？怎么我看到的数据不比别人多啊？LZ有没有数据呢？

  2. RabeenZhu 于 2010-05-13 11:10 下午

    非最新版本，7×50 MAC支持超过10万。单从数量上来看“可能”不比别人多。通过在AL设备上很成熟的H-VPLS技术可以将PE边缘一直拉到最接近客户端。一般10W对于一个客户一个或者几个VPLS的MAC数来说算是海量了。10W对中间的P设备可能不够海量，这个时候可以通过部署PBB去解决这个问题。

  3. manjusri 于 2010-05-14 1:09 上午

    MAC：256K
    FIB: 4M
    QUEUE: 128K

  4. fpeking 于 2010-05-14 4:06 上午

    一开始的时候Queue还是很大的，（没有现在大），８K的数字就把韦乐平张新建之类的给吓了一条。
    现在回过头来看，几乎没有哪家不做这么大了。

  5. 陶潜 于 2010-05-14 11:01 上午

    QUEUE: 128K.
    这里是指所有的线卡加起来，还是一张线卡？

    如果128k queues在一张线卡上：
    假设一个queue至少容纳一个jumbo packet,也就是这个queue所占的buffer至少10k bytes,那么这张线卡上的packet buffer就是128k X 10k =1.28Gbytes,再考虑上200G的store/retreive的速度(假设100G的线速)，不知道什么类型的Ram可以满足要求。

  6. manjusri 于 2010-05-14 11:09 上午

    一个线卡

  7. kevin 于 2010-05-14 1:58 下午

    to 5:

    128k q为什么一定要支持128k jumbo pkt呢？考虑下实际网络情况吧

  8. 陶潜 于 2010-05-14 2:51 下午

    to 7，我举的例子比较极端。
    但是，一般而言，一个queue里总要能放上几个包，如果只能容纳一两个包，那么scheulder或者shaping的效果是很差劲的。
    我的意思说因为queue数量很大，必然导致packet buffer很大，速度要求又很高。

  9. manjusri 于 2010-05-14 3:39 下午

    这个问题很根本，是个好问题。
    大多数队列调度参数使用报文长度，不是个数，因为shaping的是流量的速率，当然如果不是IP报文变长，而是固定信元，就无所谓了

  10. 陶潜 于 2010-05-14 4:26 下午

    to 9:
    大多数队列调度参数“应该”使用报文长度，不是个数，因为shaping的是流量的速率。

    这个观点我非常同意，我以前测试的时候碰到了这个问题，当调度参数(Queue最大深度)用报文个数时,shaping效果比较差,改成长度时,效果好很多。

  11. malabas 于 2010-05-14 10:03 下午

    对于vpls的MAC问题，可以采用VPLS HUB&SPOKE, 这样通过SPOKE AC和HUB PW水平分割，可以把PE的MAC压力分散给HUB CE，IP转发和控制模型由集中到分散。PBB+VPLS也可以，不过随着路由和MPLS到边缘，PBB价值渐弱。
    IP技术看似协议做的差不多了，实际上只能说能用不好用。

  12. CC 于 2010-05-16 7:06 上午

    陶潜同学在米国啊？令人怀念的兄弟可好啊

  13. 陶潜 于 2010-05-16 6:21 下午

    to 12
    不要潜水了,hoho，报上名来。

  14. aaa 于 2010-05-16 8:50 下午

    陶哥还在研究queue阿，告诉你一个电信网中的事实，一个port 8个queue就可以吹牛了！

  15. qiaoyu 于 2010-05-16 11:24 下午

    老大 做个 full pdf 吧