張一凡，李津，虞紅芳 ，孫罡

1．中國電子科技集團(tuán)公司第五十四研究所，河北 石家莊 050000

2．信息系統(tǒng)安全技術(shù)國家重點(diǎn)實驗室，北京 100101

3．電子科技大學(xué)，四川 成都 611731

引 言

軟件定義網(wǎng)絡(luò)（Software Defined Networking, SDN）是一種新型網(wǎng)絡(luò)架構(gòu)[1]，它的核心思想是將傳統(tǒng)路由器、交換機(jī)中的控制平面和轉(zhuǎn)發(fā)平面分離，由集中式的控制平面對網(wǎng)絡(luò)進(jìn)行管理和維護(hù)，通過控制平面提供可編程化的網(wǎng)絡(luò)接口為多樣化的網(wǎng)絡(luò)管理和服務(wù)提供了易用性和可擴(kuò)展性。

與傳統(tǒng)交換機(jī)相比，SDN 交換機(jī)除了進(jìn)行數(shù)據(jù)平面的報文轉(zhuǎn)發(fā)外還要通過南向協(xié)議接受來自控制器的配置和動態(tài)指令。目前，針對傳統(tǒng)交換機(jī)數(shù)據(jù)平面的測試已經(jīng)有了相關(guān)的規(guī)范[2][3]，測試方法和測試工具都已經(jīng)比較成熟，而針對南向協(xié)議的測試目前還處于起步階段。所以本文的重點(diǎn)在于突破SDN交換機(jī)南向協(xié)議的性能測試技術(shù)，研究SDN 交換機(jī)南向協(xié)議性能測試系統(tǒng)。

SDN 南向協(xié)議發(fā)展迅速，除了最初提出的 OpenFlow[4]協(xié)議以外許多傳統(tǒng)配置協(xié)議如NETCONF[5]、 OVSDB[6]、PCEP[7]等協(xié)議也逐漸開始作為傳統(tǒng)網(wǎng)絡(luò)設(shè)備的SDN 過渡協(xié)議開始使用。目前這些協(xié)議均處于發(fā)展?fàn)顟B(tài)，依托這些協(xié)議的技術(shù)仍然存在不足之處，對測試系統(tǒng)的南向協(xié)議擴(kuò)展能力提出了挑戰(zhàn)。協(xié)議測試技術(shù)一般分為一致性測試、互通性測試、性能測試和魯棒性測試四種類型[8]。其中性能測試通過某種特定的方式，按照一定的測試策略對被測實現(xiàn)進(jìn)行探測，獲取其各項性能指標(biāo)，評價其是否滿足用戶性能需求，用于確保被測實現(xiàn)可以穩(wěn)定高效地完成任務(wù)。SDN 交換機(jī)性能測試內(nèi)容多而雜，需要頻繁配置測試設(shè)備、測試環(huán)境和工具，生成不同的測試用例和環(huán)境，因此需要消耗大量的時間和人力。從國內(nèi)外對SDN 交換機(jī)性能測試的研究來看現(xiàn)有的無論是基于網(wǎng)絡(luò)測試儀還是基于開源軟件的SDN 網(wǎng)元性能測試框架都不能兼顧靈活性和精確性。

1 相關(guān)工作

針對SDN 交換機(jī)性能測試目前國內(nèi)外已經(jīng)有了一些研究和測試活動，但是這些研究和測試大多都是針對OpenFlow 協(xié)議開展的，對于其他南向協(xié)議，目前大多的文章都是研究其在傳統(tǒng)網(wǎng)絡(luò)中的性能表現(xiàn)。

本古里安大學(xué)的Gelberger 等人[9]研究了SDN架構(gòu)所增加的網(wǎng)絡(luò)復(fù)雜性對網(wǎng)絡(luò)性能的影響。他們通過分析交換機(jī)延遲、吞吐量和抖動三個指標(biāo)試圖探究網(wǎng)絡(luò)的可編程性與性能影響之間的關(guān)系。他們針對吞吐量，使用了一個標(biāo)準(zhǔn)工具iperf 來建立一個TCP/IP 流，具有各種TCP 窗口大小，從5K 字節(jié)到10M 字節(jié)；針對延遲，使用不同幀大小生成合成幀，并使用額外的時間戳來計算延遲；針對抖動，通過計算相鄰報文延時的變化來計算抖動。最后發(fā)現(xiàn)SDN 網(wǎng)絡(luò)的復(fù)雜性和可編程性雖然會影響單個網(wǎng)元的性能，但是由于執(zhí)行復(fù)雜網(wǎng)絡(luò)任務(wù)和應(yīng)用所需的設(shè)備和資源數(shù)目更少，SDN 架構(gòu)提高了網(wǎng)絡(luò)的整體性能。但是文章同樣指出SDN 的具體實現(xiàn)對性能有很大的影響。

在劍橋大學(xué)、TU Berlin/T-Labs 和倫敦瑪麗王后大學(xué)的Rotsos C 等人[10]開發(fā)的OFLOPS 項目中，針對SDN 交換機(jī)的性能測試，借鑒現(xiàn)代的多核環(huán)境，以多線程實現(xiàn)OFLOPS 平臺。針對并行輸入控制，設(shè)計多個測量模塊，包括數(shù)據(jù)包生成、數(shù)據(jù)包捕捉、控制信道、SNMP 信道和時間管理器五個線程。針對測量場景對轉(zhuǎn)發(fā)平面的影響，OFLOPS 平臺與交換機(jī)之間除了控制信道之外，還嵌入了數(shù)據(jù)信道。針對數(shù)據(jù)包生成功能，OFLOPS 支持三種機(jī)制：用戶空間、通過pktgen 模塊的內(nèi)核空間和基于NetFPGA 數(shù)據(jù)包生成器擴(kuò)展進(jìn)行硬件加速。針對數(shù)據(jù)包捕捉和時間戳，OFLOPS 同時支持pacp 庫和修改的NetFPGA 設(shè)計。在此基礎(chǔ)上，測試了行為處理、流表更新速度、流量監(jiān)控和消息之間的交互這四個指標(biāo)。

