中国新飞豹战机脱胎换骨 据称已使用隐身涂料_新浪军事_新浪网

中国新飞豹战机脱胎换骨 据称已使用隐身涂料_新浪军事_新浪网

当时，“飞豹”的研制经费只相当于1亿美元，同西方国家研制一个机型至少需几十亿甚至上百亿美元不可同日而语。限于条件，许多试验是在露天完成，使用手摇 计算机和计算尺处理大量数据，绘图过程完全依赖手工，不免拖长了时间。1988年12月14日，该机首飞成功，空军却认为此机型在国际上已经落后，于 1992年表态将不予采购，只剩下海军航空兵独立支撑。90年代后期中国引进了俄罗斯苏一30战斗机，该型机除具备苏一27的空中格斗性能外，还有良好的 对地攻击和较大的载弹量，许多人认为其完全可以替代“飞豹”。不过海军航空兵考虑到苏一30价格太高不能大量采购，另外中国必须推出自己研制的歼轰机而不 能完全走外购之路，终于把这一项目坚持完成。

【原创】战场上的蒲公英（二十九）

【原创】战场上的蒲公英（二十九）

蔡智诚他们赶到柳堤圈（今河南省夏邑县和虞城县之间）的时候，共军主力已经撤退了。伞兵们四处搜寻只找到百十个掉队的新兵。这些新兵穿着新棉袄、手上没有枪，一人扛着一根枣木扁担，不象是打仗的倒象是一伙送军粮的挑夫队。
虽然没有武器，但共军新兵的思想觉悟却不低。国军“政治指导室”给他们做“精神训话”，几个俘虏居然反过来搞鼓动宣传，他们私底下扯着罗华拉家常：“朋友，看你也是个苦出身。咱们天下穷人是一家，不要为地主老财去卖命……”。罗华从小就在船上拉纤，风吹雨打弄得满脸沧桑，看上去确实是一副苦大仇深的模样。可他这人阶级觉悟太低，最不喜欢别人说他穷，被揭了老底之后就有些恼羞成怒：“去去去！穷在闹市无人问，富在深山有远亲。老子才不和你们一家人”。
那时候，共产党正在军队里开展“三查”“诉苦”运动，也就是查工作、查思想、查阶级，通过“诉苦追根”查出阶级根源，然后让“剥削阶级思想向无产阶级思想投降”，大家再重新站队，全都站到了劳动人民一边……国军军官对这种做法虽有耳闻，但却闹不清是怎么回事，于是就组织共军俘虏进行现场表演，让国民党的政治指导员和政治协理员在边上观摩旁听。
诉苦会的效果真是惊心动魄，震得国军将士目瞪口呆，大家都说共产党的这一招实在太厉害了。
可厉害归厉害，最后还必须批判才行，这讲评的任务就落到了指导员的头上。于是蔡智诚就指出：共军诉苦的实质不是“哭穷”而是“均富”，这是长毛造反的老招数，共军把贫穷的仇恨都推到有钱人的身上，把暴力土改当成了让懒人致富的捷径，这分明属于违背社会传统道德的行为……蔡指导员在台上讲得口干舌燥，底下的听众却应声寥寥，因为明摆着的情况是共产党那边欢欣鼓舞、国民党这边怨声载道——不能给老百姓分地分粮食，扯什么传统道德都无济于事。
罗华被解放军的诉苦代表搞得眼泪汪汪，光顾着哭了，结果共产党的宣传没弄懂、国民党的道理也没听清。他懵懵懂懂地问指导员：“老蔡啊，我祖上也是有房子有地的，后来被我爷爷耍钱输光了，你说这赌博到底算不算是剥削？”
“……”，蔡智诚也不知该怎么回答才好。

其实，解放军战士并没有钢筋铁骨，几个月来，他们一直是以顽强的意志和牺牲的精神在支撑着自己坚持战斗。先前，苏北兵团不断攻击苏中和苏南地区是为了吸引 国民党军主力东移、配合刘邓大军转出大别山（晋冀鲁豫野战军主力于48年3月转出大别山，5月份在洛阳成立了以刘伯承为司令员、邓小平为政委的中原军 区），而现在他们再度不顾疲倦地发起新的攻势，是为了破坏陇海铁路东段交通，迟滞国民党军西援进程、配合即将展开的豫东战役——蔡智诚他们当时并不知道共 军的战略意图，但即使是知道了，他们也无法理解共产党人的团结协作精神，更无法理解解放军的那种为了全局而甘愿牺牲自己的高度觉悟。

应对"最困难的一年"_网易财经

应对"最困难的一年"_网易财经

因此说,中国式通胀是纠正要素价格偏低以促进经济转型而必然发生的,其主要负作用是,过去依靠包括低工资等要素竞争力带来的大量财富主要聚集在企业和财政 之手,因此,用通胀和名义汇率升值来纠正汇率带来的内外失衡,需要更多地依赖内需时,占人口多数的普通百姓会因通胀进一步削弱其消费能力,并承受低工资积累和高通胀剥夺的不公待遇。

《我与达赖喇嘛的四次见面》（之八）达赖喇嘛面对天方夜谭的�

《我与达赖喇嘛的四次见面》（之八）达赖喇嘛面对天方夜谭的�
其实在见达赖喇嘛的过程中，有句话一直在我嘴边没说出口——如果采用递进民主制，即使西藏独立的目标都可以实现。那只要具备一个前提——绝大多数西藏人都 坚决要求独立。我没讲这句话，是因为感觉似乎真有点“叛国”味道了。不过平心而论，我跟达赖喇嘛讲的一切，目的都在于把西藏留在中国，而不是要让西藏独 立。我为达赖喇嘛所做的任何“出谋划策”，也都是以“西藏留在中国”为我们的共同基础。只不过我认为能够使西藏最终留在中国的，不是镇压，而是给西藏自由 与自主。同时我也坚信这一点，如果中国方面能主动允许西藏实行递进民主制，西藏独立的前提就不会存在。因为实行了递进民主制的西藏已经实现高度自治，绝大 多数西藏人就不会再去要求独立。而且递进民主制产生的西藏领导人将是有高度理性的，他们比谁都清楚追求独立要付出的代价是西藏无法承受的。关于这方面的论 证，我已写在《递进民主制与代议民主制：解决西藏问题的方法比较》一文中。

不过与达赖喇嘛谈了这么多，总该找出一些可以沟通的内容，产生一些作用吧？总结下来，可以谈的有三点：一是达赖喇嘛走“中间道路”的诚意，可以用我的近距 离观察，反驳把“中间道路”描绘成阴谋的说法；二是达赖喇嘛的健康状况，让那些认定他已身心日衰，力图把西藏问题拖到他死后的人重新考虑一下时间表；三是 达赖喇嘛在西方社会的威望，把这样的人放在敌对位置，等于是把自己放在西方公众的对立面。在阐明这三点的基础上，再谈达赖喇嘛是解决西藏问题的钥匙，只有 同达赖喇嘛达成解决西藏问题的方案，对中国才是一劳永逸。这样去谈，能不能对决策者产生一点影响呢？

《我与达赖喇嘛的四次见面》（之七）达赖喇嘛百分之百赞成

《我与达赖喇嘛的四次见面》（之七）达赖喇嘛百分之百赞成

还有，达赖喇嘛提出将来西藏实行的制度既不是社会主义制度，也不是资本主义制度。我欣赏这种理念。然而具体而言，那到底是一个什么样制度？仅有理念 还不够，需要有具体的设计和细节描述。西藏流亡政府公布过未来西藏的政治制度，但没有未来西藏的经济制度。社会主义制度和资本主义制度主要从经济上区分， 如果没有形成具体制度，许多障碍就无法克服。西藏境内目前仍有大批被称为“翻身农奴”的人，不能不正视他们的存在。他们一直疑虑高度自治的西藏会不会要他 们把土地重新交还给过去的领主？虽然达赖喇嘛一再强调西藏不会回到旧制度，但是如果一天不明确新制度是什么，“翻身农奴”们就不会停止猜疑和担忧。 www.6park.com

还 有共产党在西藏留下的遗产，几十年时间产生出的一大批同共产党休戚与共的藏人，如党政官员、国有企事业职工、退休干部等既得利益者，他们的各个方面、甚至 能否生存下去都和现体制密不可分。如果西藏实行高度自治，现体制退出西藏社会，这部分人会发生何种变化？能不能保证生存？怎么处理现体制留下的“国有单 位”？能不能消化十多万集中于城市的“干部职工”？如何转化他们？方案是什么？步骤是什么？……这一切都需要进行系统研究和周密安排，设计出平衡的配套措 施。大而化之的笼统概念是远远不够的。所谓“革命是人民的盛大节日”， 人们在变革过程当中可以欢欣鼓舞，什么事都好说，问题往往发生在变革实现的第二天。一旦西藏真开始高度自治，所有责任就再无他人承担，全得靠自己。每天面 对十分具体的柴米油盐，缺一点都不行，但流亡西藏现在不要说做好这些准备，连细致的思考都不是很多。 www.6park.com

我 的结论是，要跳出只有达赖喇嘛一人打“中间道路”旗帜的局面，需要思考和研究相应的方案。北京现在指责“中间道路”是一种欺骗手法，先搞半独立，再作为跳 板走向独立。反驳这种指责，最好的方式就是把“中间道路”具体化，而不是像一些流亡藏人的简单回答——达赖喇嘛做了如此妥协你们还不接受，我们只有继续争 取独立！那正好会被北京用来证明“中间道路”只是谈判手腕和独立跳板。而如果能把“中间道路”具体化，拿出可操作的方案，就比较容易向汉人证实“中间道 路”的真诚，是目标而非手段。汉人多疑，是因为历史上受过的欺骗太多，习惯了猜忌。他们不会像藏人一样，对达赖喇嘛的话视为一言九鼎，而是不信口头允诺， 只有看到实际作为，眼见为实，才可能逐步消除他们的猜忌。 www.6park.com

