分享

 上面的大段关于城域网的论述，居然没有提到曾经试图辉煌到甚嚣尘上的ATM，是不应该的，所以下面也谈一下ATM。但是ATM已经是昨日黄花，IT是吃青春饭的，ATM已是门前冷落鞍马稀，估计现在的80/90后没人喜欢看这青年才俊眼里已经可以算是老掉牙的老太太了，世态炎凉，人情冷暖，尽在IT人生，所以本篇内容，不得不在技术描述中加点人生调料，妄图借一点小资情调打开一下人老珠黄的尴尬场面。此正是：
人老尽靠粉扑面，唏嘘长叹谁见？强作欢颜为接客，遥想当年perfect，扼腕！
 在我大学毕业前，ATM就是现在的MPSL，everything over ATM是最fashion的数通网络技术，从核心网到城域网到desktop，基于ATM的网卡都有，你说得多贵？我当时刚搞懂PC机的基本装机和基本C语言的DOS编程，对计算机世界上业界大拿的忽悠文章，只能剪下来收藏，以便以后能读懂的时候再拿出来学习，因为这个报纸和其重量比，基本是免费的，估计卖废纸的价格能很大程度上能弥补购买的成本，当然，我并没有试过，后来这一大堆剪报不知道在哪次搬家中丢掉了，即使没有丢，再拿出来，也许看到的是：早就不流行了，现在哪还有人穿呀。所以当时最喜欢的还是上面的IT普及教育级别的文章，ATM是其中大体不懂而被收藏的topic之一，因为工作关系后来接触到ATM技术，所以现在仍然记得当时ATM剪报的事
 在ATM之前，IP的承载网络有两大challenges：一个是WAN的速度和业务不能兼顾的问题，以E1/E3为主的X25/FR显然是低速并且复杂的协议，而STM-1/4的颗粒比较大，并且基于TDM的，不能提供业务层面的复用，也没有精细的业务QOS的保证；另外一个是EHT LAN，ETH是LAN王，但是没有HA/OAM/QOS的ETH是不会被运营商广泛用用到WAN上的，在城域网的应用主要是来做internet，提供低成本高带宽复用的能力，和ATM是不一样的。
 ATM的目标定位是比较清楚的：提供高速的single ATM network，multiple services supporting，在业务上，ATM精细化的定义了CBR/rt-VBR//nrt-VBR/UBR等多种业务管道，同时对每种管道，又提供多种AAL，主要是AAL1/2/5，其中AAL1和2在实际应用中区别并不明显，所以主要就是CELL（AAL1/2）管道和FRAME(AAL5)管道，一般来讲分别对应TDM和数据类的业务。同时ATM定义的很好的OAM机制，包括F4/F5，一般来讲，基于VC的F5（不是负载分担设备的F5）比基于VP的F4更多一些。以上只是对ATM的概括介绍，但管中窥豹也能看到ATM是一个多么perfect的协议，所以大家把它应用到anywhere，everything，包括desktop，在当时似乎也无可厚非，并且也确实有部分实际的应用。为此，ATM定义了很多IWF，包括ATM-ETH, ATM-FR(FR over ATM)等等
 现在大家都急着把ATM phase out，尤其是北电在意料中的倒下更是加速了大家抛弃ATM的信心和速度，在商业社会里，资本是冷血无情的代名词，不要跟他们谈感情，那只会受伤更深。但是在当时，进入21世纪的时候，DSLAM、3G和NGN(soft switch/carrier VOIP)开始emerging的时候，并没有好的承载网络可以选择，要么速度低，要么缺少service-awareness QoS，为什么一定要HA和QOS，因为DSLAM/VoIP、3G里面的语音问题，在今天看来，语音那么一点点流量，给他一点足够的带宽不久够了吗？但是这是后生可畏的想法，在当时，甚至有立法要求必须保留传统语音交换作为VoIP的备份，并且当时虽然大家看到数据会成为主要的revenue，但是毕竟语音还是现实的revenue，语音业务是基础，怎敢随便用一个网络承载语音，所以最早的DSLAM是ATM DSLAM，3G的R4之前的版本语音和数据都是ATM，并且当时业界有ATM和router之争，大家当然会互相PK，忽悠客户，当时大体的结果是对于运营商的综合业务网络，基本都建立了ATM network，而数据网络，有实力的运营商会选择建立以太网络，包括EOS
 从上面的performance看，北电选择ATM，抛弃路由器，也在情理之中，至少在revenue上还是赚了很多的。但是毕竟ATM已经过气了，所以ATM肯定是有问题的，从技术的观点看，ATM的完美和IP的简单是冲突的，这是违反IP网络的本质的，而IP是未来是毫无疑问的，所以ATM出局也是毫无疑问的。具体的表现在ATM的完美使其不得不复杂，复杂的结果就是严重影响了速度的提升，本质上是高速的成本太高，IP是属于平民化草根阶层的，ATM有点贵族气质了，草根喜欢大口喝肉，大口吃酒，这不是ATM能够忍受的人生，大家道不同，不足以谋，分手既然已是必然，又何必问佛诸多缘由，所以我们就此打住，顺其自然乃我道家真谛，强求合欢，快亦不快
 对于起步阶段的中国厂商，不用说在ATM和IP之争的话语权，其中的权衡，连美洲的资深巨鳄都不能看清楚，我们也只能妄作分析，所以此时的国内厂商是两条腿走路，虽然不能把获取赌单的高额回报，但至少能获得生存资本，对于强权下的弱者来说，自然要有弱者的哲学，有毕其功于一役的时候，也要有compromising的时候，不可能全部都猛扑上去，也不可能总是compromise。但是大体上，在中国，似乎是ATM略占上风，长远来看，这是个错误的重点
 ATM就先说到这里，在后面的FMC中还会有相当的篇幅考虑ATM迁移的问题，这个不得不处理的累赘也是运营商身上的肉，怎么割能尽量省钱还少伤筋动骨，不是小事
 ATM本身是和X25/FR一样独立建网的，所以绝大多数运营商都有ATM城域网，后面城域网还要考虑ATM和MPLS比较等问题，但在这里先暂告一段落，因为笔者对ATM城域网建设的具体方案不是很熟，并且已经不fashion了，所以也就不去细追究了，有感兴趣的读者和补充相关材料
 下面在正式隆重推出AL的新ME方案前，要拿一章介绍一些非主流的的ME技术和以太网在AL ME的发展，为AL的主流新ME清理一下门户。