隨后，Rotsos C 等人[11]又在OFLOPS 的基礎(chǔ)上，加入OSNT[12]數(shù)據(jù)包生成器組成OFLOPS-Turbo 測試系統(tǒng)，使得端口的雙向速率增加到20Gbit/s。

卡爾頓大學(xué)的Kunz T 等人[13]在光傳輸網(wǎng)絡(luò)中對OpenFlow 協(xié)議與NETCONF 協(xié)議進(jìn)行了對比。他們分別使用OpenFlow 協(xié)議和基于YANG 模型的NETCONF 協(xié)議連接OpenDayLight 控制器和兩臺跨數(shù)據(jù)中心的BIT7800 網(wǎng)元設(shè)備，通過請求不同的帶寬請求來測試兩個協(xié)議作為南向協(xié)議的性能。最后發(fā)現(xiàn)NETCONF 協(xié)議相對OpenFlow 協(xié)議速度更寬，所需的控制報文更少，但是OpenFlow 協(xié)議可以使數(shù)據(jù)面的鏈路利用率更高。

天地互連全球SDN 測試認(rèn)證中心[14]于2016年10月使用測試OpenFlow 交換機(jī)產(chǎn)品的性能測試工具OFsuite_performance，針對SDN 交換機(jī)的性能，以O(shè)pen vSwitch v2.8.0 為測試對象，測試了TABLEMISS 表項的PACKET IN 性能、非TABLE-MISS 表項的PACKET_IN 性能、流表更新和PACKET_OUT 消息吞吐/時延等多個性能指標(biāo)。

中國信息通信研究院穆琙博等人分別從接口級別和網(wǎng)元級別提出針對測試指標(biāo)。南向接口高性能測試檢驗?zāi)舷蚪涌谠诟邩I(yè)務(wù)負(fù)載條件下的網(wǎng)絡(luò)接口能力，主要有兩個測試指標(biāo)：業(yè)務(wù)處理能力和緩存能力[15]。前者測試南向接口的最大業(yè)務(wù)吞吐量，后者測試最大緩存長度。

臺灣交通大學(xué)，中原大學(xué)，臺灣科技大學(xué)的林盈達(dá)等人[16]針對OpenFlow 交換機(jī)性能首次提出精細(xì)內(nèi)部指標(biāo)的概念，并提出精細(xì)內(nèi)部指標(biāo)的測試方法：鏡像報文(Mirror-in-Process)、突發(fā)流量丟包(Burst-until-loss)、連續(xù)背靠背流量(Back-to-backtraffic)以及硬件超時計算空閑超時(Idle-timeoutderived-by-hard-timeout)。該團(tuán)隊開發(fā)測試工具開發(fā)的工具OFBench 使用五個測試用例測試了動作時間(action time), 流水線時間（pipeline time），緩存大?。╞uffer size），流水線效率（pipeline efficiency）和超時準(zhǔn)確性（timeout accuracy）五個性能指標(biāo)。

長沙理工大學(xué)的黎維[17]，熊兵[18]等人分別在軟件定義廣域網(wǎng)和軟件定義數(shù)據(jù)中心網(wǎng)絡(luò)中針對OpenFlow 協(xié) 議中的PACKET_IN 和PACKET_OUT兩種消息延遲進(jìn)行了理論分析和實驗。他們分別針對兩種網(wǎng)絡(luò)環(huán)境分析了控制器集群的PACKET_IN消息和數(shù)據(jù)分組的到達(dá)過程，分別建立了分組轉(zhuǎn)發(fā)性能模型。進(jìn)而針對廣域網(wǎng)環(huán)境應(yīng)用M/M/n/m、M/M/1/m 排隊模型，數(shù)據(jù)中心網(wǎng)絡(luò)環(huán)境下應(yīng)用L/M/n 和L/M/1 排隊模型，刻畫了軟件定義網(wǎng)絡(luò)系統(tǒng)的消息處理和分組處理性能。最后該項研究使用SDN測試認(rèn)證中心的OFsuite_Performance 測試工具和Cbench[19]進(jìn)行了一系列實驗驗證他們模型的結(jié)果，并對不同網(wǎng)絡(luò)規(guī)模下控制器集群的部署提出了部署要求和優(yōu)化建議。

國防科大的蔣越，楊翔瑞等人[20]提出了基于CPU+FPGA 架構(gòu)的可配置SDN 交換機(jī)測試方案ORTF。其核心思想是利用FPGA 設(shè)計了一條通用報文處理流水線，將數(shù)據(jù)轉(zhuǎn)發(fā)和南向協(xié)議流量統(tǒng)一處理，從而達(dá)到數(shù)據(jù)和控制報文時鐘同步的目的。通過硬件標(biāo)記報文時間，使用軟件來將以太網(wǎng)報文重組，最終得到測試結(jié)果。在文中他們針對Pica8 P-3297 型交換機(jī)進(jìn)行了OpenFlow 協(xié)議中Barrier 消息延遲測試，驗證了該交換機(jī)Barrier 機(jī)制實現(xiàn)正確。

