基于OpenFlow的SDN架構(gòu)研究與實(shí)踐

于天放，芮蘭蘭

(北京郵電大學(xué) 網(wǎng)絡(luò)與交換技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室，北京 100876)

0 引 言

隨著IT技術(shù)的高速發(fā)展，云計(jì)算、虛擬化等新興業(yè)務(wù)的不斷涌現(xiàn)，對(duì)網(wǎng)絡(luò)的承載能力提出了更高的要求。在傳統(tǒng)網(wǎng)絡(luò)中，控制平面功能是分散地運(yùn)行在各個(gè)節(jié)點(diǎn)中，控制邏輯和數(shù)據(jù)轉(zhuǎn)發(fā)被緊耦合在網(wǎng)絡(luò)設(shè)備上，這種分布式的控制方式增加了網(wǎng)絡(luò)管理的難度，不僅帶來了網(wǎng)絡(luò)互操作性的問題，而且難以開展基于真實(shí)網(wǎng)絡(luò)流量的新技術(shù)研究和實(shí)驗(yàn)。SDN[1]和OpenFlow[2]的理念就是在上述背景下得以快速發(fā)展的。SDN的基本思想是采用相互分離的控制平面和轉(zhuǎn)發(fā)平面，通過將控制功能抽象到控制平面中實(shí)現(xiàn)集中化的網(wǎng)絡(luò)狀態(tài)控制，同時(shí)為用戶提供開放式可編程接口，使得用戶能夠根據(jù)上層業(yè)務(wù)需求對(duì)網(wǎng)絡(luò)資源進(jìn)行靈活調(diào)度。OpenFlow是SDN控制器與交換機(jī)之間的主要通信協(xié)議[3]，其規(guī)定了OpenFlow交換機(jī)的基本組件與性能要求，為實(shí)現(xiàn)網(wǎng)絡(luò)設(shè)備的數(shù)據(jù)轉(zhuǎn)發(fā)與路由控制的解耦合提供了一種全新的方法。

文中首先介紹了SDN的發(fā)展現(xiàn)狀以及基于OpenFlow的SDN架構(gòu)實(shí)現(xiàn)方案。在此基礎(chǔ)上，詳細(xì)探討了OpenFlow協(xié)議下的底層網(wǎng)絡(luò)拓?fù)浒l(fā)現(xiàn)機(jī)制和網(wǎng)絡(luò)性能監(jiān)測(cè)機(jī)制，并搭建了實(shí)驗(yàn)平臺(tái)進(jìn)行仿真實(shí)踐。

1 SDN發(fā)展現(xiàn)狀及實(shí)現(xiàn)方案

1.1 SDN與OpenFlow的發(fā)展歷程

SDN的前身來自于斯坦福大學(xué)提出的用于企業(yè)集中安全控制的Ethane[4]架構(gòu)。該架構(gòu)在鏈路層和網(wǎng)絡(luò)層之間定義了一個(gè)保護(hù)層，由一臺(tái)邏輯中央控制器對(duì)網(wǎng)絡(luò)主機(jī)進(jìn)行安全綁定和認(rèn)證。研究人員可以定義基于網(wǎng)絡(luò)流的安全策略，并將這些策略運(yùn)用在各種網(wǎng)絡(luò)設(shè)備上，由控制器對(duì)每個(gè)流檢測(cè)是否違反了相關(guān)的策略，并為每個(gè)流確定路由。

在上述相關(guān)工作基礎(chǔ)上，Nick Mckeown教授等提出了OpenFlow概念。OpenFlow定義了控制器與OpenFlow交換機(jī)之間的通信協(xié)議，允許控制器來決定網(wǎng)絡(luò)數(shù)據(jù)流的路徑，并且能夠?qū)崿F(xiàn)細(xì)粒度的數(shù)據(jù)包優(yōu)先級(jí)劃分和創(chuàng)建端口級(jí)別的流量控制規(guī)則。OpenFlow技術(shù)后經(jīng)由Clean State項(xiàng)目的不斷推廣，以及在GENI計(jì)劃中的應(yīng)用，逐漸發(fā)展為SDN。2011年，Google、Microsoft等企業(yè)聯(lián)合成立了開放網(wǎng)絡(luò)基金會(huì)聯(lián)盟，共同致力于推動(dòng)SDN技術(shù)的發(fā)展，并進(jìn)行相關(guān)標(biāo)準(zhǔn)制定和市場(chǎng)推廣，使其成為全球開放網(wǎng)絡(luò)架構(gòu)與網(wǎng)絡(luò)虛擬化領(lǐng)域的研究熱點(diǎn)。

