基于OpenFlow的SDN架構研究與實踐

于天放，芮蘭蘭

(北京郵電大學 網絡與交換技術國家重點實驗室，北京 100876)

0 引 言

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

文中首先介紹了SDN的發展現狀以及基于OpenFlow的SDN架構實現方案。在此基礎上，詳細探討了OpenFlow協議下的底層網絡拓撲發現機制和網絡性能監測機制，并搭建了實驗平臺進行仿真實踐。

1 SDN發展現狀及實現方案

1.1 SDN與OpenFlow的發展歷程

SDN的前身來自于斯坦福大學提出的用于企業集中安全控制的Ethane[4]架構。該架構在鏈路層和網絡層之間定義了一個保護層，由一臺邏輯中央控制器對網絡主機進行安全綁定和認證。研究人員可以定義基于網絡流的安全策略，并將這些策略運用在各種網絡設備上，由控制器對每個流檢測是否違反了相關的策略，并為每個流確定路由。

在上述相關工作基礎上，Nick Mckeown教授等提出了OpenFlow概念。OpenFlow定義了控制器與OpenFlow交換機之間的通信協議，允許控制器來決定網絡數據流的路徑，并且能夠實現細粒度的數據包優先級劃分和創建端口級別的流量控制規則。OpenFlow技術后經由Clean State項目的不斷推廣，以及在GENI計劃中的應用，逐漸發展為SDN。2011年，Google、Microsoft等企業聯合成立了開放網絡基金會聯盟，共同致力于推動SDN技術的發展，并進行相關標準制定和市場推廣，使其成為全球開放網絡架構與網絡虛擬化領域的研究熱點。

1.2 基于OpenFlow的實現方案

基于OpenFlow的SDN架構由控制器和OpenFlow交換機(文中簡稱為OF交換機)構成。OF交換機的功能包括安全通道、組表、多級流表和OpenFlow協議等幾個部分。

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

OF交換機進行數據轉發的依據是流表，多個流表串聯起來形成流水線，流水線對數據包的處理過程如圖1所示。

圖1 多級流表的數據包匹配過程

當數據包進入交換機后，將從流表1開始匹配。流表中的表項按照優先級的高低依次與數據包進行匹配，當匹配到一條表項時，會觸發該表項指令集的執行，這些指令會進行計數器的更新、修改數據包的動作集合等操作。當數據包跳轉到最后一個流表時，如果不存在匹配項，則該數據包將轉發給控制器，否則，執行數據包對應的動作集合中所有的動作指令。

OF交換機中的組表可以將每個數據流劃分到相應的組中，對屬于同一組標識的所有數據包執行相同的動作集，從而實現廣播和多播功能。

2 基于OpenFlow的拓撲發現機制

2.1 鏈路層發現協議

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

表1 基本的TLV類型

LLDP將本地設備的主要功能、設備編碼、管理地址和接口標識等信息構造成TLV封裝在LLDPDU中，周期性地發送給鄰居設備，同時將從鄰居設備接收的LLDPDU以標準的管理信息庫(management information base，MIB)形式進行存儲。網絡管理程序可以通過SNMP[6](simple network management protocol)協議訪問獲取這些信息，從而發現和模擬網絡拓撲結構。

2.2 OF交換機發現機制

OpenFlow協議允許一臺交換機同時連接多個控制器，因此，當交換機啟動時會進行主控制器和從屬控制器的IP地址和TCP端口的初始化設置。文中僅討論單控制器的情形。控制器和OF交換機通過建立TLS會話實現OpenFlow消息的傳遞，具體的流程描述如下:

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

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

步驟2：OF交換機的發現。

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

2.3 OpenFlow鏈路發現機制

依據初始化階段獲得的OF交換機信息，控制器為每個OF交換機的所有可用端口發送一個OFPT_PACKET_OUT消息。該消息攜帶了一個LLDP數據包，數據包由Chassis ID和Port ID構成。交換機收到消息后按照Port ID將消息轉發給相鄰的交換機，鄰居交換機將消息中的LLDP數據包連同本身的元數據一起封裝到OFPT_PACKET_IN消息中發送給控制器，控制器對收到的消息進行解析，得出交換機之間的鏈接關系，同時進行網絡拓撲狀態的更新操作。

假設網絡由M個OF交換機構成，每個交換機的可用端口數為N，交換機之間的連接數為H，則控制器需要發送的OFPT_PACKET_OUT消息數為：

(1)

控制器完成網絡中所有OF交換機之間鏈路發現過程需要接收的OFPT_PACKET_IN消息數為：

SUMpacket-in=2H

(2)

圖2 基于LLDP的鏈路發現過程

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

3 基于OpenFlow的網絡性能監測機制

3.1 網絡QoS的主要性能指標

網絡QoS用于為指定的網絡通信提供更好的服務能力，它可以用一系列可度量的指標來描述。

(1)吞吐量:對于網絡、端口或其他設施，單位時間內成功傳送的數據量。

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

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

3.2 OpenFlow網絡的性能監測

在OpenFlow網絡中，控制器定期向OF交換機發送OFPT_STATS_REQUEST消息，該消息中的Type字段定義了多種類型的請求信息，包括單流、多流、流表、端口和隊列等。控制器通過交換機回復的OFPT_STATS_REPLY消息獲取不同類型請求的計數信息，根據這些信息，控制器能夠計算出吞吐量、時延和丟包率等性能指標。

