摘 要: 提出了一種綜合的適合MPLS網絡的主動式流量和擁塞控制" title="擁塞控制">擁塞控制策略。通過仿真表明,與傳統的TCP協議相比,該策略縮短了擁塞反饋時延" title="時延">時延,有效地避免了網絡擁塞,提高了業務吞吐量。
關鍵詞: MPLS 擁塞控制 帶寬時延積
近年來,隨著Internet用戶數量的迅速增加和各種新型業務對網絡服務質量" title="服務質量">服務質量提出的嚴峻挑戰,越來越嚴重的網絡擁塞問題逐漸暴露出來,擁塞控制已經成為網絡技術領域的重要研究課題之一。目前Internet 上廣泛使用的擁塞控制協議是Tahoe TCP[1],改進協議主要有Reno TCP[2]、NewReno TCP[3]以及SACK TCP[4]協議等。深入研究以上幾種協議可以看到[5]:這些協議本質上都是使用諸如確認、超時及重復確認等隱含信號推斷網絡狀態,并利用反饋修正數據源的發送窗口,控制注入網絡的業務量以緩解網絡擁塞。其中一直存在的問題是:網絡擁塞的檢測和控制不是由發生擁塞的網絡節點及時和主動地進行,而是在端到端的基礎上由源端通過各種隱含信號推測出來。這不但延緩了對網絡擁塞的檢測和控制,還可能造成更嚴重的網絡擁塞。上述改進協議在這一問題上都未能提出較好的解決方案。
因此,在路由器中引入擁塞控制已顯得非常必要。這依賴于路由器的計算能力。多協議標簽交換MPLS(Multi-protocol Label Switching)順應了這種要求。它在無連接的IP網絡引入面向連接的機制,形成MPLS域,標簽邊緣路由器LER(Label Edge Router) 具有計算能力,完成分類、調度和QoS 映射等處理。標簽交換路由器 LSR(Label Switch Router) 完成簡單轉發,即“邊緣智能,核心交換”。本文利用MPLS的這種特性,將反饋擁塞算法從端點引入到網絡邊緣節點,并設定低等級業務接入門限,可以有效縮短擁塞反饋時延,提高業務吞吐量。通過仿真證明該算法具有較好的性能。
1 綜合擁塞策略的基本思想
本文提出的擁塞控制策略" title="控制策略">控制策略正是在MPLS網絡中由路由器參與擁塞控制的主動式流量和擁塞控制機制[6]。在基于反饋的擁塞控制系統中,鏈路" title="鏈路">鏈路瓶頸的擁塞持續時間與帶寬時延積直接相關[7]。網絡端到端的時延越大,端點能夠檢測到網絡發生擁塞的時間就越長;網絡帶寬越大,在端點檢測到網絡擁塞之前,端點發送到擁塞網絡中的數據量就越大,導致網絡擁塞進一步惡化。因此,在網絡帶寬一定的情況下,減少時延是減少擁塞的一個重要因素。
基于這樣的考慮,筆者把傳統TCP的反饋擁塞計算從端點引入到網絡邊緣節點。為縮短擁塞反饋時延,利用路由器LSR監視隊列長度的功能,認為緩存隊列達到某一長度閾值,即表明有擁塞的可能,由該路由器向邊緣路由器LER發送擁塞預警信息,由邊緣路由器對預警信息做出反應,進行流量接入控制;同時,通知端點降低發送速率,進入Slow Start 狀態,從而及時地預測和緩解擁塞狀況。
同時考慮到大多數研究中,對高等級業務的服務質量比較關注,只對高等級業務做出相應的處理和控制,讓高等級業務優先占用資源,而對盡力而為的低等級業務則采取等待或者在資源不夠的時候優先丟棄或舍棄的策略;完全不關心網絡中大量普遍存在的、未提出任何要求的低等級業務的服務質量,只是在滿足高等級業務的前提下對其進行簡單的處理。這種處理在網絡的承載量不是很大時作用是明顯的,但是在網絡承載的業務量較大時就不是很合理了。在網絡業務承載量較大時,由于盡力而為業務是只要網絡有資源容納就進入,因此就出現了這樣的現象:大量盡力而為業務剛剛被接入網絡進行傳輸,此時如果又有一個新的高等級業務到達,而剩余的網絡資源不夠的話,由于高等級業務將優先占用網絡資源,因此剛剛被接入的盡力傳輸業務將被丟棄。這樣盡力傳輸業務的傳輸時延和丟失率將隨著業務到達率的增加而大大增加,從而損害了盡力傳輸業務的性能,而且還將造成網絡資源的無畏浪費,降低全網的性能。
鑒于以上考慮,在綜合策略中設定了一個低等級業務的接入門限,只有在網絡較空閑的情況下,盡力而為業務才被接入。這種操作在網絡負荷不高時,效果不明顯,但是在網絡負荷較高時效果非常明顯。其原理是:雖然通過不接入少量低等級業務使得低等級業務的吞吐量下降,但是,在網絡負荷較高時,這避免了已接入低等級業務在中間節點的大量無謂的丟棄,提高了低等級業務的實際傳輸效率和資源的有效使用率。同時,也大大降低了網絡轉發節點的處理復雜度,可以在不改變原有高等級業務的處理和性能下,有效地提高低等級業務的性能,并且提高全網的吞吐量。
最后在尾丟棄策略上,采用隨機早檢測RED算法和優先級相結合的策略。RED算法將決定丟棄是否發生,優先級將決定那個分組被丟棄。
2 綜合的MPLS流量工程擁塞控制策略
如前所述,采用路由器LSR對隊列長度進行監測,并取隊列長度的70%作為擁塞預警值,即低等級業務的準入門限,同時把進入網絡的數據流進行緩存分類,分為高等級業務和盡力而為業務,而且高等級業務隊列還按優先級排隊,高的優先級排在前面,從而建立了一種綜合的MPLS流量工程的擁塞控制策略ICC(Integrated Congestion Control Strategy for MPLS Traffic Engineering)。在該策略中,當隊列流量沒有超出預警值時,路由器正常轉發緩存隊列的數據,不進行流量控制;當任一LSR檢測到自己的緩存隊列超出預警值,便向其邊緣入口LER發送預警信息,入口LER收到預警信息啟動隊列管理機制,對盡力傳輸型業務限制接入,同時邊界MPLS LER通知數據發送源端降低數據發送速率。在每個路由器內部,采用隨機早檢測RED算法和優先級相結合的策略。當分組到來時,考察隊列長度q,若隊列長度介于隊列容量/2和隊列容量之間,把分組按優先級進行排隊,然后以概率P丟棄隊尾數據包。若隊列已滿,則直接丟棄數據包。其中,,minth為隊列容量/2, maxth為隊列容量。丟棄數據包的順序是從隊列尾部開始,因為隊列是按優先級排隊的。這樣就保證了高等級業務的優先服務,同時這種丟棄策略也使網絡擁塞得到緩解。
3 仿真實例
仿真中采用的拓撲結構如圖1所示。端節點client TOSi 和server TOSi 之間建立連接,鏈路的帶寬為1Mbps,發送端采用TCP(Reno) 協議,報文平均長度為1000byte,網絡中共有60個TCP源,其輸入模型為FTP模型。路由器router A和router B之間構成瓶頸鏈路,鏈路帶寬為2.048Mbps,傳輸延遲為20ms~100ms,此范圍對應于從局域網平均遲延到廣域網的鏈路平均遲延,在仿真中通過改變此鏈路遲延就可改變鏈路的帶寬遲延積。路由器中的緩沖區最多可容納350個報文。
解決擁塞的最終目的是為了提高吞吐量,所有的吞吐量都是按照目的端點收到的有用包來計算的。隨著鏈路時延的增加,即帶寬時延積的增加,瓶頸鏈路的吞吐量如圖2、3和4所示。由于ICC和TCP都依賴于網絡節點和端點的反饋通信,因此兩者的性能都隨著帶寬時延積的增大而下降。但由于ICC利用中間節點進行反饋,縮短了擁塞反饋時延,其性能要優于傳統TCP的性能。這主要是因為鏈路時延增加后,數據包的RTT 時間增加,TCP協議的定時器長度也隨之增加,造成了用戶終端對網絡擁塞進行檢測和控制時間的延長。此外,由于TCP 協議至少需要經一個RTT時間才能發現網絡擁塞,在此之前終端將繼續發送大量的數據包。這樣就有可能造成擁塞節點情況的進一步惡化,造成數據包的大量丟失,從而也影響瓶頸鏈路的吞吐量。
圖5是采用ICC和傳統TCP方法對照情況下的高、低等級業務的吞吐量圖。圖5中網絡延遲為50ms。可以看出:在網絡資源較空閑的情況下,采取適當的低等級業務接入門限,可以有效提高低等級業務吞吐量,從而使網絡的吞吐量得到提高。
隨著互聯網業務的膨脹和新業務的增加,單一的TCP擁塞控制已不能完全滿足擁塞控制的要求,必須使路由器參與到主動的擁塞控制中。本文在分析了相關的擁塞控制策略的基礎上,將反饋擁塞算法從端點引入到了網絡邊緣節點,并設定低等級業務接入門限。理論分析和仿真結果表明在網絡中瓶頸鏈路延遲較大時不僅可提高高等級業務的吞吐量,也照顧了低等級業務的吞吐量。
參考文獻
1 V. Jacobson. Congestion avoidance and control. Proceedings of SIGCOMM Symposium on Communications Architectures and Protocols, 1988; 314~329
2 V. Jacobson. Modified TCP congestion avoidance algorithm. End2End-intrest Mailing list, 1990
3 S. Floyed, T. Henderson. The new Reno modification to TCP′s fast recovery algorithm. RFC2582, 1999
4 M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. TCP selective acknowledgment options. RFC2018, 1996
5 羅萬明, 林闖, 閻保平. TCP/IP擁塞控制研究. 計算機學報, 2001;24(1):1~18
6 張志群, 丁煒, 邵旭. MPLS網絡主動式流量和擁塞控制機制及性能分析.電子與信息學報, 2002;24(11):1573~1580
7 J. C. Bolot, A. Shankar. Dynamical behavior of rate based flow control systems. Computer Communication Review, ACM SIGCOMM, 1996;26(2):5~18