IP QoS 怎么还不行 IP融合大势所趋，但QoS问题却一直是IP承载语音和视频的软肋。一方面，大家都在呼唤QoS，同时业界也出现了很多QoS的研究成果；而另一方面，QoS在现有网络的实用却很少。QoS给人的感觉像是扶不起的阿斗。
QoS已经喊了十多年了，学术界关于QoS的论文也称得上汗牛充栋了，设备商们的器产品介绍里几乎无一例外都有“支持QoS”一项。但是，目前的现实却是，全世界范围内没几个实际运营的IP网使用了QoS。而且大会小会上，QoS依然是专家们口中的关键词。QoS已经成为IP融合的技术瓶颈，成为运营商铺设电信IP网的心腹大患，成为网络走向NGN道路的拦路虎，成为3G隐忧。业界为QoS做了这么多的努力，出了那么多成果，为什么还会出现目前这种尴尬的局面呢？IP QoS好像是扶不起的阿斗。QoS，你怎么还不行？带着这个问题，笔者走访了一些这方面的专家，期待得到答案。
技术其实还不成熟 截至目前，在IP上实现QoS，归根结底有两种思想。这两种思想已经被IETF作为两种QoS体系以的形式定义下来：一种是IntServ，一种是DiffServ。IntServ借用传统电路思想，在基于IP的呼叫两端,先通过信令建立一条虚连接链路，然后呼叫双方的报文都经此链路传递，从而达到保证传输质量的目的。IntServ基本思想在于以资源预留的方式实现QoS保障。而DiffServ则是传统路由思想的延伸，实现简单。它把流经路由器的数据包按照一定的优先级分类，然后按照优先级顺序将数据包转发至下一跳路由器。
这两种思想各有千秋，也各有弊端。IntServ试图全盘照搬电路思想，为每一路呼叫都建立一条虚链路。相应地，网上的路由器需要为每条链路维护一个状态。当网络规模大到一定程度时，维护链路状态的工作将使核心网路由器不堪重负。这种方式使IP网络良好的可扩展性优点大打折扣。而且，每次呼叫前都必须进行的信令传递过程也很耗费带宽。IntServ的这两个缺点在当前网络条件下几乎是致命的，因此学术界目前研究的重点大部分都集中在DiffServ上。而DiffServ的问题在于，它只着眼于网络中的单个路由器，缺乏全网观念。它只为进入当前路由器的报文设置不同的优先级，而并不关心此报文即将到达的下一跳路由器的状态如何。在网络没有拥塞时，不同优先级的数据包按部就班发送，没有问题。而一旦网络发生拥塞，即使采用DiffServ，报文无论优先级多高，一样会被阻塞。因此，DiffServ被称作软QoS。
DiffServ能够生效的前提是网络不会出现拥塞。如何避免网络拥塞？Internet架构中有另一个研究分支——流量工程（Traffic Engineering，TE）定位此问题。将MPLS TE和DiffServ结合是目前大家比较看好的DiffServ研究方向。但是否有效，还有待验证。
随着研究的深入，人们渐渐意识到，只靠目前存在的某一个QoS体系是无法全部解决IP QoS问题的，应该将IntServ和DiffServ二者思想结合，既有由动态信令机制带来的灵活性，又有按业务进行流分类的简单性。然后，再辅以流量工程以及改进传统最短路径路由方式的技术。这样的方案才是完美的。但是截至目前，多数将这些技术结合在一起的方案还没有标准化。
部署其实并不简单 上面提到的IntServ、DiffServ、以及MPLS TE，其实很多设备商的路由器都已支持，但现实情况却是这些功能往往被束之高阁。这些名词只是设备商销售产品的宣传口号，只是运营商的有备无患。为何会出现这种情况呢？QoS是个全网的概念，是个端到端的概念。一路呼叫的QoS保证不是单靠链路上某一个路由器就能单独完成的，它是链路上所有节点倾力合作的结果。这就涉及到现有网络架构的改进问题。
目前，针对QoS的网络架构设计工作已有很多组织在做，包括Internet2、ETSI、MSF、PacketCable以及3GPP等。大家的总体思路基本一致：在承载层上专为QoS引入一控制层；控制层通过信令指示边缘路由器动态分配资源，建立SLA；在核心路由器使用DiffServ+MPLS TE实现有效的QoS。见图。
在此架构中，呼叫发起端先向Softswitch发送业务申请；Softswitch将此呼叫的业务类型通知Bandwidth Manager；Bandwidth Manager根据获得信息通知边缘路由器制订报文的DiffServ分类规则；然后，有QoS保证的呼叫就可以开始了。
这个架构的好处在于，将QoS的控制功能从承载层分离，减少了路由器的负担。对现有网络更改小，充分利用现有网络中路由器的功能。在与软交换结合后，这个架构可以做到对网络上的报文流按业务识别，从而也解决了电信级IP网的收费问题。
值得一提的是，国内业界也在积极研究QoS的网络架构问题，并积极参与标准制订工作。今年7月，中国电信和华为公司联合向ITU-T提交了两篇相关文稿：D351《一种电信级的QoS方案框架——IP骨干网》，和D350《一种电信级的QoS方案框架——IP接入网》。这两篇文稿分别定义了在IP骨干网和IP接入网中实施电信级QoS技术的框架、结构和需求。两篇文稿的内容已被接受并加入到Y.qosar和Y.123.qos两篇标准草案中。
但是，我们必须说，由于这是一个全新的网络运营环境，各类接口的标准化工作尚待进一步细化。而且，如何实现不同组织制订的网络架构的互通，以及如何降低升级现有网络的成本，都是部署QoS网络架构时不得不面对的问题。
需求其实并不紧迫 一直以来，业内就盛传所谓“假IP电话”，即运营商将自己剩余的传统电话网带宽按照IP电话的价格卖给老百姓。对于老百姓来说是好事，花了IP电话的钱，享受了传统电话的质量，何乐而不为呢。不过，这也从侧面反应出个问题：一些运营商的电路交换业务还是供大于求！至少到目前为止是这样。语音业务向来是运营商收入的大头，“既然既有的资源已经足够满足需求了，我们为什么还要再耗费人力物力去搞什么IP电话呢？对于一项前途未卜的技术，即使要搞，也应该等其它最急需的运营商试验完了，我们再踩着他们的肩膀往上搞么。何苦冒这个风险？”运营商们会这么想。这种逻辑其实很正常。
而且，就算是开通IP电话，“现在的DWDM技术如此发达，核心网带宽达到几十个G，不用QoS，通话质量一样能够得到保证，所以没必要去搞QoS”。美国运营商Sprint就持这样一种观点。事实上，通过科学的网络流量配置，他们确实做到了。
再有，“谁规定IP电话就一定要达到电信级的通话质量标准？为什么就不能把IP电话定位为平民电话？老百姓也许能够忍受相对差些的通话质量，只要花费更少。”一些学者发出这样的声音。想想也对，作为一个天生就不是面向连接的，现在人为地往上添加种种连接功能，以期达到当初设计时想都没想的目标，会不会得不偿失？
后记 在罗列了一些QoS的现状，引用了各种各样的言论后，笔者在这里很想表达一下自己的观点：IP QoS应该搞，也一定能搞成。笔者认为，目前IP QoS的关键还是在于需求驱动，在于运营商。没有实际运行，没有向公众开放，学术界和设备商们研究的再多也是纸上谈兵。而一旦这些研究成果和设备被实践在运营商的网络中，那么尽管开头会出现这样那样的问题，也许会让运营商和设备商手忙脚乱，但这些问题被一一解决的过程也就是QoS走向成熟的过程。可喜的是，国内一些运营商已经开始尝试。中国联通今年6月份率先建立多业务统一网络平台UNINET，并计划明年在15个城市试点IP可视电话。而随着Softswitch和MSTP的试商用，中国电信也在积极地寻求解决QoS的有效方法。这些举措将给各种QoS技术提供一个舞台，让它们充分展示自己、完善自己。
IP QoS，你一定能行！
QoS网络架构拓扑图 IP QoS大事记 IntServ(Integrated Services)
1994年，IETF出版RFC1633(Integrated Services in the Internet Architecture: an Overview)，标志IntServ出现。
DiffServ(Differentiated Services)
1998年，IETF出版RFC2475(An Architecture for Differentiated Services)，标志DiffServ出现。
MPLS
1997年，以公司为首的几家公司提出了MPLS(Multiprotocol Lable Switch)技术。MPLS技术产生的初衷就是为了综合利用网络核心的交换技术和网络边缘的IP路由技术各自的优点。现在，MPLS已成为实现TE(Traffic Engeering)的重要手段，并且与DiffServ结合成为提供QoS的重要手段。
BB(BandWidth Broker)
1999年，Internet 2在QBone体系架构中引入BandWidth Broker，用来实现QoS。虽然由于其过于复杂，目前已基本停止研究，但其思想被后来的PacketCable、3GPP、ETSI、MSF等组织广泛采用。
【责编:admin】
--------------------next---------------------