3.2.1 吞吐量測量分析

OF交換機向控制器回復的單流類型OFPT_STATS_REPLY消息是數據流吞吐量測量的依據。該消息的結構如下：

struct ofp_flow_stats{

…

uint32_t duration_sec; //數據流持續時間

uint32_t duration_nsec; //數據流額外生存時間

…

uint64_t packet_count; //已發送的數據包數

uint64_t byte_count; //已發送的字節數

…

}

控制器在T1時刻和T2時刻分別統計數據流發送的字節數和持續活動時間，通過求得T2-T1時間間隔內的數據增量，進而計算出數據流的吞吐量值，用公式表達為：

(3)

3.2.2 鏈路時延測量分析

鏈路時延測量的過程用圖2加以說明。

(1)控制器到交換機的時延。

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

(2)交換機間的鏈路時延。

首先，控制器產生一個可以識別的時延探測包下發到交換機S1，探測包的數據段攜帶著控制器下發探測包的時間戳。交換機S1將探測包通過Port2端口轉發給交換機S2，交換機S2將探測包封裝到OFPT_PACKET_IN消息通過Port3端口發送給控制器。控制器收到消息后，對當前時間與探測包中的時間戳求差值，記為Ta。同理，控制器向交換機S2發送探測包，重復上述過程，所求得的時間差值記為Tb。由控制器鏈路發現過程可知，Ta與Tb之和等于RTT1、RTT2、RTTS1-S2三者之和，因此，交換機S1與S2之間的鏈路單向時延可表示為：

(4)

3.2.3 丟包率測量分析

當控制器向OF交換機發起端口狀態請求信息時，OF交換機回復的OFPT_STATS_REPLY消息中包含了端口發送和接收的數據包數、出錯的數據包數等信息。端口類型的OFPT_STATS_REPLY消息結構如下：

struct ofp_port_stats{

…

uint64_t rx_packets; //已接收的數據包數

uint64_t tx_packets; //已發送的數據包數

…

uint64_t rx_dropped; //接收時丟棄的數據包數

uint64_t tx_dropped; //發送時丟棄的數據包數

…

}

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

(5)

4 實驗環境搭建與仿真分析

采用Floodlight[8]和Mininet[9]搭建一個小型SDN網絡，便于進一步理解控制器和OF交換機之間的工作機制。

4.1 仿真拓撲

Mininet與Linux系統完全兼容，可以快速部署到硬件環境中，其內置的OVS(Open vSwitch)虛擬交換機能夠模擬出包含多終端和網絡設備的復雜大規模計算機網絡。在本例中，采用Mininet虛擬一個包含三個主機節點、一個OF交換機和一個遠程控制器的拓撲結構，如圖3所示。啟動網絡包分析工具Wireshark[10]，能夠看到控制器和交換機之間定時發送的OF_ECHO_REQUEST和OF_ECHO_REPLY消息。在Mininet命令行界面運行“pingall”命令，執行結果如下：

h1→h2h3

h2→h1h3

h3→h1h2

由上述結果可知，在初始階段，主機間處于相互連通狀態。

圖3 Mininet創建的拓撲結構

Floodlight控制器中的LinkDiscoverManager模塊實現鏈路發現功能，該模塊通過向OVS交換機下發LLDP數據包和BDDP(broadcast domain discovery protocol)數據包來獲取網絡中每條鏈路的信息。TopologyManager模塊監聽LinkDiscoverManager模塊的更新信息，如果有鏈路狀態更新，則采用Dijkstra算法[11]進行節點間的路徑計算并生成對應的拓撲實例。

由于Floodlight控制器中負責流表下發的Forwarding模塊采用了反應式流表安裝方法，當數據包到達OVS交換機后，初始狀態下交換機內沒有任何匹配的流，則Forwarding模塊產生一些臨時流表指導數據包繼續轉發。因此，當執行“pingall”命令后，主機之間依然能夠通信。除了上述反應式流表模式，Floodlight控制器還支持靜態流表寫入方法(static flow pusher)。定義一條測試流規則實現H1到H2之間的鏈路不可達，流規則描述如下：

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命令將該流規則安裝到控制器中，并再次運行“pingall”命令，測試結果如下：

h1→xh3

h2→xh3

h3→h1h2

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

表2 OVS交換機不同端口的數據統計

4.2 網絡性能監測實驗與分析

(1)吞吐量測量。

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

(2)鏈路時延測量。

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

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

(3)丟包率測量。

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

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

(b)不同大小數據包的平均時延

(c)傳輸不同長度數據的丟包率

5 結束語

SDN是一種數據控制分離、具有靈活軟件編程能力的新型網絡架構，它通過提供開放式接口，實現對網絡狀態的集中控制并根據業務需求進行資源的全局調配和優化。文中介紹了SDN的主要實現方式OpenFlow技術，詳細探討了基于OpenFlow協議的鏈路發現機制和網絡性能監測機制并搭建了基于Floodlight和Mininet的實驗平臺進行仿真測試。SDN網絡的目標是服務于多樣化的業務應用創新，因此，在下一步的工作中，主要開展SDN應用編排與資源管理技術的研究。