国产欧美日韩精品a在线观看-国产欧美日韩精品一区二区三区-国产欧美日韩精品综合-国产欧美中文字幕-一区二区三区精品国产-一区二区三区精品国产欧美

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

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

圖1  集成服務框架示意圖

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

圖2  RSVP及其API實現模型

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

圖3  集成服務原型系統總體設計框圖

圖4 令牌桶整形示意圖

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

5  對原型系統的測試及其結果
5.1  測試環境

圖5

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