基于OpenFlow 的SDN 中鏈路層拓撲發(fā)現(xiàn)的優(yōu)化*

董 帥，張安琳，黃道穎*，王宣立，劉江豪

（1.鄭州輕工業(yè)大學(xué)計算機與通信工程學(xué)院，鄭州 450000；2.鄭州輕工業(yè)大學(xué)工程訓(xùn)練中心，鄭州 450000）

0 引言

目前，SDN（Software Defined Network，SDN）成為了未來網(wǎng)絡(luò)架構(gòu)領(lǐng)域的研究熱點。SDN 作為一種集中控制的網(wǎng)絡(luò)架構(gòu)，相對于傳統(tǒng)的網(wǎng)絡(luò)來說，它將控制與轉(zhuǎn)發(fā)分離，將所有的控制功能交給控制器；并且SDN 可以讓人們在控制器上根據(jù)不同功能的應(yīng)用程序進行軟件編程，因此，特別適用于軍用計算機網(wǎng)絡(luò)未來架構(gòu)。通過在軍用網(wǎng)絡(luò)中實現(xiàn)SDN控制器的功能，達到對網(wǎng)絡(luò)全方位的掌控，能更好的適應(yīng)戰(zhàn)場變化，滿足現(xiàn)代戰(zhàn)爭中對信息的高效傳輸要求。面對未來戰(zhàn)爭任務(wù)需求的多樣性，基于SDN 的軍用彈性可重構(gòu)網(wǎng)絡(luò)發(fā)展將成為重要趨勢［1］。

但是對于控制器來說，這些會導(dǎo)致控制器負載了太多的功能，由以前很多底層網(wǎng)絡(luò)設(shè)備各自分擔(dān)的控制功能，全部移交給了控制器，并且還要面對多樣化的應(yīng)用服務(wù)。因此，控制器的負載成為了SDN 網(wǎng)絡(luò)的新問題，并且控制器的負載狀況也會制約著網(wǎng)絡(luò)規(guī)模?？刂破餍枰獙θ志W(wǎng)絡(luò)的狀態(tài)保持全面并且實時的掌握，拓撲發(fā)現(xiàn)作為控制器一直在運行的基礎(chǔ)服務(wù)，優(yōu)化拓撲發(fā)現(xiàn)對減少控制器的負載有著重要作用。Azzouni A［2］等人提出了sOFTDP關(guān)于拓撲發(fā)現(xiàn)的安全和優(yōu)化問題，并把一部分的控制權(quán)限移交給交換機來減少控制器的負載，導(dǎo)致了控制和轉(zhuǎn)發(fā)再次耦合；關(guān)于拓撲發(fā)現(xiàn)的優(yōu)化問題，來自The University of Melbourne 的FarzanehPakzad教授也進行了相關(guān)研究［3］，他提出了OFDPv2 用于拓撲發(fā)現(xiàn)，利用OpenFlow 交換機可以重寫包頭的特性，針對交換機發(fā)送Packet-Out 消息，一定程度上減少了控制器的負載，但并沒有考慮到Packet-in 消息的變化。

針對上述問題，本文在傳統(tǒng)OpenFlow 拓撲發(fā)現(xiàn)協(xié)議（OpenFlow Discovery Protocol，OFDP）的基礎(chǔ)上提出一種OpenFlow 拓撲發(fā)現(xiàn)端口檢測機制（Open-Flow Discovery Protocol-Port Detection，OFDP-PD）。利用SDN 可以軟件編程和擁有全局拓撲的優(yōu)勢，對端口狀態(tài)進行檢測，找出已經(jīng)進行過拓撲發(fā)現(xiàn)的端口，減少不必要的開銷，加快拓撲生成速度，來達到減少控制器負載的目的，一定程度上緩解控制器對網(wǎng)絡(luò)規(guī)模的制約。最后期望提出的OFDP-PD 能減少消息數(shù)量，加快拓撲生成速度，減少控制器負載。

