◆高志鑫 程 煒 徐天奇 李 琰
(云南民族大學(xué)電氣信息工程學(xué)院 云南 650500)
基于OpenFlow的流量控制功能設(shè)計和實現(xiàn)
◆高志鑫 程 煒 徐天奇 李 琰
(云南民族大學(xué)電氣信息工程學(xué)院 云南 650500)
OpenFlow協(xié)議使得網(wǎng)絡(luò)具有高度的靈活性以及強(qiáng)大的可編程能力,本文利用這一特點(diǎn),通過軟件仿真的形式,在Floodlight控制器的基礎(chǔ)上實現(xiàn)了QoS流量控制功能,并在Mininet仿真實驗環(huán)境下實現(xiàn)了系統(tǒng)端口TCP限速、TCP帶寬保障以及視頻流速率帶寬保障三個具體的QoS策略。
OpenFlow;流量控制;QoS
OpenFlow最早由斯坦福大學(xué)的NickMcKeown教授[1]等研究人員在2008年4月中提出[2],是一種將控制和轉(zhuǎn)發(fā)分離開的架構(gòu)。其基本理念在于將控制邏輯從網(wǎng)絡(luò)設(shè)備中抽離出來,人們可以對其進(jìn)行任意的編程,對網(wǎng)絡(luò)層次結(jié)構(gòu)以及各個層面之間的關(guān)系和接口進(jìn)行規(guī)劃。它的提出最大化限度地提高了網(wǎng)絡(luò)資源利用率,使得網(wǎng)絡(luò)的配置和管理更加快速靈活,提高了網(wǎng)絡(luò)運(yùn)行效率的同時,也抑制了網(wǎng)絡(luò)基礎(chǔ)設(shè)施的無限制擴(kuò)張,減少了網(wǎng)絡(luò)部署和維護(hù)的成本[3],在不改動網(wǎng)絡(luò)設(shè)備本身的情況下,實現(xiàn)新型的網(wǎng)絡(luò)協(xié)議和拓?fù)浼軜?gòu)。
從2008年提出到現(xiàn)在,OpenFlow已經(jīng)在硬件和軟件支持方面取得了長足的發(fā)展,尤其推動了QoS的技術(shù)創(chuàng)新。通常,一個完整的OpenFlow網(wǎng)絡(luò)是由控制器、交換機(jī)和OpenFlow協(xié)議組成的,通過控制器下發(fā)流表規(guī)則,集中控制交換機(jī)中流的處理和轉(zhuǎn)發(fā)行為[4]。在整個管理系統(tǒng)中QoS控制管理模塊部署在OpenFlow控制器上,提供DiffServ模型的流表控制管理功能。其中,OpenFlow網(wǎng)絡(luò)流表的下發(fā)由控制器和被控制的OpenFlow交換機(jī)通過OpenFlow協(xié)議規(guī)范來完成。OpenFlow交換機(jī)提供了多種計數(shù)器,對通過交換機(jī)的流進(jìn)行字節(jié)數(shù)和報文數(shù)的統(tǒng)計和分類,并將不滿足條件的報文丟棄或者延遲發(fā)送,最終實現(xiàn)QoS技術(shù)。
本文將通過開源軟交換機(jī)上進(jìn)行二次開發(fā),實現(xiàn)基于OpenFlow協(xié)議的傳統(tǒng) DiffServ模型流分類、標(biāo)記和入隊的流表控制機(jī)制,和基于HTB算法的隊列管理和隊列調(diào)度算法的流量控制機(jī)制,最后將控制器和交換機(jī)進(jìn)行集中式控制分布式處理的方式進(jìn)行部署設(shè)計,并完成三個具體QoS策略實現(xiàn)。
實驗測試首先通過 Mininet的custom下的Python文件建立自定義拓?fù)?,如圖1:
圖1 Mininet自定義拓?fù)?/p>
MAC地址00:00:00:00:00:00:00:01、00:00:00:00:00:00:00:02分別為 OpenvSwitch1和OpenvSwitch2,連接OpenvSwitch1的為服務(wù)器,提供視頻流、Web等服務(wù),連接 OpenvSwitch2 的為主機(jī)Host1,Host2。當(dāng)被標(biāo)記的數(shù)據(jù)流通過OpenvSwitch 時,在其上應(yīng)用的QoS代理對交換機(jī)進(jìn)行的隊列配置應(yīng)具有對這些數(shù)據(jù)流的分組進(jìn)行匯聚分類和轉(zhuǎn)發(fā)的能力。如果Host1到Host2方向上的數(shù)據(jù)流的帶寬與事先配置的HTB隊列調(diào)度算法設(shè)置的帶寬一致,則可驗證 OpenFlowQoS管理系統(tǒng)上的DiffServ模型流量控制功能的正確性。同時,TCP測試客戶端執(zhí)行:iperf-s,服務(wù)器執(zhí)行:iperf-c10.0.0.2。
2.1 系統(tǒng)端口速率 TCP 限速測試
為了驗證管理系統(tǒng)指令配置模塊的配置的結(jié)果,從Host進(jìn)行打包測試,驗證配置端口速率限制的正確性。首先由服務(wù)器作為服務(wù)端,Host1 作為客戶端進(jìn) 行TCP打包,然后加入 QoS 策略再進(jìn)行 TCP 打包測試。從打包結(jié)果可以看出 QoS 策略完成了端口隊列速率限制的功能。首先不加入策略,服務(wù)器到Host1的TCP帶寬為20Gbps左右,測試結(jié)果如圖2所示:
圖2 查看加入Qos策略之前,h1的TCP帶寬
然后開啟QoS的服務(wù)(圖3):
圖3 開啟QoS功能
在OpenvSwitch1的接口上創(chuàng)建Queue隊列機(jī)制(圖4):創(chuàng)建一條實際的QoSPolicy策略(圖5):
圖4 創(chuàng)建queue隊列
圖5 創(chuàng)建qos策略
最后利用iperf工具測試服務(wù)器到Host1的TCP速率(圖6):
圖6 查看加入QoS策略之后,h1的TCP帶寬
不加入隊列機(jī)制時由服務(wù)器向Host1發(fā)送的數(shù)據(jù)流速率在20Gbps左右,在加入了一條限制隊列之后(限制在 2Mbps)實驗結(jié)果顯示,由服務(wù)器向 Host1 發(fā)送的數(shù)據(jù)流速率限制在了2Mbps左右,與前面配置的預(yù)期結(jié)果一致,證明了QoS系統(tǒng)對底層交換設(shè)備流量控制功能的正確性。同理,對其他流量可以做限速來保障需要額外帶寬的流量。
2.2 系統(tǒng)端口 TCP 帶寬保障測試
在第一個測試的基礎(chǔ)上改變 OVS 上的 Queue隊列機(jī)制, Queue0 的機(jī)制是保障最低的帶寬為 10Mbps(圖7):
圖7 顯示Queue0隊列
定義一條具體的 TCP 流基于 Queue0,將具體的 TCP 流基于 Queue0 的 QoS 策略寫入 Json文件(圖8):
圖 8 定義TCP流基于Queue0隊列
再利用iperf工具測試服務(wù)器到Host1的TCP速率(圖9):
圖 9 顯示TCP流帶寬
在加入Queue0隊列之后速度比之前20Gbps降低,主要因為Queue0的策略保障最低帶寬為10Mbps,所以帶寬還是達(dá)到了861Mbps。
2.3 系統(tǒng)視頻流速率帶寬保障測試
在Floodlight 控制器中已經(jīng)聲明 Protocol=“4b”是Packet_Video 流量,說明可以具體到特定視頻流的帶寬保障。改變OVS上的Queue隊列機(jī)制, Queue0的機(jī)制是保障最低的帶寬為20kbps,如圖10:
圖10 顯示queue0隊列
將視頻流量寫入 QoS Policy 策略,Queue隊列機(jī)制使用Queue0 帶寬隊列,如圖11:
圖11 視頻流QoS Policy寫入成功
再利用iperf工具測試服務(wù)器到Host1的視頻流速率,如圖12:
圖12 顯示視頻流帶寬
可見,借助Floodlight控制器可對視頻流進(jìn)行單獨(dú)區(qū)分并且保障其帶寬。
本文在Mininet仿真實驗環(huán)境下實現(xiàn)了三個具體QoS策略:(1)限制基于TCP流量或者其他流量來保障服務(wù)級別高的帶寬;(2)直接保障基于TCP流量或者其他流量的帶寬;(3)借助Floodlight控制器對視頻流進(jìn)行單獨(dú)區(qū)分并且保障其帶寬。仿真實驗驗證了這三種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,畢軍,張紹宇,姚廣等.軟件定義網(wǎng)絡(luò):SDN與OpenFlow解析.[M].北京:人民郵電出版社.2014.
[4]左青云,陳鳴,趙廣松等.基于OpenFlow的SDN技術(shù)研究.[J].軟件學(xué)報.2013(05):1078-1097.
本文受國家自然科學(xué)基金(61461055,61761049)與云南省高??萍紕?chuàng)新團(tuán)隊支持計劃資助(通訊作者:李琰)。