校園專網(wǎng)中基于SDN的路徑選擇與帶寬保障策略

肖軍弼　隋萌萌　陳　松　任密林　萬　里

1(中國(guó)石油大學(xué)(華東)計(jì)算機(jī)與通信工程學(xué)院　山東 青島 266580) 2(下一代互聯(lián)網(wǎng)重大應(yīng)用技術(shù)(北京)工程研究中心有限公司　北京 100084)

0　引　言

校園專網(wǎng)是校園網(wǎng)絡(luò)體系中的重要組成部分，其服務(wù)范圍涵蓋財(cái)務(wù)、安防、能源監(jiān)管等校園生活的方方面面。在傳統(tǒng)網(wǎng)絡(luò)中，開通校園專網(wǎng)通常需要管理員進(jìn)行大量的接口和ACL規(guī)則配置，過程十分繁瑣。且專網(wǎng)一旦開通，一般不會(huì)發(fā)生大規(guī)模變化,若要開通新的專網(wǎng)業(yè)務(wù)，則需要執(zhí)行大量配置變更以實(shí)現(xiàn)數(shù)據(jù)精準(zhǔn)轉(zhuǎn)發(fā)和流量安全隔離。受種種因素所限，傳統(tǒng)網(wǎng)絡(luò)體系結(jié)構(gòu)下的校園專網(wǎng)存在安全性、靈活性、穩(wěn)定性和可擴(kuò)展性等方面的缺陷。軟件定義網(wǎng)絡(luò)SDN依靠其數(shù)控分離、集中管理的強(qiáng)大優(yōu)勢(shì)，通過控制器下發(fā)專網(wǎng)管理策略，從全局視角實(shí)現(xiàn)對(duì)專網(wǎng)的管控，能夠?qū)崿F(xiàn)新增設(shè)備的即插即用和配置策略的自動(dòng)復(fù)制下發(fā)，簡(jiǎn)化管理運(yùn)維負(fù)擔(dān)，提高變更管理效率[1]。

然而，隨著專網(wǎng)承載業(yè)務(wù)的日益增加，網(wǎng)絡(luò)擁塞問題日趨嚴(yán)重。專網(wǎng)承載的大多是重要業(yè)務(wù)，或者在某時(shí)段內(nèi)需要保障高優(yōu)先級(jí)服務(wù)的業(yè)務(wù)(如視頻會(huì)議等)。如何在一張有限的物理網(wǎng)絡(luò)上承載更多的新業(yè)務(wù)并保障重要業(yè)務(wù)的服務(wù)質(zhì)量不受干擾成為未來專網(wǎng)面臨的新課題。當(dāng)前，SDN中Floodlight控制器在路徑選擇和流量調(diào)度方面默認(rèn)采用最短路徑算法。這種單一的解決方式并未考慮到網(wǎng)絡(luò)的當(dāng)前帶寬使用狀態(tài)，也沒有預(yù)防未來其他突發(fā)流量可能帶來的沖擊，更沒有為各種業(yè)務(wù)不同的帶寬需求提供有效的保障措施。為提高業(yè)務(wù)帶寬需求的保障效果，增強(qiáng)網(wǎng)絡(luò)的穩(wěn)定性和健壯性，本文在OPPBG算法的基礎(chǔ)之上，通過計(jì)算鏈路剩余帶寬差值的方差改進(jìn)路徑選擇算法，并融合端口隊(duì)列設(shè)置方式，提出一種改進(jìn)的路徑選擇與帶寬保障策略。

1　設(shè)置端口隊(duì)列與OPPBG算法

1.1　使用OpenFlow設(shè)置端口隊(duì)列

OpenFlow是當(dāng)前在控制平面和數(shù)據(jù)平面之間最具影響力的南向接口協(xié)議[2]。OpenFlow交換機(jī)通過簡(jiǎn)單的隊(duì)列機(jī)制提供有限的QoS支持。交換機(jī)的一個(gè)端口上可添加一個(gè)或多個(gè)隊(duì)列，這些隊(duì)列用于映射流條目。映射到指定隊(duì)列的流條目將依據(jù)隊(duì)列配置(如最小速率、最大速率等)進(jìn)行處理。根據(jù)端口隊(duì)列這一特性，處理動(dòng)作為Set Queue的流表將被推送至相關(guān)交換機(jī)中，從而將不同的業(yè)務(wù)流調(diào)度至不同隊(duì)列中[3]以便進(jìn)行下一步處理。