1 傳統(tǒng)的SDN 拓撲發(fā)現(xiàn)機制

目前，SDN 的拓撲發(fā)現(xiàn)使用了NOX 控制器的發(fā)現(xiàn)協(xié)議OFDP，OFDP 是在傳統(tǒng)網(wǎng)絡(luò)中的鏈路層發(fā)現(xiàn)協(xié)議（Link Layer Discovery Protocol，LLDP）的基礎(chǔ)上實現(xiàn)的。LLDP 的本質(zhì)是信息發(fā)現(xiàn)與通告協(xié)議，規(guī)定了不同廠商的設(shè)備不僅可以向鄰近的網(wǎng)絡(luò)設(shè)備發(fā)送自己的配置消息，而且可以對鄰近網(wǎng)絡(luò)設(shè)備的消息進行存儲。

OpenFlow 是SDN 提供的南向接口的標準協(xié)議，是控制層與基礎(chǔ)設(shè)施層的接口，負責(zé)SDN 控制器和SDN 交換機之間的通信，使控制器可以直接配置管理交換機。

在初次進行設(shè)備連接的時候如圖1 所示，Open Flow 交換機會配置控制器的IP 地址和TCP 端口號，啟動時，交換機將與對應(yīng)的控制器進行通信，并建立傳輸安全通道（Transport Layer Security，TLS）來進行保護連接?？刂破魍ㄟ^安全通道向交換機發(fā)送Set-Config 和Get-Config-Request 消息來發(fā)送自己的設(shè)備版本等信息和請求獲取交換機的配置消息。交換機向控制器發(fā)送Get-Config-Reply 消息來回復(fù)控制器，回復(fù)自己的MAC 地址和各個端口的信息等。這時候控制器和交換機就有了初步的交互，但是控制器僅僅知道交換機的地址和端口配置信息，卻不知道交換機在網(wǎng)絡(luò)中的位置，以及該交換機連接的鏈路狀態(tài)信息。

圖1 控制器與交換機通信流程圖

控制器為了獲取全局的網(wǎng)絡(luò)拓撲視圖，控制器會按照指定時間（默認5 s）周期性的分別向網(wǎng)絡(luò)中所有交換機的所有端口下發(fā)送包含拓撲發(fā)現(xiàn)協(xié)議數(shù)據(jù)單元的Packet-Out 消息。

OpenFlow 可以使控制器設(shè)置交換機之間的轉(zhuǎn)發(fā)規(guī)則從而控制流在網(wǎng)絡(luò)中的路徑，在當前的拓撲發(fā)現(xiàn)中，控制器都會提前給交換機下發(fā)預(yù)安裝規(guī)則［4］。當交換機接收到除控制器以外的端口發(fā)來的拓撲發(fā)現(xiàn)消息（以太網(wǎng)類型0X88cc）后，將接收端口等信息添加，并封裝成Packet-In 消息轉(zhuǎn)發(fā)至控制器［5］。

如圖2 所示，將拓撲發(fā)現(xiàn)細化來看，在進行拓撲發(fā)現(xiàn)時，控制器controller 為交換機Switch S1 的每個端口分別發(fā)出一個帶有拓撲發(fā)現(xiàn)協(xié)議數(shù)據(jù)單元的Packet-Out 命令發(fā)送至該端口所連接的網(wǎng)絡(luò)設(shè)備［6］。（S1，port1）端口向交換機S2 發(fā)送，當Switch S2 接收到（S1，port1） 端口所轉(zhuǎn)發(fā)過來的Packet-Out 命令后，查詢流表發(fā)現(xiàn)以太網(wǎng)類型為0X88cc，把自己接收的端口號和設(shè)備識別號等信息提取出來封裝到Packet-In 消息和接收消息的端口等信息的元數(shù)據(jù)發(fā)送給controller。由此控制器檢測到一條鏈路（S1，port1）→（S2，port3）。這樣產(chǎn)生1 條Packet-Out 和1 條Packet-In 消息。

