軟件定義網(wǎng)絡(luò)中拓撲發(fā)現(xiàn)機制的性能改進研究

梁　陶宏才

摘 要：在軟件定義網(wǎng)絡(luò)體系架構(gòu)中，控制器作為核心部件需要隨時獲取網(wǎng)絡(luò)的狀態(tài)信息，尤其是網(wǎng)絡(luò)的拓撲結(jié)構(gòu)。因此，如何快速高效地發(fā)現(xiàn)網(wǎng)絡(luò)的拓撲信息在軟件定義網(wǎng)絡(luò)中尤為重要。對目前主流的控制器平臺實現(xiàn)拓撲發(fā)現(xiàn)的成本和開銷進行評估，提出一種基于鏈路層發(fā)現(xiàn)協(xié)議的改進拓撲發(fā)現(xiàn)機制，通過減少控制器發(fā)送的Packet-Out消息數(shù)來降低控制負載。實驗結(jié)果表明，與目前的拓撲發(fā)現(xiàn)機制相比，改進后的拓撲發(fā)現(xiàn)機制大大提高了控制器性能。

關(guān)鍵詞：軟件定義網(wǎng)絡(luò)；控制器；拓撲發(fā)現(xiàn)；鏈路層發(fā)現(xiàn)協(xié)議；Packet-Out消息

中圖分類號：TP393 文獻標志碼：A 文章編號：2095-2945（2018）15-0045-03

Abstract： In the software defined network architecture， the controller as the core component needs to obtain the network state information at any time， especially the network topology. Therefore， how to quickly and efficiently discover the network topology information is particularly important in the software definition of the network. This paper evaluates the cost and overhead of realizing topology discovery on the main controller platform， and proposes an improved topology discovery mechanism based on link layer discovery protocol， which reduces the control load by reducing the number of Packet-Out messages sent by the controller. Experimental results show that the improved topology discovery mechanism greatly improves the controller performance compared with the current topology discovery mechanism.

Keywords： software defined network； controller； topology discovery； link layer discovery protocol； Packet-Out message

引言

軟件定義網(wǎng)絡(luò)（Software Defined Networking，SDN）是一種以控制轉(zhuǎn)發(fā)分離為中心思想的新型網(wǎng)絡(luò)架構(gòu)，其核心部件SDN控制器需要實時地獲取網(wǎng)絡(luò)的狀態(tài)，尤其是網(wǎng)絡(luò)的拓撲結(jié)構(gòu)。拓撲發(fā)現(xiàn)功能作為控制器提供的一項關(guān)鍵服務，是SDN進行集中配置和管理網(wǎng)絡(luò)的前提。因此，一個高效可靠的拓撲發(fā)現(xiàn)機制對于SDN網(wǎng)絡(luò)至關(guān)重要，研究如何提高拓撲發(fā)現(xiàn)機制的性能具有十分重要的意義。

1 拓撲發(fā)現(xiàn)機制概述

1.1 機制描述

目前，在SDN網(wǎng)絡(luò)中實現(xiàn)拓撲發(fā)現(xiàn)的方法并沒有官方的標準。NOX[1]是最早期的一款SDN控制器，大多數(shù)控制器平臺實現(xiàn)拓撲發(fā)現(xiàn)的方法均是按照NOX的實現(xiàn)方式衍生而來的，如POX、Floodlight、Ryu等。

當前的拓撲發(fā)現(xiàn)機制主要利用鏈路層發(fā)現(xiàn)協(xié)議（Link Layer Discovery Protocol，LLDP）[2]實現(xiàn)。SDN控制器使用Packet-Out消息周期性地向與之相連的所有OpenFlow[3]交換機的每個端口發(fā)送LLDP幀。當某個交換機接收到這些LLDP幀后，再使用Packet-In消息將兩臺交換機之間的鏈路信息發(fā)送給控制器。當控制器搜集了所在區(qū)域的所有鏈路信息后可建立網(wǎng)絡(luò)的全局拓撲結(jié)構(gòu)。

1.2 場景示例

現(xiàn)假設(shè)有兩個OpenFlow交換機連接在控制器上，如圖3所示。