作者注：既然选择长期吃技术这碗饭，那么如果不做得有点激情，人生可能会在长期的碌碌中暗淡无聊，没给夕阳的时候留下可资有趣味回忆的材料。本来的计划是写一个METRO NETWROK的三部曲就算了，没想到越写越多，估计可能还要至少3章才能进入尾声

分享

分享

在前面我介绍BGP安全解决方案之一的SoBGP的时候提到过信任网也就是web of trust。后面想想觉得意犹未尽，其实这只是信任模型的一种。网络安全中的信任关系基本上有如下几种类型，很有意思的是这几种东东似乎都可以在现实生活中找到类比。

1.直接信任

这是最简单的信任模型了，就是Peer to Peer的直接信任了。在生活中也很容易找到例子，例如我和我老婆就是直接信任，其中不需要有任何的媒介。试想一下，如果需要中间人才能信任自己老婆，世界将会怎样。同样父子关系也属于这一类的直接信任。在网络世界中，两台直连的设备之间通过共享密钥的方式建立的信任关系，也可以属于此类。

2.层次信任

很典型的就是PKI中一个root ancher下面延伸出来的信任树。笔者觉得现实生活中可以类比一个大家族，父亲和叔叔之间的关系是通过爷爷这个root ancher建立的。你自己和堂兄弟之间也是一样。在网络世界中这种关系的风险就是，如果root ancher出现问题，例如密钥泄露，则树倒猢狲散，整体crash了。现实生活中一样，如果兄弟两个连爹妈都不认，兄弟间很信任的情况几乎不可想象。

3.信任网

