鄭 鵬 胡成臣 李 昊

(西安交通大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)系 西安 710049)(智能網(wǎng)絡(luò)與網(wǎng)絡(luò)安全教育部重點(diǎn)實(shí)驗(yàn)室(西安交通大學(xué)) 西安 710049)(zeepean@gmail.com)

軟件定義網(wǎng)絡(luò)(software defined networking, SDN)通過分離的控制平面和數(shù)據(jù)平面，給網(wǎng)絡(luò)管理提供了統(tǒng)一的編程接口，帶來了極大的靈活性.OpenFlow作為最具影響力的控制平面和數(shù)據(jù)平面的通信協(xié)議，成為了業(yè)界的事實(shí)標(biāo)準(zhǔn)[1].但是這種控制平面與數(shù)據(jù)平面完全分離的方式需要在OpenFlow交換機(jī)和控制器之間頻繁地交互各種控制器南向接口(控制器與交換機(jī)之間的接口)消息.而過于繁雜的南向接口交互開銷對控制器的處理能力、數(shù)據(jù)通路處理延時、南向接口的信道帶寬等造成很大的壓力，成為網(wǎng)絡(luò)性能提升的瓶頸.

Fig. 1 OpenFlow procedure of control flow and data flow圖1 典型的OpenFlow網(wǎng)絡(luò)控制流和數(shù)據(jù)流示意圖

在OpenFlow網(wǎng)絡(luò)中，交換機(jī)和控制器之間開銷主要體現(xiàn)在控制器通過交互指揮交換機(jī)完成對數(shù)據(jù)包的處理.OpenFlow網(wǎng)絡(luò)通過控制器下發(fā)到交換機(jī)中的流表來確定數(shù)據(jù)包的轉(zhuǎn)發(fā)等操作.當(dāng)新的數(shù)據(jù)包達(dá)到OpenFlow交換機(jī)時，典型的處理過程如圖1所示.抵達(dá)網(wǎng)絡(luò)的數(shù)據(jù)包首先與交換機(jī)中流表項(xiàng)的匹配域(match field)依次匹配，如圖1數(shù)據(jù)流路徑1)與控制流路徑①.若匹配成功，則按照該流表項(xiàng)的動作域(action field)處理數(shù)據(jù)包，比如轉(zhuǎn)發(fā)、丟棄等；若匹配失敗，則觸發(fā)Table-Miss事件，交換機(jī)通過Packet-In消息將數(shù)據(jù)包交給控制器處理，如圖1中數(shù)據(jù)流路徑2).控制器計(jì)算數(shù)據(jù)包的轉(zhuǎn)發(fā)路徑，并通過Flow-Mod消息將流表項(xiàng)安裝到交換機(jī)，如圖1中控制流路徑②.同時控制器通過Packet-Out消息將數(shù)據(jù)包返回給交換機(jī)，如圖1中數(shù)據(jù)流路徑3)和控制流路徑③.數(shù)據(jù)包回到交換機(jī)后，匹配這條流的數(shù)據(jù)包都按照新下發(fā)的流表項(xiàng)抵達(dá)目的地，如圖1中數(shù)據(jù)流4)和5)所示.

由于交換機(jī)中的流表資源容量有限，無法匹配到所有的數(shù)據(jù)包.對于無法匹配到正常流表項(xiàng)的數(shù)據(jù)包，都可能會給交換機(jī)和控制器的交互帶來大量的Packet-In消息和Flow-Mod消息，同時也會導(dǎo)致如下問題：1)分離的數(shù)據(jù)平面和控制平面使得Table-Miss的數(shù)據(jù)包需要往返于交換機(jī)與控制器之間，給網(wǎng)絡(luò)數(shù)據(jù)流帶來較大的時延和冗余的轉(zhuǎn)發(fā)路徑，兩者之間的交互容易成為網(wǎng)絡(luò)的瓶頸，影響網(wǎng)絡(luò)的性能[2].文獻(xiàn)[3]也指出數(shù)據(jù)流路徑建立時的Table-Miss是造成包傳輸時延的一個重要原因.2)流表“更新振蕩”問題.當(dāng)交換機(jī)中流表不足時，新流產(chǎn)生的Flow-Mod流表項(xiàng)找不到空間，則會替換掉交換機(jī)中現(xiàn)有的流表項(xiàng).然而控制器并不知道新下發(fā)的流表項(xiàng)對應(yīng)的數(shù)據(jù)流信息.如果新流表項(xiàng)對應(yīng)的數(shù)據(jù)流是一條小流(總字節(jié)數(shù)或總包數(shù)很小的流，具體定義見2.2節(jié))，那么小流表項(xiàng)的下發(fā)很可能會替換掉原流表中大流(其定義見2.2節(jié))對應(yīng)的流表項(xiàng).此后，交換機(jī)中的小流表項(xiàng)只會匹配到少量的數(shù)據(jù)包，造成流表利用率降低，流表資源浪費(fèi)；而被替換的大流表項(xiàng)很大概率會有后續(xù)的數(shù)據(jù)流到來，觸發(fā)更多的Packet-In消息和Flow-Mod消息，新到大流流表項(xiàng)的再次下發(fā)導(dǎo)致交換機(jī)中的流表項(xiàng)頻繁的變化和冗余的更替.這種流表更新振蕩現(xiàn)象進(jìn)一步加重了控制器南向接口的通信開銷，降低了網(wǎng)絡(luò)的整體性能，難以滿足當(dāng)前的云數(shù)據(jù)中心發(fā)展對網(wǎng)絡(luò)的帶寬和時延有著越來越高的要求[4].

