基于IP擁塞控制算法自動化分析

張景輝 王雅坤 王庚

（唐山學(xué)院，唐山 063020）

0 引言

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

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

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

1 RSVP協(xié)議

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

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

2 星上IP交換的擁塞控制

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

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

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

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

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

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

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

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

2.2 協(xié)議交互過程

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

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

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

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

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

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

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

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

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

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

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

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

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

3 仿真結(jié)果和分析

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

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

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

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

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

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

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

4 結(jié)論

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

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

[1] 秦凱運,楊煜普,謝劍英, 面向?qū)拵P網(wǎng)絡(luò)的擁塞控制研究進展[J].通信學(xué)報,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.