基于SDN的QoS管理機(jī)制研究

張靖+舒圣濤+劉翠玲+俞駿豪+李挺

摘 要：隨著互聯(lián)網(wǎng)的發(fā)展，媒體流的數(shù)目逐漸增多。由于受到傳統(tǒng)網(wǎng)絡(luò)架構(gòu)的限制，已經(jīng)很難對(duì)這些流進(jìn)行靈活控制與管理。SDN的出現(xiàn)為解決此問(wèn)題提供了新的思路。文章提出了一個(gè)基于SDN的QoS管理方案，使用阻塞隊(duì)列對(duì)不滿足傳輸條件的流進(jìn)行管理。當(dāng)有流到達(dá)時(shí)，首先判斷是否有滿足流約束條件的路徑。如果擁有，控制器下發(fā)流表進(jìn)行流的傳輸；如果沒(méi)有，控制器將流加入阻塞隊(duì)列。當(dāng)有流完成傳輸時(shí)，控制器及時(shí)調(diào)度阻塞隊(duì)列中的流。文章對(duì)方案進(jìn)行了優(yōu)化，為QoS流選擇路徑時(shí)增加了時(shí)延抖動(dòng)參數(shù)，能夠排除一些時(shí)延不穩(wěn)定的路徑，及時(shí)對(duì)流進(jìn)行調(diào)度，增加了鏈路資源的利用率。

關(guān)鍵詞：SDN；QoS；網(wǎng)絡(luò)；優(yōu)化

當(dāng)前網(wǎng)絡(luò)中充斥著各種類(lèi)型的流量，有E-mail，ftp，WebTV等。這些不同類(lèi)型的流對(duì)鏈路質(zhì)量有不同的要求，例如，ftp有比較大的帶寬需求，而WebTV需要較小時(shí)延的鏈路進(jìn)行傳輸，相對(duì)于E-mail這種對(duì)鏈路質(zhì)量沒(méi)有要求的流來(lái)說(shuō)，對(duì)媒體流的管理要復(fù)雜得多。

由于傳統(tǒng)網(wǎng)絡(luò)的分布式結(jié)構(gòu)，傳統(tǒng)網(wǎng)絡(luò)下的QoS架構(gòu)只能在小規(guī)模的網(wǎng)絡(luò)中使用，沒(méi)有一個(gè)全局的網(wǎng)絡(luò)視圖，導(dǎo)致了資源的浪費(fèi)，缺乏靈活性與高成本也是其主要的缺點(diǎn)。軟件定義網(wǎng)絡(luò)（Software Defined Network，SDN ）架構(gòu)的出現(xiàn)，為解決QoS問(wèn)題提供了一個(gè)新的思路。在本文中，提出了SDN機(jī)制下的QoS解決方案，通過(guò)增加阻塞隊(duì)列提高鏈路資源利用率，減少Q(mào)oS流對(duì)其他流的影響。在此基礎(chǔ)上增加了時(shí)延抖動(dòng)參數(shù)，提高控制器選擇路徑的可靠性。主要實(shí)現(xiàn)方法總結(jié)如下：（1）在選擇QoS路徑時(shí)，增加了時(shí)延抖動(dòng)參數(shù)；（2）使用流的阻塞隊(duì)列對(duì)流進(jìn)行管理。

1 Qos架構(gòu)的現(xiàn)狀

近幾年已經(jīng)有研究者對(duì)SDN機(jī)制下的QoS架構(gòu)進(jìn)行了研究，與傳統(tǒng)的QoS架構(gòu)進(jìn)行優(yōu)化，提出了一個(gè)模型。它將QoS流分為3種類(lèi)型。（1）QoS level-1：最高優(yōu)先級(jí)流量，對(duì)此類(lèi)流量進(jìn)行動(dòng)態(tài)路由。（2）QoS leve-2：次優(yōu)先級(jí)流量，在對(duì)最高級(jí)流量動(dòng)態(tài)路由后，對(duì)此類(lèi)流量進(jìn)行動(dòng)態(tài)路由。（3）Best-effort：最低優(yōu)先級(jí)流量，對(duì)于此類(lèi)流量不進(jìn)行動(dòng)態(tài)路由，只根據(jù)最短路徑傳輸[7]。