對于增大的時延和冗余的轉(zhuǎn)發(fā)路徑，分析數(shù)據(jù)包轉(zhuǎn)發(fā)過程可以發(fā)現(xiàn)，除正常的轉(zhuǎn)發(fā)路徑之外，數(shù)據(jù)包需要額外的往返于交換機(jī)和控制器之間.如圖2所示，傳統(tǒng)OpenFlow網(wǎng)絡(luò)數(shù)據(jù)流的轉(zhuǎn)發(fā)路徑3)和4)是存在冗余的.這種冗余路徑的根源在于，控制器在計(jì)算數(shù)據(jù)包的轉(zhuǎn)發(fā)路徑時忽略了控制器這個特殊的“交換節(jié)點(diǎn)”的存在.而事實(shí)上，控制器在網(wǎng)絡(luò)中是承載著“交換節(jié)點(diǎn)”的功能的，因?yàn)榫W(wǎng)絡(luò)中不斷會有觸發(fā)Table-Miss的數(shù)據(jù)包(或包頭)到達(dá)控制器，這些數(shù)據(jù)包只能由控制器來處理.直觀上，如果將圖2中數(shù)據(jù)包經(jīng)過的路徑3)和4)替換為3′)，冗余的路徑4)就可被消除，數(shù)據(jù)包的傳輸時延就能降低.問題的困難之處在于我們無法簡單地使用路徑3′)替換掉路徑3)和4)，因?yàn)榭刂破鞲静豢赡艹惺苋W(wǎng)的流量.而流表更新振蕩問題是由控制器下發(fā)流表項(xiàng)時缺乏表項(xiàng)對應(yīng)的數(shù)據(jù)流信息導(dǎo)致，因此在控制器上實(shí)現(xiàn)對數(shù)據(jù)包流量的細(xì)粒度識，是防止大流表項(xiàng)被小流流表項(xiàng)替換的關(guān)鍵所在.

Fig. 2 The redundant forwarding path of OpenFlow data flow圖2 傳統(tǒng)OpenFlow網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)路徑冗余

真實(shí)網(wǎng)絡(luò)中的流量分布具有顯著的不均衡特性[5]：為數(shù)不多的大流占據(jù)著大量的網(wǎng)絡(luò)帶寬，但消耗的控制指令并不多；而占據(jù)少量網(wǎng)絡(luò)帶寬的小流，由于其數(shù)量巨大，需要消耗更多的控制指令和流表資源，甚至?xí)屨即罅鞯馁Y源導(dǎo)致重復(fù)的控制指令導(dǎo)致流表更新振蕩問題.這不僅消耗了大量的數(shù)據(jù)平面和控制平面之間的信道資源，造成了數(shù)據(jù)平面和控制平面的冗余交互，同時也會造成交換機(jī)流表資源的浪費(fèi)，增加數(shù)據(jù)包的時延.

本文基于網(wǎng)絡(luò)流量分布不均衡的特征，重點(diǎn)針對僅占據(jù)少量網(wǎng)絡(luò)帶寬但是種類繁多的小流，消除冗余路徑，降低傳輸時延，優(yōu)化控制器南向接口交互開銷.

1 相關(guān)工作

為了減小控制器的壓力，降低南向接口開銷，文獻(xiàn)[3]在交換機(jī)上利用額外的流表資源，記錄允許上傳給控制器的數(shù)據(jù)流信息，過濾出重要的信息轉(zhuǎn)發(fā)給控制器，減輕控制器壓力.但是該機(jī)制不僅消耗了過多流表資源，還需要對交換機(jī)進(jìn)行修改，很難在真實(shí)網(wǎng)絡(luò)中使用.文獻(xiàn)[5]深入分析了網(wǎng)絡(luò)流量的分布特性，并且提出了利用流量分布不均衡特性來進(jìn)行路由器設(shè)計(jì)的策略.作者針對單個網(wǎng)絡(luò)設(shè)備上的控制面和數(shù)據(jù)轉(zhuǎn)發(fā)面，提出了TFO(traffic-aware flow offloading)算法，用于提升轉(zhuǎn)發(fā)表的命中率，減小本地控制平面與數(shù)據(jù)平面的通信開銷.但其針對單個網(wǎng)絡(luò)設(shè)備“緊耦合”的數(shù)據(jù)-控制平面設(shè)計(jì)的算法無法用于解決OpenFlow網(wǎng)絡(luò)中數(shù)據(jù)-控制平面之間的交互開銷問題，原因如下：

1) 適用的網(wǎng)絡(luò)體系結(jié)構(gòu)有本質(zhì)的區(qū)別.TFO算法是對其先前工作基于硬件加速的軟件路由器原型[6]的系統(tǒng)描述，其算法適用于路由器內(nèi)部的控制平面和數(shù)據(jù)平面，如果網(wǎng)絡(luò)中有多個轉(zhuǎn)發(fā)設(shè)備，那么每個設(shè)備上都需要運(yùn)行其算法.而本文研究適用于數(shù)據(jù)-控制平面物理分離的OpenFlow網(wǎng)絡(luò)，能部署于整個網(wǎng)絡(luò)的集中式控制器上的算法.

2) 適用的體系系統(tǒng)不同導(dǎo)致算法的開銷有巨大的差異.由于TFO算法僅僅運(yùn)行在單個轉(zhuǎn)發(fā)設(shè)備上，因此需要處理的流量規(guī)模僅限于單個設(shè)備上未命中轉(zhuǎn)發(fā)表的新流，單節(jié)點(diǎn)失配的流量規(guī)模允許轉(zhuǎn)發(fā)設(shè)備上的控制器維護(hù)在不同時間片內(nèi)(1 s，10 s，10 min)所有流的大小排序；但是OpenFlow控制器面向全網(wǎng)所有的轉(zhuǎn)發(fā)設(shè)備，難以維護(hù)每個設(shè)備上的流量信息.另外，單個設(shè)備上靠近的數(shù)據(jù)-控制平面也允許TFO算法的控制器與轉(zhuǎn)發(fā)表實(shí)時的交互，例如在每一次更新轉(zhuǎn)發(fā)表之前，實(shí)時計(jì)算現(xiàn)存于轉(zhuǎn)發(fā)表的表項(xiàng)與擬更新的表項(xiàng)的差異.但是在OpenFlow網(wǎng)絡(luò)中要求控制器實(shí)時維護(hù)每個設(shè)備上的轉(zhuǎn)發(fā)表，或者在每次更新轉(zhuǎn)發(fā)表之前都向數(shù)據(jù)平面的設(shè)備請求當(dāng)前的轉(zhuǎn)發(fā)表內(nèi)容，不僅會對控制器的性能提出了更高的要求，同時也給數(shù)據(jù)-控制平面之間的交互引入了新的開銷，這也與本文想要解決的問題存在沖突.因此，針對OpenFlow網(wǎng)絡(luò)南向接口開銷優(yōu)化需要探索新的方法.

