張景輝 王雅坤 王庚

（唐山學院，唐山 063020）

0 引言

衛(wèi)星通信網絡已經成為全球通信基礎設施不可缺少的一部分。衛(wèi)星鏈路有著不同于地面有線環(huán)境和固定應用的一些特點，如：通信時延長、鏈路誤碼率高、帶寬資源少、鏈路連接的間斷性等，因此傳統(tǒng)的TCP中使用的擁塞控制算法難以滿足要求，必須讓IP層參與網絡的擁塞控制。

擁塞控制算法[1]可分為在端系統(tǒng)上使用的源算法和在網絡設備上使用的鏈路算法兩種。源算法中使用最廣泛的是TCP協(xié)議中的擁塞控制算法。鏈路算法的研究主要集中于“主動隊列管理”AQM（active queue management）算法研究。TCP中使用的擁塞控制算法已經成為保證Internet穩(wěn)定性的重要因素。

擁塞控制[2]的解決方案一般被分為兩類：一類是開環(huán)，一類是閉環(huán)。閉環(huán)方案是通過反饋環(huán)路將擁塞信息從檢測點傳送到可采取行動的地方。星地鏈路時延大，出現擁塞時再進行反饋的方案不易實現。因此，本文采用開環(huán)方案，通過在交換分組之前對資源進行預留來避免擁塞，并將RSVP協(xié)議用于星上交換機的擁塞控制。

1 RSVP協(xié)議

作為IP網絡中實現資源保留與控制的協(xié)議，RSVP提供了一套完整的信令機制，該機制可被用于在網絡中為數據流建立一條具有足夠帶寬的單向通道，從而實現對數據流的可預測性傳輸。RSVP協(xié)議包含一個信令的呼叫建立過程。在此呼叫建立過程中，用戶提出帶寬和QoS參數的請求。網絡中的參與RSVP協(xié)議過程的路由器將對于自身是否有足夠的資源做出回應。RSVP中從源到目的地所經過的每一臺路由器都需要進行這樣的處理。當一個中間節(jié)點不能滿足相應的請求時，它便向接收方發(fā)送拒絕信息，拒絕此QoS請求，中斷信令的處理過程。如果網絡和用戶能夠對提出和響應的QoS參數達成一致，則呼叫被正式建立，為該流分配鏈路帶寬和緩沖區(qū)空間，并且把相關的流狀態(tài)信息裝入路由器中；同時，網絡中的路由器對呼叫狀態(tài)信息進行維護。當源站開始向網絡發(fā)用戶數據包時，為了確保流量不超過其達成一致的QoS流量參數，網絡將對其進行監(jiān)視，路由器查找對應的資源列表，判斷它是否被預留了帶寬[3]。

RSVP協(xié)議在封裝時處于傳輸層的位置，但并不用來傳輸應用層的數據，類似于ICMP、IGMP及路由協(xié)議，也是一種Internet控制協(xié)議。對于不支持RSVP的路由器來說，該協(xié)議是透明的，即不支持RSVP的路由器可簡單地將RSVP分組作盡力傳送處理。RSVP共有7種報文：1）路徑請求Path；2）預留請求Resv；3）路徑錯誤PathErr；4）預留出錯ResvErr；5）路徑拆除PathTear；6）預留清除ResvTear；7）預留確認[4]。

2 星上IP交換的擁塞控制

星上擁塞控制的基本過程是：地面站點在發(fā)送IP數據之前，先向星上IP交換機發(fā)送路徑請求消息，星上交換機根據星上交換機中緩存區(qū)的利用情況決定是否為該數據預留資源，然后為地面站點發(fā)送資源預留或拒絕消息，地面站點只有在收到星上交換機的資源預留消息后才能發(fā)送IP數據報文，否則等待并定期發(fā)送路徑請求消息。

Internet上出現的接近40%的IP數據是40字節(jié)的不帶數據的TCP回應報文。在進行擁塞控制時，如果對于地面站點待發(fā)送的每個IP報文都進行路徑的請求，那么就會出現大量的路徑請求及資源預留消息，對于短報文來說，傳輸效率較低，且時延更大。因此，本文在進行星上擁塞控制時，對40字節(jié)和44字節(jié)的短報文并不進行路徑請求，由于短報文分組占近40%，采取該策略將減少大量的路徑請求及預留消息。

2.1 星上擁塞控制的消息類型及格式