2 SDN 交換機(jī)南向協(xié)議性能測試需求分析和方案設(shè)計

本節(jié)首先結(jié)合SDN 交換機(jī)南向協(xié)議的發(fā)展趨勢和公開的測試結(jié)果總結(jié)SDN 交換機(jī)南向協(xié)議性能測試需求，明確測試方案設(shè)計難點(diǎn)；然后給出靈活精確的SDN 交換機(jī)南向協(xié)議性能測試方案。

2.1 SDN 交換機(jī)南向協(xié)議性能測試需求和難點(diǎn)

本節(jié)將通過分析SDN 交換機(jī)南向協(xié)議發(fā)展特點(diǎn)和已有的SDN 交換機(jī)南向協(xié)議性能測試結(jié)果來得到SDN 交換機(jī)南向協(xié)議性能測試需求，明確性能測試方案設(shè)計難點(diǎn)。

首先是SDN 交換機(jī)南向協(xié)議的發(fā)展特點(diǎn)。軟件定義網(wǎng)絡(luò)架構(gòu)如圖1 所示，該架構(gòu)分為三層：網(wǎng)絡(luò)應(yīng)用層、控制決策層和數(shù)據(jù)轉(zhuǎn)發(fā)層。南向協(xié)議作為聯(lián)系數(shù)據(jù)轉(zhuǎn)發(fā)層和控制決策層的紐帶，一方面向控制器傳遞交換機(jī)上報的網(wǎng)絡(luò)狀態(tài)信息，另一方面向交換機(jī)傳遞控制器下發(fā)的轉(zhuǎn)發(fā)策略。軟件定義網(wǎng)絡(luò)從架構(gòu)上確定了SDN 交換機(jī)控制決策和數(shù)據(jù)轉(zhuǎn)發(fā)解耦，但是并沒有指定南向協(xié)議的具體實現(xiàn)方式。

圖1 SDN 架構(gòu)Fig.1 SDN architecture

在SDN 發(fā)展初期，OpenFlow 協(xié)議是唯一的南向協(xié)議。從文獻(xiàn)[21]中可以看到，OpenFlow 協(xié)議自2008年被提出，一直保持快速的迭代速度。開放網(wǎng)絡(luò)基金會在2009年發(fā)布了OpenFlow 交換機(jī)規(guī)范 1.0 版本[22]，到2015年OpenFlow 已經(jīng)迭代到1.5.1版本[23]。

到了SDN 發(fā)展中后期，越來越復(fù)雜的網(wǎng)絡(luò)場景導(dǎo)致OpenFlow 協(xié)議流表的匹配項越來越繁雜，這給SDN 交換機(jī)硬件設(shè)計廠商帶來了嚴(yán)峻的挑戰(zhàn)。為了解決OpenFlow 協(xié)議帶來的問題，一些廠商通過將傳統(tǒng)協(xié)議NETCONF、BGP-LS、PCEP 與傳統(tǒng)交換機(jī)結(jié)合，提出了具備一定軟件定義能力的SDN 解決方案。同時，很多廠商開始發(fā)展自己的SDN 架構(gòu)。華為推出了Protocol-oblivious forwarding（POF）[24]架構(gòu)。思科推出了SDN 解決方案Cisco Application Centric Infrastructure（Cisco ACI）[25]并在2014年提出了自己的私有南向協(xié)議Opflex[26]。開放網(wǎng)絡(luò)基金會也提出了自己的協(xié)議無關(guān)SDN 架構(gòu)P4[27]。

下面介紹一些SDN 交換機(jī)南向協(xié)議性能測試結(jié)果。劍橋大學(xué)的Rotsos C 等人使用OFLOPS[10]針幾種不同廠家的的OpenFlow 交換機(jī)進(jìn)行了一系列測試。在報文修改延遲測試中，發(fā)現(xiàn)基于硬件實現(xiàn)的交換機(jī)延遲普遍小于10us，而基于軟件實現(xiàn)的交換機(jī)延遲普遍在幾百微秒；在流表更新延遲測試中發(fā)現(xiàn)想要精確感知交換機(jī)狀態(tài)的變化，必須基于數(shù)據(jù)面報文轉(zhuǎn)發(fā)行為來探測；在流表下發(fā)和修改延遲測試中，利用數(shù)據(jù)面的探針報文來感知流表生效的時刻，最快的交換機(jī)延遲為幾百微秒，最慢的交換機(jī)延遲為幾十毫秒；針對獲取交換機(jī)流表狀態(tài)時延測試發(fā)現(xiàn)流表狀態(tài)獲取嚴(yán)重依賴CPU 的性能，普遍的處理延遲大于1ms，部分交換機(jī)甚至達(dá)到了1s。

全球SDN 測試認(rèn)證中心聯(lián)合IXIA 等公司分別舉辦了2016、2017 春季SDNVF FEST 測試活動[28]。在活動中針對烽火通信、華為、Radisys、智邦科技等公司的SDN 交換機(jī)進(jìn)行了相關(guān)性能測試。在流表安裝速率的測試中，當(dāng)控制器以1Kpps 速率下發(fā)流表時，交換機(jī)的流表安裝速率最高為每秒500 條。將控制器發(fā)送速率提高到10Kpps 時，交換機(jī)的流表項安裝速率最高為每秒1666 條；在PACKET_IN 上報速率測試中得到最高速率為8000pps；組表轉(zhuǎn)發(fā)測試只有華為一家廠商支持，結(jié)果顯示交換機(jī)轉(zhuǎn)發(fā)速率能夠達(dá)到網(wǎng)卡線速，轉(zhuǎn)發(fā)延遲為98810ns。