文獻(xiàn)[7]提出控制器按照主動(proactive)方式執(zhí)行規(guī)則下發(fā)：根據(jù)已知信息以及收集到的網(wǎng)絡(luò)特征，預(yù)測將要發(fā)生的轉(zhuǎn)發(fā)等事件，并提前安裝對應(yīng)規(guī)則.這種方法的優(yōu)點(diǎn)在于，由網(wǎng)絡(luò)中新流到達(dá)導(dǎo)致的Packet-In消息以及流安裝的事件被大大減少，但是它需要更大的硬件流表支持才能安裝足夠多的流預(yù)裝，在OpenFlow版本更新到1.3版本之后[8]，交換機(jī)將在流表溢出時直接用新安裝的流表項(xiàng)覆蓋原有流表項(xiàng)，因此無法達(dá)到預(yù)期的目標(biāo)，同時它對小流導(dǎo)致的控制指令數(shù)量并沒有改善.文獻(xiàn)[9]希望能夠結(jié)合2種策略的優(yōu)點(diǎn)，根據(jù)流特征使用不同策略下發(fā)規(guī)則.但是由于實(shí)際流量特征很難簡單預(yù)測，在很多情況下并不能有效運(yùn)行.在控制器資源有限的情況下，文獻(xiàn)[10]主動拋棄用戶設(shè)置的Packet-In消息，以保證基礎(chǔ)消息可以得到正常的響應(yīng).文獻(xiàn)[11]也有隊(duì)列機(jī)制，防止關(guān)鍵消息受到一般消息的阻塞.這種隊(duì)列機(jī)制都以犧牲響應(yīng)速度為代價(jià)來保證SDN控制平面的基本功能可以正常運(yùn)行.在大規(guī)模的網(wǎng)絡(luò)中，控制平面需要每秒能夠處理百萬條流產(chǎn)生的Packet-In消息[12].文獻(xiàn)[13]中提出了利用控制器直接將數(shù)據(jù)包轉(zhuǎn)發(fā)到目的交換機(jī)的策略，但這種策略要求控制器轉(zhuǎn)發(fā)數(shù)據(jù)包的同時也下發(fā)對應(yīng)的流表更新消息，因此無法解決流表冗余更新的問題，而這正是本文著重解決的問題.

2 系統(tǒng)設(shè)計(jì)

2.1 可抑制的繁重的交互開銷

本文優(yōu)化的交互開銷重點(diǎn)是指往返于控制平面和數(shù)據(jù)平面之間的“可抑制的繁重的交互開銷”，其中“可抑制”表示當(dāng)前的OpenFlow模型有可改進(jìn)的空間，而“繁重”意味著相關(guān)開銷可成為網(wǎng)絡(luò)性能瓶頸，對交互開銷的優(yōu)化具有較大的價(jià)值.通過對當(dāng)前的SDN網(wǎng)絡(luò)的分析，我們可以歸納出如下2類典型的可抑制的繁重的交互開銷：

第1類是控制器對數(shù)據(jù)平面重復(fù)性控制導(dǎo)致的開銷.OpenFlow網(wǎng)絡(luò)中交換機(jī)完全按照控制器的指令對流量進(jìn)行轉(zhuǎn)發(fā).指導(dǎo)數(shù)據(jù)包轉(zhuǎn)發(fā)行為的指令存儲在格式為規(guī)則-行為(rule-action)流表中，然而交換機(jī)中的流量資源是稀缺的，不可能存儲所有的轉(zhuǎn)發(fā)信息.因此隨著網(wǎng)絡(luò)事件的不斷發(fā)生，完成數(shù)據(jù)包的處理需要越來越多的指令；在交換機(jī)有限的資源限制下，舊的指令由于新的決策加入而被替換或者刪除.一個難以避免的問題是，這些被替換的指令信息并不是毫無用處，隨著后續(xù)網(wǎng)絡(luò)事件的發(fā)生，交換機(jī)可能還需要使用與被刪除指令同樣的信息來進(jìn)行決策.這會導(dǎo)致同樣的網(wǎng)絡(luò)事件重復(fù)發(fā)生的時候，控制器將不斷重復(fù)進(jìn)行數(shù)據(jù)包識別，決策以及控制命令下發(fā)，從而導(dǎo)致冗余的交互開銷.而我們對流量特征的分析結(jié)果(見3.1節(jié))顯示，僅占總帶寬1%的小流數(shù)量超過了總流數(shù)的一半，這就會消耗超過一半的控制器的轉(zhuǎn)發(fā)指令.因此，重復(fù)性控制指令的開銷有很大優(yōu)化空間.

第2類是數(shù)據(jù)平面流量從交換機(jī)穿越到控制器導(dǎo)致的開銷，主要是由數(shù)據(jù)包觸發(fā)Table-Miss事件導(dǎo)致.這類開銷數(shù)量巨大，當(dāng)交換機(jī)流表資源不足導(dǎo)致的流表更新振蕩現(xiàn)象會讓這類消息變得尤為繁重.

2.2 開銷優(yōu)化方案

本文提出一種基于流量特征的OpenFlow南向接口開銷優(yōu)化技術(shù)uFlow，通過控制器對數(shù)據(jù)流進(jìn)行細(xì)粒度的識別和記錄，在不影響控制器性能的情況下，利用控制器的可達(dá)性對占據(jù)少量網(wǎng)絡(luò)帶寬但是種類繁多的小流直接轉(zhuǎn)發(fā)，達(dá)到消除OpenFlow南向接口冗余開銷，節(jié)省交換機(jī)流表資源，同時減少時延的目的.

uFlow通過控制器上的流量實(shí)時識別算法，將需要處理的數(shù)據(jù)流識別為2類：大流和小流.

定義1. 小流.在Δt時間內(nèi)，對應(yīng)的數(shù)據(jù)包數(shù)量小于N且總字節(jié)數(shù)小于S的流.

定義2. 大流.在Δt時間內(nèi)，對應(yīng)的數(shù)據(jù)包數(shù)量大于N或總字節(jié)數(shù)大于S的流.參數(shù)Δt,N,S作為流量識別算法的參數(shù)，可以根據(jù)網(wǎng)絡(luò)運(yùn)行狀況動態(tài)確定.

Fig. 3 Mice flow procedure of uFlow圖3 uFlow對小流的處理流程