最后一个就是信任网了，这个东东好像是PGP最先引入的。可以类比于我们的社交圈子。对于做市场的来说，应该比我等搞研发的更有深刻体会。信任网中可以有直接信任，也可以引入层次信任，总之属于一个超级大杂烩了。

这里有个很有意思的问题，信任网的宽度。对于RIP之类的路由协议，默认最多信任16跳，这就是RIP认为最大的网络宽度或网络纵深。忘记某个人曾经说过，最多一个地球人经过6个中间介绍人可以认识世界上任何一个人，笔者深以为然。例如，笔者认识公司大老板（当然，大老板未必知道我这个小兵），大老板认识总部的大大老板，大大老板认识美国政府高官，美国政府高官认识奥巴马。这样经过4跳，笔者可以认识奥巴马。同理，笔者老婆认识公司大老板，大老板是政协委员可能认识北京高官，高官认识胡锦涛，于是笔者经过4跳也可以认识总书记。神奇吧。

中国有句老话，八竿子打不着的亲戚，这句话是错误的，笔者可以断言，任何亲戚6杆子都可以打到:-)

有了上面的认识，笔者断言虽然人类的数量远远大于路由器，但真实网络世界中的信任网纵深不会太大。

另一个笔者想到的问题是信任的衰减，显然不是线性递减的，至少是指数递减。笔者虽然4杆子打到奥巴马，但笔者就算可以认识奥巴马，但build的信任关系应该是和老婆信任关系的万分之一了。

其实信任关系有不少问题，例如如何从信任网取消信任，如何加入信任网，信任如何传递以及即使是直接信任关系如何区别信任的程度等等。这些都是工程问题，一些实际的系统，例如PGP中应该会考虑所有的这些问题。笔者不谈这些问题，只是胡扯一些联想，有兴趣者可以继续学习。

分享

分享

【陈怀临注：为了配合关于Metro Ethernet的讨论，下面找到了相关的视频。希望对读者有帮助。这是清华大学的一个教学录像。一共5集。更多的看参阅：清华大学城域网教学】

分享

分享

作者注：本系列内容为一家之言，能力碌碌，尤其对于前传部分，涉及多种传统和非传统通讯技术，作者当时初入江湖，涉世未深，懵懂无为，所述内容，粗陋肤浅，必有漏洞，请读者谅解，多加comments，多多修正，不胜感激

（2）        MSTP：对于传统的vendor，在思科IP产品的垄断态势下，直接对抗效果不佳，所以MSTP成为中华风的天下，包括在标准上的努力和斗争，当然华为挟在SDH的强大份额，肯定是这个市场的最大受益者。MSTP通过把TDM/ATM/ETH三网合一，接入SDH，比如可以叫single SDH， multiple service来忽悠运营商，确实很好，这里面ETH的处理，就是EOS，MSTP设备把L2甚至可以做到L3（实际上好像基本没有人这样做，还是只做L2）集成到MSTP设备中，把所有业务传到POP点处理，这在当时的业务需求下，也没什么不好，为什么还要增加一层switch或者router呢？并且L2也可以做简单的本地交换，所以基于MSTP的城域网，至少是中国城域网的一个主流方案。增加SWITCH/ROUTE的方案似乎可以把POP能分布更边缘一些，可以忽悠future-proof，但还是面对MSTP的成本和现实优势，也不太好抵挡。但是MSTP对当时的港湾是很难受益的，肯定要打击这个方案，当港湾准备大力进入光网的时候，因为触动的任老板的核心利益，因此痛遭灭门，被彻底根除，一代通讯天才男哥，也因此流落到不停的寄人篱下的地方，令人扼腕

基于EOS的城域网，其实利用率是很低的，一个是GF的物理封装浪费带宽问题，比如一个100M的ETH，需要155M的VC进行封装，2.5G的SDH，只能支持2个GE封装，10G的SDH到现在为止都不便宜，在当时10G SDH成为北电的利润仓库的情况下，无论如何是不会很便宜的。另外一个是ATM和ETH是物理上独立的承载，没有multiplexing的，当然，在当时还没有成熟的TDM/ATM PW over MPLS/IP的情况下，也不可能multiplexing，所以整体来看，基于MSTP的城域网成为主流也是历史的必然 