在設(shè)置隊(duì)列和調(diào)度流量之前，文獻(xiàn)[4]首先使用Dijkstra算法選擇從源端到目的端的最短路徑。然后沿此路徑在一段適當(dāng)?shù)逆溌飞?，多個(gè)具有不同最大速率和最小速率配置的隊(duì)列將設(shè)置在端口上用于限制最大傳輸速率并保障最小帶寬需求。通過OpenFlow的流表下發(fā)策略，不同帶寬需求的業(yè)務(wù)將被放入適當(dāng)?shù)年?duì)列中。流表的匹配字段表示需要保障帶寬的業(yè)務(wù)，動(dòng)作字段設(shè)置為Set Queue。

使用OpenFlow設(shè)置端口隊(duì)列能夠通過不同速率限制的隊(duì)列有效區(qū)分不同帶寬需求的業(yè)務(wù)，從而為重要業(yè)務(wù)提供有效的帶寬保障，而且能夠排除普通業(yè)務(wù)的干擾，對(duì)重要業(yè)務(wù)流具有較強(qiáng)的控制力。但是設(shè)置端口隊(duì)列前的路徑選擇采用簡(jiǎn)單的最短路徑方法，沒有考慮當(dāng)前鏈路狀態(tài)和已存在于路徑中的流量。當(dāng)多條業(yè)務(wù)流的總帶寬需求超過鏈路容量時(shí)，極易發(fā)生擁塞，導(dǎo)致重要業(yè)務(wù)的服務(wù)質(zhì)量大大降低。

1.2　OPPBG算法

為了滿足服務(wù)在不同時(shí)間尺度的不同帶寬需求，文獻(xiàn)[5]提出了OPPBG算法。在該算法中，基于北向接口[6]的SDN管理平臺(tái)使用REST API收集全網(wǎng)信息，RBG(Routing with Bandwidth Guarantee)算法根據(jù)收集到的網(wǎng)絡(luò)信息執(zhí)行路由算法得到調(diào)度路徑，最后根據(jù)計(jì)算結(jié)果生成或更新流表?xiàng)l目并將流表下發(fā)至相應(yīng)的交換機(jī)中。

RBG算法將路徑中當(dāng)前存在的流量和鏈路容量納入考慮范圍。三元組fw(src,dst,ban)用于描述從源節(jié)點(diǎn)src發(fā)往目的節(jié)點(diǎn)dst、帶寬需求為ban的業(yè)務(wù)流fw。該算法首先創(chuàng)建當(dāng)前網(wǎng)絡(luò)拓?fù)涞母北?，并刪除剩余帶寬不滿足fw需求的鏈路。隨后，在拓?fù)涓北局?，使用Dijkstra算法計(jì)算從源節(jié)點(diǎn)src到目的節(jié)點(diǎn)dst的最短路徑(此最短路徑的鏈路剩余帶寬必定滿足fw的帶寬需求)，由此得出調(diào)度流量的最佳路徑。

這種方法確保所選路徑能夠滿足業(yè)務(wù)流的帶寬需求，充足的鏈路資源可以防止網(wǎng)絡(luò)中已有流量與新到流量的相互干擾。然而，如果采用最短路徑算法后得出多條可用路徑，如何在多條路徑情況下進(jìn)行調(diào)度操作或從中擇優(yōu)選用并沒有進(jìn)一步討論。另一方面，當(dāng)多個(gè)不同帶寬需求的業(yè)務(wù)沿同一路徑傳輸時(shí)，如果不采取有效的帶寬保障措施，多個(gè)業(yè)務(wù)流將平分剩余可用帶寬。在這種情況下，具有較大帶寬需求的業(yè)務(wù)可能無法獲得足夠的帶寬，造成高丟包率而使服務(wù)質(zhì)量降低。因此，在選擇流量調(diào)度路徑時(shí)，我們必須綜合考慮當(dāng)前鏈路狀態(tài)以及未來的潛在影響因素，盡可能降低對(duì)重要業(yè)務(wù)種種可能的干擾。