1.2 基于OpenFlow的實(shí)現(xiàn)方案

基于OpenFlow的SDN架構(gòu)由控制器和OpenFlow交換機(jī)(文中簡(jiǎn)稱為OF交換機(jī))構(gòu)成。OF交換機(jī)的功能包括安全通道、組表、多級(jí)流表和OpenFlow協(xié)議等幾個(gè)部分。

安全通道是連接控制器和OF交換機(jī)的接口，控制器通過該接口對(duì)OF交換機(jī)進(jìn)行管理和控制。安全通道采用TLS(transport layer security)技術(shù)對(duì)控制器和OF交換機(jī)之間的控制和管理信息進(jìn)行加密傳輸。

OF交換機(jī)進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)的依據(jù)是流表，多個(gè)流表串聯(lián)起來形成流水線，流水線對(duì)數(shù)據(jù)包的處理過程如圖1所示。

圖1 多級(jí)流表的數(shù)據(jù)包匹配過程

當(dāng)數(shù)據(jù)包進(jìn)入交換機(jī)后，將從流表1開始匹配。流表中的表項(xiàng)按照優(yōu)先級(jí)的高低依次與數(shù)據(jù)包進(jìn)行匹配，當(dāng)匹配到一條表項(xiàng)時(shí)，會(huì)觸發(fā)該表項(xiàng)指令集的執(zhí)行，這些指令會(huì)進(jìn)行計(jì)數(shù)器的更新、修改數(shù)據(jù)包的動(dòng)作集合等操作。當(dāng)數(shù)據(jù)包跳轉(zhuǎn)到最后一個(gè)流表時(shí)，如果不存在匹配項(xiàng)，則該數(shù)據(jù)包將轉(zhuǎn)發(fā)給控制器，否則，執(zhí)行數(shù)據(jù)包對(duì)應(yīng)的動(dòng)作集合中所有的動(dòng)作指令。

OF交換機(jī)中的組表可以將每個(gè)數(shù)據(jù)流劃分到相應(yīng)的組中，對(duì)屬于同一組標(biāo)識(shí)的所有數(shù)據(jù)包執(zhí)行相同的動(dòng)作集，從而實(shí)現(xiàn)廣播和多播功能。

2 基于OpenFlow的拓?fù)浒l(fā)現(xiàn)機(jī)制

2.1 鏈路層發(fā)現(xiàn)協(xié)議

鏈路層發(fā)現(xiàn)協(xié)議[5](link layer discovery protocol，LLDP)是802.1ab中定義的鏈路層協(xié)議，它的幀格式包括目的MAC地址、源MAC地址、幀類型、鏈路層發(fā)現(xiàn)協(xié)議數(shù)據(jù)單元(link layer discovery protocol data unit，LLDPDU)以及校驗(yàn)位等字段。其中，LLDPDU字段用于承載要發(fā)送的消息，基本的信息單元采用TLV(Type-length-value)形式表示，TLV類型如表1所示。

表1 基本的TLV類型

LLDP將本地設(shè)備的主要功能、設(shè)備編碼、管理地址和接口標(biāo)識(shí)等信息構(gòu)造成TLV封裝在LLDPDU中，周期性地發(fā)送給鄰居設(shè)備，同時(shí)將從鄰居設(shè)備接收的LLDPDU以標(biāo)準(zhǔn)的管理信息庫(kù)(management information base，MIB)形式進(jìn)行存儲(chǔ)。網(wǎng)絡(luò)管理程序可以通過SNMP[6](simple network management protocol)協(xié)議訪問獲取這些信息，從而發(fā)現(xiàn)和模擬網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。