圖2 OpenFlow 拓撲發(fā)現(xiàn)圖

在進行s2 交換機的鏈路發(fā)現(xiàn)時，控制器向S2發(fā)送Packet-Out，S2 通過port3 將Packet-Out 發(fā)給S1。S1 將其中的拓撲發(fā)現(xiàn)協(xié)議數(shù)據(jù)單元提取出來，封裝成Packet-In 發(fā)送給控制器。控制器檢測到一條的鏈路（S2，port3）→（S1，port1）。此時產(chǎn)生了1 條Packet-Out 和1 條Packet-In 消息［7］。

控制器通過解析Packet-In 消息中的有效負載信息（即交換機標識號S1 和端口標識號port1），和命令中的元數(shù)據(jù)（即交換機接收信息的端口號和設(shè)備識別號）可以解析出兩臺交換機之間的鏈路信息。即有一條鏈路存在于（S1，port1）→（S2，port2）之間，然后又發(fā)現(xiàn)有一條鏈路存在于（S2，port2）→（S1，port1）之間。在傳統(tǒng)網(wǎng)絡(luò)中，是由交換機進行存儲鏈路信息的，通過維護本地的信息管理庫（Management Information Base，MIB），和遠程MIB 兩個庫，進行源MAC、源端口號到本地MAC、接收端口一次確認鏈路。

由此可以看出，在SDN 拓撲發(fā)現(xiàn)中同一條鏈路，每一次拓撲發(fā)現(xiàn)，都會被發(fā)現(xiàn)2 次，造成了資源成倍的浪費。為了保持拓撲信息的持續(xù)更新，控制器需要不斷地執(zhí)行拓撲發(fā)現(xiàn)。因此，拓撲發(fā)現(xiàn)對控制器帶來的負載非常重要并且是持續(xù)性的。拓撲發(fā)現(xiàn)對控制器造成的負載，由它發(fā)出的Packet-Out 消息的數(shù)量，以及需要處理Packet-In 消息的數(shù)量所決定。

需要處理的Packet-Out 消息數(shù)量和所有控制器所管轄交換機的總端口數(shù)有關(guān)［8］，如式（1）所示

其中，n 是交換機的總數(shù)量，Pi是交換機i 的端口數(shù)，MPacket-Out是控制器發(fā)出的Packet-Out 消息的數(shù)量。

要發(fā)送的Packet-In 消息數(shù)量與鏈路的數(shù)量有關(guān)，如式（2）所示。

其中，L 是所有鏈路的數(shù)量，MPacket-In是控制器接收到要處理的Packet-In 消息的數(shù)量。

2 改進的OpenFlow 鏈路層拓撲發(fā)現(xiàn)機制OFDP-PD

在OFDP 中，受限于傳統(tǒng)網(wǎng)絡(luò)分布式的架構(gòu)，每個網(wǎng)絡(luò)設(shè)備都需要自己進行存儲網(wǎng)絡(luò)的拓撲信息，網(wǎng)絡(luò)設(shè)備不僅要存儲本地MIB 還要存儲鄰居設(shè)備的MIB［9］。因此相鄰的網(wǎng)絡(luò)設(shè)備之間的鏈路，會被持續(xù)性的重復(fù)檢測，造成了資源持續(xù)浪費［10］。

然而在SDN 中可以對網(wǎng)絡(luò)拓撲進行全方位的管理，在拓撲發(fā)現(xiàn)之前對端口進行檢索，跳過已經(jīng)進行過拓撲發(fā)現(xiàn)的端口，對未拓撲發(fā)現(xiàn)的端口進行拓撲發(fā)現(xiàn)，并在拓撲發(fā)現(xiàn)過后進行重復(fù)拓撲檢測，將已經(jīng)發(fā)現(xiàn)過的拓撲端口進行標記，由此達到全局最優(yōu)。對這種機制的改進，將其叫做OFDP-PD。

2.1 改進思路

