承  彥  馮  徑  顧伯萱  馬小駿  顧冠群

1  引言
計算機網(wǎng)絡(luò )系統是CIMS重要的支撐系統之一。支持企業(yè)CIMS應用的計算機網(wǎng)絡(luò )主要提供異機數據訪(fǎng)問(wèn)、異機程序訪(fǎng)問(wèn)和增值通信三大類(lèi)功能。包括支持實(shí)現文件和數據共享的企業(yè)管理信息系統、共享生產(chǎn)數據和過(guò)程管理的ERP（Enterprise Resources Planning；企業(yè)資源規劃）系統，以及支持CAD（Computer Aided Design），CAM（Computer Aided Manufacturing）和CAPP（Computer Aided Process Planning）等應用集成的PDM（Product Data Management）系統。
上述的各種企業(yè)應用系統對支撐網(wǎng)絡(luò )有著(zhù)各不相同的傳輸與處理要求。例如，ERP對延遲的敏感程度非常高，它希望網(wǎng)絡(luò )系統提供最低延遲的服務(wù)；另一方面，視頻會(huì )議、協(xié)同工作等企業(yè)應用，都對網(wǎng)絡(luò )有較高的實(shí)時(shí)請求或高帶寬請求。因此，現代企業(yè)CIMS系統對支撐網(wǎng)絡(luò )提出了很高的服務(wù)質(zhì)量請求。
當前光纖傳輸技術(shù)的快速發(fā)展似乎能夠向網(wǎng)絡(luò )提供趨向于無(wú)限大的帶寬，足以承載大量多媒體或實(shí)時(shí)應用的流量。但是，帶寬的增大并不能避免傳輸突發(fā)帶來(lái)的延遲抖動(dòng)；網(wǎng)絡(luò )帶寬的增加也不意味著(zhù)每個(gè)應用的每個(gè)數據流都能分配到相應增加的服務(wù)速率；另外，結點(diǎn)的處理能力到目前為止仍然是網(wǎng)絡(luò )服務(wù)的瓶頸。
因此，當前有眾多致力于有效管理帶寬的各種服務(wù)質(zhì)量（QoS）相關(guān)的協(xié)議與體系結構的研究。另外，由于Internet是基于TCP/IP協(xié)議簇的，而且較長(cháng)的一段時(shí)間內不會(huì )改變，這樣，通過(guò)Internet所能得到的QoS保證必然應由TCP/IP提供?；贗P的QoS控制的目的就是在盡力而為的IP的基礎之上提供一定程度的預測與管理。
當前有兩種對QoS的基本刻畫(huà)方式[1]，一是資源預留，網(wǎng)絡(luò )資源根據應用的請求，服從相應的管理策略進(jìn)行分配；二是優(yōu)先級，根據帶寬管理標準對網(wǎng)絡(luò )通信量進(jìn)行分類(lèi)并據此分配資源，對標識為較高要求的類(lèi)別提供優(yōu)先處理。前者主要體現在集成服務(wù)體系（IntServ）中，其QoS保證更為嚴格；后者則由區分服務(wù)（DiffServ）來(lái)實(shí)現，提供的是一種比較粗糙簡(jiǎn)單的服務(wù)分類(lèi)。
IntServ/RSVP服務(wù)模式提供了與當前Internet上的各種應用類(lèi)型及其傳輸要求比較匹配的服務(wù)類(lèi)型；同時(shí)，已有的服務(wù)基本沒(méi)有改變，因此已有的應用無(wú)需調整；當前的Internet轉發(fā)機制也沒(méi)有改變，因此，即使當前的系統未作任何升級，端系統仍然能夠從IntServ體系中得到某一類(lèi)別的服務(wù)，但得不到QoS保證。這種服務(wù)體系結構是能夠提供Internet上的端-端服務(wù)質(zhì)量保證的。
下面我們對IntServ/RSVP進(jìn)行分析，并且就原型系統的實(shí)現展開(kāi)詳細的討論。
2  IntServ/RSVP服務(wù)體系結構概述
針對各類(lèi)應用的不同要求，在原來(lái)的服務(wù)之外，集成服務(wù)模型又另外定義了兩類(lèi)具有不同程度QoS保證的服務(wù)：確保服務(wù)（Guaranteed Service）和負載受控服務(wù)(Controlled Load Service)。
2.1  集成服務(wù)模型[3]
圖1給出了在路由器上實(shí)現集成服務(wù)的框架示意圖，它與主機的實(shí)現區別在于不需要進(jìn)行路由處理。集成服務(wù)的實(shí)現框架包括4個(gè)部分：
?  分組調度器――使用隊列及其他機制管理不同分組流的轉發(fā)；
?  分組分類(lèi)器――為了進(jìn)行流量管理，每個(gè)到來(lái)的分組都應映射到一個(gè)類(lèi)中，同一類(lèi)的所有分組得到分組調度器的相同處理；
?  接納控制――采用某個(gè)算法來(lái)決定路由器或主機是否能在不影響其他流的情況下，將所請求的QoS給予一個(gè)新流；
?  預留建立協(xié)議――在端系統和路由器創(chuàng )建并維護流狀態(tài)。
 