2、              IP over WDM/fiber。毫无疑问，这是思科的始作俑，当然是基于自己地位和利益的考量，思科是清楚网络的发展趋势，所以根本不会去收购传统的光网络供应商，思科要的是near future、future和far future。无论从学术理论还是技术发展，IP over WDM无疑是正确的，但是无法让传统运营商放弃已经在光网上的投资，即使思科全部回购都未必能动摇运营商的决心，一个基层IP工程师的要求和薪水，和一个光网络工程师不是在一个level上，这对运营商即使拿到免费的IP网络都未必能承受的。这里主要的选择如下：

（1）        IP over DWDM：城域的DWDM在当时是很难部署的，成本很高并且没有足够的业务买单，近几年才开始的城域DWDM还远没有普及，在当时是不可能的，所以思科虽然推出的当时IP+光的ONS15000系列，直到现在都没有市场，并且思科没有传统vendor的市场，所以这个方案既不符合传统运营商的利益，也没有自己的历史积累，所以对思科基本上没有成功的可能性

（2）        IP over CWDM：这个可行性远高于DWDM，并且技术门槛也低，所以占领了一部分的城域市场，但大家都有份，思科并没有在这个上面获利很多，当时CWDM应该只有4个波，也就是只能有两个环，并且当时还没有10G的CWDM光模块，有也会很贵，所以CWDM的方案有一定的市场份额，但是并没有超出MSTP，毕竟MSTP可以说我的EOS是基于SDH的，有足够的可靠性，而CWDM+switch是没有这么高的可靠性的

（3）        IP over （dark）fiber：不用说，IP独用，并且IP当时还不能做TDM/ATM仿真，传统运营商没法用，除非光纤足够丰富，但毕竟铺光纤也好，租光纤也会，都是要花不少银子的，所以这个方案也是很稀少的应用

现在看来是城域WDM化，TDM/ATM/ETH over MPLS/IP，N网合一，但是即使现在，许多运营商的方案还是让TDM/ATM自然消亡的migration方案，而不是立刻就迁移到IP，运营商有自己实际的考虑，从人力的能力到资源折旧的综合TCO，不是纯技术决策市场，需要smooth 

总结一下这个阶段的城域网，比如大体可以在1998-2003年，主要是基于MSTP的EOS的城域网，主力产品是MSTP的SDH产品和L3交换机，受益厂家主要思科的交换机路由器产品，和以华为/AL为首的MSTP产品

城域网系列2 – ATM插曲

       上面的大段关于城域网的论述，居然没有提到曾经试图辉煌到甚嚣尘上的ATM，是不应该的，所以下面也谈一下ATM的

       在我大学毕业前，ATM就是现在的MPSL，everything over ATM是最fashion的数通网络技术，从核心网到城域网到desktop，基于ATM的网卡都有，你说得多贵？我当时刚搞懂PC机的基本装机和基本C语言的DOS编程，对计算机世界上业界大拿的忽悠文章，只能剪下来收藏，以便以后能读懂的时候再拿出来学习，因为这个报纸和其重量比，基本是免费的，估计卖废纸的价格能很大程度上能弥补购买的成本，当然，我并没有试过，后来这一大堆剪报不知道在哪次搬家中丢掉了，即使没有丢，再拿出来，也许看到的是：早就不流行了，现在哪还有人穿呀。所以当时最喜欢的还是上面的IT普及教育级别的文章，ATM是其中大体不懂而被收藏的topic之一，因为工作关系后来接触到ATM技术，所以现在仍然记得当时ATM剪报的事（未完待续）

注：未完待续可能要等一段时间了，不好确定要多久，也许很快，也许要一个月以后，很抱歉，首席

分享

分享