控制器首先為交換機S1的3個端口創(chuàng)建單獨的LLDP幀，其中Chassis ID為交換機S1的DPID，Port ID為各自的端口號。然后，通過Packet-Out消息指示交換機S1將該LLDP幀通過Port 1端口發(fā)送出去。當該幀到達交換機S2的Port 3端口后，會觸發(fā)交換機S2發(fā)送Packet-In消息給控制器，該Packet-In消息中包含了由交換機S1的Port 1端口發(fā)送的LLDP幀。控制器從收到的Packet-In消息中可以解析得到該Packet-In消息是由交換機S2的Port 3端口觸發(fā)的，同時可以解析出該幀是從交換機S1的Port 1端口發(fā)送的，此時控制器就可確定交換機S1的Port 1端口和交換機S2的Port 3端口是直連的。若推廣到整個網(wǎng)絡(luò)，控制器可以指示從所有交換機的所有端口發(fā)送LLDP幀，從而獲取全網(wǎng)的拓撲信息。

1.3 性能評估

控制器負載取決于控制器需要發(fā)送的Packet-Out消息的數(shù)量，以及它接收到的和需要處理的Packet-In消息的數(shù)量。由傳統(tǒng)拓撲發(fā)現(xiàn)機制可知，控制器所要發(fā)送的帶LLDP的Packet-Out消息的總數(shù)是所有與控制器相連的交換機總端口數(shù)。設(shè)L為交換機之間的鏈路數(shù)量，S為交換機的數(shù)量，Pi為交換機i的端口數(shù)量。Npacket-out表示控制器需發(fā)送的Packet-Out消息的總數(shù)，則：

2 拓撲發(fā)現(xiàn)機制改進

2.1 改進思路

控制器負載和性能對于軟件定義網(wǎng)絡(luò)的可伸縮性至關(guān)重要，而拓撲發(fā)現(xiàn)通常是所有控制器在后臺持續(xù)運行的服務，因此它對控制器負載的影響也尤為顯著。為了便于控制器在接收交換機的帶LLDP的Packet-In消息時可以確定源端口，每個LLDP幀都需要將Port ID TLV初始到相應的交換機出口端口。當前實現(xiàn)此功能的方法是控制器通過單獨的Packet-Out消息為每個交換機的每個端口發(fā)送專用的LLDP幀，控制器需要發(fā)送的帶LLDP的Packet-Out消息數(shù)是網(wǎng)絡(luò)中端口的總數(shù)。一個更好的選擇是只向每個交換機發(fā)送一個帶LLDP的Packet-Out消息，并要求它在所有端口上發(fā)送相應的LLDP幀。由于OpenFlow不支持重寫LLDPDU部分，因此在將LLDP幀轉(zhuǎn)發(fā)到所有端口前無法重寫Port ID TLV。根據(jù)OpenFlow交換機和控制器之間建立連接時交換機會通知控制器其端口ID和關(guān)聯(lián)的MAC地址，以及OpenFlow交換機重寫數(shù)據(jù)包頭的能力，由此改進機制可利用MAC地址作為標識符來幫助控制器確認來自交換機的帶LLDP的Packet-In消息的源端口。

2.2 具體改進與實現(xiàn)流程

改進的拓撲發(fā)現(xiàn)機制對原有機制的細節(jié)作了如下更改：

（1）控制器與交換機建立連接后，當交換機響應Features Request消息時，通過Features Reply消息通知控制器有關(guān)其操作端口、ID和MAC地址的信息。控制器再根據(jù)每個交換機的MAC地址和端口ID建立映射關(guān)系并存入數(shù)據(jù)庫中。

（2）修改控制器發(fā)送Packet-In消息的動作，將發(fā)送到每個交換機的帶LLDP的Packet-In消息數(shù)限制為一個，并將LLDPDU中的Port ID TLV字段置為0。

（3）為每個交換機建立新規(guī)則，指定從控制器接收的每個LLDP幀將在所有可用端口上轉(zhuǎn)發(fā)，并將LLDP幀的源MAC地址字段置為對應端口的MAC地址。

（4）修改控制器接收Packet-In消息的處理程序，通過對比所收到的LLDP幀的源MAC地址字段與步驟（1）收集的控制器數(shù)據(jù)庫中相應的映射關(guān)系找到對應的端口號，以此確認鏈路連接關(guān)系。

改進后的拓撲發(fā)現(xiàn)機制示例如圖4所示。與圖3對比，有如下兩個明顯的區(qū)別：一是控制器給交換機S1發(fā)送的Packet-Out消息數(shù)，由原先的三個端口各一條修改為一個交換機僅一條；二是交換機各端口轉(zhuǎn)發(fā)的LLDP幀結(jié)構(gòu)，Port ID字段由原先對應的端口ID修改為0，而源MAC地址由原先統(tǒng)一的交換機MAC地址修改為各端口對應的MAC地址。

