基于OpenFlow的流量控制功能設計和實現

◆高志鑫 程 煒 徐天奇 李 琰

（云南民族大學電氣信息工程學院 云南 650500）

基于OpenFlow的流量控制功能設計和實現

◆高志鑫 程 煒 徐天奇 李 琰

（云南民族大學電氣信息工程學院 云南 650500）

OpenFlow協議使得網絡具有高度的靈活性以及強大的可編程能力，本文利用這一特點,通過軟件仿真的形式，在Floodlight控制器的基礎上實現了QoS流量控制功能，并在Mininet仿真實驗環境下實現了系統端口TCP限速、TCP帶寬保障以及視頻流速率帶寬保障三個具體的QoS策略。

OpenFlow；流量控制；QoS

0 引言

OpenFlow最早由斯坦福大學的NickMcKeown教授[1]等研究人員在2008年4月中提出[2]，是一種將控制和轉發分離開的架構。其基本理念在于將控制邏輯從網絡設備中抽離出來，人們可以對其進行任意的編程，對網絡層次結構以及各個層面之間的關系和接口進行規劃。它的提出最大化限度地提高了網絡資源利用率，使得網絡的配置和管理更加快速靈活，提高了網絡運行效率的同時，也抑制了網絡基礎設施的無限制擴張，減少了網絡部署和維護的成本[3]，在不改動網絡設備本身的情況下，實現新型的網絡協議和拓撲架構。

從2008年提出到現在，OpenFlow已經在硬件和軟件支持方面取得了長足的發展，尤其推動了QoS的技術創新。通常，一個完整的OpenFlow網絡是由控制器、交換機和OpenFlow協議組成的，通過控制器下發流表規則，集中控制交換機中流的處理和轉發行為[4]。在整個管理系統中QoS控制管理模塊部署在OpenFlow控制器上，提供DiffServ模型的流表控制管理功能。其中，OpenFlow網絡流表的下發由控制器和被控制的OpenFlow交換機通過OpenFlow協議規范來完成。OpenFlow交換機提供了多種計數器，對通過交換機的流進行字節數和報文數的統計和分類，并將不滿足條件的報文丟棄或者延遲發送,最終實現QoS技術。

本文將通過開源軟交換機上進行二次開發，實現基于OpenFlow協議的傳統 DiffServ模型流分類、標記和入隊的流表控制機制，和基于HTB算法的隊列管理和隊列調度算法的流量控制機制，最后將控制器和交換機進行集中式控制分布式處理的方式進行部署設計，并完成三個具體QoS策略實現。

1 實驗測試方法

實驗測試首先通過 Mininet的custom下的Python文件建立自定義拓撲，如圖1：

圖1 Mininet自定義拓撲

MAC地址00:00:00:00:00:00:00:01、00:00:00:00:00:00:00:02分別為 OpenvSwitch1和OpenvSwitch2，連接OpenvSwitch1的為服務器，提供視頻流、Web等服務，連接 OpenvSwitch2 的為主機Host1,Host2。當被標記的數據流通過OpenvSwitch 時，在其上應用的QoS代理對交換機進行的隊列配置應具有對這些數據流的分組進行匯聚分類和轉發的能力。如果Host1到Host2方向上的數據流的帶寬與事先配置的HTB隊列調度算法設置的帶寬一致，則可驗證 OpenFlowQoS管理系統上的DiffServ模型流量控制功能的正確性。同時，TCP測試客戶端執行：iperf-s，服務器執行：iperf-c10.0.0.2。

2 流量控制功能驗證

2.1 系統端口速率 TCP 限速測試

為了驗證管理系統指令配置模塊的配置的結果，從Host進行打包測試，驗證配置端口速率限制的正確性。首先由服務器作為服務端，Host1 作為客戶端進 行TCP打包，然后加入 QoS 策略再進行 TCP 打包測試。從打包結果可以看出 QoS 策略完成了端口隊列速率限制的功能。首先不加入策略,服務器到Host1的TCP帶寬為20Gbps左右,測試結果如圖2所示：

圖2 查看加入Qos策略之前,h1的TCP帶寬

然后開啟QoS的服務（圖3）：

圖3 開啟QoS功能

在OpenvSwitch1的接口上創建Queue隊列機制（圖4）:創建一條實際的QoSPolicy策略（圖5）：

圖4 創建queue隊列

圖5 創建qos策略

最后利用iperf工具測試服務器到Host1的TCP速率（圖6）：

圖6 查看加入QoS策略之后，h1的TCP帶寬

不加入隊列機制時由服務器向Host1發送的數據流速率在20Gbps左右，在加入了一條限制隊列之后(限制在 2Mbps)實驗結果顯示，由服務器向 Host1 發送的數據流速率限制在了2Mbps左右，與前面配置的預期結果一致，證明了QoS系統對底層交換設備流量控制功能的正確性。同理，對其他流量可以做限速來保障需要額外帶寬的流量。

2.2 系統端口 TCP 帶寬保障測試

在第一個測試的基礎上改變 OVS 上的 Queue隊列機制, Queue0 的機制是保障最低的帶寬為 10Mbps（圖7）:

圖7 顯示Queue0隊列

定義一條具體的 TCP 流基于 Queue0,將具體的 TCP 流基于 Queue0 的 QoS 策略寫入 Json文件（圖8）：

圖 8 定義TCP流基于Queue0隊列

再利用iperf工具測試服務器到Host1的TCP速率（圖9）：

圖 9 顯示TCP流帶寬

在加入Queue0隊列之后速度比之前20Gbps降低,主要因為Queue0的策略保障最低帶寬為10Mbps,所以帶寬還是達到了861Mbps。

2.3 系統視頻流速率帶寬保障測試

在Floodlight 控制器中已經聲明 Protocol=“4b”是Packet_Video 流量,說明可以具體到特定視頻流的帶寬保障。改變OVS上的Queue隊列機制, Queue0的機制是保障最低的帶寬為20kbps，如圖10:

圖10 顯示queue0隊列

將視頻流量寫入 QoS Policy 策略，Queue隊列機制使用Queue0 帶寬隊列，如圖11:

圖11 視頻流QoS Policy寫入成功

再利用iperf工具測試服務器到Host1的視頻流速率，如圖12：

圖12 顯示視頻流帶寬

可見，借助Floodlight控制器可對視頻流進行單獨區分并且保障其帶寬。

3 總結

本文在Mininet仿真實驗環境下實現了三個具體QoS策略：（1）限制基于TCP流量或者其他流量來保障服務級別高的帶寬；（2）直接保障基于TCP流量或者其他流量的帶寬；（3）借助Floodlight控制器對視頻流進行單獨區分并且保障其帶寬。仿真實驗驗證了這三種QoS策略的有效性。

[1] McKeown N,Software-defined networking.[C].//INFO COM keynote talk/.2009.

[2]Open Networking Foundation.Software-defined networking:The new norm for networks.[R].ONF White Paper/.2015.

[3]Thomas D.Nadeau,Ken Gray,畢軍,張紹宇,姚廣等.軟件定義網絡:SDN與OpenFlow解析.[M].北京:人民郵電出版社.2014.

[4]左青云,陳鳴,趙廣松等.基于OpenFlow的SDN技術研究.[J].軟件學報.2013(05):1078-1097.

本文受國家自然科學基金（61461055,61761049）與云南省高校科技創新團隊支持計劃資助（通訊作者：李琰）。