【陈怀临注：这篇“论山寨手机与Android联姻的技术基础”是我认为目前中文世界里对手机产业，特别是从技术的角度，对山寨机和Android分析得最好的文献。写作之严谨，功底之深厚，让人叹服。此中有真意，欲辩已忘言。由衷的感谢作者Sunny和Kan。读者可以下载全文论山寨手机与Android联姻的技术基础，也可以分章阅读：论山寨手机与Android】

（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说了，一般队列就在和接口或者用户关联，后面的几级都是调度组合，并不再分配单独的队列

4、  OAM

Native Ethernet本身实在是简单，也许因此很久都没人去关注OAM，在LAN的时候，尤其是在企业网，维护很简单，似乎也没什么大问题。而在电信网，OAM在传统网络中从协议到产品实现到网络设计，都占有自己的一席之地，即使到了AL新ME的时候，并没有立刻产生专门的的ETH OAM协议，但是因为新ME的核心是EoMPLS(Ethernet over MPLS/TE)，核心是让L2的的广播域通过VPLS站在在MPLS/TE的肩膀上（VLL可以看作VPLS的一种特例），从而获得MPLS VPN的隔离安全性和TE的可靠性，许多事情都不得不具有相反的两面，你获得的这些好处很难不付出代价，所以EoMPLS同时也把MPLS/TE复杂性带了进来，所以在没有ETH OAM标准前，AL就做了私有的MAC ping/tracert，并通过网管和VCCV ping （VPLS），MPLS ping/tracert等作了还不错的关联，可以说给基于EoMPLS的新ME一个初步的OAM解决方案，虽然不甚完美，但在AL的OAM特性及配套网管的包装下，能做的这个程度，虽然不能和ATM/SDH的OAM相媲美，但也算过得去，不致让这个短木板太短 

5、  H-QOS

这里不提新ME方案，是因为在AL7750前，没有产品做HQOS，QOS要做到什么程度，这个争议一直就没有停止过，而7750包装了5级H-QOS，my god, what are they doing?!直到现在，HQOS的商用并不广泛。IP QOS的研究应该早于2000年，但真正开始实现大概从2000年开始，QOS一直被认为是是否重要的事，这在非常重视质量的西方是没有疑问的，疑问在怎么做？谁来做？既然说到QOS，所以插入一些背景信息，以便理解。QOS的分类方法很多，按照时间或者怎么说，按照事先避孕或事后丸补救，划分两大类

（1）        事先避孕：术语叫CAC（Connection Admission Control），这从传统的电路交换通信时代就开始有了，这个时候QOS其实不是可选，而是MUST，因为是电路硬链接，在真正建立呼叫前，你必须通过协议把各段电路分配好了，然后才能告诉两端，OK，连好了，你们做吧，如果电路资源不足以建立这个链接，那么只好让两边等，当然，你们有YY的权利，这不可耻。所以不存在用户多了影响通话质量的问题，只是影响接通率，传统语音发达了几十年，有一整套监控质量的数据体系，什么呼损率了等等，我不是很熟，但一般来讲，只要接通了，就可以安全的做了，不比担心被抓，拥塞产生的语音通话质量问题，更多的是在VOIP刚开始流行的时候，这里面，万一资源用光了，有重要电话不能做，影响重大如何处理，不用担心，再挤的火车，也得留出一些首长专座以备不时之需，不是腐败，比如119，110等，你得给人家一直预留好资源，保持线路通畅吧。首长也一样重要，首长不舒畅，如何为人民服务？首长因得不到好的服务而生气冲动，作出错误决策，那要害多少人。在IP电信化的考虑中，这个技术是首先要被考虑的，在还没有MPLS TE的时候，就考虑利用IP HEADER中的一些保留bits来做拥塞信息的标记，通过负反馈机制告警汇聚接入点的设备，客满了，普通客人，就甭接了，但对VIP客户，当然要继续接，思科路由器还实现了一些RFC，后来这些研究也在MPLS/TE上做了一些，因为目前看不到什么实际意义，所以也忘了这些RFC的名字，技术象妓女，一旦过气，就人前冷落鞍马稀，懒得有人光顾了，人类有时候真是太不是东西了。IP的CAC，最主要的还是TE技术，现在还有一些类似的方案，比如从终端开始发起TE tunnel/LSP，从理论上当然是很好的，但是商用上有很多麻烦，TE的麻烦事很多，比如TE的带宽分配模型就很难记住，只记住一个名字最好玩的，叫俄罗斯木偶，但这个木偶是怎么工作的的，次次记，次次忘。因为TE需要路由协议扩展配合，还有各种麻烦，所以对大容量的TE tunnel/LSP的支持，也会很麻烦，也就意味着增加成本。如果传统的基于硬件电路独享CAC可以叫硬CAC，那么基于TE的CAC也可以叫做软CAC，TE的主要目的是把MPLS的面向连接的LSP提供预先资源保证（QOS保证），所以从IP(无连接)-MPLS(有链接)-TE(有保证的连接)，是IP技术发展的三大步走，但是因为IP电信化的FMC进程并没有那么快，而IP网络主要的traffic generator还是电信不会提供QOS保证的internet，所以TE的QOS技术基本上没有什么大的用武之地，商用部署有限，具体到部署，在一个线路上，一部分要做RSVP，一部分不做，是不好处理的，具体就不说了，包括DS-TE这些麻烦的东西，也就省了说了