首先，利用SDN 可以編程的優(yōu)勢，對控制器中的拓撲發(fā)現(xiàn)模塊進行優(yōu)化［11］。在拓撲發(fā)現(xiàn)時，控制器中Switches 類初始化函數(shù)創(chuàng)建用于存儲設(shè)備的數(shù)據(jù)結(jié)構(gòu)，創(chuàng)建事件，創(chuàng)建兩個新線程執(zhí)行端口檢測和鏈路檢測兩個函數(shù)。

端口檢測函數(shù)首先遍歷端口找到需要拓撲發(fā)現(xiàn)的端口，遍歷進行拓撲發(fā)現(xiàn)。OFDP 先實例化端口，檢測端口把存在的端口都發(fā)送OFDP 報文，OFDP-PD 先檢測端口，不發(fā)送上一輪拓撲發(fā)現(xiàn)重復(fù)檢測的端口。通過這種簡單的自學(xué)習(xí)機制避免鏈路已經(jīng)進行過拓撲發(fā)現(xiàn)后被再次進行拓撲發(fā)現(xiàn)，不浪費地進行鏈路拓撲發(fā)現(xiàn)。

其次，利用控制器擁有全局網(wǎng)絡(luò)拓撲的優(yōu)勢［12］，可以直接檢測到每條鏈路的狀態(tài)，從而避免了傳統(tǒng)的分布式網(wǎng)絡(luò)中分別要在鏈路兩端重復(fù)存儲拓撲信息的不足，在控制器收到交換機發(fā)送的Packet-In消息時，直接解析鏈路兩端信息。當檢測到這條鏈路與庫中的鏈路相同時，在端口實例中添加標記，設(shè)置data.repeat=1，來保證下一次對這個端口進行拓撲發(fā)現(xiàn)時不會被重復(fù)發(fā)現(xiàn)。

2.2 改進的算法

如圖3 所示，OFDP-PD 會對端口進行檢測，對未拓撲發(fā)現(xiàn)的端口進行發(fā)現(xiàn)，從而避免以前的洪泛式拓撲發(fā)現(xiàn)，并在控制器拓撲發(fā)現(xiàn)期間，對重復(fù)端口進行標記［13］。主要步驟如下：

圖3 OFDP-PD 機制流程圖

步驟1 網(wǎng)絡(luò)初始化，交換機通過設(shè)置的IP 地址連接控制器，建立安全通道，相互告知使用版本和記錄對應(yīng)端口連接的mac 地址等信息。

步驟2 開始拓撲發(fā)現(xiàn)，對端口進行遍歷，當遍歷到的端口尚未發(fā)送過OFDP 報文，檢測data.repeat（是否已被拓撲發(fā)現(xiàn)）是否為None。如果是，則將端口加入將要進行拓撲發(fā)現(xiàn)的端口列表準備發(fā)送，若不是，則繼續(xù)執(zhí)行步驟2，接著對下一端口進行檢測。

步驟3 控制器對未進行拓撲發(fā)現(xiàn)的端口進行拓撲發(fā)現(xiàn)，將報文放到Packet-Out 消息中并發(fā)送，交換機按消息中的動作轉(zhuǎn)發(fā)給相鄰的交換機。

步驟4 相鄰交換機接收到Packet-Out 消息查詢流表，將接收報文的端口號和自己的dpid（設(shè)備識別號）等信息和報文的信息，放入Packet-In 消息并發(fā)送給控制器。

步驟5 控制器接收Packet-In 消息，查詢兩臺交換機之間的鏈路是否在拓撲中，如果是，則再檢查鏈路是否已重復(fù)發(fā)現(xiàn)，并將data.repeat 置為1。如果未發(fā)現(xiàn)鏈路，則建立新的鏈路放入拓撲中。

2.3 合理性分析