2.2 OF交換機(jī)發(fā)現(xiàn)機(jī)制

OpenFlow協(xié)議允許一臺(tái)交換機(jī)同時(shí)連接多個(gè)控制器，因此，當(dāng)交換機(jī)啟動(dòng)時(shí)會(huì)進(jìn)行主控制器和從屬控制器的IP地址和TCP端口的初始化設(shè)置。文中僅討論單控制器的情形?？刂破骱蚈F交換機(jī)通過建立TLS會(huì)話實(shí)現(xiàn)OpenFlow消息的傳遞，具體的流程描述如下:

步驟1：安全通道的建立。

OF交換機(jī)首先嘗試連接控制器默認(rèn)開啟的TCP 6633端口，并和控制器交換證書進(jìn)行認(rèn)證。當(dāng)認(rèn)證通過后，雙方通過發(fā)送OFPT_HELLO消息確認(rèn)能夠支持的OpenFlow協(xié)議版本進(jìn)而建立安全通道。

步驟2：OF交換機(jī)的發(fā)現(xiàn)。

安全通道成功建立后，控制器將向OF交換機(jī)發(fā)送OFPT_FEATURES_REQUEST消息要求交換機(jī)上報(bào)自己的功能特性。OF交換機(jī)則用OFPT_FEATURES_REPLY消息回復(fù)控制器，消息中包含了交換機(jī)的DPID(DATA path identity)、所支持的流表數(shù)、可用的端口和端口的MAC地址等信息。至此，控制器就可以精確掌握成功連接到網(wǎng)絡(luò)的交換機(jī)信息。

2.3 OpenFlow鏈路發(fā)現(xiàn)機(jī)制

依據(jù)初始化階段獲得的OF交換機(jī)信息，控制器為每個(gè)OF交換機(jī)的所有可用端口發(fā)送一個(gè)OFPT_PACKET_OUT消息。該消息攜帶了一個(gè)LLDP數(shù)據(jù)包，數(shù)據(jù)包由Chassis ID和Port ID構(gòu)成。交換機(jī)收到消息后按照Port ID將消息轉(zhuǎn)發(fā)給相鄰的交換機(jī)，鄰居交換機(jī)將消息中的LLDP數(shù)據(jù)包連同本身的元數(shù)據(jù)一起封裝到OFPT_PACKET_IN消息中發(fā)送給控制器，控制器對(duì)收到的消息進(jìn)行解析，得出交換機(jī)之間的鏈接關(guān)系，同時(shí)進(jìn)行網(wǎng)絡(luò)拓?fù)錉顟B(tài)的更新操作。

假設(shè)網(wǎng)絡(luò)由M個(gè)OF交換機(jī)構(gòu)成，每個(gè)交換機(jī)的可用端口數(shù)為N，交換機(jī)之間的連接數(shù)為H，則控制器需要發(fā)送的OFPT_PACKET_OUT消息數(shù)為：

(1)

控制器完成網(wǎng)絡(luò)中所有OF交換機(jī)之間鏈路發(fā)現(xiàn)過程需要接收的OFPT_PACKET_IN消息數(shù)為：

SUMpacket-in=2H

(2)

圖2 基于LLDP的鏈路發(fā)現(xiàn)過程

圖2為控制器進(jìn)行鏈路發(fā)現(xiàn)的具體過程?？刂破魍ㄟ^OFPT_PACKET_OUT消息向交換機(jī)S1的Port1、Port2和Port3端口各發(fā)送一個(gè)LLDP數(shù)據(jù)包，交換機(jī)S1按照Port ID分別將數(shù)據(jù)包在相應(yīng)的端口轉(zhuǎn)發(fā)給鄰居交換機(jī)。以Port2端口為例，交換機(jī)S1將LLDP數(shù)據(jù)包通過Port2端口轉(zhuǎn)發(fā)給交換機(jī)S2的Port3端口，按照初始的流規(guī)則定義，除去交換機(jī)的Controller端口外的所有端口只要收到LLDP數(shù)據(jù)包都轉(zhuǎn)發(fā)給控制器，因此交換機(jī)S2將收到的LLDP數(shù)據(jù)包連同自己的元數(shù)據(jù)一起封裝到OFPT_PACKET_IN消息并發(fā)送給控制器?？刂破鲗?duì)該消息進(jìn)行解析，得到如下轉(zhuǎn)發(fā)信息：①LLDPDU：{Chassis ID=S1，Port ID=Port2}；②Meta-Data：{Chassis ID=S2，Port ID=Port3}。根據(jù)這些信息，控制器能夠確定交換機(jī)S1和S2之間存在鏈路關(guān)系。