（2）        IP QOS（QOS这部分是临时插进来的，未完待续）

内容简介：IPv6 address长度是128bit，Ipv4 address长度的32bit。就地址长度而言，扩大4倍。就容量而言，扩大了2^96倍。IPv6 Address Lookup对路由器设备的挑战有多大，是比IPv4难4倍还是难40倍？当前路由设备对IPv6 FIB查表的支持程度竟究如何？本文从三层转发最长匹配（LPM）原理出发，对比分析IPv6对路由器设备的带来的挑战难度。同时，根据LPM的实现原理，提出对现有设备IPv6 Address lookup及IPv6 FIB支持情况的测试用例的设计三原则：IPv6地址离散性、不同掩码长度，IPv6 Prefix有嵌套和分叉。同时，根据这三个原则对国内运营商选型测试中常用的两例IPv6测试进行分析，指出其优点改进方向。最后，提出一个满足上述四个原则的测试用例脚本。

1．迎接IPv6时代—Are the Boxes Ready?

全球的IPv4地址即将用完，尤其是中国的地址最为紧缺。另一方面，物联网概念的提出，对IP地址的需求成N倍增长。因此，IPv6地址即将走上舞台。中国政府已经将Ipv6的推进提到国家战略的高度。中国的各大运营商也对应Ipv6网络演进纷纷采取大动作，例如中国电信宣布成为全球首家认证通过的IPv6宽带接入运营商。

近年来，国内外各设备运营商纷纷对路由器设备展开IPv6 Address Lookup能力的测试，以期望这些设备能在未来的IPv6商用网络中发挥正常作用。测试的内容，主要考核点：IPv6 FIB容量、IPv6路由刷新性能、IPv6转发性能。

由于全世界IPv6并未大规模商用，IPv6路由分布和地址分配方案都存在较大变数。另一方面，IPv6地址容量大得足以给地球上每一粒沙子分配一个地址；而当前设备能处理的IPv6地址和前缀容量很有限，相对IPv6整个容量而言只能算沧海中的一小粟。因此，如何设计一个具备代表性的测试用例，以客观地评价设备对未来商用网络的支持情况，就变成一个非常重要的工作。

IPv6 address长度是128bit，Ipv4 address长度的32bit。就地址长度而言，扩大4倍。就容量而言，扩大了2^96倍。IPv6 Address Lookup对路由器设备的挑战有多大，是比IPv4难4倍还是难40倍？当前路由设备对IPv6 Address Lookup支持程度究竟如何？当前这方面的分析很少。

众所周知，三层转发查找远远比二层转发要难。难度差别来源于三层转发的一个本质特殊：最长匹配LPM。