前言：仍然是内外都忙，频繁出差，私事公事，身心俱疲，但也难以忘记曾经承诺给首席的关于ME的文章，因为最近偶然收到一个基层工程师关于城域网方案选型中why L3的议论，有一点点意思，所以想整理来借用一下，但直接发表显突兀，所以不得不罗嗦几句城域网的一些历史，因此有下面的文章，不想越写越多，感觉很罗嗦，很抱歉读者不能一下读到我刚才提到的文章，如果不喜欢读老太太说历史的内容，那么可以把精力放到对个人更有意义的事情上，作者非常支持读者

城域网目前已经成为承上（CORE）启下（access）的中心，所以成为运营商网络的建设核心，也因此成为IP网络技术的热点，在业务融合和TCO降低的驱动下的FMC更加速了城域网的重要地位，而POP设备的融合和service awareness的需求更增加了城域网的复杂性
城域网的概念大概在90年代才开始，是在IP发展开始普及的时候成为internet承载网络的必不可少的一部分，因为在没有IP之前的数据流量十分有限，并没有充分的业务需求，此时的数据业务要么限制在LAN，要么是低速的基于传统交换机或者DDN的X25/FR WAN网络，这成为制约人类文明发展的barrier，从二战到80年代，在以20世纪初为开始的科学理论和实践创新为基础，40年的经济和技术积累，使信息和知识得到极大的丰富，已经开出超出人脑手动能力的范围，计算机的发展从一个根本上解决的local的问题，但是如何让整个人类能快速的接受已经爆炸的信息，需要创新的工具作为知识传播的引擎，那么在终端计算机化的情况下，网络的IP和路由就成为人类文明发展的理所当然的物理engine，夸张点说像四大文明中的造纸术和印刷术。
所以LAN和低速的WAN必须要颠覆，此前的X25/FR对ACCESS/METRO/CORE的区分并不明显，从协议上来说，X25的的极端复杂当初是为了应付当时线路的不稳定，而线路质量得到改善后的FR，大幅简化但仍然比较繁琐，这都不是太适合城域网的需求，此时基于Ethernet的LAN是另外还一个极端：极其简单，但其广播的本质，低可靠性和管理性也是以传统运营商主建城域网不喜欢的地方，建立数据传输城域网在90年代末PC和internet爆发时高速发展的情况下，是必须的，但是并没有100% perfect的技术，所以21世纪初几年的城域网建设就出现了几种选择
1、 EOS：不是canon相机，是Ethernet over SDH/SONET，是MSTP（Multi-Service Transfer Platform，不是multiple spaning tree protocol）的主要组成部分，无论如何变化，基本就是在SDH上承载Ethernet，可以直接在SDH新建和升级扩容时支持，这是传统vendor极力推崇的方式，当然是利益问题，忽悠的要点无非是成本低，可靠性高，业务支持强。当然事实并非完全如此，在MSTP下，有两种选择
（1） Ethernet L2/L3 Switch or Route rover MSTP，L3 Switch和路由器的主要区别是路由能力和IP业务能力，当时的IP其实没啥业务，一个internet，包括零售和转售，一个是企业专线，这里的区别无非是路由capacity和capability，尤其是指BGP、GRE、uRPF、组播、MPLS/L3VPN等，这里可能更多的还是在MPLS/L3VPN的支持能力上的区别更有意义。决定L2/3 SWITCH和路由器的选择的关键是TCO，显然，switch要比router便宜的多，便宜的原因有技术复杂度导致基于以太的L2/3芯片得以海量使用的原因，也有思科在路由器市场垄断能力更高的原因。当然，实际上，无论是选择switch还是router，当时全球来看，大部分还是思科的市场。但在交换机门槛较低的中国，华为、港湾的拼杀下的思科也很无奈。抛开政治恩怨不说，对于运营商，即使路由器城域网再好，但毕竟成本是不好难承受的，并且从HA和QOS来说，当时的switch和路由器也并无很大的本质区别，并且当时并没有电信级的语音和视频需求，不需要很高的HA和QOS，当时热门的视频会议，在中国还发展出基于传统SDH/E1的标准，历史上也是中华争抢自主知识产权的field之一，当然当时的视频会议更多的是基于WAN的，对城域的需求有限。说到OAM，可能路由器更复杂，至少对工程师的要求更高，这对运营商是必须要考虑的实际问题，所以综合考虑，在当时的ME，基本上没有路由器的事，L2/3 switch大行其道，当然，对于思科，也是乐见其成，受益匪浅，并且因此思科在传统L2的ME技术方案上达到了细致入微登峰造极的地步，思科的65系列交换机是其中最经典的产品，也许今日思科在ME产品的尴尬，也和65的过分成功有些干系.一些具体情况，在后面的文章中会略作细数