如果控制器識別到數(shù)據(jù)包對應(yīng)的是一條小流，那么控制器直接將該流對應(yīng)的所有數(shù)據(jù)包送達(dá)目的地交換機(jī)，如圖3所示.這樣既減少了該流的傳輸時延，又節(jié)省了交換機(jī)的流表空間.如果數(shù)據(jù)流被識別為大流，那么控制器首先將識別大流過程中到達(dá)的數(shù)據(jù)包直接送達(dá)目的交換機(jī)，同時立即下發(fā)流表項(xiàng)到交換機(jī)，使得后續(xù)的數(shù)據(jù)包都能夠通過流表項(xiàng)來轉(zhuǎn)發(fā)，如圖4所示，由此減少冗余的流表更新.

Fig. 4 Elephant flow procedure of uFlow圖4 uFlow對大流的處理流程

這種解決方案主要有如下優(yōu)點(diǎn)：

1) 極大地降低OpenFlow網(wǎng)絡(luò)中數(shù)據(jù)平面和控制平面的交互開銷，消除交換機(jī)和控制器之間的冗余交互.

2) 節(jié)省大量流表資源.值得注意的是，本文提出的方案與文獻(xiàn)[14]中的Rule-Caching算法并不沖突，二者是在2個不同的維度上節(jié)省流表資源.本文的方案中節(jié)省流表資源的原因在于，通過控制器對小流直接送達(dá)目的地，減少了交換機(jī)中小流對應(yīng)流表項(xiàng)的安裝，消除了潛在的流表冗余更新.

3) 節(jié)省OpenFlow交換機(jī)中的緩存空間，釋放控制流量.經(jīng)典的處理方式中，交換機(jī)必須要緩存Packet-In消息與Flow-Mod消息這段時間內(nèi)的數(shù)據(jù)包的內(nèi)容，浪費(fèi)了寶貴的緩存資源.而在本文的處理方式中，直接將整個數(shù)據(jù)包交給控制器來送達(dá)目的地.直觀上看來，這會消耗額外的交換機(jī)與控制器之間的帶寬資源，增加南向接口的開銷，但是我們的實(shí)驗(yàn)(見3.2節(jié))表明并非完全如此：因?yàn)檫@種方案消除了流表振蕩和冗余交互.

4) 這種設(shè)計(jì)可以大大降低小流時延.

2.3 uFlow系統(tǒng)設(shè)計(jì)

uFlow在不影響OpenFlow控制器上其他應(yīng)用程序?qū)Υ罅鬓D(zhuǎn)發(fā)的前提下，消除小流反復(fù)進(jìn)入退出對控制器網(wǎng)絡(luò)資源與計(jì)算資源的消耗.uFlow系統(tǒng)在控制器中的結(jié)構(gòu)如圖5所示，位于Packet-In消息入口和控制器核心服務(wù)之間.來自O(shè)penFlow交換機(jī)的Packet-In消息首先由大小流識別模塊處理.如果Packet-In消息內(nèi)容被識別為大流數(shù)據(jù)包，則直接將數(shù)據(jù)包交還給控制器，按照正常流程處理，比如后續(xù)由路由應(yīng)用計(jì)算并下發(fā)相應(yīng)的流表項(xiàng).

Fig. 5 Architecture of uFlow system圖5 uFlow系統(tǒng)架構(gòu)

如果被識別為小流，數(shù)據(jù)包則轉(zhuǎn)交給小流匹配表處理.小流匹配表中記錄了該模塊已處理過的小流信息，包括交換機(jī)端口與數(shù)據(jù)包目的地址的對應(yīng)關(guān)系等.若匹配成功，則更新小流匹配表中的計(jì)數(shù)信息，并通過Packet-Out消息直接將數(shù)據(jù)包送達(dá)目的地;若匹配失敗，則向控制器請求全局拓?fù)湫畔ⅲ@取到目的交換機(jī)ID和端口信息加入查找匹配表，最后再通過Packet-Out消息將數(shù)據(jù)包送達(dá)目的地，從而消除了小流量反復(fù)進(jìn)入退出對控制器網(wǎng)絡(luò)資源與計(jì)算資源的消耗.

下面我們通過與傳統(tǒng)OpenFlow網(wǎng)絡(luò)中數(shù)據(jù)包處理流程對比，來說明uFlow系統(tǒng)對于數(shù)據(jù)包處理的過程及特點(diǎn).

1) 傳統(tǒng)OpenFlow網(wǎng)絡(luò)中數(shù)據(jù)包處理流程

在傳統(tǒng)的OpenFlow網(wǎng)絡(luò)中，正如圖6所示，當(dāng)數(shù)據(jù)包到達(dá)OpenFlow交換機(jī)后，首先與交換機(jī)上的流表進(jìn)行匹配，若匹配成功，數(shù)據(jù)包按照匹配表項(xiàng)的指令進(jìn)行處理；若匹配失敗，數(shù)據(jù)包則被Packet-In消息轉(zhuǎn)發(fā)給控制器處理.控制器通過全局拓?fù)湫畔⒂?jì)算出數(shù)據(jù)包的轉(zhuǎn)發(fā)路徑，并通過Flow-Mod消息將新的流表項(xiàng)下發(fā)給交換機(jī).

交換機(jī)收到Flow-Mod添加流表的消息后，如果流表還有剩余空間，則直接將新的流表項(xiàng)插入流表中；如果流表已經(jīng)裝滿，則按照某種替換策略刪除一條舊的流表項(xiàng)，然后再插入新的流表項(xiàng).常用的替換策略包括最近最少使用算法(least recently used, LRU)、最不經(jīng)常使用算法(least frequency used, LFU)等.本文實(shí)驗(yàn)中采用替換策略為實(shí)際應(yīng)用中常用到的LRU替換方法.數(shù)據(jù)包處理的整體流程如圖6所示.

Fig. 6 Packet processing flow in OpenFlow Network圖6 傳統(tǒng)OpenFlow網(wǎng)絡(luò)中數(shù)據(jù)包處理流程

2) uFlow系統(tǒng)中數(shù)據(jù)包處理流程

Fig. 7 Packet processing flow in uFlow Network圖7 uFlow系統(tǒng)中數(shù)據(jù)包處理流程

