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

作者 | 2010-04-15 18:31 | 类型 专题分析, 互联网, 弯曲推荐, 通讯产品 | 34条用户评论 »

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）

（2） 事后丸：IP QOS，有两种事后丸，第一种是带有一定的预防效果的，既然要做一点事前预防工作，所以就要做在进去的时候，而不是出去的时候，这里还有两粒，一粒是RED/WRED，也就是根据设定的阈值，在还没有发生congestion的时候就开始丢弃，为了处理TCP的慢同步带来的同呼吸问题，所以要random，而为了区分业务的质量重要性，要给予不同的weight；另外一粒就是CAR，有什么单桶三色和双桶三色，具体算法区别记了又忘。CAR也可以和业务优先级结合，具体就是在CAR后的remarking上做文章，通过重新对CIR和PIR着色，使其在出去的时候得到不同的待遇。实际应用中，CAR是流行和直接的方式，RED/WRED偶尔辅助一下，用得不多，没仔细去对比为什么，仔细比一下应该有原因的。第二种就是出口队列技术，其实队列本身也可以用在前面，比如AL7750的CAR其实就是用队列处理的，用队列其实比不用队列好，队列因为报文缓存而具有shaping能力，CAR只是保存一些token，没有实际报文存贮，所以不能shaping，也就是没有token的时候没缓存直接丢弃，有token的时候想补救也没有对象了，子欲养而亲不在，称父母在的时候多孝敬父母吧。所以在上面的方法中，华为使用入口H-QOS的方式实现更精确的功能，可能其他不少vendor也是类似这么做的，这里还是主要讨论outbound方向，实际上，在这个方向上用得队列最多。都是用在congestion发生的时候，congestion可以精细化到对时延的抢占上，也就是即使没有报文丢失，也有congestion发生的可能，比如调度的先后会影响到时延，所以对时延敏感的重要业务可以有限调度，比如分配一个PQ，这里要加上重要二字，因为即使你对啥都敏感，但你对别人不重要，也没人理你，你自己过敏去吧。技术上主要是PQ/WFQ，同时支持带宽抢占，就是其他队列没人排队的时候，你也用他们的带宽，蹲位紧张的时候，别浪费了。当然对于UNI接口，运营商可以设置限制不让用户超出合同带宽，也是很合法的。不是有带宽就免费给你用，放那放着，你多多掏银子的时候才能给你，运营商是商人，不是开源社区，这里分为UNI和NNI，海量队列主要就应用在UNI上，当然某些vendor比如华为比较强，在NNI也做了被其称为VPN-QOS的技术，把用户队列带到NNI出口。IP QOS中最有趣的MPLS TE部分放在了上面，这里不是详细介绍MPLS TE技术的地方，就不展开了

IP QOS大体可能就这么多。对于IP QOS的实际使用，大体有两类观点：
（1）不需要QOS，因为带宽足够大，网络中的带宽利用率其实很低，还没等congestion，运营商已经扩容了，没有congestion的真正发生，所以QOS根本就没有真正发生作用。这是实际运营经验的一种体现，在许多情况下似乎很正确，但实际情况下是有一定问题：
1）一个是不丢包不代表时延OK，所以在带宽没有满，但是已经开始有拥挤的情况下，对时延敏感的重要业务需要给予一定的有限调度权利，那么就需要PQ的QOS机制
2）如果带宽一直得不到充分利用，那么成本的降低有问题的，或者反应了竞争不够充分，比如中国的电信市场，在欧洲电信法后，出现很多的tier2/3运营商，为了成本和效率，不可能带宽很充分，所以需要QOS来保证非internet业务。再就是有时对热点链路估计不足，导致这些链路发生拥塞
3）基于用户的业务需要，一个是你要保证你承诺的带宽，另外就是你不想把没有承诺的带宽给客户免费午餐，当然更恶劣的还有甚者故意劣化没有承诺的流量，达到让你购买承诺的不可靠人的目的，这里是玩笑了，但是在P2P泛滥而运营商看着带宽白白流水而不能变成白银流到自己口袋的时候，是真想让P2P流量恶劣得使用户讨厌用P2P了才好，实际上我们的P2P还一直用得还可以，运营商虽然恨在心里，可以也不敢下手太狠，毕竟，我们客户是他们的衣食父母，太狠了，道德上不好，我们做父母得也不会允许孩子们太过分纵容
（2）另外一种就是从精细化运营角度，来做非常精确精细的QOS控制，包括一套集中控制的策略服务器，路由器山充分的队列，用户可以通过portal定制的menu等等，看起来很美，但实际中被使用得有限，准备了精美的餐具和食品，可惜以草根为主的用户不感冒，所以投入产出不是很好，这种精细化QOS的思路也就在不冷不热中偶有被人们提起