听 到这里，达赖喇嘛表示说他百分之百的赞成我的话。不过我知道不要为他说的“百分之百”得意，因为那是他的口头禅。我见过好几个人描述他们与达赖喇嘛的对 话，都得到过达赖喇嘛“百分之百”的同意或赞成。达赖喇嘛接着开始对我具体地解释“中间道路”的内容。可能是我没有说明白。我提出那些问题不是针对问题本 身，是为举例说明“中间道路”没有进入到具体化。他似乎是认为我想得到对那些问题的具体回答，话题便转到那上。

《我与达赖喇嘛的四次见面》（之三）达赖喇嘛说“我不反共！�

《我与达赖喇嘛的四次见面》（之三）达赖喇嘛说“我不反共！�

达赖喇嘛很会说话。他每天在各种场合说话，练出来了。他的谈话逻辑清楚，一环扣一环，用词既准确又简单。此前听了解情况的人说过，达赖喇嘛以往跟汉 人见面，难得有深入交谈。他有时爱回顾历史，说到五十年代西藏怎么回事，如何见毛泽东等，那些汉人的兴趣就集中到那上面，几个问答下来，时间也就差不多 了，结果那样的见面往往是礼仪性质大于实际意义。因此我的打算是不向他提问题，也不进行采访。限于我能和他交谈的时间，实在问不了多少问题，也采访不出来 什么，莫不如尽可能地用来说我想跟他说的话。LD之所以花了那么多力气安排我和他见面，就是希望我能跟他讲一些他从别人那里听不到的话。 www.6park.com

这 次见面限定时间只有半个小时，其中用于翻译就需要一半时间，因此在达赖喇嘛讲话之外，我没有几分钟可以说话。我对达赖喇嘛说的主要内容是，如果把西藏视为 中国的一部分，那么我也把达赖喇嘛视为中国的领袖，而不单单是西藏的领袖。西藏问题不是一个单独的西藏问题，它是整个中国问题的一部分。在中国问题没有解 决的前提下，西藏问题不可能单独获得解决。只有先把中国从一个专制社会变成一个多元化的开放社会，西藏问题才有可能真正解决。因此我说，希望达赖喇嘛不是 只把力量放在解决西藏问题上，还应该在解决中国的问题上发挥作用。

技术前沿——电信级以太网的三大主流技术 - 华为

技术前沿——电信级以太网的三大主流技术 - 华为

技术前沿——电信级以太网的三大主流技术

第12期 光网专刊

文档下载(930 KB)

文/李喜祥

　　电信级以太网（CE）的概念一经MEF提出，就引起业界的普遍关注。经过一年多沸沸扬扬的争论，CE最终定位于在城域网络中解决IP、以太网、TDM等业务的传送问题。但是究竟何为CE？TMPLS、PBT、PVT又是什么样的技术？运营商又该如何做出正确的选择？


CE概念之辩

　　从2005年2月17日MEF举办第一次CEWC（Carrier Ethernet World Congress），到2005年9月13 日公布业界第一次CE认证，再到今日CE市场的启动，MEF在通信产业界掀起了一股CE旋风，席卷了从技术、标准到产品、市场，从接入、汇聚到核心网络等 不同层面的多个领域，一时间业界津津乐道于此。

　　然而CE并不是一个特定的技术术语，不专指某种网络技术，也不排斥某种网络技术。按照MEF定义，它包括5个方面的内容：标准化的业务（以太网透明专 线、虚拟专线、虚拟局域网）；可扩展性（各种以太网业务、10万条以上的业务规模、从1M到10GE）；可靠性（用户无感知的故障恢复、低于50ms的保 护倒换）；QoS（端到端有保障的业务性能）；电信级网络管理（快速业务建立、OAM、用户网络管理）。但这并不是全部。

　　从运营商角度看，CE技术是指以太网技术由企业网应用到电信网的技术；从网络层次角度看，也是以太网由局域网应用到城域网、广域网的技术。传统的电信 网络具有较强的可扩展性、层次性、安全性、容错性、可区分服务、可操作维护性、可管理性和可控制性，比如ATM网络、SDH网络。近年来Internet 网络技术的发展，更是给电信网络引入了流量工程的机制，并从MPLS和ASON引入了控制平面的概念。目前在各标准组织中，数据平面、控制平面、管理平面 是对网络架构比较清晰的模型划分。

　　MEF推出的CE认证以网络能够支持的以太网业务类型（比如E-Line、E-LAN）和业务所能够达到的性能（比如一定的时延、抖动、丢包率）为衡 量标准，并不限定某种特定的以太网技术方案。这样在实际部署中CE的传送层，即以太网业务的服务层的技术选择可以有多种。目前出现的CE传送层技术有 SDH/Sonet、OTN、MPLS/IP、Ethernet、WDM、ATM等，各自有其数据交叉/交换、OAM、QoS等机制。CE的管理平面和控 制平面，根据电信网络的要求，对不同的以太网业务的传送技术将会保持一致的规格。相应的标准正在ITU-T和IETF进行研究。

　　当前有三种主要的CE技术进入标准组织并开始在电信网络部署，下面分别介绍。


TMPLS 横空出世

　　Transport MPLS 是ITU-T SG15定义的基于MPLS技术的一个面向连接的包传送技术，是MPLS的一个子集。它是将数据通信技术同电信网络有效结合的一个技术。由于同 IP/MPLS网络具有一致的基础技术，它被看作MPLS从核心网络向城域网和接入网的自然延伸。

　　TMPLS抛弃了IETF为MPLS定义的繁复的控制协议族，简化了数据平面，去掉了不必要的转发处理，并增加了ITU-T传送风格的保护倒换和OAM功能。它不支持的特性有：PHP、精细的包丢弃算法、标签合并、ECMP等等。

　　TMPLS被设计成与它的客户信号和控制网络（如MCN、SCN）独立，它并不限定要使用某种特定的控制协议或管理方式，这给网络运营商选择不同的控 制平面、管理平面和承载不同的用户业务留下空间。它承载的客户信号可以是IP/MPLS，也可以是以太网。TMPLS的连接具有较长的稳定性，这使它可具 有传送网络所必备的保护倒换和OAM等功能特性。

　　以太网业务通过TMPLS传送，会用到MPLS-Ethernet互通机制，也就是PWE3技术。按照RFC 3985对PWE3架构的定义，PWE3是在包交换网络PSN（Packet Switched Network）上仿真电信网络业务的基本特性，以保证其穿越PSN而性能只受到最小的影响，这些业务包括E1/T1专线、帧中继FR、ATM、 Ethernet等。IETF为PW定义了一组OAM功能。PW的维护工具BFD是一个轻量级的LSP-Ping和LSP-Traceroute，但是从 传送的风格来看这个OAM工具依然需要较多的软件处理。

　　在标准化的进程上，TMPLS走在其它CE技术的前面，TMPLS架构（G.8110.1）、MPLS设备（G.8121）、MPLS OAM（Y.1711）、保护倒换（Y.1720/G.8131）的第一个版本在2006年2月的ITU-T SG15全会上得以通过。IETF对以太网PW的定义也已经成熟。

　　然而TPMLS在实际应用中不会像理论上这么简单，它与核心网络的IP/MPLS、边缘网络的MPLS、PWE3技术如何互通还在争论中，有意见认为 TMPLS应该处于服务层，而在与核心网络互通时则是一个对等的模型，即在核心网络边缘终结TMPLS。支持PWE3也会给它带来复杂性。


PBT试图力挽狂澜

　　PBT着力于将以太网技术直接应用于以太网业务的传送。

　　PBT的一个基础是IEEE802.1ah定义PBB（Provider Backbone Bridge），即MAC-in-MAC技术，而MAC-in-MAC的来源是RPR的多层MAC帧技术。

　　MAC-in-MAC和PBB

　　MAC-in-MAC是一种基于MAC堆栈的技术，用户MAC被封装在运营商MAC之中作为内层MAC加以隔离，增强了以太网的扩展性和业务的安全 性。PBB使用MAC-in-MAC并引入了I-TAG。I-TAG更适合用来与其它的技术比如MPLS进行互通，它不再被用作标识一个虚拟的网络而是标 识一个业务。

　　 PBT

　　结合电信网络特征、面向连接的以太网技术PBT（Provider Backbone Transport）在2005年10月浮出水面。PBT基于MAC-in-MAC但并不等同于MAC-in-MAC，其核心是：通过网络管理和网络控制 进行配置，使得CE中的以太网业务事实上具有连接性，以便实现保护倒换、OAM、QoS、流量工程等电信传送网络的功能；使用Provider MAC加上VID（VLAN ID）进行业务的转发，从而使得CE受到运营商的控制而隔离用户网络；基于VLAN关掉MAC自学习功能，避免广播包的泛滥，重用转发表而丢弃一切在 PBT转发表中查不到的数据包。

　　基于以太网桥接网络，PBT技术中VLAN ID被用作标识通向同一个目的地址的平行的以太网路径。VLAN ID不再是网络中全局有效，不同的DA可重用相同的VLAN ID。因为业务通过DA+VID的方式进行识别，VLAN ID的相同不会造成以太网交换机在数据帧转发中的冲突。在IEEE802.1D中已经定义了独立VLAN学习IVL（Independent VLAN Learning）的方式，即基于DA+VLAN进行转发，这与通常面向连接的技术比如ATM和MPLS基于局部有效的标签进行交换有所不同。

　　PBT技术承诺与传统以太网桥的硬件兼容，DA＋VID在网络中间节点不需要变化，数据包不需要修改，转发效率高，可支持面向连接网络中具有的带宽管 理功能和连接接纳控制CAC（Connection Admission Control）功能以提供对网络资源的管理，通过网管配置或通过网络控制器NC（Network Controller）建立连接，可方便实现灵活的路由和TE。

　　PBT-Lite