與傳統(tǒng)的OpenFlow網(wǎng)絡(luò)處理流程不同，控制器收到Packet-In消息后并不直接進(jìn)行路由計(jì)算或者下發(fā)流表，而是首先對數(shù)據(jù)包進(jìn)行大小流判斷，根據(jù)判斷的結(jié)果作相應(yīng)的處理.當(dāng)數(shù)據(jù)包被判斷為大流之后，控制器才會下發(fā)Flow-Mod消息，達(dá)到節(jié)省控制信令、減少流表替換的效果.當(dāng)數(shù)據(jù)包被判斷為小流之后，控制器則直接將其送達(dá)目的地.uFlow系統(tǒng)對數(shù)據(jù)包處理的整體流程如圖7所示：

2.4 大小流識別算法

大小流識別模塊是uFlow系統(tǒng)對數(shù)據(jù)包分析的入口，負(fù)責(zé)處理所有Packet-In消息并區(qū)別大小流，根據(jù)識別的結(jié)果決定不同的處理方式.當(dāng)Packet-In到達(dá)控制器后，小流代理系統(tǒng)首先將該數(shù)據(jù)包交給大小流識別模塊.為了滿足數(shù)據(jù)包快速轉(zhuǎn)發(fā)的要求，我們設(shè)計(jì)了簡單高效的大小流識別算法：根據(jù)到達(dá)數(shù)據(jù)包的在一段時間內(nèi)的總數(shù)目和字節(jié)數(shù)來區(qū)分大小流.初始階段，我們認(rèn)為所有的數(shù)據(jù)包都是小流，由控制器直接轉(zhuǎn)發(fā).

大小流識別模塊記錄著當(dāng)前有效的大流集合和所有流的計(jì)數(shù)信息.數(shù)據(jù)包到達(dá)控制器之后，首先更新該數(shù)據(jù)包所在流的統(tǒng)計(jì)信息.如果該流在Δt時間內(nèi)累計(jì)的數(shù)據(jù)包總數(shù)超過N，或者數(shù)據(jù)包累計(jì)總字節(jié)數(shù)超過S，則數(shù)據(jù)包直接被判斷為大流數(shù)據(jù)包;否則判斷為小流數(shù)據(jù)包.最后，根據(jù)超時信息再次更新流的統(tǒng)計(jì)信息.大小流識別偽代碼描述如算法1所示：

算法1. 大小流識別算法.

輸入：待識別的數(shù)據(jù)包pkt;流的總包數(shù)，大小流區(qū)分參數(shù)N;流的總字節(jié)數(shù)，大小流區(qū)分參數(shù)S;控制器中記錄每條流包數(shù)量Ncnt;控制器中記錄每條流的總字節(jié)數(shù)Scnt；

輸出：0,數(shù)據(jù)包被判斷為小流;1,數(shù)據(jù)包被判斷為大流.

過程：FLOW DESCRIM (pkt,N,S,Ncnt,Scnt)

BEGIN

flowID←get_flowID(pkt)；

pkt_num←get_pkt_num(pkt)；

pkt_size←get_pkt_size(pkt)；

update_Ncnt(Ncnt,flowID,pkt_num)；

update_Scnt(Scnt,flowID,pkt_size)；

IFflowID.num>N‖flowID.size>S

RETURN 1；

ELSE

RETURN 0；

ENDIF

Check_timeout(Ncnt,Scnt).

END

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

3.1 流量分布特征實(shí)驗(yàn)

本小節(jié)將通過對實(shí)際網(wǎng)絡(luò)流量的統(tǒng)計(jì)來說明流量分布極度不均衡的特征，從而給uFlow的系統(tǒng)設(shè)計(jì)提供理論依據(jù).

我們總共分析了22.71 GB來自ISP核心路由器上的流量[15]的分布特征.通過固定長度的目的IP前綴(本文使用目的IP的前16 b)來區(qū)分一條流，我們分別得到了在不同的時間窗口下，真實(shí)流量中每條流對應(yīng)的數(shù)據(jù)包總數(shù)量和總大小的分布特征.圖8和圖9分別展示了在30 min內(nèi)通過核心路由器上的流量中每條流對應(yīng)的數(shù)據(jù)包總數(shù)目以及流數(shù)目的累計(jì)分布圖.如圖9所示，占比為1.3%的863條流對應(yīng)的數(shù)據(jù)包總數(shù)達(dá)到了90%.表1展示了在不同的時間窗口下網(wǎng)絡(luò)流量的分布特征.

Fig. 8 Packet number distribution in real traffic圖8 數(shù)據(jù)流對應(yīng)的包數(shù)目分布圖

Fig. 9 CDF of packet number in real traffic圖9 數(shù)據(jù)流對應(yīng)包數(shù)目的累計(jì)分布圖

這些數(shù)據(jù)都表明真實(shí)流量的分布特征是極度不均衡的.網(wǎng)絡(luò)中的小流種類繁多，占比非常高，因此與小流相對應(yīng)的流表項(xiàng)數(shù)量很大，需要消耗的控制平面與數(shù)據(jù)平面交互開銷也非常高.通過消除這些小流流表項(xiàng)的安裝來降低控制器南向接口交互開銷，節(jié)省交換機(jī)中的流表資源，符合uFlow系統(tǒng)設(shè)計(jì)的預(yù)期.

Table 1 Distribution of Traffic in Different Time Slot表1 不同時間窗口下網(wǎng)絡(luò)流量分布的不均衡特征

3.2 交互開銷優(yōu)化實(shí)驗(yàn)

為了驗(yàn)證uFlow系統(tǒng)對OpenFlow南向接口開銷優(yōu)化的效果.我們將交互消息劃分為如下2個類別：第1類控制平面發(fā)出的控制指令，主要是Flow-Mod消息，我們稱之為控制流交互開銷;第2類是由數(shù)據(jù)平面發(fā)出的攜帶數(shù)據(jù)包的消息，主要是Packet-In消息，我們稱之為數(shù)據(jù)流交互開銷.我們在SDN物理交換機(jī)OnetSwitch[16]平臺上對uFlow原型系統(tǒng)進(jìn)行了實(shí)驗(yàn)和測試.通過對真實(shí)網(wǎng)絡(luò)流量回放的方式，對uFlow系統(tǒng)的性能進(jìn)行了測試，主要測試指標(biāo)為：

1) 控制流交互開銷.控制器向交換機(jī)下發(fā)流表的總條數(shù)，即Flow-Mod消息的總數(shù)量.

2) 數(shù)據(jù)流交互開銷.數(shù)據(jù)平面穿越控制器的總流量，即Packet-In消息中數(shù)據(jù)包的總量.