此外还有一些公平理论，就是运营商不应该做QOS，QOS对用户不够民主自由和公平，在internet来看似乎如此，但如果考虑到internet和电信业务融合在一个网络，就不太一样了，具体在上面有描述，所以这种基于社会理论的想法，学术上很好，但实际上遵循的人不多

大多数实际部署上，很多就是用每端口的8个队列，对于UNI端口，一般不会超过4个，UNI的端口可能有逻辑接口的考虑，多扩展到N个逻辑接口，这也是AL7750的H-QOS的主要永无之地。只有其中的hierarchy有什么用，大多数情况下没有用，尤其是号称的5级，实际上号称的5级，真正生效的也未必有这么多级。在实际中，H发生有两种情况
（1）需要做基于用户的QOS调度，那么此时一个用户内部再有不同的业务，比如数据/语音/视频，以及用户还可能非为金银铜，那么就需要2、4甚至4级了，更多的是两级
（2）需要做基于VPN的QOS调度，具体情况和上面类似
实际上在H-QOS不多的应用中，主要是2级的应用，偶尔有3级的可能，在应用中，因为业务的灵活性，实际上的映射和调度模型优势更灵活，这里AL7750的H-QOS在灵活性上的设计是比较好的，当然华为后来做得也不错，其他的C/J就要逊色很多了
QOS用软件实现性能基本没法保证，后来强大的QOS，都是借助硬件实现，并且嵌入在转发引擎的QOS协处理能力是有限的，要更高更强的QOS，都是用独立的ASIC做TM，同时该ASIC也可以顺便兼做一些计数器等兼职功能。HQOS的实现网友HJ说了，一般队列就在和接口或者用户关联，后面的几级都是调度组合，并不再分配单独的队列

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

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

雁过留声