圖1  集成服務(wù)框架示意圖

(1)  負載受控服務(wù)
負載受控服務(wù)[5]在網(wǎng)絡(luò )重載情況下提供近似網(wǎng)絡(luò )輕載時(shí)的QoS。這種服務(wù)的QoS是不精確的；它關(guān)心的是長(cháng)期的服務(wù)結果。要想獲得這種服務(wù)，應用應該向網(wǎng)絡(luò )結點(diǎn)提供一個(gè)對其產(chǎn)生的流量的總體描述，用Tspec表示；收到這種服務(wù)請求的網(wǎng)絡(luò )元素必須根據請求者提供的Tspec，保證在處理這一類(lèi)流量時(shí)有適當的帶寬和分組處理資源，例如路由器或交換機端口的緩沖空間。
(2)  確保服務(wù)
確保服務(wù)[6]提供確定的帶寬與端―端延遲的保證，對于遵守規范的分組保證沒(méi)有排隊丟失。這種服務(wù)是專(zhuān)為嚴格的實(shí)時(shí)服務(wù)而設的。當數據流符合速率為r、深度為d的令牌桶時(shí)，如果R>r，則延遲的上界為b/R。為了允許對這個(gè)理想模型的偏離，WFQ調度器引入兩個(gè)差錯參數，C和D。下文將詳細討論這種調度規則。這樣，延遲的上界變?yōu)?BR>b/R+C/R+D                             (1)
在確保服務(wù)中，峰值速率p是有所限制的，以減小延遲的上界。另外，由于流是由分組組成的，因此還要考慮最大分組長(cháng)度M。加上所有這些因素，確保服務(wù)的更精確的端－端排隊延遲的上界如下：
    (2)