　　在不基于MAC-in-MAC的情况下，PBT-Lite成为一种轻便的数据平面封装形式。PBT-Lite依然使用运营商MAC，但只有一层，它与 传统以太网封装看起来没什么两样，但是转发的行为与PBT一致。接入的不同业务通过不同的映射方式转换成PBT-Lite的形式。


PVT趁势而上

　　在TMPLS先行一步、PBT强势出击的时候，PVT（Provider VLAN Transport）也奔赴到标准化的前台。

　　PVT的前身是VXC（VLAN Cross Connection），采用了类似ATM交换的机制进行可达两层VLAN TAG的交换。相对于VLAN stacking（IEEE802.1ad），MAC stacking（IEEE802.1ah）等传统的以太网技术，PVT引入了确定的连接性，可以支持电信级保护倒换、流量工程和Hard QoS，能支持P2P和P2MP业务，有一定的可扩展性。

　　在PVT中，使用VLAN ID来标识不同的业务实例，MAC地址对于数据转发没有意义。PVT可以基于一层VID，也可以基于S＋C；接入的以太网业务可以是带TAG的，也可以是 基于端口的，还可以是端口＋TAG的形式；可以与现有的以太网交换机混合组网，在电信运营网络中并存；使用对外层VID（P-VID）分区段的方式进行 PVT和Bridging的区分；VID区段的范围可根据需要进行配置。

　　无论从标准化的推动过程还是CE解决方案的角度，PVT和PBT都是两个相互竞争的技术。相对而言，PBT与传统以太网的兼容性和与其它网络技术的互 通性优于PVT，而TMPLS已在标准化进程中抢占先机，以后的竞争，很可能将是PBT和TMPLS在实现成本上的竞争。


运营商需要做出清醒的判断

　　运营商之所以青睐CE，是寄希望于以太网的优势并借此降低CAPEX和OPEX，但CE会像业界所期盼的那样便宜吗？

　　我们来看看传统以太网所具有的优势：即插即用、操作维护简单；芯片技术成熟、量产、性价比高；基于共享总线机制、用户接入无限制、应用灵活。但这些并不是CE的特点。

　　CE对以太网技术进行了不同形式的改造，包括MEF所定义的5个方面，再加上GMPLS统一控制、流量工程、网络安全等方面的需求。增加了这些电信网 络的特征，“便宜”可能会是一个美丽的误会。所以业界对于以太网技术的CE化，应该慎重选择和增加所需要的功能，避免将这个充满希望的技术做得过于复杂。 从这个角度讲，一个瘦的控制平面应该是运营商所希望看到的。

　　目前CE的网管和控制还是空缺，但网管可以确定基于ITU-T定义的传送网络网管功能进行扩展，而控制平面会与ASON控制兼容，将GMPLS作为控制平面信令的基础。

　　运营商对CE传送技术的选择，应该将CAPEX和OPEX综合考虑，这里包括了根据现有网络的特点进行改造。在TMPLS/PBT/PVT成为主流的 以太网业务传送技术后，他们的服务层，可以根据业务的增长和网络的状况灵活选择MPLS/IP、Ethernet、SDH/Sonet、OTN、WDM等 技术作为底层的传送技术。

　　在标准方面，ITU-T的系列标准是优选，运营商网络的架构、设备、OAM、保护倒换、网络管理等标准均在ITU-T开发成功。以太网的老家 IEEE802倾向于在电信领域同ITU-T合作。而CE的控制平面，将借助IETF对GMPLS的扩展成果。另外MEF的测试认证是运营商选择成型产品 的重要依据。

　　CE最终要能为特定的运营商网络提供差异化的成本最优技术解决方案，而在与CE相关的新技术、新产品及新设备层出不穷之际，笔者认为，没有最合适的技术，只有最优的技术组合。

推荐给好友

李金华:最该改的就是发改委_网易新闻中心

李金华:最该改的就是发改委_网易新闻中心
不能光说，要有些人、机构来研究。我的看法，讲得不一定妥当，把改革放在发改委，是不合适，本来发改委就是机构改革的龙头，需要改革的就是它，它去牵头搞机构改革，这个怎么可能呢？所以要有一个操作的机构和人员来研究这个问题。”“分配问题，如果能在我们中华人民共和国成立100周年的时候解决，就不错了。怎么样把公共财政体制真正建立起来，要从整体规划上来考虑，总得设计一个好的方案。而且政府要稍微后退一点，最后由中央、人大来决定，研究时要吸收各方面学者专家的力量。”

【原创】美国空军空中加油机订单旁落欧洲

【原创】美国空军空中加油机订单旁落欧洲

美国空军的这个决定是很出意料的。在此之前，欧洲虽然对A330MRTT的优越性具有坚定的信心，但对入选不抱希望。美国商界更是认为毫无悬念，肯定是波 音KC-767入选。除了特殊情况，美国军方在重大装备上选用外国设计是没有先例的。T-45教练机（原型为英国的“鹰”式）、AV-8垂直起落战斗机 （原型为英国的“鹞”式）、T-6教练机（原型为瑞士的PC-9）都是在美国没有相应产品的情况下入选的。M9手枪（原型为意大利的贝莱塔92F）、 M249轻机枪（原型为比利时的“米尼米”）被美国陆军选用，取代M1911手枪和M60通用机枪，到现在还是很受争议的决定。M9和M249毕竟是“无 关紧要”的轻武器，不影响美军的“美械美造”的根本。但像加油机这样几百、上千亿美元的大项目，这就非同一般了。

A330MRTT的入选象征了美国军事工业的一个重要转折：美国视为国本的军事工业也开始进入买办时代了，只要不涉及主战装备，即使是重大装备，也可能不再坚持“美械美造”了。

这是一个悲伤的故事（9）

这是一个悲伤的故事（9）
说到这里，就顺手说说“蒋雄奇”同志。俺开篇已经点出来了，这不是一个简单的悲伤故事。因为王耀武的经历从实际上是他那个时代的一个缩影，而这个缩影所折 射的一大部分就有关于“蒋雄奇”同志。------不可否认地是，从一个一无所有的奉化寡妇家孩子到中华民国总统，蒋雄奇的生涯不愧“雄奇”二字，他的个 人能力也当得起“雄奇”二字。但作为一个正在历史转折关头的中国领袖，他选择的是一条快捷然而错误的路线，他的基础是上层，这让他很快地掌权并名义上统一 中国，-------然而问题是，他所结合的上层实际上还是从旧中国基础上发展出来的上层，-----也因此，既然他已经成为了这个上层的利益维护者，就 无法使他有可能从下层开始对中国的现代化进程做一个革命性的改变。-----这就是他的一生起伏的结症所在，------从某种意义上讲，蒋雄奇同志可以 说是旧中国的最后一个政治家。-------对这个结论最有力的支持就是，他把权力交给了自己的儿子。

How To Compile A Kernel - The Debian (Sarge) Way | HowtoForge - Linux Howtos and Tutorials

How To Compile A Kernel - The Debian (Sarge) Way | HowtoForge - Linux Howtos and Tutorials

ext make sure you enable the Fusion MPT device drivers under Device Drivers --> Fusion MPT device support. I don't know if this is necessary on all platforms; at least it is on mine (Debian Sarge on a VMware Server) because otherwise you'll get this error message when you boot your new kernel:

How to: Compile Linux kernel 2.6

How to: Compile Linux kernel 2.6

Compiling custome kernel has its own advantages and disadvantages. However new Linux user / admin find it difficult to compile kernel. Compiling kernel needs to understand few things and then just type couple of commands. This step by step howto covers compiling Linux kernel version 2.6 under Debian GNU Linux. However, instructions remains same for any other distribution except for apt-get command.

Step # 1 Get Latest Linux kernel code

Visit http://kernel.org/ and download the latest source code. File name would be linux-x.y.z.tar.bz2, where x.y.z is actual version number. For example file inux-2.6.23.tar.bz2 represents 2.6.23 kernel version. Use wget command to download kernel source code:
$ cd /tmp
$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-x.y.z.tar.bz2

Note: Replace x.y.z with actual version number.

Step # 2 Extract tar (.tar.bz3) file

Type the following command:
# tar -xjvf linux-2.6.23.tar.bz2 -C /usr/src
# cd /usr/src

Step # 3 Configure kernel

Before you configure kernel make sure you have development tools (gcc compilers and related tools) are installed on your system. If gcc compiler and tools are not installed then use apt-get command under Debian Linux to install development tools.
# apt-get install gcc

Now you can start kernel configuration by typing any one of the command:

• $ make menuconfig - Text based color menus, radiolists & dialogs. This option also useful on remote server if you wanna compile kernel remotely.
• $ make xconfig - X windows (Qt) based configuration tool, works best under KDE desktop
• $ make gconfig - X windows (Gtk) based configuration tool, works best under Gnome Dekstop.

For example make menuconfig command launches following screen:
$ make menuconfig

You have to select different options as per your need. Each configuration option has HELP button associated with it so select help button to get help.

Step # 4 Compile kernel

Start compiling to create a compressed kernel image, enter:
$ make
Start compiling to kernel modules:
$ make modules

Install kernel modules (become a root user, use su command):
$ su -
# make modules_install


Step # 5 Install kernel

So far we have compiled kernel and installed kernel modules. It is time to install kernel itself.
# make install

It will install three files into /boot directory as well as modification to your kernel grub configuration file:

• System.map-2.6.23
• config-2.6.23
• vmlinuz-2.6.23

Step # 6: Create an initrd image

Type the following command at a shell prompt:
# cd /boot
# mkinitrd -o initrd.img-2.6.23 2.6.23

initrd images contains device driver which needed to load rest of the operating system later on. Not all computer requires initrd, but it is safe to create one.

Step # 7 Modify Grub configuration file - /boot/grub/menu.lst

Open file using vi:
# vi /boot/grub/menu.lst

title           Debian GNU/Linux, kernel 2.6.23 Default
root            (hd0,0)
kernel          /boot/vmlinuz root=/dev/hdb1 ro
initrd          /boot/initrd.img-2.6.23
savedefault
boot