作為對比，我們也使用同樣的流量對傳統(tǒng)的OpenFlow網(wǎng)絡(luò)處理系統(tǒng)交互開銷進(jìn)行了測試.

3.2.1 實(shí)驗(yàn)參數(shù)

在本文實(shí)驗(yàn)中，為了保持大小流區(qū)分算法的簡單與快速.我們設(shè)置小流參數(shù)為：在Δt=10 s時間內(nèi)，最多包數(shù)目N=16，最大字節(jié)數(shù)S=12 800 B.這些參數(shù)的設(shè)置來自于3.1節(jié)分析的數(shù)據(jù)流量中有近80%左右的數(shù)據(jù)流對應(yīng)的包數(shù)和字節(jié)數(shù)都不高于此.由于篇幅限制，關(guān)于參數(shù)的自適應(yīng)調(diào)整和分析可以作為一步的工作，不在此展開.

3.2.2 測試數(shù)據(jù)

本實(shí)驗(yàn)中測試用到的數(shù)據(jù)來自新西蘭WAND網(wǎng)絡(luò)研究組提供的某ISP核心路由器上的真實(shí)網(wǎng)絡(luò)流量*http://wand.net.nz/wits/index.php.這些數(shù)據(jù)流由DAG 3.7 GB捕獲卡[16]接入ISP核心路由器持續(xù)捕獲得到，包含了連續(xù)多天的流量.我們從不同時間段，根據(jù)鏈路負(fù)載程度選擇出3段具有代表性的流量進(jìn)行實(shí)驗(yàn)，每段流量的持續(xù)時間均為30 min.

1) Trace1：表示30 min重度負(fù)載流量.包含當(dāng)?shù)貢r間15:30-16:00時間段內(nèi)通過核心路由器上所有數(shù)據(jù)包.流量總大小為22.71 GB，數(shù)據(jù)包總數(shù)為40 311 405.

2) Trace2：表示30 min中度負(fù)載流量.包含當(dāng)?shù)貢r間18:30-19:00時間段內(nèi)通過核心路由器上所有數(shù)據(jù)包.流量總大小為16.13 GB，數(shù)據(jù)包總數(shù)為28 710 953.

3) Trace3：表示30 min輕度負(fù)載流量.包含當(dāng)?shù)貢r間02:00-02:30時間段內(nèi)通過核心路由器上所有數(shù)據(jù)包.流量總大小為6.01 GB，數(shù)據(jù)包總數(shù)為11 155 171.

3.2.3 開銷優(yōu)化實(shí)驗(yàn)結(jié)果

下面是OpenFlow南向接口交互開銷優(yōu)化的實(shí)驗(yàn)結(jié)果，包括控制流交互開銷和數(shù)據(jù)流交互開銷.

1) 控制流交互開銷

控制流交互開銷優(yōu)化效果如圖10所示，圖中展示了uFlow與傳統(tǒng)OpenFlow網(wǎng)絡(luò)中處理方式(LRU)消耗的控制流交互開銷總量對比.圖10(a)(b)(c)分別表示在重度負(fù)載流量、中度負(fù)載流量和輕度負(fù)載流量這3種情況下，uFlow系統(tǒng)與傳統(tǒng)OpenFlow網(wǎng)絡(luò)消耗的Flow-Mod消息數(shù)量對比.結(jié)果表明處理30 min網(wǎng)絡(luò)流量，uFlow系統(tǒng)消耗的Flow-Mod數(shù)量遠(yuǎn)小于傳統(tǒng)OpenFlow網(wǎng)絡(luò)中的處理方式.對于重度負(fù)載流量，uFlow在平均情況下能夠節(jié)省60%左右的Flow-Mod消息數(shù)量；對于中度和輕度負(fù)載的數(shù)據(jù)流量，uFlow平均情況下分別能夠節(jié)省80%和90%左右的Flow-Mod消息數(shù)量.

進(jìn)一步分析可以發(fā)現(xiàn)，在不同的交換機(jī)容量從1 000～50 000條不斷增加的情況下，uFlow對控制流交互開銷的優(yōu)化程度(即uFlow系統(tǒng)對Flow-Mod消息的降低比例)呈現(xiàn)出先增后降的趨勢，如圖11所示.當(dāng)交換機(jī)流表容量小于20 000～30 000條時，交互開銷優(yōu)化比例隨流表增加而增大.這是由于在這段區(qū)間內(nèi)，uFlow優(yōu)化主要體現(xiàn)在流表命中率的提高，這極大地減少了Table-Miss事件的數(shù)量，抑制了大量的重復(fù)性控制指令.而后續(xù)當(dāng)流表容量繼續(xù)增大后，流表的數(shù)量越來越接近網(wǎng)路中總流數(shù)目，Table-Miss事件本身會隨著流表容量的增加而大大減小.此時uFlow對小流識別并直接轉(zhuǎn)發(fā)會需要消耗一定的交互開銷，因此優(yōu)化比例會隨著流表容量的繼續(xù)增大而降低.當(dāng)然，這種下降趨勢可以通過動態(tài)調(diào)整流量識別算法來做進(jìn)一步的改進(jìn).

Fig. 10 Control flow overhead of uFlow and OpenFlow圖10 控制流交互開銷對比圖

2) 數(shù)據(jù)流交互開銷

Fig. 11 Flow-Mod message optimization ratio withflow table capacity圖11 不同流表容量下對Flow-Mod的消息優(yōu)化比例

我們對傳統(tǒng)OpenFlow網(wǎng)絡(luò)和uFlow系統(tǒng)中的Packet-In消息攜帶的數(shù)據(jù)包總流量進(jìn)行了統(tǒng)計(jì)，結(jié)果如圖12所示.圖12展示了在不同的交換機(jī)流表容量下，uFlow系統(tǒng)與傳統(tǒng)的OpenFlow網(wǎng)絡(luò)中數(shù)據(jù)流的開銷(即控制器需要處理的數(shù)據(jù)包總量).從圖12中可以發(fā)現(xiàn)，當(dāng)流表容量較小時(小于5 000條左右)，uFlow系統(tǒng)產(chǎn)生的數(shù)據(jù)流開銷比傳統(tǒng)OpenFlow網(wǎng)絡(luò)更小，這是因?yàn)閡Flow消除了大流表項(xiàng)的冗余更新；當(dāng)流表容量繼續(xù)增大時，uFlow系統(tǒng)的數(shù)據(jù)流開銷相對于傳統(tǒng)OpenFlow網(wǎng)絡(luò)略有增加，這是由控制器對小流的直接轉(zhuǎn)發(fā)會消耗額外的數(shù)據(jù)流開銷所導(dǎo)致.但可以發(fā)現(xiàn)此時數(shù)據(jù)流開銷的總量仍然非常小，這并不會給數(shù)據(jù)平面和控制平面的交互帶來壓力.