2　基于SDN的路徑選擇與帶寬保障策略設(shè)計(jì)

2.1　路徑選擇算法描述

假定從源到目的地的路徑p包含多段鏈路li，每段鏈路的容量為ci，已使用的帶寬為bi，如式(1)和式(2)所示：

C=[c1,c2,…,ci,…,cn]

(1)

B=[b1,b2,…,bi,…,bn]

(2)

使用三元組f(src,dst,band)表示一條需要進(jìn)行調(diào)度的新到業(yè)務(wù)，其源端為src，目的端為dst，帶寬需求為band。為確保業(yè)務(wù)流能夠從源端到達(dá)目的端，全路徑算法首先將通過深度優(yōu)先遍歷獲取從src到dst的所有可達(dá)路徑。隨后，使用式(3)計(jì)算所有路徑中每段鏈路的剩余可用帶寬ri，并將剩余可用帶寬不滿足業(yè)務(wù)流f需求的鏈路刪除(該段鏈路所在的可達(dá)路徑也隨之刪除)。

R=[r1,r2,…,ri,…,rn]=C-B

(3)

現(xiàn)在，所有可到達(dá)目的地且滿足帶寬需求的路徑已被選出。接下來采用Dijkstra算法從中選擇最短路徑。如果僅存在一條最短路徑，則選用該路徑作為調(diào)度流量的最佳路徑。

若存在多條最短路徑，下一步計(jì)算得出每條路徑包含的所有鏈路中剩余帶寬的最小值，并將各條路徑的鏈路最小剩余帶寬進(jìn)行比較，從中選取最小剩余帶寬中的最大值。該最大值所在的路徑具有更強(qiáng)的容納能力，能夠承載更多后續(xù)進(jìn)入的流量，因而當(dāng)前業(yè)務(wù)不易受到后續(xù)業(yè)務(wù)的干擾，路徑更加穩(wěn)定。

顯然，在選出最大的鏈路最小剩余帶寬之后，仍有可能存在多條路徑，即可能會(huì)得到多條具有相同的鏈路最小剩余帶寬的路徑。為進(jìn)一步確保系統(tǒng)的健壯性和業(yè)務(wù)的服務(wù)質(zhì)量，算法對(duì)各條路徑進(jìn)行更深入的評(píng)估和比較，具體步驟如下：

第1步我們已經(jīng)得到每條路徑上每段鏈路的剩余帶寬以及該路徑上的鏈路最小剩余帶寬。對(duì)于每條路徑，將每段鏈路的剩余帶寬與鏈路最小剩余帶寬相減，得到一組差值。對(duì)于路徑p上的鏈路li，該差值可依照式(4)表示為di。

di=ri-min(ri)

(4)

第2步對(duì)于路徑p，所有差值di將被歸為一個(gè)數(shù)據(jù)組，并使用式(5)計(jì)算該組數(shù)據(jù)的方差，從而評(píng)估這些差值的離散程度。

(5)

第3步計(jì)算出各組數(shù)據(jù)的方差后，方差值最小的一組數(shù)據(jù)所在的路徑將選定為最終的最佳路徑用于調(diào)度流量。方差最小意味著該條路徑不會(huì)因某一段或某幾段鏈路的突然擁塞而輕易受到干擾。對(duì)于重要業(yè)務(wù)而言，這樣的路徑能夠提供更加穩(wěn)定高質(zhì)量的服務(wù)。