結(jié)合SDN 交換機(jī)南向協(xié)議的發(fā)展歷程和已有的SDN 交換機(jī)性能測試結(jié)果，可以看到SDN 交換機(jī)南向協(xié)議性能測試需求包含三方面：首先是良好的擴(kuò)展性。南向協(xié)議發(fā)展迅速、種類多、迭代快，測試方案必須能夠快速適配南向協(xié)議的快速發(fā)展；其次是方便靈活的流量構(gòu)造能力。從測試結(jié)果來看吞吐量量級在每秒幾千報文，這表明南向協(xié)議性能測試對探針報文的發(fā)送能力要求并不嚴(yán)苛。但是從測試指標(biāo)來看測試過程中需要的流量場景靈活多變，這就要求測試方案必須具備方便靈活的突發(fā)流量構(gòu)造能力；最后是精確的時間測量能力。從延遲測試結(jié)果來看，結(jié)果量級大多在幾十微秒到幾十毫秒。這就要求測試方案必須具備亞微秒的時間測量精度，才能保證延遲測試結(jié)果的準(zhǔn)確性。

為了滿足上述測試需求，SDN 交換機(jī)南向協(xié)議性能測試方案設(shè)計面臨兩個難點(diǎn)：首先是良好的可擴(kuò)展性與系統(tǒng)復(fù)雜功能之間的矛盾。性能測試方案功能繁雜，需要包含方便靈活的控制面/數(shù)據(jù)面流量構(gòu)造、發(fā)送、捕獲和分析功能。如何使測試方案既能夠高效執(zhí)行復(fù)雜系統(tǒng)功能又保證良好的系統(tǒng)擴(kuò)展性和易用性成為了系統(tǒng)架構(gòu)設(shè)計的一大難點(diǎn)；其次是方便靈活的流量構(gòu)造能力與精確時間測量能力之間的矛盾。軟件方案可以輕松保證靈活方便的流量構(gòu)造能力，但會導(dǎo)致報文捕獲精確度嚴(yán)重降低。硬件方案可以極大提高報文的捕獲精度，卻使得流量構(gòu)造十分繁瑣。如何將系統(tǒng)功能進(jìn)行合理的軟硬件劃分成為了系統(tǒng)設(shè)計的又一大難點(diǎn)。

2.2 靈活精確的SDN 交換機(jī)南向協(xié)議性能測試方案

圖2 靈活可擴(kuò)展的SDN 交換機(jī)南向協(xié)議性能測試方案Fig.2 Flexible and scalable SDN switch southbound protocol performance test scheme

為了滿足2.1 節(jié)中提出的良好的系統(tǒng)擴(kuò)展性和方便靈活的突發(fā)流量構(gòu)造能力，本文提出了如圖2所示的靈活可擴(kuò)展的SDN 交換機(jī)南向協(xié)議性能測試方案。從測試流程來看，在進(jìn)行性能測試時，用戶通過控制臺用戶接口選擇測試?yán)?。每個測試?yán)ㄟ^自定義控制器模塊與待測交換機(jī)建立控制信道，通過流量生成模塊生成探針流量觸發(fā)交換機(jī)的行為，通過流量捕獲模塊將控制和數(shù)據(jù)信道的報文按需捕獲，被捕獲的數(shù)據(jù)探針報文被送回測試?yán)绦?，被捕獲的南向協(xié)議報文被報文重組模塊重組為應(yīng)用層報文后送往測試?yán)绦颍罱K由測試?yán)绦蚍治鰣笪牡玫綔y試結(jié)果由控制臺用戶接口展示。

在靈活可擴(kuò)展的SDN 交換機(jī)南向協(xié)議性能測試方案中具體包含6 個部分：控制臺用戶接口、測試?yán)?、自定義控制器模塊、流量生成模塊、流量捕獲模塊、自定義報文分析模塊。各個模塊詳細(xì)功能如下所述。

控制臺用戶接口：與測試用戶進(jìn)行交互的接口。在測試過程中，用戶首先在此選擇要進(jìn)行的測試并對相關(guān)參數(shù)進(jìn)行配置，然后系統(tǒng)內(nèi)部調(diào)用對應(yīng)的測試?yán)绦蜻M(jìn)行實際測試，最后將測試結(jié)果展示給用戶。

測試?yán)赫麄€測試系統(tǒng)的核心模塊，驅(qū)動整個測試流程的進(jìn)行。用戶可以按需編寫自己的測試?yán)绦?。測試?yán)梢园葱鑴?chuàng)建控制器實例來與待測交換機(jī)進(jìn)行南向協(xié)議通信，可以通過流量生成模塊按照指定發(fā)送間隔產(chǎn)生指定類型的流量，可以通過流量捕獲模塊按需抓取測試過程中的控制/數(shù)據(jù)信道的流量，可以通過自定義報文分析模塊對南向協(xié)議流量進(jìn)行重組，從而得到精確的控制面事件。

自定義控制器模塊：負(fù)責(zé)與待測交換機(jī)進(jìn)行南向協(xié)議通信，包括維持協(xié)議連接，下發(fā)自定義配置等。此模塊包含兩部分，下層的不可變通信模塊主要負(fù)責(zé)提供TCP/UDP 通信接口，上層由用戶自行擴(kuò)展南向協(xié)議，最終實現(xiàn)靈活可變得自定義控制器模塊。

流量生成模塊：主要負(fù)責(zé)按照測試?yán)渲玫陌l(fā)送間隔生成一系列指定類型的數(shù)據(jù)流量。

