摘 要:互連網絡為數據、音頻和視頻等應用提供不同的實現服務質量(QoS)的策略,如集成服務模型IntServ、差分服務模型DiffServ和多標簽交換協議MPLS等。隨著多播應用的出現,上述技術不能有效地為多播提供端到端的服務質量。分析上面各種技術在多播應用中的不足,并給出了不同文獻提出的解決方案,同時也分析了異構網絡實現滿足服務質量的多播策略和遇到的問題。最后指出了實現多播服務質量要解決的問題。
關鍵詞:集成服務模型;差分服務模型;標簽交換;服務質量;多播
Research of Multicasting Strategies Based on Quality of Service
CHEN Lin
(Institute of Computer Science,Yangtze University,Jingzhou,434023,China
Abstract:The Internet provides strategies of Quality of Service(QoSfor data,audio and video communication applications,these technologies include IntServ modes,DiffServ mode and MPLS protocol.With the emergence of multicasting applications,technologies above cannot service those applications effectively to realize end to end QoS.This paper analyses the three models to support multicasting applications,and points the shortages of them,and also presents solutions in many other papers.Multicasting strategies and problems in heterogeneous networks environments are also analyzed.
eywords:IntServ;DiffServ;MPLS;service of quality;multicast
1 引 言
互聯網基于IP協議為不同服務類別提供盡力而為的服務。隨著網絡的發展,新的應用不斷涌現,如視頻點播、視頻會議、遠程教育、協同工作等,這些新應用的共同特點是:
(1) 對基于IP的網絡提出了服務質量(Quality of Service,QoS)要求,如必要的帶寬需求、低的端間延遲、低抖動、低丟失率和可靠傳輸等;
(2) 一點發送消息,多點接收,即多播。由于多播技術只是在多播樹的分枝處復制多播流,因而節省了網絡有限的帶寬資源,也減輕了服務器負載,因而具有廣闊的前景。
目前、為應用提供服務質量保證的技術有:多協議標簽交換協議MPLS、集成服務模式IntServ和差分服務模式DiffServ[1]。MPLS協議使用標簽交換在數據鏈路層和網絡層提供快速流量傳輸,在MPLS網絡中,入口路由器根據流的等價類為流加上標簽,核心路由器檢查標簽并轉發流,而在出口路由器,標簽被移除,流被還原。這種方法使得邊界路由器復雜,而核心路由器相對簡單。
集成服務模式IntServ使用資源預留RSVP協議為每個流提供不同的服務質量保證,顯然,該服務模式具有更多的QoS粒度,但是路由器必須為每個流維護狀態信息,不具備可擴展性。
與IntServ模式比較,DiffServ模式是為每類應用提供QoS保證,具有較粗的服務粒度,因而具有更好的可擴展性。在DiffServ區域,邊界路由器根據流的區分服務標記DSCP對流分類,確保符合流的TCA規范,并歸入行為聚集。在該模式中,核心路由器要檢查流的DSCP得到 QoS參數,也需要IP協議的支持(因為DiffServ中的DSCP替代了IP4中的ToS域或IP6中的CoS域)。
上述3種模式適用于滿足服務質量的單播應用,當應用于多播時,由于上述協議的局限性,以及多播應用的特點,會遇到各種困難。本文分析這3種技術在多播中的應用,指出存在的不足之處,并綜述了不同文獻的解決方案。同時指出了混合網絡為多播應用提供QoS的困難和解決的技術路線。
2 IntServ模式與多播
集成模式IntServ是為實時應用如視頻會議等遠程場景而設計的,其內在的固有特性就支持多播。在QoS方面,IntServ結構提供兩類服務,即可控負載型服務和質量保證型服務,前者提供時延、帶寬與丟包率等參數的保證,不能控制固定延遲,但能保證排隊延遲的大小;后者使用資源預留協議RSVP,能保證最小的傳輸時延。
資源預留RSVP協議面向接收者,即由接收端發起資源預留,適用于單播通信和多播通信。針對不同的資源預留請求,RSVP協議定義了3種資源預留模式:固定模式、通配符模式和顯示共享模式。資源預留使用了PATH消息和RESV消息,當信息發送源接收到不同接收成員的RESV消息時,便能根據接收到的消息計算出多播路由樹。
一旦預留了資源,請求的服務質量便能得到保證。但在IntServ模式中,網絡中的每個路由器都要維護各類數據庫(含軟狀態信息等),并且功能模塊實現復雜(如RSVP信令要提供QoS協商機制、各路由器要建立和維護預留信息、對用戶的請求要實現接納許可控制和傳輸流的監控等),導致的直接后果是可擴展性和魯棒性差,導致IntServ模式在大型網絡、尤其是重負載網絡中的應用。
3 DiffServ模式與多播
IntServ模式的不可擴展性是差分模式DiffServ產生的主要原因。DiffServ模式提供兩類QoS服務:快速轉發EF和保證轉發AF。DiffServ模式的主要成員有:核心路由器、邊緣路由器、資源控制器。在該模式中,網絡的邊緣路由器對每個分組進行分類、標記DS域,用DS域來攜帶IP分組對服務的需求信息;在網絡的核心節點上,路由器根據分組頭上的DS碼點選擇碼點所對應的轉發處理;而資源控制器配置了管理規則,為客戶分配資源,他可以通過服務級別協定SLA與客戶進行相互協調以分享規定的帶寬。由于DiffServ已有的框架、結構都是基于單播的,并且多播成員的加入、退出組的動態隨機性以及網絡的異構性使得入口邊界路由器很難對多播流量進行準確的監控,因此將DiffServ模式應用于多播會產生新的問題[2,3],存在的問題主要表現在:
(1) 被忽視的預留子樹問題NRS[4,5]
DiffServ模式中的資源必須先預留再使用,當新成員加入多播樹時(使用PIM-SM,PIM-DM,DVMRP等[1] 協議),在流復制點,DS域的內容被復制到每個流的IP報頭,并且復制的流會獲得與原來多播組相同的DSCP值,并獲得與原先相同的調度轉發處理和區分服務,但是新的加入并沒有經過接納許可控制和資源預留的必要過程。由于額外的資源被繞過區域管理的新增接收節點所消耗,其他正確預留資源的接收者的服務質量將受到負面影響甚至遭到破壞。
要解決NRS問題,就要防止任何未經資源預留就享用高級服務的情況,因此,NRS問題的解決方案是:在子樹與原多播樹的接合點,轉換發向新成員的DS編碼,使其對應的PHB值比默認的PHB級別低,即使用BE(Best Effort)甚至更低的LE(Limited Effort)服務,從而制約新的傳輸流即使對BE服務的資源也不能搶占,維護了公平性,只有當新成員的資源預留許可得到管理實體的確認并得到新的DSCP后,才可以享受比BE和LE級別高的服務質量。
(2)擴展性問題
在傳統多播模型中,隨著多播組成員的增加,多播樹上的路由器需要保存的信息量也將隨之增加,導致在DiffServ 網絡中實現多播傳輸卻存在著可擴展性問題[6]。
可擴展性問題解決方法之一是減少內部路由器的多播狀態[6],即只在邊界路由器進行多播樹的計算與維護工作,在內部路由器中選擇關鍵節點保存多播轉發表,而其他非關鍵中間路由器等同于普通路由器,不保存任何多播組狀態,從而減少內部節點的負擔,提高了可擴展性。另一種方法是消除內部路由器的多播狀態,如EBM[7]和DSMCast[8] 方案。EBM方案只在邊界路由器實現多播,在域內設置一個邏輯管理員節點用于管理域內的多播組的信息,由管理員節點給要加入多播組的新成員選擇一個邊界節點作為加入點,多播流被轉換為多個單播流,所以無須在內部路由器維護多播路由表;DSMCast 則利用了封裝技術,在邊界路由器將多播樹的信息編碼添加到報文頭,內部路由器根據自己的標識符或IP地址以及數據報文中攜帶的多播樹信息查找到相關的轉發記錄,根據此記錄進行報文復制、重新標記與轉發。
(3)異構多播組問題
在一個異構的網絡環境中,多播組的多個接收成員可能希望獲得不同的服務質量,如有的僅希望獲得基本的BE服務,而其他成員希望獲得更高的服務。對服務質量參數要求的不同增加了問題的復雜性。更嚴重的是,不同成員要求的服務種類可能沒有可比性而無發統一服務質量。
DiffServ 是面向接收者的,服務質量等級由發送源來決定。當新成員動態加入多播組時,要求中間路由器能根據用戶不同的QoS 請求標記出口報文的DSCP 值, 而中間路由器不保存每個流的狀態,并且不具備標記功能,如何實現異構多播組問題變成為多播關鍵問題之一。
較好的解決方案[4,9] 是擴展路由表并存儲DSCP,再輔以管理措施。在沒有預約資源的情況下,接收者僅允許獲得LBE服務;當要求的兩種服務類型不能比較優劣時,上游節點只需傳送較好的即可。
(4)發送方任意動態改變問題
在一個多播組中,任意成員都可以發送消息,而DiffServ是單向結構,這意味著,如果有多個發送者同時發送數據流的話,則其資源必須分別預留。
對于只需要BE服務的成員而言,可以在任何時候向組發送數據流而無需任何其他機制。當有QoS需求時,可以在多播路由表中為每個鏈路增加一項DSCP,并配以一定的管理機制。該方案簡單,同時也保持了DiffServ模式良好的可擴展性。
其他如服務類間的公平性問題、多點到多點的多播傳輸問題和共享樹的流量監控問題等[3]也限制了DiffServ模式在多播領域的使用。
4 MPLS協議與多播
多協議標簽交換MPLS是面向連接和IP路由技術的一種新的IETF交換方案的標準。他使用第三層(L3)轉發信息啟動第二層(L2)分組交換,將第二層交換的高性能和第三層轉發的高擴展性融為一體,而IntServ和DiffServ模式工作在網絡層。
基于IP的MPLS網絡包含2個主要組件:控制組件(邊緣標簽路由器LER)和轉發組件(標簽交換路由器LSR)。控制組件使用標準的路由協議(L3)與其他路由器交換標簽并維護前向路由表,當分組到達時,轉發組件使用分組中的標簽信息和控制組件維護的路由表(標簽轉發信息)確定分組的路由。在MPLS多播中,一般使用反向路由協議(RPF協議)來確定接收的分組是否屬于當前多播組,因此,MPLS中的多播路由樹基于標簽值和入口界面來建立。MPLS協議實現多播存在的問題是:
(1) 標簽交換路徑LSP的設計
多播實現需要設計標簽交換路徑,而目前的MPLS協議只涉及點到點的LSP實現,并且組成員的動態關系使得LSP不夠穩定,也需要消耗大量的標簽和信息傳遞開銷;
(2) 流量聚集問題
在MPLS網絡入口,單播流要聚集為多播流并且映射到LSP,其目的在于獲得MPLS的可擴展性,但是這種流量聚集并不適合多播,目前的研究也只是局限在轉發路由器的狀態,而不是包含一組路由器的LSP;
(3) 在核心路由器中L2層的分組交換和L3層的信息轉發共存問題
如果有成員通過非MPLS網絡加入到多播組,則MPLS網絡中的某個邊緣標簽路由器LER必須維護兩個前向路由表,一個路由表在L3層,另一個在L2層(通過非MPLS網絡),使得分組通過該路由器的不同出口到達MPLS網絡的下一個路由器和非MPLS網絡;如圖1所示,S1、S2是發送者,R1、R2是同組中的接收者,標簽交換路由器LER使用RP路由協議[1],相應的多播樹為RPT;當S1發送時,R1、R2通過RPT樹接收分組,如果后來R1通過SPT多播樹加入該會話組,則LER路由器必須為同一個多播組維護兩棵多播樹[10],導致在用SPT替換RPT時,一個成員接收到2份同樣的分組。
對于上述問題,解決方法是要么借助于L3路由,要么建立基于特定源的標簽交換LSP[11]:MPLS的L2層使用ATM模式傳輸標簽,根據多播共享樹中源的不同虛擬通道為不同的源賦以標簽,在圖1的LER路由器中,再將多播路由表從共享樹映射特定源的樹,并構造下一跳的標簽轉發入口。

在屬于不同的自治系的多個MPLS子網絡系統中,可能有些MPLS子網絡不支持邊界網關協議BGP,使得成員的加入請求不能到達其他AS中的數據發送源。解決方法是使用擴展的MPLS協議預先建立滿足QoS約束的多播路由樹[12],由于樹的所有信息嵌套在MPLS協議中,MPLS網絡的內部路由器就不需要支持多播,這種方法的缺點是不適合動態多播環境。
MPLS協議用于多播存在的其他問題是:標簽的缺乏和可擴展性問題,其中后者表現在:路由器需要為每個活動的多播組維護路由狀態信息,增加了組播路由器的處理開銷。
5 混合網絡結構與多播
實用網絡一般是兩種或者兩種以上上述網絡模式的組合,這樣的混合網絡結構在基于QoS的多播應用中同樣存在問題[10],下面分別加以介紹并給出問題的解決方法。
(1) IntServ和DiffServ相結合的多播
如圖2所示,S、R分別為QoS流的發送者和接收者,IntServ區域的邊緣路由器(ER1,ER2)與DiffServ區域的邊界路由器(BR1,BR2)通過接口直接相連,其中,IntServ區域內部使用RSVP信令傳輸分組。存在的主要問題是RSVP信令如何穿越DiffServ區的問題。

解決的方案是DiffServ網絡區域的管理實體BB使用通用的開放策略服務[13](Common Open Policy Service,COPS):當多播組形成時,RSVP的PATH消息在DiffServ區域中通過隧道被廣播到所有的接收者;當接收者希望獲得比BE更好的服務時,使用RESV消息響應,DiffServ接收到RESV消息時,發送COPS消息給其內部的管理實體BB,BB和DiffServ內部的所有路由器進行交互并為接收者預留資源。
在提供端到端QoS方面,IntServ和DiffServ是一對很好的互補模式[2],因此,不同的文獻提供了若干不同的方案和實現機制,如面向可擴展核心的動態分組狀態的DPS方案[14,15],在分組頭部對數據流的狀態進行編碼,缺點是實現比較困難;文獻[16]提出了一種基于3種優先級別的帶寬確保型服務BGS機制來提供端到端的QoS;文獻[17]則提出了另外一種在DiffServ的網絡中結合RSVP協議提供資源預留和QoS保證的框架,其中允許DiffServ邊界路由器與RSVP協同工作,而內部路由器不識別RSVP消息。
(2) MPLS協議和IntServ模式相結合的多播
在MPLS網絡中,一般擴展IntServ中使用的RSVP協議,讓其具有流量工程(TE:Traffic Engineering)的功能來保證應用的QoS。嚴格來講,流量工程TE是為單播應用設計的,文獻[18,19]則在此基礎上提出了不依賴于傳統多播路由協議建立多播樹的方法。
文獻中的解決方案是預先建立在線/離線的滿足流量工程規范的多播樹(稱為PRE-T)。在基于源的多播樹[18]方法中,樹PRE-T被包含在PATH消息中發送到所有的組成員,源接收到成員返回的RESV消息后自底向上產生多播樹;而文獻[19]既可以基于源(為新的多播會話建立多播樹)、又可以基于接收者建立多播樹(為成員動態加入/離開建立多播樹),對于一個多播會話而言,預先計算的樹的信息保存在源的多播信息數據庫MIDB中,當新成員要加入時,發送JOIN信息給源,觸發樹的重新計算。
在MPLS中使用RSVP-TE實現多播的好處是擴展性強,因為MPLS中的路由器不需要維護MIDB信息,缺點是過多的PATH消息和RESV消息增加了網絡的負載。
(3) MPLS和DiffServ相結合的多播
如上所述,MPLS在L2層實現,而DiffServ在IP頭實現。因此,這兩種方法結合實現多播時需要進行服務質量的映射,由于DSCP域有6 b,而MPLS的EXP域只有3 b,在映射時,某些信息將丟失。圖3給出了MPLS和DiffServ結合實現多播的結構。
文獻[20]提出了E-LSP方法,給出了在DiffServ網絡中支持MPLS的細節:當多個行為聚集(BA)映射為單個LSP時,MPLS頭部的EXP域被用來確定每跳行為(PHB),對于一個給定的EFC,一個LSP可以最多支持8個BA。文獻[21]則擴展了E-LSP方法:在發布流量時,對相同的LSP使用相同分類,即標簽被編碼到EFC和服務類信息中,其中定義了三種服務類型:0類(BE服務)、1類(EF服務)、2類(AF1服務和AF2服務)。文獻[22]則提出了在基于MPLS的ATM網絡中支持DiffServ模式的實現算法。

6 結 語
IntServ集成模式、DiffServ差分模式和MPLS協議是Internet上實現服務質量的3種技術,應用于多播時各有其特點,其中IntServ技術固有的特點是支持多播,并且為每個流提供相應的QoS,其嚴重不足是可擴展性問題;DiffServ技術為每類流提供服務質量,具有很好的可擴展性;MPLS和DiffServ具有相似性,缺點是存在“胖邊沿瘦核心”路由器問題。
本文給出上述3種模式在實現基于服務質量的多播時存在的問題和部分解決方案,也指出了3種技術混合實現滿足服務質量的多播時的困難和解決策略。在多播應用需求日益增長的今天,對該問題進行研究具有現實意義。
參 考 文 獻
[1]陳琳.基于服務質量的多播路由算法研究[D].武漢:武漢大學,2005.
[2]林闖,單志廣.計算機網絡的服務質量[M].北京:清華大學出版社,2004.
[3]高茜,羅軍舟.區分服務網絡中IP多播:問題與解決方案[J].計算機研究與發展,2005,42 (5:823-829.
[4]Bless R Wehrle.IP Multicast in Differentiated Services Networks.IETF Internet,2002,draft-bless-diffserv-multicast-05.txt,November.Draft(draft-bless-diffserv-multicast-00.txt,1999.
[5]Bless R,Wehrle .Group Communication in Differentiated Services Networks,First IEEE/ACM International Symposium on Cluster Computing and the Grid,2001:618-625.
[6]Li ,Mohapatra P.QoS-aware Multicasting in diffServ Domains.In:Proc IEEE GlobeCom Taipei:IEEE Press,2002:2 118-2 122.
[7]Striege A,Bouabdallah A,Bettaharet H.EBM:Edge-based Multicasting in diffServ Networks.The 5th Int′l Workshop on Network Group Communications (NGC,Munich,Germany,2003.
[8]Striegel A,Manimaran G.A Scalable Approach to diffserv Multicasting.In:Neuvo Y,ed.Proc.of the IEEE Int′l Conf.on Communications CICCJ.Helsinki:IEEE Communications Society,2001:2 327- 2 331.[]
[9]Bless R,Wehrle .DS Multicast Router Extension,2001,draftbless-diffserv-mcast-routerext-00.txt,July.
[10]Agarwal A,WangB.Supporting QoS in IP Multicast Networks.Computer Communications,2003(26:1 533-1 540.
[11]Acharya A,Griffoul F.IP Multicast Support in MPLS.ATM Workshop,1999,IEEE Proceedings,1999:211-218.
[12]Ooms D,Hoebeke R.MPLS Multicast Traffic Engineering,2002,draft-ooms-mpls-multicast-te-01.txt,February.
[13]Su H C,Hwang R H.Multicast Provision in a Differentiated Services Network[C].15th International Conference on Information Networking,2001:189-196.
[14]Stoica I,hang H.Per Hop Behaviors Based on Dynamic packet States.IETF Internet Draft.
[15]Stoica I,hang H.Providing Guaranteed Services without Per Flow Management.In ACM SIGCOMM′99.http://www.cs.cmu.edu/~hzhang,1999.
[16]Borgonovo F,Fratta L.End-to-End QoS Provisioning Mechanism for Differentiated Services.IETF Internet Draft.July 29,1998.
[17]Detti A,Listanti M,Salsano.Supporting RSVP in a Differentiated Service Domains:An Architectural Framework and a Scalability Analysis.In:IEEE International Conference on Communications(ICC′99,Vancouver,British Columbia,Canada,1999:204-210.
[18]Cheng D.RSVP-TE:Extensions to RSVP for Multicast LSP Tunnels.draft-cheng-mpls-rsvp-multicast-er-00.txt,2001.10.
[19]Chung J M.RSVP-TE.Extensions for MPLS Multicasting Services.2002,draft-chung-mpls-rsvp-multicasting-00.txt,February.
[20]Faucheur F L,Wu L,Davie B,et al.Multi-Protocol Label Switching (MPLS Support of Differentiated Services,RFC3270,2002.
[21]Moh M,Wei B,hu J H.Supporting Differentiated Services with Per-class Traffic Engineering in MPLS[C].Tenth International Conference on Computer Communications and Networks,2001:354-360.
[22]Jing ,Li L.Supporting Differentiated Services in MPLS based ATM Switches[C].APCC/OECC′99,Fifth Asia-Pacific Conference on Communications and Fourth Optoelectronics and Communications Conference,1999,1:91-99.