2 路由查找LPM算法及实现

2.1 什么是最长匹配LPM？

最长匹配（Longest Prefix Match）是指如果一个IPv4地址与FIB表中的多个路由前缀(prefix)匹配，则以掩码长度最长的前缀为最终匹配结果。例如，一个路由器中有4条路由：

1)  1.*.*.*/8

2)  1.2.*.*/16

3)  1.2.3.*/24

4)  1.2.3.4/32

一个IPv4地址1.2.3.5在上述路由表中查找时，会与前3项前缀匹配上，与第4项匹配不上。匹配上的3个前缀中，1.2.3.*/24的掩码最长，所以它就是最长匹配结果。

为什么需求最长匹配？这是因为prefix有嵌套。为什么Prefix有嵌套？是因为IP地址的分配方式引起。其中一个例子是：一个Tier 1运营商申请到一个A类地址，它将其中划分一小块批发给Tier 2运营商; Tier 2运营又会继续再划出一小块，分配给Tier 3运营商。这样，就发生了“路由前缀嵌套”现象。

理论上，IPv4地址最多会嵌套24层（从8bit A类地址开始计算）；这就是说，在路由转发查表时，一个IPv4地址最多可能同时与24个前缀匹配上，此时设备要从24个前缀中选择一个最佳前缀（掩码最长为最佳）。

2.2 LPM最长匹配实现算法

二层MAC转发查表可以使用Hash算法（请见小师的Hash表介绍），三层IP转发查表要使用最长匹配LPM算法。前者是精确匹配，一个地址只会与转发表中一个表项比对上；后者却是，一个IP地址与转发表中的多个表项同时匹配命中，并在匹配命中的多个表项中选择一个最佳表项。正是这个多项匹配，造成LPM算法的实现难度远远大于Hash算法，这是常说三层转发难度高于二层转发的主要原因之一。例如，一个Broadcom的以太网单芯片，可以轻松支持64K MAC地址表，但IPv4转发表只有8K量级。

LPM算法的基本实现原理是用Tree-based search。即

1） 将众多路由前缀构造成一棵树（Tree）；

2） 当查找IP地址时，从树的根开始往下查找，每到一个分支点，就可以判断是否已经匹配上。如果已经匹配上，就先记录下来；

3） 继续往下走，直到没有进一步的匹配，或者已经到达树的顶端（即叶子）；

4） 在多个匹配中的节点中，选择掩码最长的。一般而言，越往下的节点，其掩码越长。

下图是一个1-bit binary trie树算法的原理图。大家看看，是否长得象一棵Orange Tree（倒过来）？

如果输入IP地址1111110000，则在该Tree中走法是：首先从根开始，命中P1；第1bit为1，往右走，命中P2；第2bit为1，再往右走; 第3bit为1，往右走，命中P5，第4bit为1，该往右走，但发现右边没有路了，故查找结束。此过程中，P5/P2/P1都命中，但P5掩码最长，故匹配结果为P5。

实际上，从P2到P5只需要一步就可以完成，而不是2步。这是因为路径上没有分叉，走向是唯一的，这叫SKIP。

在上述1-bit binary trie搜索树的原理基础上，可优化发展出Multi-bit trie，Treebimap等算法。这些算法在当前路由设备中比较常见。

2.3 用1bit Trie搜索树实现IPv6查表的难度分析

IPv4有32bit，故用它构造成一棵1-bit Trie树时，最高有32层。IPv6地址有128bit，故用它构造一棵1-bit Trie树时，最高有128层。

从Trie搜索树的形状可以看出，如果树的分支层数越多，则搜索难度越大。如果每次查1bit，32层高的IPv4搜索树，需要查找32次；128层高的IPv6搜索树，需要查找128次。

当前房地产是最热门话题，在此借用一下。IPv4查表之难度，就如修建一个32层的住宅楼；IPv6查表之难度，就如修建一座128层的摩天大楼。后者工作量和难度是前者的多少倍？应该不止4倍。

2.4 Multi-bit Trie算法