2.3 性能的理論分析

改進后控制器所要發(fā)送的帶LLDP的Packet-Out消息的總數(shù)是所有與控制器相連的交換機數(shù)。設(shè)Mpacket-out表示改進后控制器需發(fā)送的Packet-Out消息的總數(shù)，則：

3 實驗與結(jié)果分析

3.1 實驗環(huán)境

實現(xiàn)實驗的軟件如表1所示，我們使用基于Linux的Mininet[4]網(wǎng)絡(luò)仿真平臺模擬網(wǎng)絡(luò)，將POX作為SDN控制器平臺，Open vSwitch作為虛擬交換機，并通過Python實現(xiàn)拓撲發(fā)現(xiàn)機制的更改。

如表2所示，實驗分別考慮了3種不同的網(wǎng)絡(luò)拓撲結(jié)構(gòu)，其中拓撲1是一個具有交換機數(shù)量為100的線性拓撲，拓撲2是一個具有深度為7、分支系數(shù)為2的樹狀拓撲，拓撲3是一個具有深度為4、分支系數(shù)為4的樹狀拓撲。

3.2 結(jié)果分析

實驗中，我們對POX控制器進行檢測，以收集所發(fā)出的Packet-Out消息的信息，該信息由拓撲發(fā)現(xiàn)組件在實驗拓撲中所發(fā)出。通過公式（3）可以確認通過改進機制獲得的效率增益，如表3所示。

圖5以直方圖形式顯示了表3的實驗結(jié)果，由圖中可以清楚表明改進的機制大大減少了Packet-Out消息的數(shù)量，其中拓撲1和拓撲2對Packet-Out消息數(shù)減少了將近67%，拓撲3減少了將近80%。

Packet-Out消息的減少可以直接影響控制器負載。實驗中，我們不斷運行拓撲發(fā)現(xiàn)服務，以POX控制器默認的時間間隔5秒重復啟動新的發(fā)現(xiàn)回合。

網(wǎng)絡(luò)初始化完成后，我們利用python中用于采集系統(tǒng)基本性能信息的psutil模塊，通過其中的cpu_percent（）方法來獲取CPU時間。每項實驗的持續(xù)時間為300秒，共重復10次取平均值。

圖6顯示了整個實驗過程中POX控制器僅運行拓撲發(fā)現(xiàn)服務的累積CPU時間。由圖觀察可知，改進機制相對于傳統(tǒng)機制在節(jié)省CPU時間上有顯著效果，其中最低為拓撲1的20%，最高可達到拓撲3的40%。這表明Packet-Out消息的處理和發(fā)送是控制器CPU負載的重要組成部分，在拓撲發(fā)現(xiàn)服務中這些消息的減少可直接降低控制器的負載。

4 結(jié)束語

本文討論了軟件定義網(wǎng)絡(luò)中的拓撲發(fā)現(xiàn)問題，從控制器負載的角度分析了傳統(tǒng)拓撲發(fā)現(xiàn)機制的開銷，由此提出了一個改進的機制。該改進機制通過為每個交換機發(fā)送一個LLDP幀代替為每個交換機上的每個端口發(fā)送LLDP分組，以此減少Packet-Out消息的數(shù)量。通過實驗證明，相較于傳統(tǒng)機制，在我們給出的拓撲示例中改進機制對CPU負載的降低最高能達到40%，并可能更多地用于其他具有較高端口密度的拓撲。

控制器是軟件定義網(wǎng)絡(luò)的性能瓶頸，通過降低控制器負載使得拓撲發(fā)現(xiàn)這樣的核心服務更有效，會對整個網(wǎng)絡(luò)的性能和可伸縮性產(chǎn)生重大影響。

參考文獻：

[1]Pfaff B， Pfaff B， Pfaff B， et al. NOX： towards an operating system for networks[J]. Acm Sigcomm Computer Communication Review， 2008，38（3）：105-110.

[2]Attar V Z P， Chandwadkar P. Network Discovery Protocol LLDP and LLDP-MED[J]. International Journal of Computer Applications， 2011，1（9）：93-97.

[3]Lara A， Kolasani A， Ramamurthy B. Network Innovation using OpenFlow： A Survey[J]. IEEE Communications Surveys & Tutorials， 2013，16（1）：493-512.

[4]Kaur K， Singh J， Ghumman N S. Mininet as Software Defined Networking Testing Platform[C].// International Conference on Communication， Computing & Systems，2014.