式(2)中， 和 分別表示端―端的數據路徑上各路由器的差錯參數C和D的累積和。
對于想要調用確保服務(wù)的路由器，它必須得到數據流的通信量特性（tspec）和預留特性(rspec)。
Tspec參數包括：p 流的峰值速率；b 令牌桶深度；r 令牌桶速率；m 最小管理單元；M 最大報文長(cháng)度；
Rspec參數包括：R 帶寬，即服務(wù)速率；S 松弛參數。
2.2  集成服務(wù)體系中基于應用的QoS服務(wù)
在QoS體系結構中，QoS究竟是一種基于應用的服務(wù)，還是一種傳輸層的行為，或者兩者兼而有之。如果作為基于應用的服務(wù)，就意味著(zhù)QoS體系結構有必要擴展到某種形式的應用程序接口（API），這樣，應用可以與網(wǎng)絡(luò )協(xié)商其QoS請求，并且根據網(wǎng)絡(luò )的應答調整其行為。而如果作為一種傳輸層行為，任何應用程序都可以通過(guò)改變其主機配置或者其他網(wǎng)絡(luò )控制點(diǎn)的配置，而對應用程序本身不做任何改變，來(lái)使其流量被某種形式的QoS網(wǎng)絡(luò )服務(wù)承載。這種方式的優(yōu)點(diǎn)是，應用程序行為不需要改變；缺點(diǎn)是，應用程序無(wú)法與網(wǎng)絡(luò )或策略控制系統進(jìn)行對網(wǎng)絡(luò )管理有用的信息交互，缺乏這些信息，網(wǎng)絡(luò )提供的服務(wù)應答極有可能遠遠超過(guò)應用程序的真實(shí)請求。另外，這種方式還有一個(gè)弱點(diǎn)，是關(guān)于那些可以調整其流量狀態(tài)以適應網(wǎng)絡(luò )可得資源的應用程序，在傳輸層機制下，網(wǎng)絡(luò )資源信息有可能被傳輸層獲得，卻無(wú)法傳給應用程序。
在集成服務(wù)體系結構中，顯然不能用傳輸層的方式來(lái)實(shí)現QoS。應用程序要想在這種環(huán)境下正常工作，確實(shí)需要進(jìn)行某種調整。應用必須向服務(wù)預留模塊提供其預期流量的整體描述，換句話(huà)說(shuō)，應用必須預報其流量負載。此外，應用必須能夠與網(wǎng)絡(luò )共享預留狀態(tài)；如果網(wǎng)絡(luò )狀態(tài)出現故障，應用就能立即知道。更概括的說(shuō)，如果應用程序自愿提供對其通信量特性的精確描述，并且為了使其通信量符合描述，愿意被控制（policing），則網(wǎng)絡(luò )必須對應用的請求形成精確的應答。
因此，在IntServ/RSVP體系結構中，向應用程序提供QoS就是基于應用的方式。這種方式還有一個(gè)特點(diǎn)，就是接收方協(xié)商能力。當發(fā)送方建立一條穿越網(wǎng)絡(luò )到達接收方的QoS路徑時(shí)，如果接收方不能吸收隨之而來(lái)的數據流，則這條路徑是沒(méi)有任何價(jià)值的。這意味著(zhù)具有QoS能力的應用程序還需要某種形式的端―端能力協(xié)商，可能是通過(guò)某種協(xié)議，允許發(fā)送方將其QoS請求與網(wǎng)絡(luò )能夠提供的流資源與接收方能夠處理的流資源這兩者的較小值進(jìn)行匹配。在RSVP中，就集成了這樣的端―端應用程序協(xié)商的交互。
如果要提供高質(zhì)量的服務(wù)，對于端―端服務(wù)傳輸，有必要在請求服務(wù)的應用程序級上進(jìn)行擴展。因此，我們對RSVP API進(jìn)行了研究與改進(jìn)。
3  應用程序接口
3.1  資源預留協(xié)議及其應用程序接口實(shí)現模型
Internet上的應用程序通過(guò)API向網(wǎng)絡(luò )提出QoS請求，然后本地的RSVP控制程序將使用RSVP協(xié)議沿數據流路徑傳播這個(gè)請求；各路由器依據其可用資源情況決定是否接收或拒絕請求。若預留未成功，本地RSVP控制程序將通過(guò)API把結果返回給提出請求的應用程序。
即RSVP API（簡(jiǎn)稱(chēng)RAPI）[10]，基于一個(gè)連接在應用上的客戶(hù)段程序庫，通過(guò)對這個(gè)庫的調用完成上述功能。其執行模式如下：RSVP由一個(gè)用戶(hù)級守護程序（daemon）在主機執行，RSVP客戶(hù)程序庫中的過(guò)程通過(guò)一個(gè)Unix域的socket與本地RSVP daemon交互。RAPI就是應用與客戶(hù)程序庫之間的接口，其實(shí)現模型如圖2所示。
RAPI向應用程序提供了一組函數，接收應用的參數，并將這些參數轉換為RSVP守護進(jìn)程可以理解的信息；另一方面，把守護進(jìn)程的信息向應用報告，這是通過(guò)一系列的事件上傳過(guò)程（EVENT UPCALL）來(lái)實(shí)現的；任何消息的發(fā)送或接收都會(huì )在端系統引起一個(gè)事件的發(fā)生，通過(guò)相應的事件上傳，應用程序能夠立即得到消息的情況。
 

圖2  RSVP及其API實(shí)現模型