用1bit trie实现IPv6查表时，最坏情况下需要访问128次RAM。显然这在硬件实现上不太现实，故在NP的Data path中，一般采用其变种形式: Multi-bit trie算法。

Multi-bit Tree搜索树的原理，是在1bit trie的基础上，由每一步搜索1bit改为每一步搜索8bit（也可以是其它数字如4、或16）。这样，IPv4地址就分成8-8-8-8共4个8bit段，需要访问4次DDR2 SDRAM或RLDRAM。IPv6地址分成8-8-8…8-8共16个8bit段，需要访问16次DDR2 SDRAM或RLDRAM。Multi-bit Tri的算法示意图如下：

在上述基础上，如果树的某个搜索路径上没有分支（即路由没有重叠嵌套），则可用采用SKIP方法直接跳过，这样可以减少搜索次数。以IPv6为例，最好情况是所有路由都没有嵌套，访问2次-3次DRAM就能找到最终找到最终结果；最坏情况是路由有很多级嵌套发生，需要查找16次DRAM才能找到最终结果。

Multi-bit Trie算法的另一个特点是采用段页式管理DRAM，将片外DRAM划分成一个个Page，每个Page可以正好存放256条连续的路由（2^8=256）。如果路由不连续，则最坏情况一个Page只能放一条路由，此时容量大大减小。

2.5 Multi-bit Trie算法的特点

Multi-bit Tire算法(以及其派生算法如Tree bitmap, LC-trie)具备下述两个特点：

1） 路由容量不恒定。对+1、+2的连续路由容量最大，对随机产生的路由则容量严重变小；

2） 性能不恒定。对没有嵌套路由性能最好，对嵌套层数多的路由性能严重变差。这里的性能包括数据平面转发性能和控制平面刷新性能，因为路由插入时也需要软件查FIB表。

如果是让设备商推荐测试方法，则它一定会聪明地选择下述路由来测试设备：使用+1递增路由以使容量最大；使用不嵌套路由以使转发和刷新性能最好。

3. IPv6 Address Lookup测试用例设计原则

3.1 三个测试原则

由于IPv6 Address Lookup的难度比IPv4高4倍以上，那么使用什么的用例才能充分检验Router设备的查表性能、路由刷新性能、

根据Trie搜索树的原理，可以归纳出下述测试用例设计：

1）  IPv6地址离散性

IPv6地址容量巨大有如浩瀚之海洋，故IPv6前缀的选择尽量离散，以求有更大的代表性；

2）  不同掩码长度

同IPv4的一样，IPv6地址也采用了层次化的分配方式，而且未来的层次化是否会出现CIDR这样的更细粒度的层次化还未可知。这导致需要不同的IPv6前缀长度。所以，在测试中尽量多采用各种前缀长度来测试，以应付未来可能出现的IPv6地址分配需求。

3）  IPv6 Prefix有嵌套和分叉

这其实是层次化地址分配方式造成的必然结果。从LPM算法的实现原理看，Prefix嵌套层次越多，则构造出的树层高越高，搜索难度也就越大。所以，在测试用例中一定要考虑充分的路由嵌套。

如果站在搜索树的角度，上述原则可保证由IPv6 prefix构造成一棵枝盛叶茂的参天大树；

如果站在个房子的视角，上述原则可保证由IPv6 prefix构造成一座摩天大楼；

3.2 两则IPv6 FIB测试用例分析

根据上述三原则，下面选择国内大运营商用过的二个测试用例进行分析：

1） 用例A：几种IPv6前缀长度，+1递增路由

a)      不同的前缀长度的路由数量按照一定的比例设置；

b)     同一个前缀长度内的路由+1递增

c)      共50万IPv6路由

d)     路由分布如下所示：

2）用例B：随机前缀，前缀长度可配

在测试仪中，使用随机函数产生IPv6路由前缀。路由前缀的长度可配置

上述两个测试用例的共同最大不足点，就是路由prefix没有嵌套，在查找中始终只会匹配一个表项，而不会同时命中多个表项，失去了LPM最长匹配查表的本质特征。按三原则进行具体分析如下：