采用RSVP中的路徑請求消息Path和預留請求消息Resv來完成，根據原有的消息格式重新設計。RSVP協(xié)議中的消息封裝在IP數據報文中，通過IP頭部中的協(xié)議域來指示該報文屬于RSVP協(xié)議中的消息報文。如下表所示。

表1 RSVP協(xié)議的通用頭部

表2 星上擁塞控制對象格式

在表1通用頭部中，Vers域指的是協(xié)議版本號；Flags域中是標志比特；Msg Type域指示的是消息類型，路徑請求消息該域的值是1，預留請求消息中該域為2；Send_TTL是指發(fā)送該消息的IP報文的TTL值；在RSVP Length域中說明了以字節(jié)為單位的RSVP消息的總長，包括常見的頭部及可變長的對象；另外通用頭部中還有一個16比特的校驗和域。

如表2所示，Path消息中，主要傳送的信息有源、目的IP地址，待發(fā)送IP報文的標識號及IP報文的總長度等；Resv消息中除了待發(fā)送IP報文的一些信息如目的地址、標識號、報文總長度外，還要有是否接受該請求的標志位信息。

2.2 協(xié)議交互過程

采用RSVP協(xié)議進行資源預留來避免星上交換機緩存區(qū)的擁塞時，地面發(fā)送站點及星上交換機需要發(fā)送或接收不同的消息來進行資源的預留和數據的交換。對于消息的丟失或錯誤，地面發(fā)送站點和星上交換機都需要采用一定的措施來保證交換的正常進行。

圖1是正常情況下，資源預留協(xié)議及傳輸數據的過程，地面的發(fā)送站點只有在收到星上IP交換機的接受資源預留請求消息后才能向星上發(fā)送IP報文。

圖1 正常情況下，資源預留協(xié)議及傳輸數據過程

圖2是當地面發(fā)送站點向星上IP交換機發(fā)送的路徑請求消息出錯或丟失時，地面站點和星上交換機傳輸數據的情況。為減少星地之間的交互，在發(fā)送站點和星上交換機采取一定的超時重發(fā)策略。地面發(fā)送站點直到收到星上IP交換機發(fā)出的接收資源預留請求消息才能發(fā)送IP報文。

圖2 路徑請求消息出錯或丟失時，資源預留協(xié)議及傳輸數據過程

圖3 是當星上IP交換機發(fā)送給地面站點的資源預留消息出錯或丟失時，地面站點和星上交換機傳輸數據的情況。

資源預留消息出錯或丟失時也不發(fā)送出錯消息。地面站點在發(fā)送路徑請求消息時啟動定時器，如果定時器時間到，并沒有收到星上交換機的回復消息，或者收到了一個錯誤的消息，那么該地面站點重新發(fā)送路徑請求消息，繼續(xù)啟動定時器等待直到收到接收資源預留請求消息。

如果星上交換機根據當前的緩存利用情況接受了地面發(fā)送站點的路徑請求消息，但是該消息丟失或者出錯，如圖3(a)所示。星上交換機為該請求已經進行了資源預留，但由于消息丟失或出錯，并沒有數據到來如圖3(b)所示。對于這種情況，星上交換機也有一個定時器，當時間到但還沒有收到預約的數據，那么就釋放為該數據預約的資源。

圖3 資源預留請求消息出錯或丟失時協(xié)議交互過程

2.3 星上IP交換機的資源管理

星上IP交換機采用基于輸入緩存的Crossbar交換結構，為避免隊頭阻塞現象，采取了VOQ的技術[5]。在隊列組織時，每個輸入端口處的N個隊列固定劃分。之前的仿真結果說明了輸入端口處VOQ對擁塞的影響要比輸出重組時緩存大。針對這種結構的星上IP交換機進行擁塞設計時，需要分別管理每個VOQ的資源利用情況。

在本設計中，收到40和44字節(jié)的短報文時，如果資源夠用則緩存該IP報文，并更新資源利用情況，否則丟棄。收到地面站點發(fā)送來的路徑請求消息后，根據資源情況來判斷是否為該IP報文預留資源。若資源夠用，為該IP報文預留所需資源，同時進行定時。當定時器時間到，但該IP報文還沒到達星上交換機時，釋放該資源。當緩存的內部信元被交換至交換單元，則釋放一個信元大小的資源空間。