Remember to setup correct root=/dev/hdXX device. Save the file. If you think editing and writing all lines by hand is too much for you then try out update-grub command to update the lines for each kernel in /boot/grub/menu.lst file. Just type command:
# update-grub
Neat. Huh?

Step # 8 : Reboot computer and boot into your new kernel

Just issue reboot command:
# reboot

LKML: Mickey Stein: [Patch] gcc 4 errors out on i2c.h (2.6.11)

LKML: Mickey Stein: [Patch] gcc 4 errors out on i2c.h (2.6.11)

ate	Wed, 02 Mar 2005 07:21:04 -0800
From	Mickey Stein <>	Ads by Ad Bard
Subject	[Patch] gcc 4 errors out on i2c.h (2.6.11)

I've noticed no problems with today's new 2.6.11 in the i2c realm on
gcc3.x, but the last couple of weeks of gcc 4.x cvs give this:

Error msgs building i2c modules on 2.6.11 using gcc 4:
------------
In file included from drivers/i2c/i2c-core.c:29:
include/linux/i2c.h:58: error: array type has incomplete element type
include/linux/i2c.h:197: error: array type has incomplete element type
drivers/i2c/i2c-core.c: In function ‘i2c_transfer’:
drivers/i2c/i2c-core.c:594: error: type of formal parameter 2 is incomplete
drivers/i2c/i2c-core.c: In function ‘i2c_master_send’:
drivers/i2c/i2c-core.c:620: error: type of formal parameter 2 is incomplete
drivers/i2c/i2c-core.c: In function ‘i2c_master_recv’:
drivers/i2c/i2c-core.c:649: error: type of formal parameter 2 is incomplete
make[2]: *** [drivers/i2c/i2c-core.o] Error 1
make[1]: *** [drivers/i2c] Error 2
make: *** [drivers] Error 2
-------------
I'm not clear on whether the mainstream kernel is "supposed" to compile
error-free with the current state of
gcc 4 cvs. If not, then disregard. I tested this patch applied against
today's 2.6.11 with gcc 3.x & 4.x
by enabling all i2c module switches and building.

A thread discussing this can be found by following the link below:

http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html

The patch changes declarations from "struct i2c_msg msg[]" format to
"struct i2c_msg *msg".

I've run this by Greg K-H and fixed a typo akpm noticed. The patch
touches on several other
files using *i2c_transfer and *master_xfer that give warnings.

Signed-off-by: Mickey Stein 


--- ./include/linux/i2c.h.sav 2005-02-23 10:35:36.000000000 -0800
+++ ./include/linux/i2c.h 2005-02-23 10:46:23.000000000 -0800
@@ -55,7 +55,7 @@

/* Transfer num messages.
 */
-extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],int num);
+extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num);

/*
 * Some adapter types (i.e. PCF 8584 based ones) may support slave behaviuor.
@@ -194,7 +194,7 @@
    to NULL. If an adapter algorithm can do SMBus access, set
    smbus_xfer. If set to NULL, the SMBus protocol is simulated
    using common I2C messages */
- int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[],
+ int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs,
                    int num);
 int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr,
                    unsigned short flags, char read_write,
--- ./drivers/i2c/busses/i2c-iop3xx.c.sav 2005-02-23 10:36:21.000000000 -0800
+++ ./drivers/i2c/busses/i2c-iop3xx.c 2005-02-23 10:47:36.000000000 -0800
@@ -361,7 +361,7 @@
 * master_xfer() - main read/write entry
 */
static int
-iop3xx_i2c_master_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[],
+iop3xx_i2c_master_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs,
    int num)
{
 struct i2c_algo_iop3xx_data *iop3xx_adap = i2c_adap->algo_data;
--- ./drivers/i2c/i2c-core.c.sav 2005-02-23 10:34:59.000000000 -0800
+++ ./drivers/i2c/i2c-core.c 2005-02-23 10:49:18.000000000 -0800
@@ -583,7 +583,7 @@
 * ----------------------------------------------------
 */

-int i2c_transfer(struct i2c_adapter * adap, struct i2c_msg msgs[],int num)
+int i2c_transfer(struct i2c_adapter * adap, struct i2c_msg *msgs, int num)
{
 int ret;

--- ./drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c.sav 2005-02-23 10:39:53.000000000 -0800
+++ ./drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c 2005-02-23 10:50:07.000000000 -0800
@@ -252,7 +252,7 @@
 return rcv_len;
}

-static int master_xfer(struct i2c_adapter* adapter, struct i2c_msg msg[], int num)
+static int master_xfer(struct i2c_adapter* adapter, struct i2c_msg *msg, int num)
{
 struct ttusb *ttusb = i2c_get_adapdata(adapter);
 int i = 0;
--- ./drivers/media/dvb/b2c2/skystar2.c.sav 2005-02-23 10:40:33.000000000 -0800
+++ ./drivers/media/dvb/b2c2/skystar2.c 2005-02-23 10:50:42.000000000 -0800
@@ -293,7 +293,7 @@
 return buf - start;
}

-static int master_xfer(struct i2c_adapter* adapter, struct i2c_msg msgs[], int num)
+static int master_xfer(struct i2c_adapter* adapter, struct i2c_msg *msgs, int num)
{
 struct adapter *tmp = i2c_get_adapdata(adapter);
 int i, ret = 0;
--- ./Documentation/i2c/writing-clients.sav 2005-02-23 10:42:00.000000000 -0800
+++ ./Documentation/i2c/writing-clients 2005-02-23 10:42:30.000000000 -0800
@@ -642,7 +642,7 @@
parameter contains the bytes the read/write, the third the length of the
buffer. Returned is the actual number of bytes read/written.
 
-  extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
+  extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,
                          int num);

This sends a series of messages. Each message can be a read or write,
--- ./include/media/saa7146.h.sav 2005-02-23 12:01:51.000000000 -0800
+++ ./include/media/saa7146.h 2005-02-23 12:19:38.000000000 -0800
@@ -157,7 +157,7 @@

/* from saa7146_i2c.c */
int saa7146_i2c_adapter_prepare(struct saa7146_dev *dev, struct i2c_adapter *i2c_adapter, u32 bitrate);
-int saa7146_i2c_transfer(struct saa7146_dev *saa, const struct i2c_msg msgs[], int num,  int retries);
+int saa7146_i2c_transfer(struct saa7146_dev *saa, const struct i2c_msg *msgs, int num,  int retries);

/* from saa7146_core.c */
extern struct list_head saa7146_devices;
--- ./drivers/i2c/busses/i2c-s3c2410.c.sav 2005-02-23 12:03:29.000000000 -0800
+++ ./drivers/i2c/busses/i2c-s3c2410.c 2005-02-23 12:20:31.000000000 -0800
@@ -483,7 +483,7 @@
 * this starts an i2c transfer
*/

-static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c, struct i2c_msg msgs[], int num)
+static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c, struct i2c_msg *msgs, int num)
{
 unsigned long timeout;
 int ret;
@@ -534,7 +534,7 @@
*/

static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
-   struct i2c_msg msgs[], int num)
+   struct i2c_msg *msgs, int num)
{
 struct s3c24xx_i2c *i2c = (struct s3c24xx_i2c *)adap->algo_data;
 int retry;
--- ./drivers/i2c/busses/i2c-mpc.c.sav 2005-02-23 12:04:11.000000000 -0800
+++ ./drivers/i2c/busses/i2c-mpc.c 2005-02-23 12:17:28.000000000 -0800
@@ -233,7 +233,7 @@
 return length;
}

-static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
+static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
{
 struct i2c_msg *pmsg;
 int i;
--- ./drivers/i2c/busses/i2c-ibm_iic.c.sav 2005-02-23 12:04:42.000000000 -0800
+++ ./drivers/i2c/busses/i2c-ibm_iic.c 2005-02-23 12:21:08.000000000 -0800
@@ -549,7 +549,7 @@
 * Generic master transfer entrypoint.
 * Returns the number of processed messages or error (<0)
 */
-static int iic_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
+static int iic_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
{
     struct ibm_iic_private* dev = (struct ibm_iic_private*)(i2c_get_adapdata(adap));
 volatile struct iic_regs __iomem *iic = dev->vaddr;
--- ./drivers/i2c/busses/i2c-keywest.c.sav 2005-02-23 12:05:10.000000000 -0800
+++ ./drivers/i2c/busses/i2c-keywest.c 2005-02-23 12:26:47.000000000 -0800
@@ -399,7 +399,7 @@
 */
static int
keywest_xfer( struct i2c_adapter *adap,
-  struct i2c_msg msgs[],
+  struct i2c_msg *msgs,
  int num)
{
 struct keywest_chan* chan = i2c_get_adapdata(adap);
--- ./drivers/i2c/busses/i2c-au1550.c.sav 2005-02-23 12:06:00.000000000 -0800
+++ ./drivers/i2c/busses/i2c-au1550.c 2005-02-23 12:27:39.000000000 -0800
@@ -253,7 +253,7 @@
}

static int
-au1550_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[], int num)
+au1550_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs, int num)
{
 struct i2c_au1550_data *adap = i2c_adap->algo_data;
 struct i2c_msg *p;
--- ./drivers/i2c/algos/i2c-algo-pca.c.sav 2005-02-23 12:06:21.000000000 -0800
+++ ./drivers/i2c/algos/i2c-algo-pca.c 2005-02-23 12:28:09.000000000 -0800
@@ -178,7 +178,7 @@
}

static int pca_xfer(struct i2c_adapter *i2c_adap,
-                    struct i2c_msg msgs[],
+                    struct i2c_msg *msgs,
                    int num)
{
        struct i2c_algo_pca_data *adap = i2c_adap->algo_data;
--- ./drivers/i2c/algos/i2c-algo-pcf.c.sav 2005-02-23 12:07:04.000000000 -0800
+++ ./drivers/i2c/algos/i2c-algo-pcf.c 2005-02-23 12:28:49.000000000 -0800
@@ -332,7 +332,7 @@
}