為直觀描述整個(gè)算法流程，圖1通過一個(gè)簡(jiǎn)單的示例對(duì)上述過程加以解釋。在該示例中，從源節(jié)點(diǎn)S1到目的節(jié)點(diǎn)S8的業(yè)務(wù)流f的帶寬需求為12 Mbit/s。在圖1所示的拓?fù)渲校慷捂溌飞系臄?shù)字表示該段鏈路的剩余可用帶寬(假定所有鏈路長(zhǎng)度相同)。圖1(a)中，鏈路剩余帶寬不滿足f的帶寬需求的鏈路(S2，S7)被刪除，提取出的新拓?fù)渲兴墟溌肪軌驖M足f的帶寬需求。圖1(b)中，使用Dijkstra算法計(jì)算最短路徑，較長(zhǎng)的路徑(S2，S5，S6，S7)被排除。此時(shí)得到兩條最短路徑，并且它們的鏈路最小剩余帶寬相同(均為15 Mbit/s)。隨后根據(jù)第1步得到兩條路徑的差值組(0,10,15,15)和(0,5,15,15)。使用式(5)計(jì)算兩組數(shù)據(jù)的方差，第一組的方差為50，而第二組為56.25。經(jīng)過以上路徑選擇過程，我們將選擇方差較小的路徑(S1，S2，S3，S7，S8)作為最佳路徑。因?yàn)樵摋l路徑相比于其他路徑更加穩(wěn)定健壯，占用后的剩余可用帶寬更多，不會(huì)因某段鏈路的其他突發(fā)流量而輕易造成鏈路擁塞(如可能出現(xiàn)從S2發(fā)往S3的突發(fā)流量，因該段鏈路帶寬剩余更多，不會(huì)輕易擁塞)。

2.2　帶寬保障過程

根據(jù)當(dāng)前網(wǎng)絡(luò)狀態(tài)和未來變化影響，采用一定的算法為業(yè)務(wù)選擇最佳調(diào)度路徑。但確定最佳路徑之后，當(dāng)前尚無有效機(jī)制保障業(yè)務(wù)的不同帶寬需求。例如，如果兩條業(yè)務(wù)流使用路徑選擇算法選擇了同一路徑進(jìn)行傳輸，但這兩條業(yè)務(wù)流的帶寬需求不同。如果不采取一定的帶寬保障措施，它們將平分剩余可用帶寬，這將導(dǎo)致帶寬需求較高的業(yè)務(wù)流在傳輸中大量丟包，影響業(yè)務(wù)服務(wù)質(zhì)量[7]。

在選定最佳調(diào)度路徑之后，我們將沿該路徑在每臺(tái)交換機(jī)靠近目的端的端口上為業(yè)務(wù)流設(shè)置端口隊(duì)列。隊(duì)列包含對(duì)業(yè)務(wù)流的最大傳輸速率和最小傳輸速率的限制，并指定處理該業(yè)務(wù)數(shù)據(jù)包的方式(從某個(gè)端口將業(yè)務(wù)流轉(zhuǎn)發(fā)出去，或者將其丟棄)。

同時(shí)，為了確保多個(gè)重要業(yè)務(wù)在傳輸過程中均能獲得足夠的帶寬，每個(gè)業(yè)務(wù)都會(huì)被添加到單獨(dú)的隊(duì)列中。即使可能有多個(gè)帶寬需求相同或相近的業(yè)務(wù)，它們?cè)究梢员惶砑拥酵粋€(gè)隊(duì)列中，但我們?nèi)匀贿x擇創(chuàng)建多個(gè)相同的隊(duì)列，將每個(gè)業(yè)務(wù)獨(dú)立添加到一個(gè)隊(duì)列中。這種處理方式將防止同一隊(duì)列中的多個(gè)業(yè)務(wù)平分剩余可用帶寬，避免出現(xiàn)一個(gè)或多個(gè)業(yè)務(wù)帶寬分配不足的情況。對(duì)于整個(gè)系統(tǒng)而言，總體處理流程如圖2所示。

圖2　系統(tǒng)總體流程圖

3　實(shí)　驗(yàn)

本實(shí)驗(yàn)設(shè)計(jì)了兩個(gè)模擬場(chǎng)景，分別通過兩條先后發(fā)出的不同業(yè)務(wù)流，將本文提出的算法與OPPBG算法和端口隊(duì)列設(shè)置方法在保障業(yè)務(wù)帶寬需求、降低干擾等方面進(jìn)行比較。

3.1　實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)在運(yùn)行于Linux系統(tǒng)(安裝在VMware 10.0中的Ubuntu 16.04)的Mininet[8]中創(chuàng)建的虛擬環(huán)境下進(jìn)行。SDN控制器選用運(yùn)行于Ubuntu的Floodlight控制器[9]。為生成UDP測(cè)試流量，實(shí)驗(yàn)選用Iperf軟件測(cè)試工具，以生成穩(wěn)定的測(cè)試流量并提供包括傳輸帶寬在內(nèi)的反饋信息。