。

如果将A的前缀分布构建成一棵树，其形状比奇特，树干上没有分支，树梢上挂了很多果实。很象一株椰子树，是吧？这种树的搜索很简单，以Multi-bit trie为例，只需要访2-3次外部RLDRAM：第一次，从几棵树中选中一棵，并直接到达树梢（因为树干没有任何分叉）；第二步，从树梢的成千上万个果实中摘取一个。第二步是比较简单的，接近于线性查表，这是因为路由前缀全部是+1递增，很紧凑地放在一起，且没有多项同时匹配的问题。

显然，测试用例A路由没有很好地考察路由设备的数据平面的查表性能; 不能很好地测试路由设备控制平面的刷新性能，因为在插入新路由时控制平面也需要查RIB/FIB表。IPv6查表理论上需要访问16次片外RLDRAM（用8-bit Multi-bit Trie），而上述路由分布只需要约3次RLDRAM访问。

测试用例A的另一个问题是：它不能客观检测设备的FIB极限容量，它测试的是设备的best case下的能力，而不是worst case下的能力。这是因为设备在实现Search Tree算法时，为了实现方便，需要采用“段页式方法”将片外的DDR2 SDRAM或RLDRAM划分成很多Page，每个Page可放下256条连续的路由。如果路由是离散的，则最坏情况下一个Page只能放1条路由。

测试用例B相对于用例A而言，有很大的改进，这是因为它的路由分布更离散，检测的FIB容量比较接近于Worst case。

4. IPv6 FIB lookup测试用例脚本参考

我们希望测试用例的Prefix构造出一棵参天的Orange Tree，有很多树叉与分支，而不是树干象光棍一样的椰子树；我们希望测试用例的Prefix构造出一座摩天大楼，而不是只有一层楼高的联排或别墅。这样，才能测试设备在Worst Case情况下的FIB容量、路由刷新性能、数据平面查表转发性能。

根据测试用例三原则，一个测试脚本用例如下：

#define MaxMaskLen = 64   //需要测试的最大路由掩码长度，取值24-128

#define Step = 8          //掩码变化步进值