分享

分享

3月16日，一年一度的“Spirent Day”研讨会在北京拉开序幕。Spirent Day是思博伦通信每年针对用户举行的大会，旨在研讨最新的通信测试技术和相应的测试方法，同时向用户展示该公司最新的测试方案和产品。

在今年Spirent Day上，思博伦通信向用户全面介绍了数据中心、LTE、汇聚网络、安全与应用、IMS等诸多测试解决方案。除此之外，针对云计算、虚拟化、FCoE在内的一些新技术及应用的测试方案也成为大会的热点议题。在测试理念方面，该公司继续强调网络真实性测试，主张提供网络和设备验证过程中包括真实性、扩展性和性能测试在内的集成解决方案，并继续将QoE和QoS作为明日网络的测试重点。

随着许多新技术的产生及应用，数据中心比以往更大、更快、更复杂。这些新技术包括虚拟化、FCoE和40/100G、云计算等，给测试带来很大挑战，即如何对这些新的关键特性进行评测。例如40/100G以太网，它甚至对测试仪的数据包统计能力都有极高的要求。思博伦通信有针对性地提出，对数据中心有必要使用“整体测试”解决方案。该方案基于Spirent TestCenter平台，包括STC Virtual测试模块、FCoE测试模块，40/100G测试模块等。这意味着不仅测试单个数据中心组件，数据中心的整体性能也会被进行评估。

LTE测试是今年Spirent Day的又一大热点。随着全球运营商的LTE建设被提上日程，越发复杂的网络和终端对测试仪也提出了更高的要求。测试解决方案提供商的实力也相当重要，必须有完整的产品线/方案，能够覆盖运营商的所有测试需求。思博伦通信拥有从核心网到终端测试的全系列产品，并且全面覆盖了CDMA、UMTS及LTE，能够以此为基础更好地满足各层面的测试需求。

评论

虚心接受读者及管理团队的意见，以后新闻稿将以新产品及深度内容稿为主，并且加强评论力度。

因为工作领域的关系，笔者更关注定位于4-7层测试的Avalanche系列测试仪。说句实在话，相对于疯狂增长的DUT性能而言，Avalanche的性能提升可谓十分缓慢。4、5年前，用一对Avalanche2500基本能满足任何防火墙的测试需求；而笔者马上要测试的一款高端产品，厂商自测时竟然使用了20台Avalanche2900。

也许是感受到来自友商客户的压力，思博伦还算及时地推出了最新一代的Avalanche3100。该产品大幅提高了测试流量的生成能力，基准的HTTP新建从2900的25万每秒上升到70万每秒（均为每对性能），并发连接从500万上升到1200万。SSL性能提升更为显著，无论是HTTPS新建能力还是HTTPS带宽都有了巨大提升，非常符合现今云模式应用的发展趋势。

功能方面，可模拟应用层协议的增加也是大势所趋，整合ThreatEx也进一步加强了产品的竞争力。Avalanche3100在接口种类、数量方面相交2900变化不大，最大都支持8个千兆口；万兆规格下则提供了带有2个SFP+接口的测试模块（2900的万兆模块只有一个接口，并且每台设备只能使用一个万兆模块），这显然对用户有比较重大的意义。

猛击此处下载Avalanche3100 Datasheet