雖然利用SDN實(shí)現(xiàn)了動(dòng)態(tài)的QoS路由，但是沒(méi)有一個(gè)實(shí)時(shí)的測(cè)量模塊來(lái)獲得鏈路的狀態(tài)。提出了QoF架構(gòu)，在此架構(gòu)中，增加了實(shí)時(shí)測(cè)量模塊且實(shí)驗(yàn)結(jié)果表明其能夠?qū)崿F(xiàn)對(duì)鏈路信息的收集[8]。但是這些都是對(duì)QoS流進(jìn)行單路徑的傳輸。HiQoS改進(jìn)了Dijkstra算法，生成多條路徑，以實(shí)現(xiàn)在鏈路發(fā)生故障時(shí)能夠進(jìn)行快速切換[9]。但HiQoS主要是把鏈路帶寬作為QoS選路的主要指標(biāo)，這顯然是不夠的。增加了鏈路的實(shí)時(shí)往返時(shí)間參數(shù)，提出使用r=a*（B0/B）+b*（T0/T）+c*（L0/L）來(lái)為QoS流選擇最佳路徑[10]。雖然它在一定程度上能為某一種類(lèi)型的流提供QoS服務(wù)，但對(duì)于大規(guī)模運(yùn)用是不切實(shí)際的，因?yàn)閷?duì)a，b，c 3個(gè)參數(shù)的選擇是困難的。

上述幾種方案都在一定程度上解決了傳統(tǒng)網(wǎng)絡(luò)架構(gòu)下的QoS問(wèn)題，但是它們都沒(méi)有考慮時(shí)延抖動(dòng)參數(shù)以及缺乏對(duì)因?yàn)闆](méi)有鏈路資源而被阻塞流的有效管理。在本文中加入了時(shí)延抖動(dòng)參數(shù)以及阻塞隊(duì)列，不僅能夠提高被選擇路徑的可靠性，還能提高鏈路的資源利用率，也有效地減少了QoS流對(duì)非QoS流傳輸?shù)挠绊憽?/p>

2 QoS管理機(jī)制的實(shí)現(xiàn)

QoS管理機(jī)制的實(shí)現(xiàn)主要分為兩個(gè)部分：改進(jìn)Dijkstra算法、增加流的阻塞隊(duì)列。在對(duì)QoS流進(jìn)行選路時(shí)，時(shí)延抖動(dòng)是個(gè)重要的因素。如果不考慮時(shí)延抖動(dòng)將會(huì)導(dǎo)致選擇的路徑不是最優(yōu)、甚至不符合約束條件。例如，如圖1所示為一個(gè)SDN控制器控制4個(gè)交換機(jī)的拓?fù)?。從拓?fù)鋱D中可以發(fā)現(xiàn)從主機(jī)h1到h2有兩條路徑：s1→s2→s4，s1→s3→s4。假設(shè)主機(jī)h1到h2的流為QoS流，約束條件為時(shí)延小于60 ms。T1時(shí)刻SDN控制器測(cè)得的時(shí)延：s1→s2→s4為45 ms，s1→s3→s4為58 ms；T2時(shí)刻SDN控制器測(cè)得的時(shí)延為：s1→s2→s4為43 ms，s1→s3→s4為40ms；假設(shè)主機(jī)h1到h2的流是在T2時(shí)刻到達(dá)，如果不考慮時(shí)延抖動(dòng)參數(shù)，那么s1→s3→s4為最優(yōu)路徑。但是由于s1→s3→s4路徑時(shí)延不穩(wěn)定，抖動(dòng)相對(duì)較大，它并不是一個(gè)最優(yōu)的路徑。甚至到下個(gè)測(cè)量周期，它的延遲可能會(huì)超過(guò)60 ms，那么被選中的路徑將是不符合約束條件的路徑，所以它是不可靠的。

通過(guò)以上例子，可以發(fā)現(xiàn)抖動(dòng)參數(shù)對(duì)于路徑的選擇是非常重要的。而在以前的方案中，使用Dijkstra算法計(jì)算時(shí)延最小路徑，選取下一個(gè)節(jié)點(diǎn)時(shí)總是選擇標(biāo)記點(diǎn)之外距離源點(diǎn)時(shí)延最小的點(diǎn)，它并沒(méi)有將時(shí)延抖動(dòng)參數(shù)考慮進(jìn)去。改進(jìn)了以前的方案，在對(duì)下一點(diǎn)的選取中加入時(shí)延抖動(dòng)參數(shù)，分為以下兩種情況：（1）若源點(diǎn)到某一節(jié)點(diǎn)的路徑在最近一段時(shí)間內(nèi)的最大時(shí)延小于其他點(diǎn)的最小時(shí)延，則源點(diǎn)到該節(jié)點(diǎn)的路徑是絕對(duì)最小時(shí)延路徑，選取該節(jié)點(diǎn)作為被選取的節(jié)點(diǎn)。若不存在上述情況，則說(shuō)明沒(méi)有源點(diǎn)到哪一節(jié)點(diǎn)在最近一段時(shí)間是時(shí)延最小的路徑。當(dāng)出現(xiàn)這種情況時(shí)，使用（2）方法來(lái)選取一個(gè)源點(diǎn)到該節(jié)點(diǎn)時(shí)延較小且穩(wěn)定的節(jié)點(diǎn)。（2）計(jì)算源點(diǎn)到所有未被標(biāo)記節(jié)點(diǎn)的路徑當(dāng)前時(shí)延t與最近一段時(shí)間的時(shí)延抖動(dòng)平均值m的和t+m，選取t+m最小的路徑所對(duì)應(yīng)的節(jié)點(diǎn)。具體過(guò)程如圖2所示。