3 基于OpenFlow的網(wǎng)絡(luò)性能監(jiān)測(cè)機(jī)制

3.1 網(wǎng)絡(luò)QoS的主要性能指標(biāo)

網(wǎng)絡(luò)QoS用于為指定的網(wǎng)絡(luò)通信提供更好的服務(wù)能力，它可以用一系列可度量的指標(biāo)來描述。

(1)吞吐量:對(duì)于網(wǎng)絡(luò)、端口或其他設(shè)施，單位時(shí)間內(nèi)成功傳送的數(shù)據(jù)量。

(2)時(shí)延：數(shù)據(jù)包從鏈路的一端傳送到另一端所需要的時(shí)間。

(3)丟包率：在數(shù)據(jù)傳輸過程中，丟失的數(shù)據(jù)包數(shù)與所有傳送數(shù)據(jù)包數(shù)的比率。

3.2 OpenFlow網(wǎng)絡(luò)的性能監(jiān)測(cè)

在OpenFlow網(wǎng)絡(luò)中，控制器定期向OF交換機(jī)發(fā)送OFPT_STATS_REQUEST消息，該消息中的Type字段定義了多種類型的請(qǐng)求信息，包括單流、多流、流表、端口和隊(duì)列等?？刂破魍ㄟ^交換機(jī)回復(fù)的OFPT_STATS_REPLY消息獲取不同類型請(qǐng)求的計(jì)數(shù)信息，根據(jù)這些信息，控制器能夠計(jì)算出吞吐量、時(shí)延和丟包率等性能指標(biāo)。

3.2.1 吞吐量測(cè)量分析

OF交換機(jī)向控制器回復(fù)的單流類型OFPT_STATS_REPLY消息是數(shù)據(jù)流吞吐量測(cè)量的依據(jù)。該消息的結(jié)構(gòu)如下：

struct ofp_flow_stats{

…

uint32_t duration_sec; //數(shù)據(jù)流持續(xù)時(shí)間

uint32_t duration_nsec; //數(shù)據(jù)流額外生存時(shí)間

…

uint64_t packet_count; //已發(fā)送的數(shù)據(jù)包數(shù)

uint64_t byte_count; //已發(fā)送的字節(jié)數(shù)

…

}

控制器在T1時(shí)刻和T2時(shí)刻分別統(tǒng)計(jì)數(shù)據(jù)流發(fā)送的字節(jié)數(shù)和持續(xù)活動(dòng)時(shí)間，通過求得T2-T1時(shí)間間隔內(nèi)的數(shù)據(jù)增量，進(jìn)而計(jì)算出數(shù)據(jù)流的吞吐量值，用公式表達(dá)為：

(3)

3.2.2 鏈路時(shí)延測(cè)量分析

鏈路時(shí)延測(cè)量的過程用圖2加以說明。

(1)控制器到交換機(jī)的時(shí)延。

控制器分別向交換機(jī)S1和S2發(fā)送帶有時(shí)間戳的OFPT_ECHO_REQUEST消息，交換機(jī)S1和S2收到消息后即刻向控制器回復(fù)帶有時(shí)間戳的OFPT_ECHO_REPLY消息，控制器利用前后兩個(gè)時(shí)間戳的差值計(jì)算得到控制器到交換機(jī)S1和S2的往返時(shí)延[7](round-trip time，RTT)，記為RTT1和RTT2。

