日本在线www-日本在线播放一区-日本在线不卡免费视频一区-日本在线不卡视频-成人影院久久久久久影院-成人影院一区二区三区

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

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

圖1  集成服務框架示意圖

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

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

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

圖3  集成服務原型系統(tǒng)總體設計框圖

圖4 令牌桶整形示意圖

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

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

圖5

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