久久久91-久久久91精品国产一区二区-久久久91精品国产一区二区三区-久久久999国产精品-久久久999久久久精品

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

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

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

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

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

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

圖3  集成服務(wù)原型系統(tǒng)總體設(shè)計(jì)框圖

圖4 令牌桶整形示意圖

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

5  對(duì)原型系統(tǒng)的測(cè)試及其結(jié)果
5.1  測(cè)試環(huán)境

圖5

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