(2)交換機(jī)間的鏈路時(shí)延。

首先，控制器產(chǎn)生一個(gè)可以識(shí)別的時(shí)延探測(cè)包下發(fā)到交換機(jī)S1，探測(cè)包的數(shù)據(jù)段攜帶著控制器下發(fā)探測(cè)包的時(shí)間戳。交換機(jī)S1將探測(cè)包通過Port2端口轉(zhuǎn)發(fā)給交換機(jī)S2，交換機(jī)S2將探測(cè)包封裝到OFPT_PACKET_IN消息通過Port3端口發(fā)送給控制器?？刂破魇盏较⒑?，對(duì)當(dāng)前時(shí)間與探測(cè)包中的時(shí)間戳求差值，記為Ta。同理，控制器向交換機(jī)S2發(fā)送探測(cè)包，重復(fù)上述過程，所求得的時(shí)間差值記為Tb。由控制器鏈路發(fā)現(xiàn)過程可知，Ta與Tb之和等于RTT1、RTT2、RTTS1-S2三者之和，因此，交換機(jī)S1與S2之間的鏈路單向時(shí)延可表示為：

(4)

3.2.3 丟包率測(cè)量分析

當(dāng)控制器向OF交換機(jī)發(fā)起端口狀態(tài)請(qǐng)求信息時(shí)，OF交換機(jī)回復(fù)的OFPT_STATS_REPLY消息中包含了端口發(fā)送和接收的數(shù)據(jù)包數(shù)、出錯(cuò)的數(shù)據(jù)包數(shù)等信息。端口類型的OFPT_STATS_REPLY消息結(jié)構(gòu)如下：

struct ofp_port_stats{

…

uint64_t rx_packets; //已接收的數(shù)據(jù)包數(shù)

uint64_t tx_packets; //已發(fā)送的數(shù)據(jù)包數(shù)

…

uint64_t rx_dropped; //接收時(shí)丟棄的數(shù)據(jù)包數(shù)

uint64_t tx_dropped; //發(fā)送時(shí)丟棄的數(shù)據(jù)包數(shù)

…

}

根據(jù)這些信息，控制器就能夠計(jì)算出具體的丟包率值，用公式表達(dá)為：

(5)

4 實(shí)驗(yàn)環(huán)境搭建與仿真分析

采用Floodlight[8]和Mininet[9]搭建一個(gè)小型SDN網(wǎng)絡(luò)，便于進(jìn)一步理解控制器和OF交換機(jī)之間的工作機(jī)制。

4.1 仿真拓?fù)?/h3>

Mininet與Linux系統(tǒng)完全兼容，可以快速部署到硬件環(huán)境中，其內(nèi)置的OVS(Open vSwitch)虛擬交換機(jī)能夠模擬出包含多終端和網(wǎng)絡(luò)設(shè)備的復(fù)雜大規(guī)模計(jì)算機(jī)網(wǎng)絡(luò)。在本例中，采用Mininet虛擬一個(gè)包含三個(gè)主機(jī)節(jié)點(diǎn)、一個(gè)OF交換機(jī)和一個(gè)遠(yuǎn)程控制器的拓?fù)浣Y(jié)構(gòu)，如圖3所示。啟動(dòng)網(wǎng)絡(luò)包分析工具Wireshark[10]，能夠看到控制器和交換機(jī)之間定時(shí)發(fā)送的OF_ECHO_REQUEST和OF_ECHO_REPLY消息。在Mininet命令行界面運(yùn)行“pingall”命令，執(zhí)行結(jié)果如下：

h1→h2h3

h2→h1h3

h3→h1h2

由上述結(jié)果可知，在初始階段，主機(jī)間處于相互連通狀態(tài)。

圖3 Mininet創(chuàng)建的拓?fù)浣Y(jié)構(gòu)