纵观Avalanche系列产品的性能变化，从2500、2700、2900到3100一直在加速增长，这从一定程度上反映了Intel x86平台在通信方面处理能力的提升。笔者结合Avalanche2900的配置，综合3100已公开的性能指标，推断该产品应采用Xeon 5500平台搭配24GB或32GB内存。考虑到Xeon系列正在被Intel加入越来越多的有利于通信、安全方面的特性，3100的下一代产品必然是性能更高，成本更低。所以，虽然Avalanche3100与友商产品（尤其是以RMI、EZChip为核心的产品）相比性能仍不突出，但只要保持功能优势，完全可以期待Xeon平台的快速发展扭转局面。

突然想到，最合适在弯曲评论买广告的应该是Spirent、IXIA、BreakingPoint等测试解决方案提供商。没有任何一个媒体拥有比弯曲评论更多的厂商研发类读者了吧？只要他们填需求单的时候多写个一二台，广告费不就回来了么？

分享

分享

赵荣曾为纽约石溪大学 (Stony Brook University) 助理教授，现在是该校 “无线与信息技术中心” 软件部门 总监 (Director at Center of Excellence in Wireless and Information Technology (CEWIT))。赵教授1996年毕业于清华大学计算机系，2001年获得美国维尼州立大学（Wayne State University at Detroit, Michigan）计算机专业博士学位。自2001年至2006年担任纽约石溪大学计算机系助理教授，2006年转至该校 CEWIT 软件系统部门 任总监。 (根据其CV, 其06年后似乎已卸任教职，全职任 软件部门总监，但我们还是继续尊称赵教授吧。)

根据 CEWIT 描述，其作用类似于一个校办公司，让学校研究的最先进技术能够迅速应用于工业界，让广大师生能有一个工业界进行理论联系实践的地方；同时这个校办公司与业界 Cisco, IBM 开展广泛合作，在无线信息技术研究方面具有领先地位；这种模式值得学习。

赵教授的研究方向包括数据挖掘，信息可视化，和软件工程等。点击这里进入赵教授主页。他的联系地址是:

Rong Zhao, Ph.D.

Center of Excellence in Wireless and Information Technology (CEWIT)
Stony Brook University
Stony Brook, NY 11794-2200
631.632.4627 (voice)
631.632.4653 (fax)
rzhao AT cs DOT stonybrook DOT edu

分享

分享

Windows NetMeeting采用的是H.323协议簇，此协议簇是由ITU-T（国际电信联盟电信标准化部门）颁布。本文首先提一下H.323协议，然后点一下NetMeeting，最后分析如何做NAT ALG。

H.323协议架构

以下是H.323的整个协议架构图：

from: http://en.wikipedia.org/wiki/File:Typical_H.323_Stack.png

H.323的协议流程如下：

1. 通过H.225.0 Call Signaling建立连接（如果有网守则还包括RAS，但本文不考虑），并且协商H.245需要使用的端口；
2. H.245协议交互过程，协商RTCP以及RTP端口；
3. RTP/RTCP协议，传输音视频数据。

Data Applications中的协议用于传输非音视频数据，比如NetMeeting使用T.120来传输聊天数据，文件共享等，由于不会产生穿越的问题，所以本文不涉及。

所以H.323的架构还是非常清晰的，两类：连接控制以及数据传输。

NetMeeting和H.323

根据NetMeeting的官方文档【2】，NetMeeting使用了以下端口：

有几点需要注意的是：

1. NetMeeting使用了非H.323的协议ILS以及ULS。本文不考虑；
2. NetMeeting使用T.120作为非音视频数据传输；
3. 在实际的抓包中，TCP/1731并没有出现，本文不考虑；
4. 没有提及H.245以及RTCP，但是这两个协议确实会出现在NetMeeting的数据流中，考虑到有提及H.323 Call Control，并且符合H.245以及RTCP的TCP动态端口特征，不妨假定此项就是H.245和RTCP的总称。

在哪个地方会携带私网信息

以下叙述中，具体包格式请参见【1】。

H.225.0 Call Signaling的私网信息

此协议的交互采用的是以下的流程：