使用OFDP-PD 可以只對未進行拓撲發(fā)現(xiàn)的端口進行拓撲發(fā)現(xiàn)，減少不必要的浪費，并減少控制器處理這些進行過鏈路拓撲發(fā)現(xiàn)的反饋消息。由于OFDP-PD 可以只對未進行拓撲發(fā)現(xiàn)的端口進行拓撲發(fā)現(xiàn)，那么控制器要發(fā)送的拓撲發(fā)現(xiàn)的Packet-Out 消息數(shù)量應(yīng)該與網(wǎng)絡(luò)中所有交換機的端口數(shù)和鏈路數(shù)量有關(guān)。

現(xiàn)在控制器需要發(fā)送的Packet-Out 消息為

式中，交換機的數(shù)量是n，Pi是交換機i 的端口數(shù)，L是所有鏈路的數(shù)量。

相對于原來Packet-Out 消息的數(shù)量式（1）來說，OFDP-PD 的Packet-Out 消息數(shù)量減少了L 條。因為交換機的端口連接的還有主機，還會向主機發(fā)送消息，所以消息數(shù)量減少的是網(wǎng)絡(luò)中交換機之間鏈路的數(shù)量條消息。

不對重復(fù)發(fā)現(xiàn)的端口進行拓撲發(fā)現(xiàn)，不僅減少了Packet-Out 消息的數(shù)量，對應(yīng)的控制器接收的Packet-In 也減少了，由式（2），從以前鏈路數(shù)量的2倍到現(xiàn)在等于鏈路數(shù)量，效率提高了一倍。相對于OFDP 的泛洪式的發(fā)現(xiàn)（對所有端口進行拓撲發(fā)現(xiàn)），本機制采取了更細粒度的發(fā)現(xiàn)方式（只對未進行拓撲發(fā)現(xiàn)的端口發(fā)送消息），減少了Packet-Out消息和Packet-Out 消息的數(shù)量，減少了不必要的資源浪費，一定程度上緩解了控制器的負載。

3 仿真實驗與分析

3.1 實驗準備和參數(shù)設(shè)定

為了測試OFDP-PD 的有效性，在Ubuntu 系統(tǒng)中，使用mininet 軟件構(gòu)造了網(wǎng)絡(luò)仿真環(huán)境。在仿真環(huán)境中用Ryu 控制器和OpenVSwitch 交換機。

如表1 所示，實驗分別考慮了3 種拓撲場景：1）擁有100 臺交換機和1 臺控制器的線性拓撲；2）擁有85 臺交換機，深度和分支系數(shù)都為4 的樹形拓撲；3）擁有20 臺交換機，k 值為4 的胖樹拓撲。

表1 實驗拓撲數(shù)據(jù)

3.2 實驗結(jié)果分析

使用mininet 搭建網(wǎng)絡(luò)環(huán)境，拓撲發(fā)現(xiàn)采用的是Ryu 控制器的拓撲發(fā)現(xiàn)組件。在拓撲發(fā)現(xiàn)的周期中統(tǒng)計3 個拓撲的數(shù)據(jù)，拓撲發(fā)現(xiàn)中發(fā)送包含拓撲發(fā)現(xiàn)協(xié)議數(shù)據(jù)單元的Packet-out 消息數(shù)量，如表2所示。

表2 Packet-Out 消息

從表2 中可以清楚的看出，OFDP-PD 減少了包含拓撲發(fā)現(xiàn)協(xié)議數(shù)據(jù)單元的Packet-out 消息數(shù)量。對于3 個拓撲來說：線性拓撲減少了33%，樹形拓撲和胖樹拓撲的消息分別減少了20%和40%。由式（3）可知，OFDP-PD 相對于OFDP 的效率增益程度依賴于網(wǎng)絡(luò)中的端口和交換機的總數(shù)，和拓撲的類型沒有直接關(guān)系，也說明了OFDP-PD 可以應(yīng)用于所有的拓撲類型。