static int pcf_xfer(struct i2c_adapter *i2c_adap,
-      struct i2c_msg msgs[],
+      struct i2c_msg *msgs,
      int num)
{
 struct i2c_algo_pcf_data *adap = i2c_adap->algo_data;
--- ./drivers/i2c/algos/i2c-algo-ite.c.sav 2005-02-23 12:07:17.000000000 -0800
+++ ./drivers/i2c/algos/i2c-algo-ite.c 2005-02-23 12:29:31.000000000 -0800
@@ -490,7 +490,7 @@
 * condition.
 */
#if 0
-static int iic_combined_transaction(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[], int num)
+static int iic_combined_transaction(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs, int num)
{
   int i;
   struct i2c_msg *pmsg;
@@ -600,7 +600,7 @@
 * verify that the bus is not busy or in some unknown state.
 */
static int iic_xfer(struct i2c_adapter *i2c_adap,
-      struct i2c_msg msgs[],
+      struct i2c_msg *msgs,
      int num)
{
 struct i2c_algo_iic_data *adap = i2c_adap->algo_data;
--- ./drivers/i2c/algos/i2c-algo-sgi.c.sav 2005-02-23 12:07:40.000000000 -0800
+++ ./drivers/i2c/algos/i2c-algo-sgi.c 2005-02-23 12:29:58.000000000 -0800
@@ -131,7 +131,7 @@
 return 0;
}

-static int sgi_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[],
+static int sgi_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs,
      int num)
{
 struct i2c_algo_sgi_data *adap = i2c_adap->algo_data;
--- ./drivers/media/video/saa7134/saa7134-i2c.c.sav 2005-02-23 12:08:12.000000000 -0800
+++ ./drivers/media/video/saa7134/saa7134-i2c.c 2005-02-23 12:30:20.000000000 -0800
@@ -236,7 +236,7 @@
}

static int saa7134_i2c_xfer(struct i2c_adapter *i2c_adap,
-       struct i2c_msg msgs[], int num)
+       struct i2c_msg *msgs, int num)
{
 struct saa7134_dev *dev = i2c_adap->algo_data;
 enum i2c_status status;
--- ./drivers/media/video/bttv-i2c.c.sav 2005-02-23 12:08:29.000000000 -0800
+++ ./drivers/media/video/bttv-i2c.c 2005-02-23 12:30:56.000000000 -0800
@@ -245,7 +245,7 @@
        return retval;
}