3.2  應用程序接口存在的問(wèn)題
在對RSVP API研究之后發(fā)現，對于試圖通過(guò)應用程序接口啟用資源預留功能的應用程序來(lái)說(shuō)，如何提供QoS處理所需要的參數是一個(gè)難題，即使是向相對簡(jiǎn)單的RAPI也要提供一系列底層QoS保證所必須的參數。例如，會(huì )話(huà)的接收方可以通過(guò)調用下列函數向網(wǎng)絡(luò )提出預留請求：
Int Rapi_reserve(int  Sid,  /
int  flags,
Struct Sockaddr   *Rhost,
int  StyleId,     /*預留風(fēng)格代碼*/
rapi_stylex_t   *style_Ext
rapi_policy_t   *Rcvr_Policy,
int  Filter_SpecNo,
rapi_filter_t   *Filterspec_list,
int  FlowspecNo,
rapi_flowspec_t  *Flowspec_list /*流規范列表*/
)
加粗的參數對于預留是至關(guān)重要的。預留風(fēng)格是資源預留協(xié)議為容納多點(diǎn)投遞而設計的多路預留合并的風(fēng)格；流規范列表中的各項就是應用希望從網(wǎng)絡(luò )獲得的集成服務(wù)類(lèi)型（GS或CLS）的流描述，前文已經(jīng)給出GS的7元參數。這些參數由應用程序在調用時(shí)提交是不合理的，也是不現實(shí)的。這些參數以令牌桶參數為代表，即令牌桶深度b和令牌桶速率r。當網(wǎng)絡(luò )元素提供確保服務(wù)與負載受控服務(wù)時(shí)，這兩個(gè)參數在流量整形與流量調度過(guò)程中起著(zhù)重要的作用，直接影響到調度的效果與服務(wù)的質(zhì)量。但是，要求應用去了解并給出網(wǎng)絡(luò )元素底層處理所需的元素是不合理的，也是違背Internet網(wǎng)絡(luò )設計原則的。
因此，我們對于改進(jìn)應用程序接口作了深入的研究，主要是針對流量整形與調度的機制進(jìn)行。我們認為，要使應用程序真正能夠方便的利用應用程序接口與網(wǎng)絡(luò )進(jìn)行服務(wù)協(xié)商，網(wǎng)絡(luò )底層的細節應該是對應用透明的；用戶(hù)不需要關(guān)心網(wǎng)絡(luò )元素使用的調度算法需要什么樣的參數。另一方面，一個(gè)良好的透明的接口也可以有效的防止因應用提交數據不當而引起的服務(wù)協(xié)商失敗。
4  集成服務(wù)原型系統實(shí)現
4.1  系統總體設計
要想通過(guò)資源預留和調度來(lái)提供QoS，則參與端―端通信的各系統與組成部分有必要依次執行下列步驟：
?  QoS規范描述：通信量數量及其請求的QoS都應該有一個(gè)明確的描述，以便系統決定是否提供以及提供何種QoS；
?  能力測試與QoS計算：應用提交其QoS請求后，系統的接納控制必須檢查，這些請求在考慮到已有的預留后是否能夠得到滿(mǎn)足；如果能夠，計算出可提供最好的QoS，相應的，應用也得到一定級別的QoS保證。
?  資源預留：根據提供的QoS保證，預留適當的資源――傳輸或處理帶寬等；
?  實(shí)現QoS確保：QoS確保必須由適當的資源調度來(lái)實(shí)現。
與這4個(gè)步驟相對應，并且參考集成服務(wù)實(shí)現框架，我們對集成服務(wù)原型系統進(jìn)行了總體設計，如圖3所示。QoS規范描述由應用程序接口完成；能力測試與QoS計算由接納控制模塊完成；QoS最終由資源調度模塊實(shí)現。而RSVP作為在主機與路由器之間協(xié)商服務(wù)參數的信令協(xié)議，本身并不執行任何資源的預留。但是如果信令傳遞不當或發(fā)生故障，便會(huì )直接影響到預留的成敗。
4.2  流量整形
我們采取典型的令牌桶機制進(jìn)行流量整形。網(wǎng)絡(luò )設備使用能容納b字節令牌的令牌桶來(lái)衡量一個(gè)到達分組序列是否能滿(mǎn)足參數要求；同時(shí)，設備以r字節/秒的速率向桶中添加令牌。如果桶中的令牌數大于或等于分組長(cháng)度，就認為這個(gè)分組是符合令牌桶通信量描述的。具體說(shuō)來(lái)，當分組到達時(shí)，設備檢查在桶中的當前令牌數X與分組長(cháng)度L，若  ，則分組符合描述；否則，認為分組違反描述，如圖4所示。

圖3  集成服務(wù)原型系統總體設計框圖

圖4 令牌桶整形示意圖