相較于OFDPv2，OFDP-PD 在減少Packet-in 消息方面也有了一些新的突破，由于交換機收到的Packet-out 消息得到了有效減少，所以交換機也減少了對控制器的鏈路信息的反饋，減少了Packet-in消息的數(shù)量，加快拓撲發(fā)現(xiàn)速度。

依然使用線性拓撲、樹形拓撲、胖樹拓撲，運行Ryu 控制器收集統(tǒng)計3 種拓撲中每輪拓撲發(fā)現(xiàn)的控制器接收的消息數(shù)量，每個實驗進行10 min。

表3 展示了Packet-in 消息實驗的結(jié)果，和傳統(tǒng)的OFDP 和最新的OFDPV2 進行比較，得到了OFDP-PD 比OFDP 和OFDPV2 都會處理更少的消息。

表3 Packet-in 消息及效益增益

可以明顯的看到OFDP-PD 減少了Packet-in消息的接收數(shù)量。在3 個拓撲中都減少了50 %。Packet-in 消息數(shù)量等于交換機之間鏈路的數(shù)量，相當于針對鏈路進行發(fā)現(xiàn)。

3.3 OFDP-PD 對控制器負載的改善

OFDP-PD 對消息數(shù)量進行改進的同時，也使控制器負載得到很好的改善。為了測量控制器改善狀況，本實驗還使用了來自psutil 的get-cpu-times（）的方法來衡量控制器中CPU 的負載狀況。

以樹形拓撲為實驗背景，預(yù)設(shè)實驗時間為300 s，以1 s 為收集間隔，調(diào)用get-cpu-times（）方法進行數(shù)據(jù)采樣，收集關(guān)于拓撲發(fā)現(xiàn)的累積CPU 時間。連續(xù)運行拓撲發(fā)現(xiàn)服務(wù)，每5 s 啟動一個新的發(fā)現(xiàn)輪?？刂破魃蠜]有運行其他服務(wù)或應(yīng)用程序，這意味著Ryu 控制器的CPU 負載的變化只由拓撲發(fā)現(xiàn)服務(wù)所引起。

如圖4 所示，橫坐標是預(yù)設(shè)的實驗時間，縱坐標是拓撲發(fā)現(xiàn)服務(wù)在實驗時間中所使用的累積CPU 時間（反映CPU 工作時完成該進程所花費的時間）。OFDP-PD 的累積CPU 時間穩(wěn)定的逐步增加，表示沒有其他主要的CPU 活動的突發(fā)，并且RYU中的拓撲發(fā)現(xiàn)數(shù)據(jù)包輸出間隔分布均勻。由圖4 可見，在同樣的時間內(nèi)，OFDP-PD 所使用的累積CPU時間最少，也說明了處理和發(fā)送消息的減少，使控制器的負載降低。

圖4 拓撲發(fā)現(xiàn)的CPU 累積時間

圖5 顯示了拓撲發(fā)現(xiàn)方案在整個實驗期間（300 s）使用的總CPU 時間。圖中顯示了多次實驗的平均值。

圖5 累積CPU 時間對比

如圖5 所示，OFDP-PD 相對于OFDP 和OFDPv2 來說，在減少累積CPU 時間上有顯著效果，其中最為明顯的是樹形拓撲，而線性拓撲的變化不明顯。通過對比拓撲發(fā)現(xiàn)的累計CPU 時間實驗和式（3），可以得出以下結(jié)論：對于端口密度比較高的網(wǎng)絡(luò)，累積CPU 時間減少可能更大。累積CPU 時間的減少直接導(dǎo)致了控制器負載的降低，從而提高控制器的性能。

4 結(jié)論

OFDP-PD 對重復(fù)拓撲發(fā)現(xiàn)的端口進行檢測，精確地對鏈路進行拓撲發(fā)現(xiàn)，減輕了控制器的負載狀況。并且這種基于全局的，有效的集中控制，也更加符合軟件定義網(wǎng)絡(luò)提高網(wǎng)絡(luò)效率、降低網(wǎng)絡(luò)控制和管理的復(fù)雜度的理念。