“城域网系列 – 5 ALU新ME的前世今生（中5）”有34个回复

  1. ikewu83 于 2010-04-15 9:30 下午

    因为我不是干通信的，所以无法完全领会本系列，但还是学了很多东西！

  2. ABC 于 2010-04-16 1:28 上午

    我更看好不使用QOS的网络，呵呵。平等，自由本来就是互联网的特性。

  3. manjusri 于 2010-04-16 2:55 上午

    但目前internet的承载网络是运营商建的，运营商是一种商人，并且正在把自己的电信业务也同时承载在同一个IP网络上，所以通过QOS来保证不公平

  4. ABC 于 2010-04-16 7:12 上午

    看了LZ的回复，有点感想，可能跑偏的厉害，勿怪。
    ———————
    有两点需要注意
    1 运营商的建设思路很容易被厂商所引导。
    2 厂商宣称最了解客户。
    历史在那个时代造就了思科，华为。他们成为当前这个时代的主流。
    时过境迁，技术发展了，市场也变化了。。。。。。
    从这个角度去看IBM，真的不一样啊。

  5. 陈怀临 于 2010-04-16 8:03 上午

    没有QoS,就不是网络。不懂QoS,就是网盲：）

  6. huaboy 于 2010-04-16 2:01 下午

    很喜欢楼主的扯淡风格，学习中……
    期待楼主的续篇

  7. ilovebgp4 于 2010-04-16 7:40 下午

    个人觉得入口做policer/car还有意义，但做shaping/H-QoS有意义吗？因为入口永远不可能阻塞，阻塞应该只发生在出向接口

  8. kkk 于 2010-04-16 8:54 下午

    防止HOL不是需要入口做Qos的队列吗？而且一般我看到的入口也是shaper多，police也不是每家都有的吧

  9. 陈怀临 于 2010-04-16 9:28 下午

    7,8,QoS这个东西与客户的需要非常相关。基本上很难有定论。但我同意，在Ingress，policyng，和通过metering做packet coloring比较多。Shaping也可以做。这都看应用。。。HOL基本上是通过不同的Queue，然后在Fabric入口上来避免的。

    QoS这个东西容易搞混人。confusing。我通常的习惯是: 忘记那些××骗人的术语。自己看这窗外。问一个问题：如果你是设计者，你如何做。

    我观察一个系统时，我经常幻想一批人坐在某个办公室内讨论，把自己摆在他们中。。。

    QoS中的任何一个部分都可以在一个Node的任何一个环节做。

    举一个例子，如果是Pseduo-Interface，logical interface，如果是VPN traffic，是否都要等到traffic被classfiy之后才可以做某部分QoS？

  10. manjusri 于 2010-04-16 10:38 下午

    HOL需要ingress queue和shaping，但一般对用户不可见，not configurable
    Pseduo-Interface/logical interface/VPN traffic，我想是的

  11. kkk 于 2010-04-17 5:48 上午

    classify之后的那个Qos无非就是marker/color/CIR/PIR了，但是受Classify 条目限制太多了，一直没搞懂policing和shaping的区别和实做，shape是不是只是来包就enqueue，丢的时候RED或者tail drop,那么policing丢包呢 呢？我看到两者都有个CIR/CBS配置

  12. manjusri 于 2010-04-17 6:07 上午

    这是一些基本知识：
    POLICY基本就是classification的表现形式
    shaping就是queue缓存报文+CIR/PRI/WRED
    performance技术上的难点一个是数量，一个是小颗粒下的精度，但一般不会成为商用的barrier

  13. kkk 于 2010-04-17 7:40 上午

    是不是只有outprofile的才enqueue，inprofile的每一所谓的延迟，这个时候enqueue已经分好队列吧？它的队列信息从哪里来的，我一直看到的说法都是shaper 在egress,policer在ingress，但是实际芯片往往貌似不是

  14. 陈怀临 于 2010-04-17 7:48 上午

    Policying: 越界就把你灭了。（drop）
    Shaping: 违法就修理你。绐你机会。

    高速入口（辽国）的红绿灯：shaping
    高速入口（大宋）的收银站：policying
    (不给钱就给命）

  15. HJ 于 2010-04-17 10:04 下午

    简单比较一下Shaping和Policying：

    －Policying：
    － 只能给包着色或是丢弃，没有缓存
    － 没有缓存意味着无法解决拥塞时TCP等具备滑动窗口机制的协议性能大幅下降的问题
    － 没有缓存意味着无需昂贵的缓存硬件资源
    － 没有缓存意味着带来额外时延较小，适用于语音等对时延敏感的业务
    － 可以实现层次化的policying

    - Shaping
    － 有缓存，加上不同的RED技术，能够有效改善拥塞时TCP的性能
    － 有缓存意味着需要硬件资源，意味着成本和较小可扩展性
    － 有缓存意味着较大的额外时延
    － 可以实现层次化的调度

  16. manjusri 于 2010-04-18 12:56 上午

    HJ很精通，不说大都忘了这个名词，policying中文常译作监管，做真正拥塞前的处理，一般用CAR，但不是必须的，用queue也可以，AL就是

  17. jjww 于 2010-05-05 6:35 上午

    现在不是流行PTN，流行IP OVER DWM/OTN。怎么讲ME了？阿朗在城域很牛X吗？是不是很早的文章了？

  18. manjusri 于 2010-05-05 9:18 上午

    PTN流行刚过，IP OVER OTN还在预热中，AL是新ME的创始人，目前还是牛X之一

  19. jjww 于 2010-05-05 6:09 下午

    可是我记得mpls te这个概念好几年前就已经成熟了，不是新技术了。mpls-tp才是这两年才逐渐成熟的，而且里面的oam好像还未完善。mpls-tp倒是阿朗首创，这个没跑的，不过现在华为也贡献了很多提案

  20. manjusri 于 2010-05-05 8:48 下午

    是的，MPLS-TP没有去研究，请jjww多指教

  21. jjww 于 2010-05-06 12:52 上午

    指教谈不上，因为最近要写篇城域的文章，所以一直在网上看资料。说实话你这篇我还没看完呢。城域的历史太长，涉及技术太多，以前又没接触过，所以说指教实在谈不上。据我所知mpls-tp应该是PTN的最终选择技术，PBB-TE可能会随着北电的沦落而消沉。但二者在技术上差不太多，都共同兼备了IP分组和电信运营的共同优点。mpls-tp采用分层的模式，包括伪线层（PW3）、LSP隧道层 、和段层（section）。华为在里面贡献很大，ITU的G.8XXX好几个它都参与编写了好像。去年中移动在PTN的投资是37个亿好像，因为无线回传的需要，所以中移动目前是PTN的应用先锋，后面怎么发展可能还是要看市场如何进展。不过城域让我头疼的是它曾经用过的那么多技术，一直想根据历史捋个脉络出来。而且这么多技术的产生及推进的原因不仅仅是技术本身的变化。

  22. Alex 于 2010-05-06 1:41 上午

    Broadcom的Enduro switch芯片只支持Ethernet OAM,不支持MPLS的，有些鸡肋

  23. DPI 于 2010-05-06 6:18 上午

    华为和ALU贡献多的应该是在ITU开始搞的T-MPLS，不是MPLS-TP。后来ITU在和IETF的交锋中败北，不得以推翻T-MPLS方案而采用新的两家都认可的MPLS-TP，但口头上只说是演进，呵呵。这里的故事比较曲折。两家产品上也走了一段弯路。

  24. 理客 于 2010-05-06 6:41 上午

    在IP/MPLS，ITUT肯定是干不过IETF的

  25. fpeking 于 2010-05-06 8:14 上午

    ALU现在的明星产品不多，IP全指着城域和边缘吃饭呢。在下一代核心出来之前，很难被看成是核心的serious player。所以在业务边缘上还是有些特色的。加上本身接入、光原先都是老大，所以还可以做一做。
    个人觉得这几年业务整合网络融合的厉害，所以才有ALU IP的机会，包括华为也比较厉害。而专长纯IP的公司就稍微差点了，或者换句话说，华为阿朗都是专注电信领域而思科不是。
    城域网上不只是IETF/ITU，还有DSL Forum/MEF，现在的BBF，相信LZ一定会讲TR-101/TR-059，包括WT-187/177之类的。这些领域里明显阿朗华为比思科强，Juniper就不灵光了吧。

  26. jjww 于 2010-05-06 11:59 下午

    T-MPLS推翻的说法好像也过了吧，二者是兼容的应该。就像MSTP可以兼容SDH一样。为什么说走了弯路？ITU和IETF不是妥协了吗？双方共同开发MPLS-TP。具体是在哪个部分走了弯路？

  27. viaduct 于 2010-05-07 5:34 上午

    T-MPLS 和MPLS-TP在框架结构与功能模型上基本上是一脉相承的吧。但是，实现细节上基本上是没有办法兼容的，当然还有妥协的可能，比较很多关键性提案还是在或者还没有到工作组草案。
    IETF中Cisco（还有Juniper, Ericsson)还是力推在已有的IP/MPLS或者L2 MPLS上演进到MPLS-TP，如基于BFD的CV。
    中移动上的是T-MPLS
    另外，T-MPLS是ALU 光网络部门提出来的，而不是数通部门（7750)部门提的。

  28. fule 于 2010-05-08 5:32 上午

    一个城域网能写这么多文章，大部分网上能搜索到的信息，就不要在这里写了，弯曲的深度就是被这种文章搞浅了。最近真无聊，好多这样的文章，竟然还有入门教程之类的。首席也不管管，冗长、空洞的理论没深度，弯曲需要的是深度，特别是大家在网上学习不到的深度。细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节细节。。。。。。。。。。。。。。。。。。。。。。

  29. manjusri 于 2010-05-08 6:15 上午

    呵呵，自古就有踢馆者，亦本预料之中，毫不稀罕，也早已说明细节有限。
    只望能踢出一片精彩，创一套武艺，让诸同学叫好，别浪费了宝贵的山寨版佛山无影脚，也不枉了此类砖头文章无聊之外使湾友被获得的意外的宝玉价值，如有此效果，赞踢馆者。

    潜水数年看WEB，cyber人生趣事多，江湖何处不血雨，岂为细节烦恼活:)

  30. jjww 于 2010-05-09 5:03 上午

    我倒是觉得踢馆也未尝不可，不过踢馆就要拿出点真本事，这样踢完了大家都有提高，否则就是低水平踢馆，就像《叶问》里面那个踢馆的。

  31. 过客 于 2010-05-09 6:00 上午

    现在其实缺的就是把技术和市场都融会贯通并高瞻远瞩的通才，否则技术做的再好再专也就是工匠。

  32. 图书管理员 于 2010-05-09 5:38 下午

    manjusri这篇，个人觉得是弯曲评论最好的文章之一，读之收获多多。希望能继续！

  33. smoke 于 2010-06-26 10:25 上午

    私以为这接入设备中如何实现流量管理不是大事儿，现在的NP、TM都是极为powerful的，学术界相关的算法也层出不穷！
    倒是这种管理能力如何与上层应用相对应，迄今为止貌似都没有个体系或理论说法，大家只能笼统地说IPTV需要高带宽、VoIP需要低Jitter等等，或者是直接拿SLA说事儿，应该都没有触及根本啊。

  34. L&L 于 2010-11-10 10:56 下午

    做了几年Metro Ethernet，看了LZ文章收益匪浅，尤其是Qos这块。