4.3  PGPS調度策略[7,8]
真正向通信量提供QoS保證的是某種調度策略的有效實(shí)現。通過(guò)建立適當的流量模型，應用必要的排隊理論，我們可以對通信量的網(wǎng)絡(luò )行為進(jìn)行分析，對于特定的調度策略，可以得到其端―端網(wǎng)絡(luò )性能的分析。上層采用的服務(wù)體系結構，以及進(jìn)行網(wǎng)絡(luò )服務(wù)協(xié)商的內容，都是基于底層調度策略的模型分析的。因此，我們對集成服務(wù)使用的加權公平隊列調度（Weighted Fair Queuing，WFQ，又稱(chēng)PGPS）進(jìn)行相關(guān)分析，以便從中獲得RSVP信令交互內容的依據。
設 為分組 在PGPS條件下的離開(kāi)時(shí)刻，則對于所有的分組 ，有
                           (3)
式(3)中 是最大分組長(cháng)度， 是服務(wù)器的恒定服務(wù)速率。
當進(jìn)入的通信量經(jīng)過(guò)整形，其平均到達速率為r，令牌桶深度為b，并且當前會(huì )話(huà)I的最大分組長(cháng)度是L，則對于本地穩定的會(huì )話(huà)I來(lái)說(shuō)，端－端的延遲有如下結果：
         （4）
4.4  對資源預留協(xié)議應用程序接口的改進(jìn)
為了解決應用程序接口的問(wèn)題，對照確保服務(wù)規范中提出的端-端延遲的上界，我們提出在PGPS調度的條件下，為應用程序確定通信量參數的方法。在所有參數中，令牌桶參數是難以確定的，卻又是直接影響到調度效果的重要參數。根據公式(2)和(4)，我們可以做出如下假設
 ，即將令牌桶深度置為應用數據流的突發(fā)大??； 
 ，即服務(wù)器分配給會(huì )話(huà)的速率，就是應用程序請求預留的帶寬對于每一類(lèi)實(shí)時(shí)應用或多媒體應用都有一個(gè)相對固定的要求，例如MP3聲頻流的帶寬是128kbps，MPEG-1視頻流的正常工作帶寬是1.5Mbps，MPEG-2視頻流的一般質(zhì)量要求帶寬是5Mbps左右，高質(zhì)量帶寬要求是8Mbps左右；
令牌桶速率 根據 的值確定，保證 。為了處理方便，可以近似在數值上令 ，該值可以滿(mǎn)足多數應用的要求。
其他參數，如 等，均可以在令牌桶參數確定的情況下，根據應用的不同要求比較方便的獲得。
綜上所述，我們對API進(jìn)行了改進(jìn)。按照應用數據流對預留的不同要求，我們研究了各種數據流的一般情況，按照令牌桶機制的要求，制定出符合一般規律的令牌桶參數及其他流特性參數的值，主要由以下方面決定：
?  集成服務(wù)模式（確保服務(wù)或負載受控服務(wù)）；
?  預留質(zhì)量要求（高、中或低）；
?  數據流類(lèi)型（MPEG視頻流、音頻流或其他類(lèi)型的數據流）；
經(jīng)過(guò)上述改進(jìn)，接收雙方在給定通訊地址和端口以后，只需要對上述要求進(jìn)行選擇，就可以發(fā)送消息，這樣對應用程序比較合理。

5  對原型系統的測試及其結果
5.1  測試環(huán)境

圖5