Floodlight控制器中的LinkDiscoverManager模塊實(shí)現(xiàn)鏈路發(fā)現(xiàn)功能，該模塊通過向OVS交換機(jī)下發(fā)LLDP數(shù)據(jù)包和BDDP(broadcast domain discovery protocol)數(shù)據(jù)包來獲取網(wǎng)絡(luò)中每條鏈路的信息。TopologyManager模塊監(jiān)聽LinkDiscoverManager模塊的更新信息，如果有鏈路狀態(tài)更新，則采用Dijkstra算法[11]進(jìn)行節(jié)點(diǎn)間的路徑計(jì)算并生成對(duì)應(yīng)的拓?fù)鋵?shí)例。

由于Floodlight控制器中負(fù)責(zé)流表下發(fā)的Forwarding模塊采用了反應(yīng)式流表安裝方法，當(dāng)數(shù)據(jù)包到達(dá)OVS交換機(jī)后，初始狀態(tài)下交換機(jī)內(nèi)沒有任何匹配的流，則Forwarding模塊產(chǎn)生一些臨時(shí)流表指導(dǎo)數(shù)據(jù)包繼續(xù)轉(zhuǎn)發(fā)。因此，當(dāng)執(zhí)行“pingall”命令后，主機(jī)之間依然能夠通信。除了上述反應(yīng)式流表模式，F(xiàn)loodlight控制器還支持靜態(tài)流表寫入方法(static flow pusher)。定義一條測(cè)試流規(guī)則實(shí)現(xiàn)H1到H2之間的鏈路不可達(dá)，流規(guī)則描述如下：

FlowTable(H1- H2)={

"switch":"00:00:00:00:00:00:00:01",

"cookie":"0",

"priority":"2",

"ingress-port":"1",

"active":"true",

"actions":" output=3"

}

通過curl命令將該流規(guī)則安裝到控制器中，并再次運(yùn)行“pingall”命令，測(cè)試結(jié)果如下：

h1→xh3

h2→xh3

h3→h1h2

在Floodlight的UI頁面能夠看到命令執(zhí)行過程中OVS交換機(jī)各端口的流量統(tǒng)計(jì)數(shù)據(jù)，如表2所示。流規(guī)則通過控制器的8080端口所支持的REST[12](representational state transfer)接口下發(fā)到OVS交換機(jī)中，H1到H2之間的鏈路執(zhí)行“數(shù)據(jù)包直接丟棄”策略，因此無法ping通。H1到H3以及H2到H3之間的鏈路執(zhí)行“數(shù)據(jù)包正常轉(zhuǎn)發(fā)”策略，因此鏈路是可達(dá)的。

表2 OVS交換機(jī)不同端口的數(shù)據(jù)統(tǒng)計(jì)

4.2 網(wǎng)絡(luò)性能監(jiān)測(cè)實(shí)驗(yàn)與分析

(1)吞吐量測(cè)量。

采用網(wǎng)絡(luò)性能測(cè)試工具iperf[13]以不同的速率發(fā)送UDP[14](user datagram protocol)數(shù)據(jù)包進(jìn)行測(cè)量。選擇H1到H3之間的鏈路作為測(cè)試路徑，鏈路帶寬設(shè)置為100 M，時(shí)延為10 ms。iperf發(fā)包速率變化范圍設(shè)置為10～80 Mbps，共進(jìn)行8次測(cè)試，每次測(cè)試時(shí)間為60 s。測(cè)試OVS交換機(jī)在不同的負(fù)載流量速率下的吞吐量，測(cè)試結(jié)果如圖4(a)所示。由圖可見，隨著負(fù)載流量的不斷增大，鏈路吞吐量也隨之增大，當(dāng)負(fù)載流量超過40 Mbps時(shí)，吞吐量維持在23 Mbps左右，是因?yàn)镺VS交換機(jī)在進(jìn)行查找流表并轉(zhuǎn)發(fā)UDP數(shù)據(jù)包時(shí)，在交換機(jī)的緩沖隊(duì)列中存在大量的數(shù)據(jù)包導(dǎo)致隊(duì)列溢出而被丟棄。

(2)鏈路時(shí)延測(cè)量。