實(shí)驗(yàn)所用的網(wǎng)絡(luò)拓?fù)淙鐖D3所示。該網(wǎng)絡(luò)由7臺(tái)OpenFlow交換機(jī)和6臺(tái)主機(jī)組成，每段鏈路的容量(即鏈路帶寬)為100 Mbit/s。在圖3中，每段鏈路上的數(shù)字表示該段鏈路的剩余可用帶寬。所有OpenFlow交換機(jī)均連接到Floodlight控制器。

圖3　實(shí)驗(yàn)采用的網(wǎng)絡(luò)拓?fù)?/p>

3.2　場(chǎng)景1：對(duì)比端口隊(duì)列設(shè)置方法

在此場(chǎng)景中，本文提出的算法與使用OpenFlow在端口上設(shè)置隊(duì)列的方法進(jìn)行帶寬保障性能方面的對(duì)比，以驗(yàn)證路徑選擇算法的合理性和有效性。假定有兩條需要保障帶寬需求的業(yè)務(wù)流，二者的帶寬需求均為65 Mbit/s，且均從h1發(fā)往h2，第二條業(yè)務(wù)流在第一條業(yè)務(wù)流發(fā)出10秒后開始發(fā)送。當(dāng)采用OpenFlow設(shè)置端口隊(duì)列的保障方法時(shí)，首先選擇網(wǎng)絡(luò)中的最短路徑(h1,S1,S2,S7,h2)，并沿該路徑在每臺(tái)交換機(jī)上靠近目的端h2的端口上設(shè)置最小速率60 Mbit/s、最大速率為70 Mbit/s的隊(duì)列。由于兩條業(yè)務(wù)流的總帶寬需求(130 Mbit/s)超過鏈路容量(100 Mbit/s)，因而沿該路徑將發(fā)生擁塞，兩條業(yè)務(wù)流發(fā)生沖突，各自實(shí)際的流量傳輸速率將約為40 Mbit/s到50 Mbit/s，如圖4所示。

采用本文提出的路徑選擇算法，當(dāng)?shù)谝粭l帶寬需求為65 Mbit/s的業(yè)務(wù)流進(jìn)入網(wǎng)絡(luò)中后，仍將選取(h1,S1,S2,S7,h2)作為調(diào)度路徑。之后該路徑的剩余帶寬為35 Mbit/s，不能滿足第二條帶寬需求為65 Mbit/s的業(yè)務(wù)流的需求，因而進(jìn)行下一次調(diào)度前，(h1,S1,S2,S7,h2)將被刪除。隨后依據(jù)算法流程進(jìn)行一系列計(jì)算，最終將得到第二條業(yè)務(wù)流的最佳調(diào)度路徑為(h1,S1,S4,S6,S7,h2)，并沿該路徑設(shè)置端口隊(duì)列。根據(jù)測(cè)試，兩條業(yè)務(wù)流的帶寬需求均可得到有效的保障，而不會(huì)互相干擾，如圖5所示。

通過對(duì)比以上實(shí)驗(yàn)結(jié)果可以看出，采用路徑選擇算法后，最初的業(yè)務(wù)流不會(huì)受后來業(yè)務(wù)流的干擾，并且后續(xù)業(yè)務(wù)流的帶寬需求也將得到保障。

3.3　場(chǎng)景2：對(duì)比OPPBG算法

在本場(chǎng)景中，本文提出的算法與OPPBG算法進(jìn)行帶寬保障性能比較。假定有兩條需要保障帶寬需求的業(yè)務(wù)流量，均從h1發(fā)往h2。第一條業(yè)務(wù)的帶寬需求為65 Mbit/s，第二條業(yè)務(wù)流量在第一條業(yè)務(wù)流發(fā)出10秒后開始發(fā)送，其帶寬需求為25 Mbit/s。在這一場(chǎng)景中，無論選用本文提出的算法，還是選用OPPBG算法進(jìn)行路徑選擇，最佳路徑均為(h1,S1,S2,S7,h2)。然而，在選出最佳路徑之后，OPPBG算法將直接調(diào)度流量至所選路徑，并不為不同的業(yè)務(wù)流量設(shè)置端口隊(duì)列以保障其帶寬。因此，這兩條業(yè)務(wù)流將平分鏈路剩余帶寬，其傳輸速率大約為45 Mbit/s到50 Mbit/s。顯然，第一條業(yè)務(wù)65 Mbit/s的帶寬需求將無法得到滿足，其傳輸速率將受到影響，如圖6所示。

