一方面，大家都在呼喚QoS，同時業(yè)界也出現了很多QoS的研究成果；
而另一方面，QoS在現有網絡的實用卻很少。QoS給人的感覺像是扶不起的阿斗。
QoS已經喊了十多年了，學術界關于QoS的論文也稱得上汗牛充棟了，設備商們的路由器產品介紹里幾乎無一例外都有“支持QoS”一項。但是，目前的現實卻是，全世界范圍內沒幾個實際運營的IP網使用了QoS。而且大會小會上，QoS依然是專家們口中的關鍵詞。QoS已經成為IP融合的技術瓶頸，成為運營商鋪設電信IP網的心腹大患，成為網絡走向NGN道路的攔路虎，成為3G隱憂。業(yè)界為QoS做了這么多的努力，出了那么多成果，為什么還會出現目前這種尷尬的局面呢？IP QoS好像是扶不起的阿斗。QoS，你怎么還不行？帶著這個問題，筆者走訪了一些這方面的專家，期待得到答案。
技術其實還不成熟
截至目前，在IP協議上實現QoS，歸根結底有兩種思想。這兩種思想已經被IETF作為兩種QoS體系以協議的形式定義下來：一種是IntServ，一種是DiffServ。IntServ借用傳統電路交換思想，在基于IP的呼叫兩端,先通過信令建立一條虛連接鏈路，然后呼叫雙方的報文都經此鏈路傳遞，從而達到保證傳輸質量的目的。IntServ基本思想在于以資源預留的方式實現QoS保障。而DiffServ則是傳統路由思想的延伸，實現簡單。它把流經路由器的數據包按照一定的優(yōu)先級分類，然后按照優(yōu)先級順序將數據包轉發(fā)至下一跳路由器。
這兩種思想各有千秋，也各有弊端。IntServ試圖全盤照搬電路交換思想，為每一路呼叫都建立一條虛鏈路。相應地，網上的路由器需要為每條鏈路維護一個狀態(tài)。當網絡規(guī)模大到一定程度時，維護鏈路狀態(tài)的工作將使核心網路由器不堪重負。這種方式使IP網絡良好的可擴展性優(yōu)點大打折扣。而且，每次呼叫前都必須進行的信令傳遞過程也很耗費帶寬。IntServ的這兩個缺點在當前網絡條件下幾乎是致命的，因此學術界目前研究的重點大部分都集中在DiffServ上。而DiffServ的問題在于，它只著眼于網絡中的單個路由器，缺乏全網觀念。它只為進入當前路由器的報文設置不同的優(yōu)先級，而并不關心此報文即將到達的下一跳路由器的狀態(tài)如何。在網絡沒有擁塞時，不同優(yōu)先級的數據包按部就班發(fā)送，沒有問題。而一旦網絡發(fā)生擁塞，即使采用DiffServ，報文無論優(yōu)先級多高，一樣會被阻塞。因此，DiffServ被稱作軟QoS。
DiffServ能夠生效的前提是網絡不會出現擁塞。如何避免網絡擁塞？Internet架構中有另一個研究分支——流量工程（Traffic Engineering，TE）定位此問題。將MPLS TE和DiffServ結合是目前大家比較看好的DiffServ研究方向。但是否有效，還有待驗證。
隨著研究的深入，人們漸漸意識到，只靠目前存在的某一個QoS體系是無法全部解決IP QoS問題的，應該將IntServ和DiffServ二者思想結合，既有由動態(tài)信令機制帶來的靈活性，又有按業(yè)務進行流分類的簡單性。然后，再輔以流量工程以及改進傳統最短路徑路由方式的技術。這樣的方案才是完美的。但是截至目前，多數將這些技術結合在一起的方案還沒有標準化。
部署其實并不簡單
上面提到的IntServ、DiffServ、以及MPLS TE，其實很多設備商的路由器都已支持，但現實情況卻是這些功能往往被束之高閣。這些名詞只是設備商銷售產品的宣傳口號，只是運營商的有備無患。為何會出現這種情況呢？QoS是個全網的概念，是個端到端的概念。一路呼叫的QoS保證不是單靠鏈路上某一個路由器就能單獨完成的，它是鏈路上所有節(jié)點傾力合作的結果。這就涉及到現有網絡架構的改進問題。
目前，針對QoS的網絡架構設計工作已有很多組織在做，包括Internet2、ETSI、MSF、PacketCable以及3GPP等。大家的總體思路基本一致：在承載層上專為QoS引入一控制層；控制層通過信令指示邊緣路由器動態(tài)分配資源，建立SLA；在核心路由器使用DiffServ+MPLS TE實現有效的QoS。見圖。
在此架構中，呼叫發(fā)起端先向Softswitch發(fā)送業(yè)務申請；Softswitch將此呼叫的業(yè)務類型通知Bandwidth Manager；Bandwidth Manager根據獲得信息通知邊緣路由器制訂報文的DiffServ分類規(guī)則；然后，有QoS保證的呼叫就可以開始了。
這個架構的好處在于，將QoS的控制功能從承載層分離，減少了路由器的負擔。對現有網絡更改小，充分利用現有網絡中路由器的功能。在與軟交換結合后，這個架構可以做到對網絡上的報文流按業(yè)務識別，從而也解決了電信級IP網的收費問題。
值得一提的是，國內業(yè)界也在積極研究QoS的網絡架構問題，并積極參與標準制訂工作。今年7月，中國電信和華為公司聯合向ITU-T提交了兩篇相關文稿：D351《一種電信級的QoS方案框架——IP骨干網》，和D350《一種電信級的QoS方案框架——IP接入網》。這兩篇文稿分別定義了在IP骨干網和IP接入網中實施電信級QoS技術的框架、結構和需求。兩篇文稿的內容已被接受并加入到Y.qosar和Y.123.qos兩篇標準草案中。
但是，我們必須說，由于這是一個全新的網絡運營環(huán)境，各類接口的標準化工作尚待進一步細化。而且，如何實現不同組織制訂的網絡架構的互通，以及如何降低升級現有網絡的成本，都是部署QoS網絡架構時不得不面對的問題。
需求其實并不緊迫
一直以來，業(yè)內就盛傳所謂“假IP電話”，即運營商將自己剩余的傳統電話網帶寬按照IP電話的價格賣給老百姓。對于老百姓來說是好事，花了IP電話的錢，享受了傳統電話的質量，何樂而不為呢。不過，這也從側面反應出個問題：一些運營商的電路交換業(yè)務還是供大于求！至少到目前為止是這樣。語音業(yè)務向來是運營商收入的大頭，“既然既有的資源已經足夠滿足需求了，我們?yōu)槭裁催�要再耗費人力物力去搞什么IP電話呢？對于一項前途未卜的技術，即使要搞，也應該等其它最急需的運營商試驗完了，我們再踩著他們的肩膀往上搞么。何苦冒這個風險？”運營商們會這么想。這種邏輯其實很正常。
而且，就算是開通IP電話，“現在的DWDM技術如此發(fā)達，核心網帶寬達到幾十個G，不用QoS，通話質量一樣能夠得到保證，所以沒必要去搞QoS”。美國運營商Sprint就持這樣一種觀點。事實上，通過科學的網絡流量配置，他們確實做到了。
再有，“誰規(guī)定IP電話就一定要達到電信級的通話質量標準？為什么就不能把IP電話定位為平民電話？老百姓也許能夠忍受相對差些的通話質量，只要花費更少�！币恍⿲W者發(fā)出這樣的聲音。想想也對，作為一個天生就不是面向連接的協議，現在人為地往上添加種種連接功能，以期達到當初設計時想都沒想的目標，會不會得不償失？
后記
在羅列了一些QoS的現狀，引用了各種各樣的言論后，筆者在這里很想表達一下自己的觀點：IP QoS應該搞，也一定能搞成。筆者認為，目前IP QoS的關鍵還是在于需求驅動，在于運營商。沒有實際運行，沒有向公眾開放，學術界和設備商們研究的再多也是紙上談兵。而一旦這些研究成果和設備被實踐在運營商的網絡中，那么盡管開頭會出現這樣那樣的問題，也許會讓運營商和設備商手忙腳亂，但這些問題被一一解決的過程也就是QoS走向成熟的過程�？上驳氖�，國內一些運營商已經開始嘗試。中國聯通今年6月份率先建立多業(yè)務統一網絡平臺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年，以Cisco公司為首的幾家公司提出了MPLS(Multiprotocol Lable Switch)技術。MPLS技術產生的初衷就是為了綜合利用網絡核心的交換技術和網絡邊緣的IP路由技術各自的優(yōu)點。現在，MPLS已成為實現TE(Traffic Engeering)的重要手段，并且與DiffServ結合成為提供QoS的重要手段。
BB(BandWidth Broker)
1999年，Internet 2在QBone體系架構中引入BandWidth Broker，用來實現QoS。雖然由于其過于復雜，目前已基本停止研究，但其思想被后來的PacketCable、3GPP、ETSI、MSF等組織廣泛采用。