利用Ping命令測(cè)試不同大小的數(shù)據(jù)包對(duì)鏈路時(shí)延的影響。選擇H2到H3之間的鏈路作為測(cè)試路徑，鏈路帶寬設(shè)置為10 M，數(shù)據(jù)包大小變化范圍設(shè)置為200～1 400 Byte，共進(jìn)行5次測(cè)試，每次測(cè)試發(fā)送數(shù)據(jù)包數(shù)為5個(gè)，取平均時(shí)延值，測(cè)試結(jié)果如圖4(b)所示。

圖4(b)中的時(shí)延離差反映了數(shù)據(jù)包的往返時(shí)延距離平均時(shí)延的偏離程度，該值越大，表明響應(yīng)時(shí)間的變化范圍越大。當(dāng)發(fā)送200 Byte的數(shù)據(jù)包時(shí)，H2首先通過OFPT_PACKET_IN消息向控制器發(fā)送ICMP[15](Internet control message protocol)報(bào)文，控制器收到該報(bào)文后，添加流規(guī)則定義將該報(bào)文轉(zhuǎn)發(fā)到H3。H3收到報(bào)文后，同樣經(jīng)過OFPT_PACKET_IN消息向控制器發(fā)送ECHO回顯應(yīng)答消息，該消息最終被轉(zhuǎn)發(fā)給H2。至此，一個(gè)Ping命令的通信過程結(jié)束。上述過程的執(zhí)行影響了數(shù)據(jù)包的往返時(shí)延，由于交換機(jī)中已存在相應(yīng)的流規(guī)則，因此，后續(xù)發(fā)包的平均時(shí)延顯著減少，趨于平穩(wěn)狀態(tài)。

(3)丟包率測(cè)量。

利用iperf工具傳輸不同長(zhǎng)度的字節(jié)數(shù)進(jìn)行鏈路丟包率的測(cè)量。選擇H1到H2之間的鏈路作為測(cè)試路徑，鏈路帶寬設(shè)置為100 M，時(shí)延為10 ms，發(fā)包速率設(shè)置為20 Mbps。待傳輸?shù)淖止?jié)數(shù)長(zhǎng)度范圍設(shè)置為20～100 MB，共進(jìn)行5次測(cè)試，測(cè)試結(jié)果如圖4(c)所示。由圖4(c)可見，所測(cè)得的丟包率值均在2%以下，說明網(wǎng)絡(luò)處于正常狀態(tài)。當(dāng)傳輸數(shù)據(jù)量為60 MB時(shí)，丟包率陡然上升，表明網(wǎng)絡(luò)擁塞程度增大。當(dāng)傳輸數(shù)據(jù)量為100 MB時(shí)，丟包率達(dá)到峰值，此時(shí)OVS交換機(jī)端口緩沖區(qū)隊(duì)列溢出大量數(shù)據(jù)包被丟棄，在這種過載的狀態(tài)下，網(wǎng)絡(luò)性能出現(xiàn)大幅下降。

(a)不同負(fù)載流量下的UDP吞吐量

(b)不同大小數(shù)據(jù)包的平均時(shí)延

(c)傳輸不同長(zhǎng)度數(shù)據(jù)的丟包率

5 結(jié)束語

SDN是一種數(shù)據(jù)控制分離、具有靈活軟件編程能力的新型網(wǎng)絡(luò)架構(gòu)，它通過提供開放式接口，實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)狀態(tài)的集中控制并根據(jù)業(yè)務(wù)需求進(jìn)行資源的全局調(diào)配和優(yōu)化。文中介紹了SDN的主要實(shí)現(xiàn)方式OpenFlow技術(shù)，詳細(xì)探討了基于OpenFlow協(xié)議的鏈路發(fā)現(xiàn)機(jī)制和網(wǎng)絡(luò)性能監(jiān)測(cè)機(jī)制并搭建了基于Floodlight和Mininet的實(shí)驗(yàn)平臺(tái)進(jìn)行仿真測(cè)試。SDN網(wǎng)絡(luò)的目標(biāo)是服務(wù)于多樣化的業(yè)務(wù)應(yīng)用創(chuàng)新，因此，在下一步的工作中，主要開展SDN應(yīng)用編排與資源管理技術(shù)的研究。