如圖5所示，由一臺雙網(wǎng)卡PC機模擬路由器，連接兩個(gè)子網(wǎng)，會(huì )話(huà)的雙方分別位于不同網(wǎng)段內。選擇FreeBSD 3.4作為端系統與路由器的操作系統，因為需要對操作系統內核進(jìn)行修改。
5.2  協(xié)議一致性測試
我們首先需要測試的是系統與作為標準發(fā)布的ISI release 之間的協(xié)議一致性。發(fā)送方使用標準的API及其附帶的測試程序，接收方使用我們改進(jìn)的API及其測試程序。
?  雙方通過(guò)指定一致的目的端（接收方）IP地址和端口建立會(huì )話(huà)；
?  發(fā)送方給出己方的地址與端口、發(fā)送流量特性（Tspec），發(fā)出PATH消息；在接收方顯示PATH消息事件的輸出信息，包括會(huì )話(huà)信息（接收方地址與端口）和路徑信息（Tspec、ADSpec）；
?  在接收方顯示PATH消息事件的輸出信息，包括會(huì )話(huà)信息（接收方地址與端口）和路徑信息（Tspec，ADSpec），表明接收方收到PATH消息；此時(shí)，接收方給出己方的地址與端口和用來(lái)過(guò)濾報文的發(fā)送方地址信息，選擇服務(wù)模式、服務(wù)質(zhì)量，發(fā)出RESV消息；
?  在發(fā)送方顯示PATH消息事件的輸出信息，包括會(huì )話(huà)信息（發(fā)送方地址與端口）和預留信息（Flowspec，Filterspec），表明發(fā)送方收到RESV消息；
?  此時(shí)，一次預留會(huì )話(huà)交互成功。
雙方使用不同的API完成了此次會(huì )話(huà)，表明改進(jìn)后的API與標準的API在協(xié)議的運行上是一致的。
5.3  視頻應用的測試
我們使用一個(gè)MPEG-1視頻點(diǎn)播應用程序進(jìn)行系統服務(wù)質(zhì)量測試。視頻點(diǎn)播的客戶(hù)方試圖從服務(wù)器接收到高質(zhì)量的MPEG-1視頻數據，并進(jìn)行實(shí)時(shí)播放。視頻流使用UDP作為傳輸層協(xié)議。發(fā)送方與接收方均使用改進(jìn)的API進(jìn)行QoS協(xié)商與預留建立。對于參加測試的應用程序來(lái)說(shuō)，正常工作的帶寬需求是1.5Mbps。
測試包括2個(gè)步驟：
(1)  網(wǎng)絡(luò )輕載條件下，無(wú)論點(diǎn)播客戶(hù)端是否提交預留請求，所收到的視頻播放正常。這表明只要提供足夠的帶寬，視頻點(diǎn)播應用就能夠正常工作；
(2)  與發(fā)送方在同一子網(wǎng)內的輔助主機A1產(chǎn)生用于干擾的UDP流量，并向與接收方在同一子網(wǎng)內的輔助主機A2發(fā)送。當干擾流量逐漸增加，直至剩余帶寬接近1.5Mbps時(shí)，客戶(hù)端的播放發(fā)生了變化：
?  沒(méi)有預留的情況下，點(diǎn)到點(diǎn)的視頻傳輸受到網(wǎng)絡(luò )帶寬的影響，客戶(hù)端的播放出現嚴重的連續馬賽克現象；
?  當應用請求建立預留時(shí)，客戶(hù)端通過(guò)HPNAPI發(fā)出預留請求，指明其數據類(lèi)型（MPEG視頻流），服務(wù)質(zhì)量請求（中等），請求服務(wù)類(lèi)型（確保服務(wù)）。在預留建立之后的傳輸中，在同樣的條件下，接收端仍然能夠正常接收視頻數據流，并進(jìn)行清晰的播放。
上述測試表明，通過(guò)我們改進(jìn)的應用程序接口，應用要求的帶寬預留確實(shí)在網(wǎng)絡(luò )結點(diǎn)上得到了適當的設置；通過(guò)套接口的進(jìn)一步工作，應用的通信量參數被正確的傳遞到RSVP守護進(jìn)程。一旦接納控制接受了預留請求，應用所需的服務(wù)質(zhì)量將在各結點(diǎn)的流量調度的作用下，依據通信量參數，獲得應有的保證。這樣，在A(yíng)PI的幫助下，應用與網(wǎng)絡(luò )協(xié)商服務(wù)，最終獲得了面向應用的服務(wù)質(zhì)量保證。
6  結論
借助于適當的理論分析和原型系統的實(shí)現測試，我們對集成服務(wù)體系下面向應用的服務(wù)質(zhì)量保證進(jìn)行了上述研究。針對實(shí)際的企業(yè)網(wǎng)絡(luò )應用數據流特點(diǎn)，我們還需要作進(jìn)一步的研究。勿庸置疑的是，這方面的研究對于確保企業(yè)網(wǎng)環(huán)境下的服務(wù)質(zhì)量是有價(jià)值的。關(guān)于集成服務(wù)體系的研究目前仍在繼續；更多的新型的QoS協(xié)議與體系結構不斷的被提出來(lái)，要想獲得真正可靠的服務(wù)質(zhì)量保證，孤立的研究一個(gè)協(xié)議是不合適的。必須從整個(gè)網(wǎng)絡(luò )的體系結構上進(jìn)行自上而下的探索。