當收到的報文大小與提前預約的不同時，需及時對緩存區(qū)中的資源利用情況進行更新。當收到的IP報文使用資源比提前預約的要大時，若目前資源夠用，則允許緩存該報文，同時更新資源利用情況，但如果交換機出現擁塞時，最先丟棄該報文；若目前資源不夠用，則直接丟棄該報文，釋放原預留資源。當收到的IP報文使用資源比提前預約少時，緩存該報文，并更新資源利用情況。

3 仿真結果和分析

在原有IP交換模型的基礎上，通過改變IP源和輸入處理進程對星上IP擁塞控制進行OPNET仿真，驗證本文提出的擁塞控制算法是否能降低星上交換機的丟失率，達到擁塞控制的目的。

由于這里的擁塞控制是針對Internet上的IP報文長度分布設計的，因此仿真中數據源產生IP報文的長度服從下面五種分布：40字節(jié)-34%，44字節(jié)-4%，280字節(jié)-42%，576字節(jié)-10%，1500字節(jié)-10%。仿真時間仍然設定為1.024s，也就是200000個信元時隙。

由于1500字節(jié)的報文需要拆分成25個信元，如果VOQ的容量小于25的話，那么所有的1500字節(jié)報文都無法得到預留。因此這里對VOQ容量在小于25（24），等于25，大于25（26）時分別進行仿真，比較在同樣條件下采用擁塞控制和無擁塞控制的丟失率情況。

圖4(a)是當VOQ為25時，兩種情況下丟失率的比較。進行擁塞控制時，由于1500字節(jié)的報文需要拆分成25個信元，因此如果為1500字節(jié)的報文預留了資源，那么不發(fā)送預留消息的40和44字節(jié)短報文就會由于資源不足被丟棄。但經過擁塞控制后的丟失率明顯小于不采用擁塞控制下的丟失率。

當VOQ為24時，兩種情況下丟失率的比較如圖4(b)所示。在這種情況下，由于VOQ的容量不足以保存一個1500字節(jié)的IP報文，那么所有1500字節(jié)報文的預留請求消息都會被拒絕，星上緩存足夠存儲短報文，因此在星上沒有出現丟失，但1500字節(jié)的報文將無法被交換。因此，設置緩存大小時，VOQ隊列應至少足以保存一個IP報文，否則對于長報文來說，將永遠無法預留；從該圖的仿真結果中也能看出如果不采用擁塞控制的話，IP交換機的丟失率很大，達到了10-1量級。

圖4(c)是當VOQ為26時，采用擁塞控制和不采用擁塞控制時丟失率的比較。在這種情況下，即使星上交換機為最長的IP報文預留了資源，不發(fā)送預留消息的短報文到達時也有存儲空間，這是因為短報文拆分為一個信元，只需占用VOQ中一個信元大小的空間，因此從仿真結果可看出，在這種情況下采用擁塞控制的丟失率為0，明顯小于不采用擁塞控制時的丟失率。

圖4 不同VOQ容量下無擁塞控制和采用擁塞控制丟失率比較

4 結論

仿真結果表明，本文提出的算法可明顯地降低星上交換機的丟失率。但這種算法地面需要緩存待發(fā)送的IP報文，并要定期向星上發(fā)送路徑請求消息。

下一步，可考慮如何對多個IP報文同時發(fā)送資源預留消息、地面站為終端或者網關時不同的星上擁塞控制算法進行研究。

[1] 秦凱運,楊煜普,謝劍英, 面向寬帶IP網絡的擁塞控制研究進展[J].通信學報,2004,Vol.25,No.11:119-126.

[2] Shin-ichi Kuribayashi;Kenichi Hatakeyama, Proposed congestion control method for all-IP networks including NGN[J],10th International Conference on Advanced Communication Technology,2008.(ICACT 2008):1082-1087.

[3] Karsten, M. Collected Experience FromImplementingRSVP[J].IEEE/ACM Transactions onNetworking,IEEE2006:767-778.

[4] J.Hillston,D. I.Laurenson,H.Wang,Evaluation of RSVP and Mobility-Aware RSVP Using Performance Evaluation Process Algebra[J].IEEE International Conference on Communications,2008. (ICC'08):192-197.

[5] Banovic,D.; Radusinov,I.VOQ Simulator -Software Tool for Performance Analysis of VOQ Switches[J].International Conference on Internet and Web Applications and Services/Advanced International Conference on Telecommunications,2005.