圖6　未設(shè)置端口隊(duì)列時(shí)的傳輸速率

采用本文提出的方法，當(dāng)選擇出最佳調(diào)度路徑之后，將沿調(diào)度路徑在交換機(jī)靠近目的端的端口上為各業(yè)務(wù)流設(shè)置不同限速的隊(duì)列。為第一條業(yè)務(wù)流設(shè)置最小速率為60 Mbit/s、最大速率為80 Mbit/s的隊(duì)列，為第二條業(yè)務(wù)流設(shè)置最小速率為20 Mbit/s、最大速率為30 Mbit/s的隊(duì)列，分別保障兩條業(yè)務(wù)的帶寬需求。通過測(cè)試，這兩條業(yè)務(wù)流均能夠達(dá)到其所需的傳輸速率，業(yè)務(wù)服務(wù)質(zhì)量不受影響，如圖7所示。

圖7　設(shè)置端口隊(duì)列時(shí)的傳輸速率

通過實(shí)驗(yàn)對(duì)比可以看出，采用路徑選擇與設(shè)置端口隊(duì)列結(jié)合的方式，后來的業(yè)務(wù)流量不會(huì)影響網(wǎng)絡(luò)中已存在的業(yè)務(wù)流的服務(wù)質(zhì)量。二者可以分別獨(dú)立地正常傳輸，而不會(huì)互相干擾沖突。

4　結(jié)　語

本文對(duì)使用OpenFlow設(shè)置端口隊(duì)列的方法以及OPPBG算法的不足進(jìn)行了分析，并提出了融合改進(jìn)的方案。通過實(shí)驗(yàn)結(jié)果對(duì)比分析，改進(jìn)后的基于SDN的路徑選擇與帶寬保障策略能夠有效保障每條業(yè)務(wù)流的傳輸速率，避免擁塞并提高網(wǎng)絡(luò)的穩(wěn)定性。在未來的工作中，我們將針對(duì)不同的服務(wù)目標(biāo)，嘗試在更為復(fù)雜的網(wǎng)絡(luò)環(huán)境和真實(shí)網(wǎng)絡(luò)環(huán)境中對(duì)本文提出的算法進(jìn)行測(cè)試和優(yōu)化，從而使算法適用性更強(qiáng)。

[1] Thomas D N, Gray K. SDN: Software Defined Networks[M]. O’Reilly Media, 2013.

[2] 黃韜，劉江，魏亮，等. 軟件定義網(wǎng)絡(luò)核心原理與應(yīng)用實(shí)踐[M]. 北京:人民郵電出版社，2014.

[3] Open Networking Foundation. OpenFlow switch specification version 1.3.0 [EB/OL]. [2016-12-30]. https://www.opennetworking.org/.

[4] 肖軍弼,隋萌萌,李芃. 基于SDN的網(wǎng)絡(luò)帶寬保障系統(tǒng)[J]. 計(jì)算機(jī)系統(tǒng)應(yīng)用, 2016, 25(6):48-52.

[5] Tang W, Liu G, Yang X M, et al. OpenFlow-based path-planning with bandwidth guarantee in the inter-datacenter network[J]. Journal of South-Central University for Nationalities (Nat. Sci. Edition), 2016, 35(2): 128-134.

[6] Agarwal S, Kodialam M, Lakshman T V. Traffic engineering in software defined networks[C]// INFOCOM, 2013 Proceedings IEEE. IEEE, 2013:2211-2219.

[7] Nagaraj K, Bharadia D, Mao H, et al. NUMFabric: fast and flexible bandwidth allocation in datacenters[C]// Proceedings of the ACM SIGCOMM 2016 Conference, 2016:188-201.

[8] Mininet Team. Mininet [EB/OL]. [2016-12-21]. http://mininet.org/.

[9] Project Floodlight. Floodlight controller [EB/OL]. [2016-12-12]. http://www.projectfloodlight.org/.