Fig. 12 Data flow overhead of uFlow and OpenFlow圖12 數(shù)據(jù)流交互開銷對比圖

Fig. 13 The total southbound overhead of uFlow and OpenFlow圖13 南向接口交互開銷總和對比

對此，我們對控制平面的交互開銷與數(shù)據(jù)平面的交互開銷相加的總開銷進(jìn)行了分析，結(jié)果如圖13所示.從實(shí)驗(yàn)結(jié)果過中可以看到，uFlow系統(tǒng)對OpenFlow數(shù)據(jù)平面與控制平面的交互開銷總和仍然有明顯的優(yōu)化效果：當(dāng)交換機(jī)流表容量小于30 000條時，uFlow對重度、中度、輕度負(fù)載流量的交互開銷分別能到達(dá)34%，40%，47%的優(yōu)化效果.只有當(dāng)流表容量超過50 000條時，uFlow的交互開銷會略高于傳統(tǒng)OpenFlow網(wǎng)絡(luò)，但由于我們在實(shí)驗(yàn)中使用了目的IP的16b前綴來區(qū)分每條流，網(wǎng)絡(luò)中所有的流總數(shù)量為216，即65 500條，因而50 000條的流表容量已經(jīng)接近網(wǎng)絡(luò)中所有流的總數(shù)量，這在真實(shí)的網(wǎng)絡(luò)設(shè)備中是不可能有如此多的資源的.

關(guān)于控制器的負(fù)載情況，從直觀上來看，控制器對小流數(shù)據(jù)包的直接轉(zhuǎn)發(fā)確實(shí)增加了控制器的負(fù)載，但由于直接轉(zhuǎn)發(fā)在其他方面帶來的優(yōu)勢，使得控制器總負(fù)載不一定會增加.控制器的負(fù)載與數(shù)據(jù)平面的流量特征有很大的關(guān)系，不同的流量情況下控制器負(fù)載會有所不同.具體來說，在流量具備分布不均衡特征的情況下，控制器的總負(fù)載甚至很可能由于以下2個原因而有所降低：1)大小流區(qū)分與控制器轉(zhuǎn)發(fā)的方式極大地減少了流表頻繁更替導(dǎo)致的控制開銷.控制器需要處理的消息數(shù)量，尤其是Packet-In消息和Flow-Mod消息數(shù)量大大減小.2)控制器處理每條Packet-In消息的開銷大大減小.控制器在與數(shù)據(jù)平面的交互過程中，處理Packet-In消息需要控制器計(jì)算路由并生成相應(yīng)的流表項(xiàng)，然后將流表項(xiàng)安裝到對應(yīng)的交換機(jī)上，并通過Packet-Out消息將數(shù)據(jù)包再次發(fā)送到數(shù)據(jù)平面.在本文提出的方法中，控制器在計(jì)算路由、下發(fā)流表項(xiàng)這2個最消耗控制器資源和帶來時延的過程均有所簡化.實(shí)驗(yàn)的結(jié)果也說明，即使在比較壞的情況下，uFlow系統(tǒng)中控制器處理的消息總數(shù)量也不會增加，因此綜合來看，控制器的總負(fù)載是可控的.

3.3 其他問題

1) 流表開銷優(yōu)化效果

從3.2節(jié)中對交互開銷的實(shí)驗(yàn)結(jié)果中可以看出，對于相同的流量和相同容量的流表來說，uFlow系統(tǒng)中流量觸發(fā)的Table-Miss次數(shù)以及控制器下發(fā)Flow-Mod消息數(shù)量均有明顯的減少.這說明在同等條件下：①數(shù)據(jù)平面與控制平面交互帶寬一定；②控制器的處理總流量一定,交換機(jī)處理同樣的流量使用更少的流表資源就可以完成.

我們以圖10中Trace1為例來說明uFlow系統(tǒng)對交換機(jī)流表資源的優(yōu)化效果.如果要求在消耗的Flow-Mod消息不超過2×106的情況下完成對Trace1的處理，傳統(tǒng)OpenFlow網(wǎng)絡(luò)模型至少需要使用流表容量為20 000條的交換機(jī)，而使用uFlow技術(shù)進(jìn)行開銷優(yōu)化之后，只需要流表容量為5 000條的交換機(jī)就可以滿足設(shè)計(jì)要求.從圖11也可以看出，存在一個最優(yōu)的交換機(jī)流表容量使得南向接口開銷最小，這也是值得進(jìn)一步深入研究的工作之一.

2) 小流時延優(yōu)化效果

對于時延優(yōu)化效果，我們在Mininet[17]中建立圖1所示的網(wǎng)絡(luò)拓?fù)?，分別測試數(shù)據(jù)包通過控制器轉(zhuǎn)發(fā)與通過交換機(jī)轉(zhuǎn)發(fā)的時延大小，測量得到小流的平均時延效果如表2所示：

Table 2 Optimization of Mice Flow Delay表2 小流時延優(yōu)化實(shí)驗(yàn)結(jié)果

仿真結(jié)果顯示，uFlow系統(tǒng)中小流的端到端時延明顯小于傳統(tǒng)OpenFlow網(wǎng)絡(luò)中對數(shù)據(jù)包轉(zhuǎn)發(fā)處理的時延.主機(jī)A，B之間的小流時延達(dá)到了超過50%的降低幅度，這與小流在網(wǎng)絡(luò)中經(jīng)過的轉(zhuǎn)發(fā)節(jié)點(diǎn)數(shù)減小程度基本一致.

