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

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

1(中國石油大學(華東)計算機與通信工程學院　山東 青島 266580) 2(下一代互聯網重大應用技術(北京)工程研究中心有限公司　北京 100084)

0　引　言

校園專網是校園網絡體系中的重要組成部分，其服務范圍涵蓋財務、安防、能源監管等校園生活的方方面面。在傳統網絡中，開通校園專網通常需要管理員進行大量的接口和ACL規則配置，過程十分繁瑣。且專網一旦開通，一般不會發生大規模變化,若要開通新的專網業務，則需要執行大量配置變更以實現數據精準轉發和流量安全隔離。受種種因素所限，傳統網絡體系結構下的校園專網存在安全性、靈活性、穩定性和可擴展性等方面的缺陷。軟件定義網絡SDN依靠其數控分離、集中管理的強大優勢，通過控制器下發專網管理策略，從全局視角實現對專網的管控，能夠實現新增設備的即插即用和配置策略的自動復制下發，簡化管理運維負擔，提高變更管理效率[1]。

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

1　設置端口隊列與OPPBG算法

1.1　使用OpenFlow設置端口隊列

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

在設置隊列和調度流量之前，文獻[4]首先使用Dijkstra算法選擇從源端到目的端的最短路徑。然后沿此路徑在一段適當的鏈路上，多個具有不同最大速率和最小速率配置的隊列將設置在端口上用于限制最大傳輸速率并保障最小帶寬需求。通過OpenFlow的流表下發策略，不同帶寬需求的業務將被放入適當的隊列中。流表的匹配字段表示需要保障帶寬的業務，動作字段設置為Set Queue。

使用OpenFlow設置端口隊列能夠通過不同速率限制的隊列有效區分不同帶寬需求的業務，從而為重要業務提供有效的帶寬保障，而且能夠排除普通業務的干擾，對重要業務流具有較強的控制力。但是設置端口隊列前的路徑選擇采用簡單的最短路徑方法，沒有考慮當前鏈路狀態和已存在于路徑中的流量。當多條業務流的總帶寬需求超過鏈路容量時，極易發生擁塞，導致重要業務的服務質量大大降低。

1.2　OPPBG算法

為了滿足服務在不同時間尺度的不同帶寬需求，文獻[5]提出了OPPBG算法。在該算法中，基于北向接口[6]的SDN管理平臺使用REST API收集全網信息，RBG(Routing with Bandwidth Guarantee)算法根據收集到的網絡信息執行路由算法得到調度路徑，最后根據計算結果生成或更新流表條目并將流表下發至相應的交換機中。

RBG算法將路徑中當前存在的流量和鏈路容量納入考慮范圍。三元組fw(src,dst,ban)用于描述從源節點src發往目的節點dst、帶寬需求為ban的業務流fw。該算法首先創建當前網絡拓撲的副本，并刪除剩余帶寬不滿足fw需求的鏈路。隨后，在拓撲副本中，使用Dijkstra算法計算從源節點src到目的節點dst的最短路徑(此最短路徑的鏈路剩余帶寬必定滿足fw的帶寬需求)，由此得出調度流量的最佳路徑。

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

2　基于SDN的路徑選擇與帶寬保障策略設計

2.1　路徑選擇算法描述

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

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

(1)

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

(2)

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

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

(3)

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

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

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

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

di=ri-min(ri)

(4)

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

(5)

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

為直觀描述整個算法流程，圖1通過一個簡單的示例對上述過程加以解釋。在該示例中，從源節點S1到目的節點S8的業務流f的帶寬需求為12 Mbit/s。在圖1所示的拓撲中，每段鏈路上的數字表示該段鏈路的剩余可用帶寬(假定所有鏈路長度相同)。圖1(a)中，鏈路剩余帶寬不滿足f的帶寬需求的鏈路(S2，S7)被刪除，提取出的新拓撲中所有鏈路均能夠滿足f的帶寬需求。圖1(b)中，使用Dijkstra算法計算最短路徑，較長的路徑(S2，S5，S6，S7)被排除。此時得到兩條最短路徑，并且它們的鏈路最小剩余帶寬相同(均為15 Mbit/s)。隨后根據第1步得到兩條路徑的差值組(0,10,15,15)和(0,5,15,15)。使用式(5)計算兩組數據的方差，第一組的方差為50，而第二組為56.25。經過以上路徑選擇過程，我們將選擇方差較小的路徑(S1，S2，S3，S7，S8)作為最佳路徑。因為該條路徑相比于其他路徑更加穩定健壯，占用后的剩余可用帶寬更多，不會因某段鏈路的其他突發流量而輕易造成鏈路擁塞(如可能出現從S2發往S3的突發流量，因該段鏈路帶寬剩余更多，不會輕易擁塞)。