1. 客户端向服务端（TCP/1720）端口发起setup请求，此时会携带客户端的IP/PORT信息，如果客户端在外网，需要将IP修改成内网IP（不要生成NAT会话）；
2. 服务端回应alerting；
3. 服务端回应connect，在这个报文中，服务端会告诉自己的IP以及Port，以便后续客户端能够向服务端的此端口发起H.245连接请求，如下图所示：

不过面对这个数据包，得分两种情况考虑：

1. 如果说服务端是在公网，此端口就不需要进行修改，但是这个端口需要记录下来，而且要打上H.245的标记，不然后面碰到以此端口的H.245协议，NAT将不会认识；
2. 但是如果服务端处于内网（静态映射），IP和端口都需要修改，并且生成会话（注意标注此会话具有H.245特征），以便客户端发起H.245请求时能够匹配到。

H.245的私网信息

H.245会使用H.225.0中协商出来的端口，然后客户端会向服务端的此端口发起连接请求。在此次数据流中，会在以下几个数据包中协商RTP/RTCP将使用的端口：

1. OpenLogicalChannel
2. OpenLogicalChnanelAck
3. OpenLogicalChnanelReject

以下是一个示例：

在这个例子中，开放的RTP/RTCP端口是49603，不过这只是其中的一个，RTP/RTCP会使用多个端口进行数据传输，所以：

1. 在一个报文中可能会告知对端多个端口；
2. 会有多个报文来告知对端自己的端口。

另外，还有以下特征：

1. 客户端和服务端均会告诉对端自己开放的端口；
2. 只要在OpenLogicalChannel, OpenLogicalChnanelAck, OpenLogicalChnanelReject中任何报文中告知了对方自己的端口，后续的RTP/RTCP都有可能使用到这些端口。

那么，NAT此时的策略有：

1. 如果服务端（这个是针对最初的H.225.0连接而言，其实在后来的RTP/RTCP中，没有严格意义上的CS概念）在外网，客户端发送的私网信息需要做ALG（读者请考虑如何判别此为H.245连接），即要把IP和端口修改成公网的（可能会存在TCP reassemble现象，需要特别慎重），并且建立会话，以便让服务端能够主动式的访问此端口；服务端发送的IP/PORT信息不需要关心。
2. 如果服务端在内网，那么服务端发送的私网信息需要做ALG，同时需要把IP和端口修改成公网的，并且建立会话，以便让客户端能够主动式的访问此端口；客户端发送的IP/PORT信息不需要关心。
3. 只要是OpenLogicalChannel, OpenLogicalChnanelAck, OpenLogicalChnanelReject数据中的任何一种数据包，就需要进行1或者2步骤的操作。

经过H.245的ALG之后，已经建立了RTP/RTCP的会话，之后的音视频数据便可以顺利的在这些会话中传输了。

后记

通过以上的分析，可以看到，最基本的NetMeeting通信，有两个地方可能需要做ALG：

1. H.225.0 Call Signaling的setup和connect；
2. H.245中的OpenLogicalChannel, OpenLogicalChnanelAck, OpenLogicalChnanelReject。

参考

1. http://www.packetizer.com/ipmc/h323/standards.html “H.323 Standards”
2. http://support.microsoft.com/kb/158623 “How to Establish NetMeeting Connections Through a Firewall”

分享

分享

Lin Tan现为加拿大滑铁卢大学（University of Waterloo）ECE系助理教授。Tan教授2003年本科毕业于浙江大学计算机系；２００９年毕业于UIUC计算机系，师从著名的YY ZHOU教授。

Tan教授的研究方向包括软件可靠性、软件工程、安全、系统，集中于使用跨学科方法，如机器学习、数据挖掘、计算机体系结构及程序分析的方法解决系统可靠性问题(英文如下：
Software reliability; Software engineering; Security; Systems; Focusing on using interdisciplinary techniques such as machine learning, data mining, computer architecture and program analysis to address systems reliability problems )。

点击http://www.ece.uwaterloo.ca/~lintan/进入教授主页。她的联系地址是:

Electrical and Computer Engineering
University of Waterloo
200 University Avenue West
Waterloo, Ontario, N2L 3G1
Email: lintan at uwaterloo.ca

分享