流量捕獲模塊：負(fù)責(zé)按照測試?yán)呐渲脤?shù)據(jù)面探針報文和控制面南向協(xié)議報文全部抓取上來，然后將帶有時間信息的數(shù)據(jù)面探針報文發(fā)送給測試?yán)?，將帶有時間信息的控制面南向協(xié)議報文發(fā)送給自定義報文分析模塊。

自定義報文分析模塊：負(fù)責(zé)將帶有時間信息的南向協(xié)議以太網(wǎng)報文恢復(fù)為帶有時間信息的南向協(xié)議報文，然后發(fā)送給測試?yán)４四K也包含兩部分，下層由不可變保溫重組模塊主要負(fù)責(zé)將物理層、網(wǎng)絡(luò)層、傳輸層的頭部去掉，恢復(fù)為帶有時間戳的應(yīng)用層原生報文。上層由用戶自行擴(kuò)展南向協(xié)議分析模塊，最終獲得帶有時間信息的南向協(xié)議報文。

通過上面的設(shè)計，利用自定義控制器模塊和自定義報文分析模塊，本方案可以在不破壞整個系統(tǒng)測試流程的情況下，實現(xiàn)對不同南向協(xié)議的擴(kuò)展能力，同時利用基于libnet 的軟件流量生成模塊，可以方便靈活的按需構(gòu)造各種流量場景。至此，我們得到了一個靈活可擴(kuò)展的SDN 換機(jī)南向協(xié)議性能測試方案。

為了提高測試方案的時間測量精度，本文在 圖2 所示測試方案的基礎(chǔ)上，采用軟硬件結(jié)合的流量捕獲方式，大幅度提高報文的捕獲時間精度得到如圖3 所示的靈活精確的SDN 交換機(jī)南向協(xié)議性能測試方案。

圖3 靈活精確的SDN 交換機(jī)南向協(xié)議性能測試方案Fig.3 Flexible and accurate SDN switch southbound protocol performance test scheme

為了提高流量捕獲模塊的測量精度同時不大幅度增加系統(tǒng)復(fù)雜度，本方案使用FAST[29]架構(gòu)開發(fā)了一個硬件支撐平臺來輔助libpcap 最終實現(xiàn)精確度在納秒級的報文捕獲模塊。硬件支撐平臺主要完成南向協(xié)議/數(shù)據(jù)探針報文時間戳的獲取和回傳時間戳兩個功能。首先是報文時間戳的精確獲取，為了南向協(xié)議和數(shù)據(jù)探針報文的時間戳有可比性必須統(tǒng)一時鐘。因此控制面南向協(xié)議和數(shù)據(jù)面探針流量都要經(jīng)過同一條硬件流水線，同時在2.1 中分析得到南向協(xié)議性能測試對數(shù)據(jù)流量帶寬需求并不大。因此為了簡化設(shè)計，本方案在測試機(jī)中將南向協(xié)議和數(shù)據(jù)探針的流量采用同一個網(wǎng)卡通信，從而簡化報文時間戳的獲取。對于每一個進(jìn)入硬件支撐平臺網(wǎng)卡0 的報文，在其進(jìn)入的時刻獲取當(dāng)前時鐘計數(shù)即可。但是，當(dāng)南向協(xié)議和數(shù)據(jù)探針流量混合在一起進(jìn)入硬件支撐平臺后，硬件支撐平臺需要將二者區(qū)分開，分別轉(zhuǎn)發(fā)給待測交換機(jī)的控制網(wǎng)卡和數(shù)據(jù)網(wǎng)卡。本方案將所有數(shù)據(jù)探針流量的目的MAC 地址設(shè)為特殊值，硬件支撐平臺在0 號網(wǎng)卡收到流量后，只需簡單判斷報文的目的MAC 地址是否為特殊值即可將流量正確轉(zhuǎn)發(fā)到控制網(wǎng)卡（1 號網(wǎng)卡）和數(shù)據(jù)發(fā)送網(wǎng)卡（2 號網(wǎng)卡）。解決了報文時間戳的獲取問題，下一步就是要解決時間戳的回傳問題。同樣是為了簡化設(shè)計，考慮到南向協(xié)議性能測試時對測試機(jī)網(wǎng)卡帶寬需求并不高，本方案在硬件支撐平臺收到每個報文時，截取其前64 字節(jié)生成一個新的以太網(wǎng)報文，并將硬件時間戳記錄到報文的源MAC 地址中，通過0號網(wǎng)卡回傳給測試機(jī)。當(dāng)硬件支撐平臺0 號網(wǎng)卡收到來自測試機(jī)的流量將摘要報文回傳給測試機(jī)時便得到了報文的發(fā)送時間戳，當(dāng)硬件支撐平臺1 號網(wǎng)卡收到來自待測交換機(jī)返回的流量將摘要報文回傳給測試機(jī)時，便得到了報文的接收時間。特別注意，由于數(shù)據(jù)面流量本身沒有意義，本方案僅關(guān)注其轉(zhuǎn)發(fā)的時間，因此硬件支撐平臺3 號網(wǎng)卡在收到待測交換機(jī)轉(zhuǎn)發(fā)的數(shù)據(jù)流量后，并沒有將數(shù)據(jù)報文轉(zhuǎn)發(fā)到0 號網(wǎng)卡，而是只將數(shù)據(jù)摘要報文發(fā)送，這樣可以大幅度節(jié)約測試機(jī)和硬件支撐設(shè)備之間的通信帶寬。最終通過libpcap 和硬件支撐平臺相互配合得到了一個精確度為8ns 的流量捕獲模塊。

