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

作者 | 2010-05-10 19:34 | 类型 行业动感, 通讯产品 | 24条用户评论 »

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）

因为结构上定了上中下，只好把下写完，可能会比较鸡肋一点
补充一点TE的内容：TE因为比较复杂，所以TE LSP/TUNNEL在早期的capability是不大的，一般都建议用在CORE，而一些tier1的运营商CORE也很大，后来capability扩大了很多，但是如果要扩大到全网的TE，PE上问题未必很大，毕竟，并不需要和所有的PE都要全链接，但是P上可能有有些恐怖了，因为越是核心的P，越是有很多PE互联要经过它。所以仍然需要一些TE交换/分段PE/分层BGP等技术来解决扩展性的问题。在具体部署上，客户既希望能手动控制路由的选择，又要求能自动完成部署

曾经在这个大章的开始，痛贬C65/76，其实是有失公允，人在一定情绪和情势需求下的语言和文字虽然不免精彩，但也难免偏颇，对于C76/65就是，其实C76/65的成功是非常好的case，低价单板和高价单板共平台，在市场上有很多好的效果，一些实力有限的运营商，喜欢便宜的定西，不会一次就买一个功能很好的东西，虽然许多功能现在不用，但可能以后用。那么OK，给你便宜的单板，但后来当需要新功能的时候，只要合同没问题，那么需要物理更换成贵的单板，C合情合理很爽的又隔了一茬韭菜。类似的这种手段，在C的模式影响下，虽然大家也都在一定程度上使用，但还是C用得最娴熟老道

AL的新ME方案有了成功的开始并打下了良好的系统架构和方案架构，那么接下来的完善相对就比较容易了，下面简单介绍一些ME上用的技术
1、 ETH OAM问题：802.1ag(CFM)/802.3ah（EFM）/Y.1731，其中以Y.1731最全，但协议规定的配置方法比较复杂，尤其是802.1ag和Y.1731定义的MEP/MIP等等一系列概念最麻烦，如果完全按照协议规定的方式去做配置命令，本身就会带来一些OAM问题，所以实现的时候最好做UI上的简化处理
2、 环路保护问题：VPLS本身通过水平分割来解决环路问题，但是并不能阻止CE网络本身带来的路由环路问题为城域网的影响，尤其是在CE双归的时候，环路的几率就变大了，所以需要一些机制来处理，比如ALU的mac flapping（部分的解决），或者通过单独loop检查报文，再有就是STP in VPLS，把STP跑在VPLS里，感觉就很烦，总之这些解决方案都不是很好，最好在网络方案上避免环路，从这一点，个人不是很喜欢VPLS，纯VPLS带来的麻烦和好处可能是一样多
3、 MAC地址问题：VPLS带来大量的MAC地址，所以只好想办法解决，一个是拼命扩大MAC地址容量，比如到1M；再就是在某些场景下并不真正需要MAC学习，那么禁止VLAN内MAC学习，还有就是把PBB用在VPLS里，解决某些特殊场景下的MAC容量问题，和环路一样，这些方法都让人感觉不爽，以太网的一些基本问题，新ME的VPLS在实际网络应用中其实并没有很好的解决，所以个人不喜欢VPLS
4、 Reliability问题：SMARK LINK是思科的首创，TRUNK是标准协议，而MC-TRUNK是ALU的首创，本身其实并不复杂，SMART LINK可能是和MC-TRUNK类似的东西，但具体内容没看，目前更多的是MC-TRUNK
5、 slow protocol处理：慢协议其实就是native Ethernet上的L2协议簇，需要能灵活的定义那些透传，哪些终结
AL的在ME的是市场份额是不错的，但是在其整体的revenue中，应该是可以忽略的，AL最新在有一些做cluster向CORE扩展的roadmap，但整体上，还没有看到其全面进军数通市场的决心和策略，这一点，和华为最近的表现是有一定区别
另外提一点电力上网和cable上网，忽悠是不顶用的，电力的强弱电干扰问题和cable的共享网络结构问题，目前基本上没解，所以只有很少的电力和cable上网用户。
本来靓丽的AL新ME，用此章草草收尾，似乎预示着这个ME方案也该变一变了。
下一章：另类ME: PBT

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

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