do{

P = rand(128bit IPv6单播Address）  //产生一个随机地址（原则一：离散性）

if ( P/24 在FIB中不存在）          //去掉重复路由

{

for( j=24; j<=MaxMaskLen; j++=Step)   //（原则二：多种掩码长度）

{

INSERT FIB（P/j);    //表示插入值为P前缀长度为j的路由（原则三：散成嵌套）

Q = P + 1<<(128-j);

INSERT FIB（Q/j );   //表示插入值为Q前缀长度为j的路由（原则三：散成分支）

}

}

}while (FIBv6容量未满）

上述算法只是个参考例子，实际使用时还可以进一步优化。

作者注: 这里基本是high一些的分析,想看技术实现细一点的原理的,在这里会失望了,因为我没去做这部分工作,这和个人的工作内容和相应能力及精力有关,当然如果有湾友能补充相应内容,不胜感激

2、  系统架构和NSR/ISSU（HA）

7750的硬件结构，从单板到chassis，虽不能说是非常优秀，但无疑是比较成功的，从紧凑的三维到很高端口密度以及散热电源，比如其最早提供的40*1GE的单板，就用了特殊的PHY使面板可以布下如此高密度的以太口，7750的设计，出奇之处本身都是为了方案，并非为了吉尼斯，因为7750无疑是一款比较昂贵的产品，因为其转发芯片，大容量查表器和TCAM，支持H-QOS的TM等在当时都属于贵族用品，所以成本要高于C76，欧洲人和美国人的差异就在这里J，但是市场没人理你是否内部用了金子还是铜子，客户在冷漠的时候只关心你要我掏多少银子，你是有足够理性的独立行为能力人，你跳不跳楼不应该由我来负责，那用什么来分担这么好的产品的成本，在当时，10G端口大家都贵，并且主要作为收敛后的上行，从方案上也不合适做高密度收敛板，所以高密的GE口收敛板是非常好的idea，AL不是疯子。

7750的软件架构从外部看也是很成功的，主要有以下几点

（1）        其扩展性好，可以很容易的做到一年一个大R版本，年内可能还有几个个RX.x版本，这在以多业务下的IP/MPLS TE为核心的路由器产品，不是那么容易做到的，当然AL没有思科那么大的历史包袱和产品系列，这个可能会更容易，但那么多新模块代码，项目开发本身并不是很难，但是如何快速的和软件平台做好集成，推出商用版本，这就需要系统架构设计要好，当然没有那么完美的东西，毕竟是新产品平台，售后出现问题多一些也是难免的，大家都如此

（2）        可靠性：AL可能是第一个做了NSR和ISSU，JUNIPER可能也很快做到了。NSR用于主MCU故障时，系统业务不会有任何中断，基本原理就是把所有控制层的session都热备了，使邻居感受不到这个故障，这个和NSF不同，NSF也是要达到这个目的，但是邻居是能感受这个故障的，所以要提前通知邻居，我故障了，别挂电话，我方便一下很快，回来继续聊。另外一个是系统升级的时候，也是业务不中断，具体原理有点复杂，不多说了，因为我不大了解具体实现。但是需要指出的是，AL作为商人，买东西要吹个150%是正常现象，比如NSR，不是所有情况都能NSR，是有条件的，ISSU更是有很多限制，最致命的是，好像升级后24小时还是2小时内记不得了，要重启一下，知道这个隐埋的bomb后，好想笑，不是嘲笑，就是好笑。笑归笑，AL市场包装后的忽悠效果还是很可观的

3、  NSM

NSM在许多国内产商一向不甚重视，而这里放在系统架构后面的第一副领导的位置，可见发达国家市场和发展中国家的不同，也可见AL新ME方案的精心设计，这里有两个原因

（1）        发达国家人力成本昂贵，尤其是IP工程师，所以好的E2E业务的网管对TCO saving非常重要

（2）        多业务的IP/MPLS TE路由器，AL叫SR，系统配置复杂，如果没有好的NSM，这个运维的缺点就会难以掩盖

（3）        思科没有运营山级的ME方案的E2E网管，运营商本身就觉得路由器复杂，没有好的网管就更复杂了，当然思科不是没有能力做这个事，许多网络全网都是思科设备，思科做好网管不是更容易吗？可问题也就出在这里，既然我近乎垄断了，我还费劲巴力的做好网管，给谁省钱？你们和我思科一起玩培训不是让我既能赚钱，还能培养客户的loyalty吗？有何必自断财路呢。这种策略下，以致后来个别熟悉思科产品CLI的用户，不需要GUI的NSM网管，就喜欢CLI

AL是充分分析了市场形势，花了大力气完成SAM6520网管产品（也许名字我记错了），和SR一样，叫SM，业务管理，这些可是AL新ME方案innovation的主要精华之一。并且AL网管的报价方式也不错，把网管价格直接报在端口中，而不是按照网管能管理的节点数来报价，可见AL的报价方式更精细

AL的ME新网管，给似乎已经沉寂了几年的IP网管产品注入了一股新风和活力，重新激活了这部分网管市场，带动了运营商IP网络网管市场的许多供应商的新产品开发动力，AL的新网管对这里的贡献功不可没

这个系列的开头说了是为一个讨论why L3的同事的邮件而起，后来总是太ALU的新ME，似乎新ME成了主角，也只好强赶鸭子上架，所以这只烤鸭很可能是只肯德鸡，而不是前门的全聚德 

VLAN/QINQ虽然很强，但还是不能是以太网拍拖传统ME方案，比如scalability问题，MAC容量就很麻烦，以致大家在实践中要求在一些场景下，比如傻瓜型管道业务，不要学习MAC，直接根据VLAN转发，以彻底根除MAC学习和容量带来的麻烦。其他的安全/QOS/OAM/NSM等大规模MAN网络需要的技术，传统ME还是没有很好的解决方案，时代呼唤英雄，思科在城域网络上的76/65的传统L3/L2方案固步自封，华为跟班思科还难以成器，AL在欧洲挺身而出，揭竿而起，开创了ME的新时代 

AL能成功的推出以7750为中心的新ME也是一蹴而就的，早在2000年，AL就成和华为一起使用IBM的当时业界最好的NP芯片ranier做IP产品，据说当时华为迅速推出NE40/80系列，成功的和思科拉到最近距离，而AL似乎不太成功。但是后面的故事，确是又反了过来，AL的IP部门在成功收购了谷里的NP公司timtra后，即薄厚发，一举推出系列产品配合新ME方案，从欧洲市场开始，在ME领域开始势如破竹，而华为，在和港湾的PK惨胜中，把IP产品的错误持续到10G，本来就是follow策略，在全力纠正10G的错误的时候，即使没有这么多据都错误都未必创造新ME方案，何况当时，还哪有心情去考虑新ME，当AL的新ME 7750出来的时候，有些人立刻又蒙了。 

在细说AL新ME的特点前，不得不说说思科老ME产品和方案的特点：

在没有AL7750新ME前，在传统IP城域网方案里，C76/65真的是最完美的孪生兄弟，同时在IDC和企业网市场也是霸主，太牛了，整个产品既有集中式转发，也有分布式转发，还交融许多75系列的接口卡，L2性能很好，L3/MPLS也支持，各种核心引擎可供选择和升级，真个一个万花筒，那是革命一块砖，哪里需要哪里搬，美

C76/65的最美好的青春持续超过了5年，知道AL7750青年才俊重磅出山，迅速在ME市场扩容，然后华为NE40E系列的不断发力，C76/65终于被年老珠黄，满身雀斑，暴露无遗

1、  Packet based的交换网，还容量小

2、  集中式的L3/MPLS转发引擎，性能和功能都老落伍了

3、  升级新的主流特性就得换板，比如L2到L3，不能软件搞定

4、  组播能力也差，不能做大量的IPTV

5、  C65/76同门不同价

6、  TDM/ADM等FMC特性支持差

7、  路由表容量/MAC表容量/TE容量/LSP容量/PW容量/VPLS容量等都和对手不再一个档次

….

这样一个烂柯，居然成为选美冠军近10年，是思科垄断的好，还是看客眼光拙，还是其他美女太不争气。不是金子总要收光的，美女也要夕阳红，除非天山童姥

因为是初次向弯曲投稿， 首先，做一下自我介绍，我叫吴朱华（ike），北大硕士，PMP，前IBM中国研究院云环境管理项目首席工程师，现专注于下一代云计算系统的研发工作。本系列是关于Cisco Unified Computing System的一些研究和探索，以及对数据中心网络，存储，服务器和虚拟化之间融合的一些看法和思考，希望大家能喜欢。假如大家有什么意见的话，尽管拍！非常期待大家的comments！

云计算的简介

昨天当我看到邓侃的那篇《云里雾里云计算》感到非常欣喜，因为云计算是继大型机，PC，互联网之后的下一个Wave，无论是对国家的发展还是对整个世界的进步都是极为关键的，如果能多一个人来普及，将会对云计算更有益处。

但是我也发觉了还是有一些同学对云计算存在一些误解，无论是在弯曲还是在其他地方，都觉得云计算就是扯谈，用英文说，就是BS。我个人觉得这种情况的发生主要是由于他们没有读过云计算的开山之作，也就是Nicholas Carr的《The Big Switch》，中文名为《IT不再重要》。这本书对电力的发展史进行了非常细致的描述，并将其与IT发展进行了深刻的对比，强有力地证明了IT技术将会像电力一样成为公用事业，让人们能随时接入和按需使用。

我在这里对书的内容稍微简述一下：刚开始因为直流电传输距离短的原因，所以发电机成为很多需要电力的企业和个人的选择，但是由于能长距离传输的交流电技术的不断成熟，使得英萨尔（Insull）的关于电厂的想法成为了现实，之后由于电厂的规模效益不断地增大，使得电力的价格也随之降低，而且使用起来更方便，最后，电厂模式成为了主流。仔细想来，IT技术的发展和电力技术的发展是何等的相似，发电机好比现在的机房，交流电技术好比现在的互联网，而电厂和云计算中心更是一个模子刻出来的。

对我而言，其实云计算这个想法非常简单，它强调的就是两个东西：方便的用户体验和低廉的成本。方便的用户体验指的是人们能够非常方便地使用和搭建信息服务，而低廉的成本指的是使用和搭建信息服务的相关成本比较低。

云计算主要分为三层（NIST定义），

1. Software as a service，软件即服务，简称SaaS。
2. Platform as a service，平台即服务，简称PaaS。
3. Infrastructure as a service， 基础设施即服务，简称IaaS。

将来有机会会对这三层进行深入分析。

什么是UCS？

谈到数据中心，大家肯定会想到一个集中了密密麻麻的网线，繁多的服务器和庞大的存储的复杂体，而且由于虚拟化技术的引入，使数据中心的复杂度进一步上升，虽然它能起到整合服务器的作用。下图就说明了数据中心有多复杂！

面对这种严峻的情况，Cisco在2009年初，推出了Unified Computing System，简称UCS。它是下一代数据中心平台，在一个紧密结合的系统中整合了计算、网络、存储与虚拟化功能，旨在降低总体拥有成本（TCO），同时提高业务灵活性。该系统包含一个低延时无丢包万兆以太网统一网络阵列，以及多台企业级x86架构刀片服务器等设备。它是一个集成的可扩展多机箱平台，并在一个统一的管理域中管理所有资源。

在云计算体系中，UCS系统是处于IaaS这层，可以在其上安装VMWare vSphere来支撑多达几千台虚拟机的运行，同时简化了数据中心的建设和运营的复杂度。

本篇结束，下篇将关注UCS的架构。

最后，感谢国家，感谢于再清同学，感谢CCAV，感谢以首席为代表的弯曲同仁，因为弯曲论坛给了我很多的帮助，特别是在我不太擅长的通信和网络这两方面。

有一次去开会，台上的人在讲云计算。我问身边的听众，“听懂了吗？感觉如何？”

听众答，“云里雾里的，感觉特神秘。”

我说，“这说明讲员讲得好。有没有注意到寺庙里的气氛也很神秘？不神秘，就没有崇拜。不崇拜，你怎么肯掏钱买香火？”

【1】云计算要解决什么问题？

1997年，Google的两位创始人，Larry Page和Sergey Brin，找Andy Bechtolsheim募集投资。

Andy问，“你们打算做什么？”

Larry和Sergey答，“打算把互联网上所有网页都下载，然后建一个搜索引擎。”

Andy说，”把互联网上所有网页统统下载？！需要多大空间？几个Giga不行吧，几个Tera也不行吧，几个Peta，几个Zetta？。。。嗯，我看几个Googol也许才能撑得住。知道Googol吗？就是10的100次方，就是一个1后面拖100个0！”

估计是Andy觉得这个项目不太靠谱，所以给的钱不多，只有1百万美元。只有这么一点钱，如果去买高端的存储系统，显然是不够的。走投无路的情况下，Larry和Sergey决定用PC之类便宜的机器，组建一个机器集群。先凑合着用，等以后数据量增加以后，再购买更多的PCs，扩大集群的容量。

这个故事的真实性，有待考证。但是从中可以看到Google集群，也就是Google云计算的核心，要解决的四个问题。

1. 大规模的存储空间，用于存储海量的数据。

2. 随着业务的发展，新的数据源源不断地增加，存储空间需要相应扩大。用术语讲，这叫可扩展性，scalability。

3. 系统的硬件设备必须便宜，通常使用大宗产品（commodity），譬如PC，或者价格便宜，中等性能的Dell server。

4. 便宜的硬件设备，经常死机。所以在设计这个集群的时候，必须保证不能因为个别机器死机，导致整个系统的崩溃。也就是系统的稳定性要好，reliability。