在圖3 中由于引入硬件支撐平臺，流量重組模塊和測試?yán)惨鄳?yīng)的變化。流量捕獲模塊獲取報文分為三類，第一類是南向協(xié)議報文；第二類是南向協(xié)議報文的摘要報文；第三類是數(shù)據(jù)探針報文的摘要報文。在實際測試中，前兩類報文被一同送入報文重組模塊，得到帶有精確時間戳的南向協(xié)議報文供測試?yán)治?，?shù)據(jù)探針的摘要報文被送入測試?yán)?/p>

3 關(guān)鍵模塊設(shè)計

本節(jié)將以O(shè)penFlow 協(xié)議為例，介紹靈活精確的SDN 交換機(jī)南向協(xié)議性能測試方案中關(guān)鍵模塊的實現(xiàn)細(xì)節(jié)，包括自定義控制器、報文重組模塊、基于libnet 的流量生成模塊、基于libpcap 的流量捕獲模塊以及硬件支撐平臺。

3.1 自定義OpenFlow 控制器和報文重組模塊

自定義控制器的作用是與待測交換機(jī)建立南向協(xié)議通信，下發(fā)自定義配置信息，本節(jié)以O(shè)penFlow 1.3.5 協(xié)議為例闡述自定義控制器的實現(xiàn)流程。如圖4 所示，OpenFlow 協(xié)議工作的基本工作流程可以分為連接建立、連接維持、連接中斷三個階段。

圖4 OpenFlow 協(xié)議工作流程Fig.4 OpenFlow protocol workflow