雁过留声

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

  1. appleleaf 于 2010-05-10 9:20 下午

    电力上网应该就是传说中的用输电线上网，n年前听说国内有公司在做。
    这种技术即使能用，使用者心理上也有恐惧，呵呵。

  2. droplet 于 2010-05-10 11:23 下午

    精彩，弯曲需要这样文章。

  3. 数通人 于 2010-05-11 2:36 上午

    电力上网是很少，cable上网也很少？至少北美cable接入是主流，超过DSL和fiber的。CMTS每年也有超过1B的revenue，不能算很少吧。

  4. manjusri 于 2010-05-11 2:51 上午

    多谢数通人。北美为什么cable多，而DSL少？老的cable接入是带宽共享系统，北美怎么解决这个问题呢？

  5. yanbao 于 2010-05-11 9:03 上午

    系列文章视野很宽，最重要的是技术观点都是对的，尤其前面文章不乏精彩幽默之句，赞一个！

  6. HJ 于 2010-05-11 9:07 上午

    个人理解是因为美国这里cable带宽资源丰富，性价比高。Comcast宽带每个月30块，最低下载速度都在4M以上，最高下载速度可以达到12M。

    而AT&T的DSL服务，最高速度也就是6M，而每个月要收45块

    所谓cable带宽共享，如果你肯花本钱布足够多的CMTS的话，也不是问题。而美国的cable运营商是很赚钱的，这里有线电视的收入要比上网收入高得多。

  7. manjusri 于 2010-05-11 9:31 上午

    CMTS接入用的是同轴电缆，质量比电话用的双绞线好多了，并且使用不同的频率，解决和TV的干扰问题，当然，如果全部是IPTV了，就不需要保留TV的频段了，在每个building外需要做光纤改造，同轴电缆在所有频段都用上的情况下最大的带宽是多少？如果美国因为地广人稀，居民主要是以townhouse和villa为主的话，这种改造也许是比较容易，在人口密级的地区，如果一个building内用户过多，是不是每个用户的带宽就会有较大限制？

  8. HJ 于 2010-05-11 11:29 上午

    我觉得在美国很难找到人口密度的地方，至少在西边是这样的，整个湾区才700万人，只是上海的三分之一，而面积相当于20个上海…

  9. 瞎扯 于 2010-05-11 7:17 下午

    湾区没啥大城市，最大的San Jose才全美第十。南加人多些，特别是LA。

  10. IPQAM 于 2010-05-11 7:24 下午

    在广电网络里，最成熟的方案应该是使用pon做页面信息和遥控器信息回传，使用IPQAM做视频流的推送。
    既可以利用广电自己的城域网，利用pon带来广泛的入户5类线做宽带上网业务，也可以在使用IPQAM的情况下让下行的视频流不对接入网造成很大的带宽压力。

  11. 数通人 于 2010-05-11 10:52 下午

    PON能接入的用户数是很有限的（一般32个），而Cable一个FN可以接数百乃至数千用户。D3.0推出后，8chan绑定能有400Mbps带宽，16chan有800Mbps，下行能力和GEPON差别不大了。而且DOCSIS设计之初就是基于service的，所以有QOS的优势。
    至于共享带宽，接入设备都是oversubscribe的，只要用户数不要太多，问题还是不大的。
    理论上，同轴带宽是极高的，每个8Mhz频道在256QAM下有50Mbps，1Ghz频宽的理论带宽有近4Gbps，所以潜力还是很大的。
    现在COMCAST在推CMAP，COX也加入了，下一代的CMTS可能是个PON/CMTS/EQAM的混合体。
    至于北美Cable占主导，一来是cable的MSO都很强势，二来相比DSL，cable的经过HFC改造后，有传输距离远，信号质量好，传输带宽高，投资维护成本低的优势。
    有兴趣的可以去
    http://www.lightreading.com/lr-cable/
    看看。

  12. fpeking 于 2010-05-12 5:43 上午

    说白了cable是树形拓扑，和传统的dsl、电信网络还是不一样的。
    思科早在十几年前就在中国开始卖ubr7223/7246之类的，到底还是水土不服吧。
    美国加拿大这种地大人口少的，说到底和其他区域还是不同。

  13. 数通人 于 2010-05-12 6:46 上午

    其实cable的树形结构技术上是适合国内这类密集居住的环境的，每户都有CATV的同轴口，每幢楼只要拉一条光纤，建个FN，然后一栋大楼几百多户就share这800Mbps就行了。
    假如用EPON,要么配楼道交换机，要么就要拉多根光纤。
    而DSL也有和局端传输距离限制，带宽也不够。
    所以人口密集度类似的日本和韩国的CMTS的deploy也不少。
    国内主要是
    1.广电数通技术积累太少
    2.没有国家级的广电公司，无法和电信联通移动这类全国性的电信公司抗衡。现在刚开始做省一级网络整合，
    3.没有完善的骨干网络，国际国内出口带宽不够
    4.不提供语音业务

  14. manjusri 于 2010-05-12 10:16 上午

    所以cable接入，除了技术可行外，需要天时地利人和。

  15. JackBauer 于 2010-05-13 7:02 上午

    不是光进铜退吗？
    光纤比铜便宜。有些地方拆铜缆卖的钱就够上新设备了。省下的电费还没算呢。

  16. manjusri 于 2010-05-13 7:23 上午

    发达国家的人力成本很高，相比于线缆成本只是挖沟成本的领头

  17. fpeking 于 2010-05-14 4:12 上午

    就是因为树形下行共享带宽，在人口密度大，带宽低的情况下很难提供好的业务啊。用户增多的时候回传问题不好整。另外cable本身是为了单向网络设计的。
    现在的技术我不了解了。Docsis2.0/3.0以后。
    如果想和电信、网通一样提供2M/4M/8M到户，得布置多少CMTS啊。

  18. 数通人 于 2010-05-14 5:19 下午

    北美的cable都是HFC混合网络，局端到FN(fiber node)走的都是光纤，只有入户线是同轴而已。3.0以后的CMTS的端口密度很高了，随便一台C4/ubr10K都能带几万个用户。
    回传的确是个问题，ATDMA模式下，US所有频宽加一起也只有不到200Mbps。这个只能靠多建FN，或者以后都走IPTV，把US的频宽加大来解决了。

  19. 瞎扯 于 2010-05-17 11:05 上午

    国内以前埋的cable质量太差，带宽上不去。

  20. viaduct 于 2010-06-05 8:05 下午

    客客这篇很精辟呀，方方面面几乎都点到了，尤其是L2 VPN的弊端。 在IETF的L2VPN以及PWE3工作组目前有些提案试图解决或者优化部分问题

    “其实C76/65的成功是非常好的case，低价单板和高价单板共平台”类似的原则对于产品的前期总体设计与规划真的非常重要。

    另外，稍微补充一点， ALU的MC-TRUNK正式名称是MC-LAG，是基于802.3ad LAG协议而来，当时是无心插柳之作，可以与标准的LAG互通。除此之外，还有MC-APS。
    另外华为的设备也支持MC-LAG, MC-APS 以及Smart Link

  21. 路由甲 于 2010-06-09 7:36 上午

    SMARK LINK——据我了解这不是Cisco的创举，应该是当年的huawei-3com。

    mac-flapping从理论上来讲可以解决一切的二层环路问题，但是这个方案严重依赖MAC学习的性能，理论上来讲用NP来完成MAC学习实现mac-flapping难度太大，需要消耗过多的微码资源，因此一般来说MAC-flapping需要软件MAC学习来搞定。但是CPU学习MAC产生的麻烦比学习路由大得多，毕竟MAC学习是流触发行为，CPU学习性能较差。因此无法很好仍然无法很好解决MAC-flapping的问题。

    其实现在环路解决方案，主流仍然是STP,以及扩展出来的STP Over VPLS。

    MC-LAG，算是一个创举，但MC-LAG各种故障模式下的检测手段是一种挑战，有些情况还是比较麻烦。快速检测 + 联动才能真正解决问题。不能等待慢协议LACP自己去收敛吧。

    第一次接触到VPLS感觉其真是强大无比，当时感慨原来这个世界上有种技术可以将整个运营商网络变成一个无比硕大的交换机啊！想想很是搞笑。

    MAC学习从出生开始就不是一个电信级的东西，是为局域网而生。受人诟病在所难免。

    什么时候MAC学习完全可控，VPLS就几近完美了。

  22. southbayer 于 2010-08-08 5:42 下午

    楼主能不能讲讲这个–”尤其是802.1ag和Y.1731定义的MEP/MIP等等一系列概念最麻烦，如果完全按照协议规定的方式去做配置命令，本身就会带来一些OAM问题”. Thanks.

  23. manjusri 于 2010-08-08 5:52 下午

    MEP/MIP等是外部维护点和内部维护点的定义，还有MA和MD等概念，还有这些概念还要分层，不同层可能不能跨越，比如MAC ping。如果为了一些ETH OAM功能要先定义后这些框架，并且要定义正确才能保证ETH OAM功能能正确执行，运维人员是要晕的，所以实际实现，可能会有一定的变通

  24. river_stone 于 2010-11-03 11:48 下午

    感觉ALU 7750的成功是因为先提出了基于VPLS的ME方案，然后根据这个方案，完全量身定做了7750.L3到边缘肯定干不过C和J，以方案为基础，在方案之上设计自己的产品，这个营销手段很值得我们国内的厂商学习啊。