當(dāng)前網(wǎng)絡(luò)中，網(wǎng)絡(luò)的資源都很有限。很多情況下，請(qǐng)求傳輸?shù)牧鞑灰欢ǘ寄鼙豢刂破鞣峙渎窂?，這樣對(duì)于一個(gè)QoS架構(gòu)來(lái)說(shuō)，對(duì)阻塞流的管理是必不可少的。本文提出了使用阻塞隊(duì)列對(duì)等待的流進(jìn)行管理。在本文中有兩個(gè)阻塞隊(duì)列，一個(gè)是QoS流的阻塞隊(duì)列，另一個(gè)是非QoS流的阻塞隊(duì)列。當(dāng)有流到達(dá)時(shí)，如果當(dāng)前鏈路中沒(méi)有可供其使用的鏈路資源，則流將被加入到對(duì)應(yīng)的隊(duì)列等待調(diào)度。當(dāng)控制器接收到交換機(jī)的流表超時(shí)被刪除的消息時(shí)，按照優(yōu)先級(jí)先調(diào)度QoS流阻塞隊(duì)列中的流，然后調(diào)度非QoS流阻塞隊(duì)列中的流進(jìn)行傳輸。這樣及時(shí)對(duì)流進(jìn)行調(diào)度，不僅能夠增加鏈路的使用率，而且能夠減小對(duì)非Qos流的影響。其具體實(shí)現(xiàn)如圖3所示。endprint

3 結(jié)語(yǔ)

在本文中，提出了一個(gè)基于SDN的QoS管理機(jī)制。改進(jìn)了Dijkstra算法，在用Dijkstra算法進(jìn)行路徑選擇時(shí)，增加時(shí)延抖動(dòng)參數(shù)選擇時(shí)延較小且穩(wěn)定的鏈路，解決了由于時(shí)延抖動(dòng)而帶來(lái)的被選擇路徑不可靠的問(wèn)題。為了管理因?yàn)闆](méi)有鏈路資源而等待的流，增加了流的阻塞隊(duì)列，通過(guò)SDN控制器的全局視圖以及交換機(jī)的消息反饋對(duì)流進(jìn)行實(shí)時(shí)調(diào)度。

[參考文獻(xiàn)]

[1]EGILMEZ H E，GORKEMLI B，TEKALP A M，et al.Scalable video streaming over OpenFlow networks：an optimization framework for QoS routing[C].Brussels：2011 18th IEEE International Conference on Image Processing IEEE，2011：2241-2244.

[2]SZIGETI T，HATTINGH C，BARTON R，et al.End-to-End QoS network design：quality of service for rich-media & cloud networks[M].Indiana：Cisco Press，2013.

[3]王淑玲，李濟(jì)漢，張?jiān)朴?SDN架構(gòu)及安全性研究[J].電信科學(xué)，2013（3）：117-122.

[4]左青云，陳鳴，趙廣松.基于OpenFlow的SDN技術(shù)[J].軟件學(xué)報(bào)，2013（3）：1-20.

[5]羅宣，黃保青，韋建文.上海交通大學(xué)：面向數(shù)據(jù)中心的軟件定義網(wǎng)絡(luò)[J].中國(guó)教育網(wǎng)絡(luò)，2013（8）：24-27.

Abstract：With the development of the Internet， the number of media streams is increasing. Due to the limitations of traditional network architectures， it is difficult to control and manage these popular agility. The emergence of SDN provides a new way to solve this problem. In this paper， a SDN based QoS management scheme is proposed that uses congestion queues to manage flows that do not meet transmission conditions. When a stream arrives， first determine whether there is a path that satisfies the flow constraint. If owned， the controller sends the flow to the flow table. If not， the controller adds the flow to the blocking queue. When a stream completes the transmission， the controller can schedule the flow in the blocking queue in a timely manner. In this paper， the scheme is optimized， and the delay jitter parameter is added to the QoS flow selection path， and some delay unstable paths can be eliminated. And scheduling in time， increasing the utilization of link resources.

Key words：software defined network； QoS； network； optimizationendprint