2.2　帶寬保障過程

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

在選定最佳調度路徑之后，我們將沿該路徑在每臺交換機靠近目的端的端口上為業務流設置端口隊列。隊列包含對業務流的最大傳輸速率和最小傳輸速率的限制，并指定處理該業務數據包的方式(從某個端口將業務流轉發出去，或者將其丟棄)。

同時，為了確保多個重要業務在傳輸過程中均能獲得足夠的帶寬，每個業務都會被添加到單獨的隊列中。即使可能有多個帶寬需求相同或相近的業務，它們原本可以被添加到同一個隊列中，但我們仍然選擇創建多個相同的隊列，將每個業務獨立添加到一個隊列中。這種處理方式將防止同一隊列中的多個業務平分剩余可用帶寬，避免出現一個或多個業務帶寬分配不足的情況。對于整個系統而言，總體處理流程如圖2所示。

圖2　系統總體流程圖

3　實　驗

本實驗設計了兩個模擬場景，分別通過兩條先后發出的不同業務流，將本文提出的算法與OPPBG算法和端口隊列設置方法在保障業務帶寬需求、降低干擾等方面進行比較。

3.1　實驗環境

實驗在運行于Linux系統(安裝在VMware 10.0中的Ubuntu 16.04)的Mininet[8]中創建的虛擬環境下進行。SDN控制器選用運行于Ubuntu的Floodlight控制器[9]。為生成UDP測試流量，實驗選用Iperf軟件測試工具，以生成穩定的測試流量并提供包括傳輸帶寬在內的反饋信息。

實驗所用的網絡拓撲如圖3所示。該網絡由7臺OpenFlow交換機和6臺主機組成，每段鏈路的容量(即鏈路帶寬)為100 Mbit/s。在圖3中，每段鏈路上的數字表示該段鏈路的剩余可用帶寬。所有OpenFlow交換機均連接到Floodlight控制器。

圖3　實驗采用的網絡拓撲

3.2　場景1：對比端口隊列設置方法

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

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

通過對比以上實驗結果可以看出，采用路徑選擇算法后，最初的業務流不會受后來業務流的干擾，并且后續業務流的帶寬需求也將得到保障。

3.3　場景2：對比OPPBG算法

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

圖6　未設置端口隊列時的傳輸速率

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

圖7　設置端口隊列時的傳輸速率

通過實驗對比可以看出，采用路徑選擇與設置端口隊列結合的方式，后來的業務流量不會影響網絡中已存在的業務流的服務質量。二者可以分別獨立地正常傳輸，而不會互相干擾沖突。

4　結　語

本文對使用OpenFlow設置端口隊列的方法以及OPPBG算法的不足進行了分析，并提出了融合改進的方案。通過實驗結果對比分析，改進后的基于SDN的路徑選擇與帶寬保障策略能夠有效保障每條業務流的傳輸速率，避免擁塞并提高網絡的穩定性。在未來的工作中，我們將針對不同的服務目標，嘗試在更為復雜的網絡環境和真實網絡環境中對本文提出的算法進行測試和優化，從而使算法適用性更強。

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

[2] 黃韜，劉江，魏亮，等. 軟件定義網絡核心原理與應用實踐[M]. 北京:人民郵電出版社，2014.

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

[4] 肖軍弼,隋萌萌,李芃. 基于SDN的網絡帶寬保障系統[J]. 計算機系統應用, 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/.