我們還測量了通過控制器直接轉(zhuǎn)發(fā)情況下的小流轉(zhuǎn)發(fā)時延.實(shí)驗(yàn)中使用的控制器配置為Intel?CoreTMi7-2600 @ 3.40 GHz處理器，16 GB DDR3內(nèi)存.用于構(gòu)建SDN網(wǎng)絡(luò)的交換機(jī)為ONetSwitch[16].為了保持時鐘同步，我們在另一臺多網(wǎng)口的服務(wù)器上運(yùn)行2臺虛擬機(jī)，作為接入網(wǎng)絡(luò)的2臺主機(jī).多次測量結(jié)果顯示通過控制器直接轉(zhuǎn)發(fā)數(shù)據(jù)包的時延平均值為1.6 ms.

3) 部署方式與兼容性

uFlow系統(tǒng)可以直接部署于控制核心服務(wù)中，不會對數(shù)據(jù)平面做任何修改，運(yùn)行時對其他控制平面的應(yīng)用保持透明，因此不會影響其他控制器應(yīng)用的正常功能.這說明uFlow系統(tǒng)與其他控制器應(yīng)用能夠保持良好的兼容性，例如控制器對于小流數(shù)據(jù)包的直接轉(zhuǎn)發(fā)需要遵循訪問控制規(guī)則，通過查詢訪問控制表來實(shí)現(xiàn)；而對于負(fù)載均衡應(yīng)用，uFlow系統(tǒng)也可以在正常處理數(shù)據(jù)包后再做負(fù)載均衡處理，避免了數(shù)據(jù)包的處理沖突.

4 總結(jié)與結(jié)論

本文提出一種優(yōu)化的SDN流量處理模型uFlow，在控制器上實(shí)現(xiàn)對數(shù)據(jù)流特征信息的記錄、識別和轉(zhuǎn)發(fā).彌補(bǔ)了控制器在下發(fā)新的流表項(xiàng)時，缺乏新表項(xiàng)對應(yīng)的數(shù)據(jù)流特征信息的不足.控制器對識別后的大小流分開處理，將種類繁多但是總流量較少的小流數(shù)據(jù)包直接送達(dá)目的地，減少了小流的傳輸時延，消除潛在的流表更新振蕩和冗余的Packet-In消息，并且節(jié)省了交換機(jī)的流表空間.同時本文也通過真實(shí)流量對uFlow系統(tǒng)的效果進(jìn)行了驗(yàn)證，uFlow系統(tǒng)與傳統(tǒng)OpenFlow網(wǎng)絡(luò)相比，能顯著的減少數(shù)據(jù)包的時延，降低控制平面和數(shù)據(jù)平面的交互開銷，節(jié)省交換機(jī)的流表項(xiàng).

[1]McKeown N, Anderson T, Balakrishnan H, et al. OpenFlow: Enabling innovation in campus networks[J]. ACM SIGCOMM Computer Communication Review, 2008, 38(2): 69-74

[2]Curtis A R, Mogul J C, Tourrilhes J, et al. DevoFlow: Scaling flow management for high-performance networks[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 254-265

[3]Kotani D, Okabe Y. A packet-in message filtering mechanism for protection of control plane in OpenFlow networks[C] //Proc of the 10th ACM/IEEE Symp on Architectures for Networking and Communications Systems. New York: ACM, 2014: 29-40

[4]Wang Binfeng, Su Jinshu, Chen Lin. Review of the design of data center network for cloud computing[J]. Journal of Computer Research and Development, 2016, 53(9): 2085-2106 (in Chinese)(王斌鋒, 蘇金樹, 陳琳. 云計(jì)算數(shù)據(jù)中心網(wǎng)絡(luò)設(shè)計(jì)綜述[J]. 計(jì)算機(jī)研究與發(fā)展, 2016, 53(9): 2085-2106)

[5]Sarrar N, Uhlig S, Feldmann A, et al, Leveraging Zipf’s law for traffic offloading[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(1): 16-22

[6]Sarrar N, Feldmann A, Uhlig S, et al. Towards hardware accelerated software routers[C] //Proc of the 8th ACM CoNEXT Student Workshop. New York: ACM, 2010: No.2

[7]Advait D, Fang Hao, Sarit M, et al. Elasticon: An elastic distributed SDN controller[C] //Proc of the 10th ACM/IEEE Symp on Architectures for Networking and Communications Systems. New York: ACM, 2014: 17-28

[8]Open Networking Foundation. OpenFlow Switch Specification Version.1.3.2[S/OL]. 2012[2017-06-12]. https://www.opennetworking.org/software-defined-standards/specifications

[9]Marcial P F. Comparing openflow controller paradigms scalability: Reactive and proactive[C] //Proc of the 27th IEEE Advanced Information Networking and Applications. Piscataway, NJ: IEEE, 2013: 1009-1016

[10]Wallner R, Robert C. An SDN approach: Quality of service using big switch’s floodlight open-source controller[C] //Proc of the 35th Asia-Pacific Advanced Network. Hong Kong: APAN, 2013: 14-19

[11]Jan M, Robert V, Anton T, et al. Opendaylight: Towards a model-driven SDN controller architecture[C] //Proc of the 15th Int Symp on World of Wireless, Mobile and Multimedia Networks. Piscataway, NJ: IEEE, 2014: 1-6

[12]Theophilus B, Aditya A, David A M. Network traffic characteristics of data centers in the wild[C] //Proc of the 10th ACM SIGCOMM Conf on Internet Measurement. New York: ACM, 2010: 267-280

[13]Kim T, Lee T, Kim K H, et al. An efficient packet processing protocol based on exchanging messages between switches and controller in OpenFlow networks[C] //Proc of the 10th IEEE Int Conf and Expo on Emerging Technologies for a Smarter World. Piscataway, NJ: IEEE, 2013: 1-5

[14]Katta N, Omid A, Jennifer R, et al. CacheFlow: Dependency-aware rule-caching for software-defined networks[C] //Proc of the 2nd Symp on SDN Research. New York: ACM, 2016: 1-12

[15]Alcock S, Lorier P, Nelson R. Libtrace: A packet capture and analysis library[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(2): 42-48

[16]Hu Chengchen, Yang Ji, Gong Zhimin, et al. DesktopDC: Setting all programmable data center networking testbed on desk[J]. ACM SIGCOMM Computer Communication Review, 2014, 44(2): 593-594

[17]Oliveira R L S, Shinoda A A, Schweitzer C M, et al. Using mininet for emulation and prototyping software-defined networks[C] //Proc of the 7th Colombian Conf on Communications and Computing. Piscataway, NJ: IEEE, 2014: 1-6