-static int bttv_i2c_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[], int num)
+static int bttv_i2c_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs, int num)
{
 struct bttv *btv = i2c_get_adapdata(i2c_adap);
 int retval = 0;
--- ./drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c.sav 2005-02-23 12:09:43.000000000 -0800
+++ ./drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c 2005-02-23 12:31:38.000000000 -0800
@@ -38,7 +38,7 @@
/*
 * I2C master xfer function
 */
-static int dibusb_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg msg[],int num)
+static int dibusb_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg *msg,int num)
{
 struct usb_dibusb *dib = i2c_get_adapdata(adap);
 int i;
--- ./drivers/media/common/saa7146_i2c.c.sav 2005-02-23 12:10:06.000000000 -0800
+++ ./drivers/media/common/saa7146_i2c.c 2005-02-23 12:32:45.000000000 -0800
@@ -25,7 +25,7 @@
   sent through the saa7146. have a look at the specifications p. 122 ff
   to understand this. it returns the number of u32s to send, or -1
   in case of an error. */
-static int saa7146_i2c_msg_prepare(const struct i2c_msg m[], int num, u32 *op)
+static int saa7146_i2c_msg_prepare(const struct i2c_msg *m, int num, u32 *op)
{
 int h1, h2;
 int i, j, addr;
@@ -89,7 +89,7 @@
   which bytes were read through the adapter and write them back to the corresponding
   i2c-message. but instead, we simply write back all bytes.
   fixme: this could be improved. */
-static int saa7146_i2c_msg_cleanup(const struct i2c_msg m[], int num, u32 *op)
+static int saa7146_i2c_msg_cleanup(const struct i2c_msg *m, int num, u32 *op)
{
 int i, j;
 int op_count = 0;
@@ -272,7 +272,7 @@
 return 0;
}

-int saa7146_i2c_transfer(struct saa7146_dev *dev, const struct i2c_msg msgs[], int num, int retries)
+int saa7146_i2c_transfer(struct saa7146_dev *dev, const struct i2c_msg *msgs, int num, int retries)
{
 int i = 0, count = 0;
 u32* buffer = dev->d_i2c.cpu_addr;
@@ -372,7 +372,7 @@
}

/* utility functions */
-static int saa7146_i2c_xfer(struct i2c_adapter* adapter, struct i2c_msg msg[], int num)
+static int saa7146_i2c_xfer(struct i2c_adapter* adapter, struct i2c_msg *msg, int num)
{
 struct saa7146_dev* dev = i2c_get_adapdata(adapter);
 

install together on linux

Hi, I received the same error. I think it's because JB 2k5 is using JRE 1.4.2_04 which is pretty darn old.

After some playing around I was able to get the application to install by performing the following:

1. cd into the /tmp/install.dir.xxxxx/InstallerData directory where xxxxx is some number, if you've tried to install multiple times and received this error, you'll see multiple install.dir.xxxxx directories. Pick one, it doesn't matter which one.

2. Assuming you have the java executable on your path, type the following to launch the installer:

sudo java -classpath ./installer.zip com/zerog/ia/installer/Main

Using 'sudo,' of course, implies you are installing as root.

You can now complete the installation process as normal.

3. JBuilder 2005 won't run under a 1.5 JVM - missing classes, however you can do the following to make JBuilder run:

3i. cd into your jbuilder installation directory, say, /usr/local/borland/jbuilder2005.

3ii. then cd into the jdk1.4 directory. on my system, since I have jdk 1.5 installed, this directory is empty.

3iii. execute the following to recursively copy the 1.4 jdk to borland's installation directory tree:

cp -R /tmp/install.dir.xxxxx/Linux/resource/jre/* .

again, where xxxxx is the number of the temp directory used above.

3iv. now, executing the jbuilder executable in the bin subdirectory of your installation directory will launch JBuilder and you can start coding away.

Note that if you want to do Java development under the 1.5 JDK, you'll need to add it under Tools >> Configure >> JDKs.

Happy Coding,

新中国美术图史

新中国美术图史

毛泽东诗意山水画的出现伴随着国画改造的步伐，将传统山水画中那种脱离尘世的清高改变为结合现实的歌颂，它在当时所具有的"革命"的意义，是一般的山水画 难以表达的。而这种意义首先表现了与领袖的关系，这一层关系是当时作品能够获得社会认可的一个重要的方面；再是表现了与毛泽东诗词中革命的现实主义和革命 的浪漫主义相结合的创作方法的关系，它为山水画的改造提供了一个现时的参照，表明了作品在创作中的一个基本的思想倾向。作为一种新山水画的样式，它的流行 除了上述的意义，显然因为国画改造的实际可能与现实中的限制，使得这一样式能够获得广泛的表现空间。同时它的流行还伴随着对毛泽东个人崇拜的加剧，而发展 到这一新山水画模式的盛期--60至70年代，傅抱石的地位则由另一位代表人物李可染所替代。如果说傅抱石50年代是开创，李可染70年代则是完善。

Understanding Intelligent Carrier Ethernet [Ethernet] - Cisco Systems

Understanding Intelligent Carrier Ethernet [Ethernet] - Cisco Systems

http://www.juniper.net/solutions/service_provider/carrier_ethernet/

技术前沿——电信级以太网的三大主流技术 - 华为

技术前沿——电信级以太网的三大主流技术 - 华为

技术前沿——电信级以太网的三大主流技术

第12期 光网专刊

文档下载(930 KB)

文/李喜祥

　　电信级以太网（CE）的概念一经MEF提出，就引起业界的普遍关注。经过一年多沸沸扬扬的争论，CE最终定位于在城域网络中解决IP、以太网、TDM等业务的传送问题。但是究竟何为CE？TMPLS、PBT、PVT又是什么样的技术？运营商又该如何做出正确的选择？


CE概念之辩

　　从2005年2月17日MEF举办第一次CEWC（Carrier Ethernet World Congress），到2005年9月13 日公布业界第一次CE认证，再到今日CE市场的启动，MEF在通信产业界掀起了一股CE旋风，席卷了从技术、标准到产品、市场，从接入、汇聚到核心网络等 不同层面的多个领域，一时间业界津津乐道于此。

　　然而CE并不是一个特定的技术术语，不专指某种网络技术，也不排斥某种网络技术。按照MEF定义，它包括5个方面的内容：标准化的业务（以太网透明专 线、虚拟专线、虚拟局域网）；可扩展性（各种以太网业务、10万条以上的业务规模、从1M到10GE）；可靠性（用户无感知的故障恢复、低于50ms的保 护倒换）；QoS（端到端有保障的业务性能）；电信级网络管理（快速业务建立、OAM、用户网络管理）。但这并不是全部。

　　从运营商角度看，CE技术是指以太网技术由企业网应用到电信网的技术；从网络层次角度看，也是以太网由局域网应用到城域网、广域网的技术。传统的电信 网络具有较强的可扩展性、层次性、安全性、容错性、可区分服务、可操作维护性、可管理性和可控制性，比如ATM网络、SDH网络。近年来Internet 网络技术的发展，更是给电信网络引入了流量工程的机制，并从MPLS和ASON引入了控制平面的概念。目前在各标准组织中，数据平面、控制平面、管理平面 是对网络架构比较清晰的模型划分。

　　MEF推出的CE认证以网络能够支持的以太网业务类型（比如E-Line、E-LAN）和业务所能够达到的性能（比如一定的时延、抖动、丢包率）为衡 量标准，并不限定某种特定的以太网技术方案。这样在实际部署中CE的传送层，即以太网业务的服务层的技术选择可以有多种。目前出现的CE传送层技术有 SDH/Sonet、OTN、MPLS/IP、Ethernet、WDM、ATM等，各自有其数据交叉/交换、OAM、QoS等机制。CE的管理平面和控 制平面，根据电信网络的要求，对不同的以太网业务的传送技术将会保持一致的规格。相应的标准正在ITU-T和IETF进行研究。

　　当前有三种主要的CE技术进入标准组织并开始在电信网络部署，下面分别介绍。


TMPLS 横空出世

　　Transport MPLS 是ITU-T SG15定义的基于MPLS技术的一个面向连接的包传送技术，是MPLS的一个子集。它是将数据通信技术同电信网络有效结合的一个技术。由于同 IP/MPLS网络具有一致的基础技术，它被看作MPLS从核心网络向城域网和接入网的自然延伸。

　　TMPLS抛弃了IETF为MPLS定义的繁复的控制协议族，简化了数据平面，去掉了不必要的转发处理，并增加了ITU-T传送风格的保护倒换和OAM功能。它不支持的特性有：PHP、精细的包丢弃算法、标签合并、ECMP等等。

　　TMPLS被设计成与它的客户信号和控制网络（如MCN、SCN）独立，它并不限定要使用某种特定的控制协议或管理方式，这给网络运营商选择不同的控 制平面、管理平面和承载不同的用户业务留下空间。它承载的客户信号可以是IP/MPLS，也可以是以太网。TMPLS的连接具有较长的稳定性，这使它可具 有传送网络所必备的保护倒换和OAM等功能特性。

　　以太网业务通过TMPLS传送，会用到MPLS-Ethernet互通机制，也就是PWE3技术。按照RFC 3985对PWE3架构的定义，PWE3是在包交换网络PSN（Packet Switched Network）上仿真电信网络业务的基本特性，以保证其穿越PSN而性能只受到最小的影响，这些业务包括E1/T1专线、帧中继FR、ATM、 Ethernet等。IETF为PW定义了一组OAM功能。PW的维护工具BFD是一个轻量级的LSP-Ping和LSP-Traceroute，但是从 传送的风格来看这个OAM工具依然需要较多的软件处理。

　　在标准化的进程上，TMPLS走在其它CE技术的前面，TMPLS架构（G.8110.1）、MPLS设备（G.8121）、MPLS OAM（Y.1711）、保护倒换（Y.1720/G.8131）的第一个版本在2006年2月的ITU-T SG15全会上得以通过。IETF对以太网PW的定义也已经成熟。

　　然而TPMLS在实际应用中不会像理论上这么简单，它与核心网络的IP/MPLS、边缘网络的MPLS、PWE3技术如何互通还在争论中，有意见认为 TMPLS应该处于服务层，而在与核心网络互通时则是一个对等的模型，即在核心网络边缘终结TMPLS。支持PWE3也会给它带来复杂性。


PBT试图力挽狂澜

　　PBT着力于将以太网技术直接应用于以太网业务的传送。

　　PBT的一个基础是IEEE802.1ah定义PBB（Provider Backbone Bridge），即MAC-in-MAC技术，而MAC-in-MAC的来源是RPR的多层MAC帧技术。

　　MAC-in-MAC和PBB

　　MAC-in-MAC是一种基于MAC堆栈的技术，用户MAC被封装在运营商MAC之中作为内层MAC加以隔离，增强了以太网的扩展性和业务的安全 性。PBB使用MAC-in-MAC并引入了I-TAG。I-TAG更适合用来与其它的技术比如MPLS进行互通，它不再被用作标识一个虚拟的网络而是标 识一个业务。

　　 PBT

　　结合电信网络特征、面向连接的以太网技术PBT（Provider Backbone Transport）在2005年10月浮出水面。PBT基于MAC-in-MAC但并不等同于MAC-in-MAC，其核心是：通过网络管理和网络控制 进行配置，使得CE中的以太网业务事实上具有连接性，以便实现保护倒换、OAM、QoS、流量工程等电信传送网络的功能；使用Provider MAC加上VID（VLAN ID）进行业务的转发，从而使得CE受到运营商的控制而隔离用户网络；基于VLAN关掉MAC自学习功能，避免广播包的泛滥，重用转发表而丢弃一切在 PBT转发表中查不到的数据包。

　　基于以太网桥接网络，PBT技术中VLAN ID被用作标识通向同一个目的地址的平行的以太网路径。VLAN ID不再是网络中全局有效，不同的DA可重用相同的VLAN ID。因为业务通过DA+VID的方式进行识别，VLAN ID的相同不会造成以太网交换机在数据帧转发中的冲突。在IEEE802.1D中已经定义了独立VLAN学习IVL（Independent VLAN Learning）的方式，即基于DA+VLAN进行转发，这与通常面向连接的技术比如ATM和MPLS基于局部有效的标签进行交换有所不同。

　　PBT技术承诺与传统以太网桥的硬件兼容，DA＋VID在网络中间节点不需要变化，数据包不需要修改，转发效率高，可支持面向连接网络中具有的带宽管 理功能和连接接纳控制CAC（Connection Admission Control）功能以提供对网络资源的管理，通过网管配置或通过网络控制器NC（Network Controller）建立连接，可方便实现灵活的路由和TE。

　　PBT-Lite

　　在不基于MAC-in-MAC的情况下，PBT-Lite成为一种轻便的数据平面封装形式。PBT-Lite依然使用运营商MAC，但只有一层，它与 传统以太网封装看起来没什么两样，但是转发的行为与PBT一致。接入的不同业务通过不同的映射方式转换成PBT-Lite的形式。


PVT趁势而上

　　在TMPLS先行一步、PBT强势出击的时候，PVT（Provider VLAN Transport）也奔赴到标准化的前台。

　　PVT的前身是VXC（VLAN Cross Connection），采用了类似ATM交换的机制进行可达两层VLAN TAG的交换。相对于VLAN stacking（IEEE802.1ad），MAC stacking（IEEE802.1ah）等传统的以太网技术，PVT引入了确定的连接性，可以支持电信级保护倒换、流量工程和Hard QoS，能支持P2P和P2MP业务，有一定的可扩展性。

　　在PVT中，使用VLAN ID来标识不同的业务实例，MAC地址对于数据转发没有意义。PVT可以基于一层VID，也可以基于S＋C；接入的以太网业务可以是带TAG的，也可以是 基于端口的，还可以是端口＋TAG的形式；可以与现有的以太网交换机混合组网，在电信运营网络中并存；使用对外层VID（P-VID）分区段的方式进行 PVT和Bridging的区分；VID区段的范围可根据需要进行配置。

　　无论从标准化的推动过程还是CE解决方案的角度，PVT和PBT都是两个相互竞争的技术。相对而言，PBT与传统以太网的兼容性和与其它网络技术的互 通性优于PVT，而TMPLS已在标准化进程中抢占先机，以后的竞争，很可能将是PBT和TMPLS在实现成本上的竞争。


运营商需要做出清醒的判断

　　运营商之所以青睐CE，是寄希望于以太网的优势并借此降低CAPEX和OPEX，但CE会像业界所期盼的那样便宜吗？

　　我们来看看传统以太网所具有的优势：即插即用、操作维护简单；芯片技术成熟、量产、性价比高；基于共享总线机制、用户接入无限制、应用灵活。但这些并不是CE的特点。

　　CE对以太网技术进行了不同形式的改造，包括MEF所定义的5个方面，再加上GMPLS统一控制、流量工程、网络安全等方面的需求。增加了这些电信网 络的特征，“便宜”可能会是一个美丽的误会。所以业界对于以太网技术的CE化，应该慎重选择和增加所需要的功能，避免将这个充满希望的技术做得过于复杂。 从这个角度讲，一个瘦的控制平面应该是运营商所希望看到的。

　　目前CE的网管和控制还是空缺，但网管可以确定基于ITU-T定义的传送网络网管功能进行扩展，而控制平面会与ASON控制兼容，将GMPLS作为控制平面信令的基础。

　　运营商对CE传送技术的选择，应该将CAPEX和OPEX综合考虑，这里包括了根据现有网络的特点进行改造。在TMPLS/PBT/PVT成为主流的 以太网业务传送技术后，他们的服务层，可以根据业务的增长和网络的状况灵活选择MPLS/IP、Ethernet、SDH/Sonet、OTN、WDM等 技术作为底层的传送技术。

　　在标准方面，ITU-T的系列标准是优选，运营商网络的架构、设备、OAM、保护倒换、网络管理等标准均在ITU-T开发成功。以太网的老家 IEEE802倾向于在电信领域同ITU-T合作。而CE的控制平面，将借助IETF对GMPLS的扩展成果。另外MEF的测试认证是运营商选择成型产品 的重要依据。

　　CE最终要能为特定的运营商网络提供差异化的成本最优技术解决方案，而在与CE相关的新技术、新产品及新设备层出不穷之际，笔者认为，没有最合适的技术，只有最优的技术组合。

电信级以太网技术漫谈 - 通信频道 | IT168

电信级以太网技术漫谈 - 通信频道 | IT168

电信级以太网技术漫谈

[收藏此页] [打印]

作者：胡昌军 2007-04-05

内容导航：

第1页

第1页： 第1页

1、引言

近年来，随着城域数据业务的快速增长，城域以太网传送技术得到了迅速发展和应用，特别是电信级数据业务成为需求热点，受到了运营商和设备开发商的广泛关注。为了实现多种电信级数据业务的有效支撑，城域以太网传送技术正朝着支持电信级以太网业务的方向演进。

电信级以太网又称运营商级以太网（CE，Carrier Ethernet），最早由城域以太网论坛（MEF，Metro Ethernet Forum）在2005年初提出。经过一年多的发展，电信级以太网技术引起业界的普遍关注，成为当前城域网技术的热点讨论话题。按照MEF定义，电信级以太网技术主要以网络能够支持的以太网业务类型和业务所能够达到的性能为衡量标准，并不专指某种网络技术，其主要包括5个方面的内容：标准化的业务（专线/虚拟专线、专用局域网/虚拟专用局域网）、可扩展性（业务带宽和业务规模均可灵活扩展）、可靠性（低于50ms的保护倒换）、QoS（端到端有保障的业务性能）、电信级网络管理（快速业务建立、用户网络管理）。

2、电信级以太网的基本技术要求

下面主要从业务标准划分、服务质量（QoS）、可靠性、网络安全和网络管理等五个方面给出电信级以太网的一些基本技术要求。

2.1　业务标准划分

电信级以太网可以采用一定的手段实现点到点、点到多点的以太网连接，其支持的以太网业务类型具体可分为以下几种：

（1）EPL（以太网专线）：具有两个UNI接口，每个UNI仅接入一个客户的业务，实现点到点的以太网透明传送，基本特征是传送带宽为专用，在不同用户之间不共享。

（2）EVPL（以太网虚拟专线）：具有两个或多个UNI接口，每个UNI接口接入一个或多个客户的业务，实现点到点的连接，基本特征是UNI-N接口或传送带宽在不同用户之间共享。

（3）EPLAN（以太网专用局域网）：具有多个UNI接口，每个UNI仅接入一个客户的业务，实现多个客户之间的多点到多点的以太网连接，基本特征是传送带宽为专用，在不同用户之间不共享。

（4）EVPLAN（以太网虚拟专用局域网）：具有多个UNI接口，每个UNI可以接入多个客户的业务，实现多个客户之间的多点到多点的以太网连接，基本特征是在EPLAN基础上增加了不同用户共享传送带宽的功能。

2.2　服务质量(QoS）

服务质量（QoS）的量化指标主要有两个方面：一方面是由呼叫与连接建立的速度，包括端到端延迟（End-to-end Delay）和延迟变化（Jitter）；另一方面是网络数据的吞吐量，吞吐量的主要指标可以表明可用的带宽大小，吞吐量决定着网络传输的流量，与带宽、 出错率、缓冲区容量和处理机的能力等因素有关。

早期的以太网在局域网内主要承载数据业务，数据业务的特点是对时延不敏感，TCP的重传机制又可以容忍以太网上少量数据包的丢失，因此不需要差异化 的服务质量保证。但对于电信级以太网技术，由于其需要承载综合业务，这种不区分流量类型的Best effort服务难以保证业务的质量。电信级以太网实现QoS有IntServ（集成业务体系结构）和Diff-Serv（区分业务体系结构）两种方法， 通常使用后者，其具体实现过程包括流分类、映射、拥塞控制和队列调度。

（1）流分类：在以太网上可以根据MAC地址、VLAN ID、IP地址以及TCP/UDP端口号区分业务流；

（2）映射：根据一定策略将数据流的QoS参数映射到IP TOS字段、MPLS COS域或者802.1p字段，通常将业务区分为EF（加速转发，对应实时性较强的业务）、若干个AF（保证转发，对应不同级别的丢包敏感、实时性不强的业务）以及BF（尽力而为，对应普通IP业务）；

（3）拥塞控制：根据业务的不同要求对数据流做应用不同的拥塞控制算法，在网络节点发生拥塞时可以有选择有区别的丢弃少量数据包；

（4）队列调度：为保证时延以及时延抖动等性能，需要实现各种调度算法，包括严格优先级（SP）算法、加权公平队列（WFQ）算法、加权循环（WRR）算法，其中，SP用于对时延要求严格的业务，WFQ和WRR用于在多个业务之间按一定权值分配带宽。

2.3　电信级可靠性

传统的以太网使用链路聚合和生成树协议进行保护，链路聚合耗费大量的线路和端口资源，不适合城域网，生成树协议/快速生成树协议在链路出现故障时的 恢复时间都在秒级，远远大于电信级要求的50ms。电信级以太网技术可以采取一定的手段保证业务倒换时间小于50ms，如采用MPLS或弹性分组环 （RPR）等技术。

除了网络级保护，节点设备也采用了冗余技术，如双处理器架构的高端交换设备，提供主备倒换功能，当出现故障时可以很快倒换，倒换时间一般在毫秒级，不影响用户业务。

2.4　网络安全

对于电信级以太网来说，保证设备和网络的安全性是一项十分重要的工作，需要采取一定的措施防止非法进入其系统造成设备和网络无法正常工作，以及某些恶意的消息影响业务的正常提供。

传统以太网的安全问题已经通过VLAN技术划分虚拟网段得到解决。但随着互联网的发展，近年来网络经常遭受蠕虫等网络病毒以 及黑客的攻击，全网瘫痪的案例时有发生，合法用户的有效带宽、用户的信息安全难以得到保证。因此在建设电信级以太网时，必须考虑如何保证网络的安全性。比 较常见的以太网安全解决方案是通过ACL（访问控制列表）或者过滤数据库来过滤非法数据；端口镜像技术可以将任一端口的输入输出流量复制到指定端口输出， 帮助网络管理者监控网络的数据内容；一些高端的网络设备具有强大的应用感知和网络级自动免疫能力，能够一定程度地自动感知并过滤不安全的数据流。

2.5　以太网的管理

电信级以太网能够提供完善强大的网管，并能提供端到端的统一网管能力、集群管理能力、堆叠管理以及可视化图形管理。除了常规的配置、监控、用户数据 采样分析等，完善的网络管理还能自动发现网络故障，并能及时恢复，能够自动发现新加入的业务节点，能够配置端到端的业务；网管还能够测量端到端的性能，实 时掌控网络的运行情况。

3、几种典型的电信级以太网技术

电信级以太网技术种类众多，其中当前比较热门的三种为：传送MPLS（T-MPLS），运营商骨干网传输（PBT，Provider Backbone Transport），运营商VLAN传输（PVT，Provider VLAN Transport）

3.1　T-MPLS

固定时隙分配的传统SDH在以分组交换为 主的网络环境中暴露出很多缺点，难以满足分组以太网业务需求，MPLS技术可以很好地弥补SDH网络的缺点。但若在传统SDH中完全引入复杂的MPLS技 术，则会大大提高设备成本和网络的复杂度，也是不合适的。为了适应分组交换和传送的需求，必须对MPLS/PW技术进行简化修改，并跟传送平面相关联（比 如SDH、MSTP或其它任何传送设备），即发展成为T-MPLS技术。ITU-T SG15在2006年2月的全会上采纳了T-MPLS的概念，来代替过去的MPLS over传送网的概念，并通过了关于T-MPLS的三个标准，即G.8010.1“T-MPLS体系结构”、G.8112“T-MPLS的NNI接口”、 G.8121“T-MPLS设备功能模块特性”。T-MPLS抛弃了IETF为MPLS定义的繁复的控制协议族，简化了数据平面，去掉了不必要的转发处 理，并增加了ITU-T传送风格的保护倒换和OAM功能。总体来看，T-MPLS是ITU-T SG15定义的基于MPLS技术的一个面向连接的包传送技术，是MPLS的一个子集，是将数据通信技术同电信网络有效结合的一个技术。

T-MPLS与它的客户信号和控制网络（如MCN、SCN）是完全独立的，其不限定要使用某种特定的控制协议或管理方式。T-MPLS承载的客户信 号可以是IP/MPLS，也可以是以太网。T-MPLS的连接具有较长的稳定性，这使它可具有传送网络所必备的保护倒换和OAM等功能特性。以太网业务通 过T-MPLS传送，会用到MPLS-Ethernet互通机制，也就是PWE3技术。

T-MPLS技术由数据平面、管理平面和控制平面三个相关平面组成，从标准化程度来看，现在的标准仅规范了T-MPLS的数据平面部分功能，还需要 进一步研究T-MPLS的多播、保护、OAM等功能，此外管理平面和控制平面也需进一步规范，预计T-MPLS的系列标准将在2008年后基本完成。

3.2　PBT

运营商骨干网传输PBT（Provider Backbone-Transport）技术源自IEEE 802.1ah定义的运营商骨干网桥接PBB （Provider Backbone Bridge），即MAC-in-MAC技术。MAC-in-MAC是一种基于MAC堆栈的技术，用户MAC被封装在运营商MAC之中作为内层MAC加以 隔离，增强了以太网的扩展性和业务的安全性。PBB在MAC-in-MAC基础上并引入了I-TAG。I-TAG更适合用来与其它的技术比如MPLS进行 互通，它不再被用作标识一个虚拟的网络而是标识一个业务。

面向连接的具有电信网络特征的以太网技术PBT最初在2005年10月提出。PBT主要具有以下技术特征：

（1）基于MAC-in-MAC但并不等同于MAC-in-MAC，其核心是：通过网络管理和网络控制进行配置，使得电信级以太网中的以太网业务事实上具有连接性，以便实现保护倒换、OAM、QoS、流量工程等电信传送网络的功能；

（2）使用运营商MAC（Provider MAC）加上VLAN ID进行业务的转发，从而使得电信级以太网受到运营商的控制而隔离用户网络；

（3）基于VLAN关掉MAC自学习功能，避免广播包的泛滥，重用转发表而丢弃一切在PBT转发表中查不到的数据包。

由于采用了两层MAC技术，业务通过DA+VID的方式进行识别，VLAN ID不再是全局有效，不同的DA可重用相同的VLAN ID，VLAN ID的相同不会造成以太网交换机在 数据帧转发中的冲突。PBT技术可以与传统以太网桥的硬件兼容，DA+VID在网络中间节点不需要变化，数据包不需要修改，转发效率高，可支持面向连接网 络中具有的带宽管理功能和连接允许控制（CAC，Connection Admission Control）功能以提供对网络资源的管理，通过网管配置或通过网络控制器（NC，Network Controller）建立连接，可以很方便地实现灵活的路由和流量工程。

3.3　PVT

运营商VLAN传输技术PVT（Provider VLAN Transport）源自VLAN交叉连接VXC（VLAN Cross Connection）技术，采用了类似ATM交 换的机制进行两层VLAN TAG的交换。相对于VLAN堆栈（IEEE 802.1ad），MAC堆栈（IEEE 802.1ah）等传统的以太网技术，PVT引入了确定的连接性，可以支持电信级保护倒换、流量工程，能支持点到点和点到多点业务，有一定的可扩展性。在 PVT中，使用VLAN ID来标识不同的业务实例，MAC地址对于数据转发没有意义。PVT在实际配置是具有较大的灵活性，主要体现在：

（1）PVT可以基于一层VID，也可以基于两层VLAN ID；

（2）接入的以太网业务可以是带VLAN ID的，也可以是基于端口的，还可以是端口+VLAN ID的形式；

（3）可以与现有的以太网交换机混合组网，在电信运营网络中并存；

（4）使用对外层VLAN ID分区段的方式进行PVT和网桥的区分；

（5）VID区段的范围可根据需要进行配置。

4、电信级以太网技术发展前景

目前电信运营商之所以青睐电信级以太网技术，很重要的一个原因是希望在数据业务大发展的背景下，可以利用以太网的优势来降低CAPEX和OPEX。 我们知道，传统以太网具有众多优势，包括技术成熟、性价比高、操作维护简单、用户接入无限制、应用灵活，等等。但这些显然不能涵盖电信以太网的所有特点。 电信级以太网需要对以太网技术进行必要的改造，包括需要满足MEF所定义的5个方面的要求，以及控制平面、流量工程、网络安全等方面的需求。当在以太网技 术上增加了这些电信网络的特征后，其原有低成本优势是否仍然存在还需要打上一个问号。所以业界在实现和应用电信级以太网技术时，应该慎重选择所需要增加的 功能，避免将其做得过于复杂。从这个角度讲，一个简化的控制平面功能应该是运营商所希望看到的。目前，电信级以太网的网管和控制平面功能还是一个空白，根 据上述简化的原则，网管功能可以确定在ITU-T定义的传送网络网管功能基础上进行扩展，而控制平面可以与ASON控制相兼容，将GMPLS作为控制平面信令的基础。从传送技术选择方面，应该综合考虑CAPEX和OPEX，可以根据业务的增长和网络的状况灵活选择MPLS/IP、Ethernet、SDH/Sonet、OTN、WDM等 技术作为底层的传送技术。在标准参照方面，应该优先选择ITU-T的系列标准，同时结合IEEE 802、IETF和MEF等标准化组织或论坛的最新研究成果，从目前来看，运营商网络的架构、设备、OAM、保护倒换、网络管理等方面的ITU标准已经发 布或正在制定中，可以作为今后电信级以太网技术发展的主要参考标准依据。

从技术发展前景来看，在目前比较热门的三种电信级以太网技术中，PVT和PBT是两个相互竞争的技术，相对而言，PBT与传统以太网的兼容性以及与 其它网络技术的互通性要优于PVT，另外，T-MPLS是三者中标准化程度最高的。总体来看，PBT和T-MPLS在技术方面有一定的优势，代表了今后电 信级以太网技术的发展方向。

5、结束语

为了能够满足未来几年NGN和3G网络的大规模应用，国内各大运营商都在不断改造原有城域网络或重新组建新的城域网络，力求做到为新业务提供有充分质量保证和带宽保证的网络平台。由于新业务对数据网络的QoS和SLA要求日益增长，新的数据承载网络需要能够实现电信级保护、服务质量保证和TDM（时 分复用）能力支持等新的功能，在这种情况下，电信级以太网技术应运而生，并已成为下一代城域网发展的方向。然而，还应看到，目前电信级以太网技术所提出的 QoS、可靠性等并不能完全解决以太网所有的问题，为了真正实现具备电信特征的以太网业务，仍然需要在技术标准化、成熟度方面多做努力，还有很长的路要 走。

西班牙电信完成对北电电信级以太网技术的测试--国际要闻--通信世

西班牙电信完成对北电电信级以太网技术的测试--国际要闻--通信世

北电Telefónica全球客户副总裁FernandoValdivielsoDelgado表示：“借助于PBB和PBT技术，以太网现在可以满足市场对运营商应用的需求(如通过一个宽带连接同时实现高速互联网接入、电视和VoIP功能的三重业务融合以及无线回传和以太网连接服务)。这样如果运营商要采用更复杂、市场价值更高的传输技术(如MPLS)，那么就多了一种经济有效且简单的可选方案。TelefónicaI+D的成功测试标志着人们在全球可持续发展和采用电信级以太网的道路上又跨出了一步。电信级以太网的采用将使人们可以从这个超级连接时代中获益匪浅。”

TelefónicaI+D进行的测试包括，启用具有类似于SONET/SDH管理特性的确定性点对点以太网传输隧道来显示北电PBB和PBT技术支持无线回传的方式。测试使用的解决方案以北电城域以太网路由交换机(MERS) 8600为基础，它采用了包括PBB和PBT在内的北电最新电信级以太网创新技术。目前通过IEEE802.1的产业标准化工作，PBT技术正在不断发展 之中。IEEE802.1将该项技术称之为IEEE 802.1Qay(支持流量工程的运营商骨干桥接技术)。同时，测试还利用了北电城域以太网管理器(MEM)来提供端到端的服务、PBT中继配置功能以及 增强型网络的故障管理和故障排除功能。

Avici放弃核心路由器市场--通信产业云龙看网络技术

Avici放弃核心路由器市场--通信产业云龙看网络技术

虽然一谈核心路由器，大家知道都是Cisco、Juniper、华为，但要说Avici的核心路由器产品从没有进入到中国是不对的。

华为的NE5000E核心路由器，当前已经是非常有名了，但对于NE5000和NE5000E的不同和渊源，知道的人就不多了。华为最早进入中国运 营商核心路由器市场是靠2004年的广东电信省163骨干网扩容项目，在这个项目中，广东省网出口路由器、顺德、佛山、湛江节点路由器都使用了华为的 NE5000路由器，NE5000设备就是OEM Avici的核心路由器产品。2004年中期应该是华为数通产品线最困难时期，高端路由器产品迟迟无法商用，外还有港湾竞争，所以这次NE5000的应用 是意义重大。后来在随后的广东电信城域网扩容项目中，华为所销售的NE5000E产品就是自己开发的路由器产品了。这个项目是华为数据产品线在国内上升的 开始，也是Cisco高端路由器在运营商市场份额减少的开始。后来的中国电信CN2项目就大规模采用了华为的NE5000E设备。

近日了解到Avici在5月份宣布放弃核心路由器市场，将在2007年底停止销售核心路由器产品。然后仔细了解了一下，才发现AT&T是 Avici的唯一一个客户。面对Cisco的高端路由器进入AT&T网络，和其它新技术的挑战，如城域以太网技术，Avici认为核心路由器市场 将要发生很大的变化，路由器市场已不足以提供公司所需要的商业增长，尤其是仅有一个客户。

Soapstone Networks是Avici的子公司， Avici将把主要技术人员和资金投入到其Soapstone的产品研究中，开发新的控制平面系统，这种系统与下层物理网络技术无关，可以管理如路由型、以太网、光网等任何类型的网络。

Avici想凭借以前的技术积累：非常成熟的控制平面技术，发展出一种介于物理网络和上层应用、IT系统间的的软件解决方案，作为网络的控制层面技术。运营商普遍对这个思路和将来的产品非常看好。

第一个产品是应用于运营城域网的PBT控制器the Provider Backbone Transport (PBT) Controller。

在6月份的NXTcomm大会上，Soapstone Networks展示了其面向PBT技术的Provider Network Controller (PNC)运营商网络控制器，并在一个多节点的北电PBT网络上展示了其控制平面的互通性。为不同的网络技术设定了一个控制的框架，使得运营商快速定制和 部署业务，而同下层网络技术无关。

新的运营级以太网PBT技术具备控制平面和数据传送平面分离的特性，Avici利用其成熟的控制平面技术优势，开发跟PNC系统，而象北电网络这样的网络设备厂家，集中于PBT技术的设备实现。

Avici期望在放弃了路由器市场后，其将来主要的收入来自于Soapstone's provider network controller (PNC)，目前正在跟一些厂商、运营商做测试，在2007年有些少量的收入，预计在2008年会收入剧增。

Avici持有$61.1 million的现金，并且没有债务，业界认为其有足够的实力来实现新的商业计划。

首发自《云龙视点一周回顾》第三期

核心路由器市场分析：07回顾以及08展望 - 水煮 鱼@博客园 - 博客园

核心路由器市场分析：07回顾以及08展望 - 水煮 鱼@博客园 - 博客园

从市场层面上看，核心路由器的应用存在着企业级市场和电信级市场两个方向。目前电信级市场的拓展空间日趋有限，企业级应用是核心路由器一直的挖掘方向。但 是目前在企业级应用上，Cisco基本占据了绝对的市场优势（约75%），但是其他厂商在逐步蚕食Cisco的现有市场份额。不久前Juniper刚刚高 调发布的企业级EX系统的以太网交换机，丰富了Juniper薄弱的企业级应用产品线，也凸显了Juniper拓展企业级市场的决心和信心。相对而言，产 品线相对丰富的华为将成为Cisco在企业级市场的最大竞争对手。何况根据02年Cisco和华为的“世纪大战”中制定的“君子协定”，08年华为进入北 美市场的禁令将被解除，在全球需求最为旺盛的北美市场，Cisoc/Juniper和华为的正面交锋将可能对未来几年的核心路由器市场的格局产生变革性的 影响。

总而言之，2008年仍将是核心路由器市场高速成长的一年，竞争也日趋激烈。大鱼吃小鱼，小鱼吃虾米，在这场战役中，剩下的将是强者，而被淘汰的将仅仅书写在核心路由器市场发展的悲壮史书中。