在SDN 交換機(jī)性能測試中，需要自定義OpenFlow 控制器與交換機(jī)建立控制信道，在連接維持階段能夠根據(jù)測試?yán)男枨箪`活更改交換機(jī)配置。為了能夠達(dá)到上述目標(biāo)，本方案設(shè)計了如圖5 所示的雙線程結(jié)構(gòu)。在測試中，測試?yán)绦蚴紫葎?chuàng)建一個自定義OpenFlow 控制器實例，在創(chuàng)建時可以指定控制器實例對來自交換機(jī)消息的處理方式?？刂破鲗嵗粍?chuàng)建后，開啟如圖6 所示的單獨(dú)線程與交換機(jī)維持OpenFlow 控制信道。在測試過程中，測試?yán)绦蛘{(diào)用控制器實例提供的接口向交換機(jī)下發(fā)配置信息存在兩種方式：其一是異步消息，通過控制器提供的借口直接下發(fā)，不需要等待交換機(jī)回復(fù)；其二是調(diào)用控制器提供的接口發(fā)送消息的同時注冊一個事件，隨后測試?yán)€程進(jìn)入阻塞狀態(tài)，當(dāng)控制器線程收到期望消息后喚醒測試?yán)€程。最后，當(dāng)測試完成后，測試?yán)€程通過控制器提供的接口通知并等待控制器線程退出。

圖5 自定義OpenFlow 控制器工作流程Fig.5 Customize OpenFlow controller workflowrule_

圖6 控制器邏輯Fig.6 Controller logic

自定義OpenFlow 報文重組模塊的主要任務(wù)是讀取流量捕獲模塊抓取的pcap 文件，將其中帶有時間戳的以太網(wǎng)報文轉(zhuǎn)換為帶有時間戳的OpenFlow報文。為了實現(xiàn)這一目標(biāo)，本文設(shè)計了analysier 和node 兩個結(jié)構(gòu)體組成二級結(jié)構(gòu)。analysier 實例負(fù)責(zé)標(biāo)識一個重組原始文件，rule_node 實例標(biāo)識一個目標(biāo)文件。每個analysier 實例可以攜帶多個rule_node實例，每個rule_node 實例只能綁定到一個analysier實例中。報文重組的過程如圖7 所示，在啟動重組接口之后會創(chuàng)建一個工作線程，該線程從pcap 文件中讀取以太網(wǎng)報文，提取報文中的IP 五元組信息與analysis_rule_node_t 的過濾規(guī)則相比較，將符合過濾規(guī)則的報文傳入對應(yīng)的回調(diào)函數(shù)，最終將帶有時間戳的報文信息存儲到指定的臨時文件中。

3.2 基于libnet 的流量生成模塊

流量生成模塊的主要任務(wù)是按照配置，通過指定的網(wǎng)卡產(chǎn)生一定速率的流量。在產(chǎn)生流量時，首先使用IP 五元組信息和發(fā)包間隔參數(shù)創(chuàng)建發(fā)包實例。創(chuàng)建實例默認(rèn)是沒有配置IP 五元組掩碼的，如果想要發(fā)送報文的IP 五元組隨機(jī)發(fā)生改變，可以調(diào)用接口進(jìn)行設(shè)置。然后調(diào)用啟動接口創(chuàng)建如圖8 所示的工作線程。

圖7 報文重組邏輯Fig.7 Packet reorganization logic

3.3 基于libpcap 的流量捕獲模塊

流量捕獲模塊的主要任務(wù)是根據(jù)IP 五元組信息將流經(jīng)特定網(wǎng)卡的全部流量進(jìn)行捕獲。在捕獲流量時，首先使用IP 五元組信息和捕獲數(shù)量參數(shù)創(chuàng)建捕獲實例。然后調(diào)用啟動接口創(chuàng)建如圖9 所示的抓包工作線程。如果需要測試線程等待抓包則調(diào)用等待接口，在工作線程結(jié)束時，會調(diào)用喚醒接口來喚醒等待線程。

圖8 發(fā)包邏輯Fig.8 Sending packet logic

3.4 南向協(xié)議性能測試硬件支撐平臺

如圖3 所示，南向協(xié)議性能測試硬件支撐平臺的主要任務(wù)包含兩方面：一方面是將每個進(jìn)入0 號、1 號和3 號網(wǎng)卡的報文產(chǎn)生對應(yīng)的摘要報文，通過0號網(wǎng)卡發(fā)送給測試機(jī)。數(shù)據(jù)摘要的格式為以太網(wǎng)報文的前64 字節(jié)，將以太網(wǎng)協(xié)議類型修改為0xFF0X(最后的X 為原報文的輸入網(wǎng)卡號)，將報文源MAC地址替換為當(dāng)前的硬件時鐘計數(shù)；另一方面將進(jìn)入硬件支撐平臺的報文根據(jù)入端口和報文類型分別轉(zhuǎn)發(fā)到對應(yīng)的目的端口。具體為，進(jìn)入0 號網(wǎng)卡的報文，如果目的MAC 地址為0x0000C0000000 則認(rèn)為是數(shù)據(jù)流量，將報文從2 號網(wǎng)卡轉(zhuǎn)發(fā)，其余報文認(rèn)為是南向協(xié)議報文，將報文從1 號網(wǎng)卡轉(zhuǎn)發(fā)。進(jìn)入1號網(wǎng)卡的報文，從0 號網(wǎng)卡轉(zhuǎn)發(fā)。進(jìn)入2 和3 號網(wǎng)卡的報文直接丟棄。

圖9 抓包邏輯Fig.9 Capturing packet logic

為了實現(xiàn)上述功能，本方案使用FAST 架構(gòu)。FAST 是面向多核CPU+FPGA 平臺，支持互聯(lián)網(wǎng)創(chuàng)新研究和計算機(jī)網(wǎng)絡(luò)實驗教學(xué)的開源項目。FAST 定義了硬件加速網(wǎng)絡(luò)接口與操作系統(tǒng)內(nèi)核以及用戶態(tài)程序數(shù)據(jù)交互的格式和協(xié)議，基于軟硬件協(xié)同設(shè)計支持網(wǎng)絡(luò)設(shè)備數(shù)據(jù)平面快速實現(xiàn)。在FAST 架構(gòu)中自定義硬件模塊(UM)部分開發(fā)了如圖10 所示的三個模塊。報文緩存模塊（PKT_FIFO）的作用是緩存進(jìn)入UM 的報文，當(dāng)模塊傳來讀取信號時將數(shù)據(jù)讀出。摘要生成模塊(DGM)的作用是當(dāng)報文緩存模塊不為空時，從報文緩存模塊中讀取一個報文，生成該報文的摘要，待報文全部傳輸?shù)絼幼鬓D(zhuǎn)發(fā)模塊后，將摘要報文也傳輸?shù)絼幼鬓D(zhuǎn)發(fā)模塊。動作轉(zhuǎn)發(fā)模塊(ACM)的作用是當(dāng)有報文到來時，判斷該報文是否是摘要報文，如果是則直接轉(zhuǎn)發(fā)；否則根據(jù)與報文對應(yīng)的元信息中的入網(wǎng)卡和目的MAC 決定該報文的輸出網(wǎng)卡。限于篇幅，本文不再詳細(xì)介紹各個模塊內(nèi)部的邏輯實現(xiàn)。

圖10 硬件支撐平臺總體設(shè)計Fig.10 Overall design of hardware support platform

4 SDN 交換機(jī)性能測試實驗

本節(jié)首先介紹SDN 交換機(jī)性能測試實驗的測試環(huán)境，包括測試機(jī)、硬件支撐平臺和待測設(shè)備的相關(guān)參數(shù)，然后針對待測交換機(jī)的OpenFlow 性能進(jìn)行了一系列測試。

4.1 測試環(huán)境

將測試機(jī)、南向協(xié)議性能測試硬件支撐平臺、數(shù)據(jù)轉(zhuǎn)發(fā)性能測試硬件支撐平臺三者相結(jié)合形成高速SDN 交換機(jī)性能測試系統(tǒng)，與待測交換機(jī)連接后得到如圖11 所示的測試環(huán)境。

在測試過程中，測試機(jī)采用浪潮英信服務(wù)器NF5170M4，運(yùn)行系統(tǒng)為Ubuntu16.04。南向協(xié)議性能測試硬件采用FAST 團(tuán)隊官方提供的OpenBox-S4平臺，其基本情況為：芯片組為Zynq-7000 芯片，內(nèi)置雙核Cortex-A9 處理器，內(nèi)存大小為為512MB，網(wǎng)卡接口為4 個千兆以太網(wǎng)數(shù)據(jù)接口和1 個千兆以太網(wǎng)管理接口。待測交換機(jī)型號為新華三的S5560X-34S-EI 交換機(jī)。

圖11 測試環(huán)境示意圖Fig.11 Test environment diagram

4.2 OpenFlow 流表性能測試

OpenFlow 流表性能測試包括流表安裝延遲、修改以及刪除延遲。

流表安裝延遲測試的具體步驟為：

（1）刪除交換機(jī)中所有流表項；

（2）持續(xù)發(fā)送數(shù)據(jù)探針報文（64 字節(jié)）到交換機(jī)的端口1，此時沒有報文從端口2 轉(zhuǎn)發(fā)出去；

（3）向0 號流表下發(fā)一條流表項，該流表項匹配端口1 的數(shù)據(jù)探針報文，動作為轉(zhuǎn)發(fā)到2 號端口，記錄下發(fā)流表的時刻為T1；

（4）流表生效后會有報文從2 號端口轉(zhuǎn)發(fā)，此時停止發(fā)送報文，記錄第一個轉(zhuǎn)發(fā)報文的時刻為T2；

（5）計算測試結(jié)果Tdelay=T2-T1。

使用上述方案分別在0 條無關(guān)流表項和500 條無關(guān)流表項的環(huán)境下進(jìn)行了100 次測試，得到圖12所示的結(jié)果。從圖12 中可以看到：交換機(jī)流表安裝延遲性能基本穩(wěn)定在6ms 左右，少數(shù)情況下交換機(jī)性能抖動導(dǎo)致流表安裝延遲飆升到27ms。無關(guān)流表對流表安裝延遲沒有明顯的影響。

流表安裝延遲測試的具體步驟為：

（1）刪除交換機(jī)中所有流表項；

（2）向0 號流表下發(fā)一條流表項，該流表項匹配端口1 的數(shù)據(jù)探針報文，動作為轉(zhuǎn)發(fā)到2 號端口；

（3）持續(xù)發(fā)送數(shù)據(jù)探針報文（64 字節(jié)）到交換機(jī)的端口1，當(dāng)有報文從端口2 轉(zhuǎn)發(fā)出來時發(fā)送流表刪除報文，記錄時刻為T1；

（4）持續(xù)發(fā)送數(shù)據(jù)探針報文一段時間（5 秒），記錄最后一個轉(zhuǎn)發(fā)報文的時刻為T2；

（5）計算測試結(jié)果為Tdelay=T2-T1。

使用上述方案分別在0 條無關(guān)流表項和500 條無關(guān)流表項的環(huán)境下進(jìn)行了100 次測試，得到圖13所示的結(jié)果。

從圖13 中可以看到：從整體來看，交換機(jī)流表刪除延遲呈現(xiàn)出明顯的分層現(xiàn)象，在20%左右的情況下產(chǎn)生較長的延遲是其余較短延遲的數(shù)倍；對比500 條無關(guān)流表和0 條無關(guān)流表的結(jié)果可以看到，無關(guān)流表在延遲較低部分會增加流表刪除延遲大約0.5ms，在延遲較高的部分影響更大，極端情況下延遲達(dá)到27ms。

圖12 流表安裝延遲結(jié)果Fig.12 Flow table installation delay result

圖13 流表刪除延遲結(jié)果Fig.13 Flow table delete delay results

流表修改延遲測試的具體步驟為：

（1）刪除交換機(jī)中所有流表項；

（2）向0 號流表下發(fā)一條流表項，該流表項匹配端口1 的數(shù)據(jù)探針報文，動作為轉(zhuǎn)發(fā)到控制器;

（3）持續(xù)發(fā)送數(shù)據(jù)探針報文（64 字節(jié)）到交換機(jī)的端口1，當(dāng)收到PACKET_IN 報文時，下發(fā)流表修改表項將轉(zhuǎn)發(fā)端口修改為端口2，記錄此時刻為T1；

（4）流表生效后會有報文從2 號端口轉(zhuǎn)發(fā)，此時停止發(fā)送報文，記錄第一個轉(zhuǎn)發(fā)報文的時間為T2；

（5）測試結(jié)果為Tdelay=T2-T1。

使用上述方案分別在0 條無關(guān)流表項和500 條無關(guān)流表項的環(huán)境下進(jìn)行了100 次測試，得到圖14所示的結(jié)果。

從圖14 中可以看到：流表修改延遲表現(xiàn)出分層現(xiàn)象，在10%左右的情況下產(chǎn)生較長的延遲是其余較短延遲的數(shù)倍；對比對比500 條無關(guān)流表和0 條無關(guān)流表的結(jié)果可以看到，無關(guān)流表項會導(dǎo)致流表修改延遲增加大約1.5ms。

圖14 流表修改延遲結(jié)果Fig.14 Flow table modification delay result

5 展望與下一步工作

本文圍繞SDN 交換機(jī)南向協(xié)議性能測試進(jìn)行研究，主要包括南向協(xié)議性能測試需求分析和方案設(shè)計、系統(tǒng)實現(xiàn)三個方面。最后通過針對新華三交換機(jī)進(jìn)行了OpenFlow 流表性能測試，客觀的評價了該交換機(jī)的實際性能，驗證了測試方案的可行性。

本文主要針對單個交換機(jī)的性能指標(biāo)進(jìn)行了探討。但是隨著SDN 網(wǎng)絡(luò)的快速發(fā)展，單個設(shè)備的性能很難客觀的反映整個網(wǎng)絡(luò)的性能。后續(xù)可以繼續(xù)研究如何針對具體的網(wǎng)絡(luò)業(yè)務(wù)場景制定普適的性能指標(biāo)，然后模擬出真實的SDN 網(wǎng)絡(luò)業(yè)務(wù)流量，最終客觀的評價SDN 網(wǎng)絡(luò)的性能。

本文所提出的系統(tǒng)方案本質(zhì)上采用的是以中間人攻擊的方式將網(wǎng)絡(luò)流量進(jìn)行時間標(biāo)記，在測試端恢復(fù)出報文語義，根據(jù)報文語義中代表的網(wǎng)絡(luò)事件來得到測試結(jié)果，這就導(dǎo)致無法針對加密南向協(xié)議進(jìn)行測試。在越來越重視信息安全的今天，如何設(shè)計針對加密南向協(xié)議性能測試方案同樣值得進(jìn)一步研究。

利益沖突聲明

所有作者聲明不存在利益沖突關(guān)系。