OpenFlow協議1.0及1.3版本分析

OpenFlow是SDN控制器和交換之間交流的協議，在SDN領域有着十分重要的地位。

OpenFlow協議發展到現在已經經過了1.0、1.3、1.4等版本。其中1.0和1.3版本使用的是最為廣泛的。

本篇博文主要分析1.0版本和1.3版本OpenFLow協議在控制器和交換機之間的交互流程。

OpenFlow1.0協議交互

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

OpenFlow協議1.0的交互過程如下：

交互過程：

1. 交換機或控制器首先發送hello報文,確定openflow通信版本。
2. 交換機或控制器收到hello報文之后，回復一個hello報文，協商版本。
3. 控制器發送feature_request報文，查詢交換機具體信息。
4. 交換機收到feature_request報文之后，回復feature_reply，報告自己的詳細信息給控制器。
5. 工作過程中控制器會不斷發送echo_request給交換機，交換機回復echo_reply消息給控制器，確認連接。

OpenFlow協議1.0版本在交換機和控制器信息交互過程中，一共有如下的消息類型：

1.    Enum ofp_type {  
1.    /* Immutable messages. */  
2.    OFPT_HELLO, /* Symmetric message */  
3.    OFPT_ERROR, /* Symmetric message */  
4.    OFPT_ECHO_REQUEST, /* Symmetric message */  
5.    OFPT_ECHO_REPLY, /* Symmetric message */  
6.    OFPT_VENDOR, /* Symmetric message */  

/* Switch configuration messages. */  
7.    OFPT_FEATURES_REQUEST, /* Controller/switch message */
8.    OFPT_FEATURES_REPLY, /* Controller/switch message */  
9.    OFPT_GET_CONFIG_REQUEST, /* Controller/switch message
10. OFPT_GET_CONFIG_REPLY, /* Controller/switch message * 11. OFPT_SET_CONFIG, /* Controller/switch message */  

/* Asynchronous messages. */  
12.    OFPT_PACKET_IN, /* Async message */  
13.    OFPT_FLOW_REMOVED, /* Async message */  
14.    OFPT_PORT_STATUS, /* Async message */  

/* Controller command messages. */  
15.    OFPT_PACKET_OUT, /* Controller/switch message */  
16.    OFPT_FLOW_MOD, /* Controller/switch message */  
17.    OFPT_PORT_MOD, /* Controller/switch message */  

/* Statistics messages. */  
18.    OFPT_STATS_REQUEST, /* Controller/switch message */  
19.    OFPT_STATS_REPLY, /* Controller/switch message */  

/* Barrier messages. */  
20.    OFPT_BARRIER_REQUEST, /* Controller/switch message */
21.    OFPT_BARRIER_REPLY, /* Controller/switch message */  

/* Queue Configuration messages. */  
22.    OFPT_QUEUE_GET_CONFIG_REQUEST, /* Controller/switch m
23.    OFPT_QUEUE_GET_CONFIG_REPLY /* Controller/switch mess
24.    };  

 其中紅色為常用消息，整理如下：

Hello

Feature_request

Feature_reply

Stats_request

Stats_reply

Flow_mod

Set_config

Packet_in

Packet_out

下面分別介紹以上報文信息。

HELLO

hello 是使用來協商控制器和交換機之間openflow協議的版本號的消息。當控制器和交換機都支持openflow1.0時，使用1.0版本進行交流；

如果都支持1.3版本則使用OpenFlow1.3版本進行交流。

0x01代表版本1，即openflow1.0

Type類型為hello，表示為0

FEATURE_REQUEST

feature_request消息是控制器用來查詢交換機特性消息，如交換機ID，緩沖區數量，端口及端口屬性等。該消息只有頭部，沒有消息體。

Type類型為feature_request,標識為5

Type表示為5，代表feature_request消息。

length 代表消息長度，出去消息報頭。

Transation ID  事件ID，用來表示同一個事件。Feature——requesthe feature_reply事件ID相同。

FEATURE_REPLY

交換機收到feature_request消息之后會回復feature_reply消息來報告自己的特性。具體來說，會有交換機自身支持的流表數量，最多能緩存的數據包數量，端口特性等。

交換機報告自身的特性之后，控制器能夠更具這些特性下發指令。

datapath id 數據通道標識符，用來表示交換機的身份。在每一個控制器中獨一無二。

n_buffers 一次最多緩存的數據包數量，即交換機自己的緩存能力。

n_tables 表示交換機支持的流表數量。

capabilities 交換機端口所支持的功能,有流表，端口，STP，隊列，ARP等。

actions 該bitmask表示交換機所支持的actions，有轉發和修改包頭兩種。

port 交換機連接的端口消息。端口MAC地址，鏈路數據等。

 

FLOW_MOD

flow_mod消息是OpenFlow協議的核心消息之一。flow_mod消息的作用是下發流表項。通過Flow-Mod消息可以對流表進行添加、刪除、變更設置等操作。

command 表示flow-mod消息的動作。一共五種，實現對流表的增、刪、改操作。

idle_time  流表匹配數據計時器，如果該時間內流表匹配信息還未到達則刪除流表。

hard_time  流表項老化時間。一項流表在交換機中存在的時間超過該時間則刪除流表項。

priroity  流表項優先級，數字越大越優先。

buffer_id  交換機上保存的，發送至控制器請求處理的流表的編號。

actions  該流表的動作，有轉發，修改兩大類。具體見feature_reply消息中capabilities。

 

SET_CONFIG

set_config消息是控制器對交換機進行配置的消息。控制器可以配置交換機的MTU，報文分片處理等能力。

控制器通過向交換機發送OFPT_SET_CONFIG 和OFPT_GET_CONFIG_REQUEST

消息（該消息僅有頭部）來配置和查詢交換機配置。對於查詢消息，交換機必須回復

OFPT_GET_CONFIG_REPLY 消息。

config flags  標志用來指示該如何處理IP 碎片：正常、丟棄還是重組。

 max byte of packet  類似MTU，交換機一個數據幀能最大的數據存儲量。

 

 PACKET_IN

當交換機遇到不知道如何轉發的報文時，使用packet_in消息將無法處理的報文封裝起來發送給控制器，交給控制器去判斷處理。並且交換機會將該數據包
緩存。

該消息的另一個觸發是當交換機接收到制定報文，該報文的匹配動作就是發送給控制器，這時交換機也會將該報文用packet_in消息封裝，發送給控制器。

控制器收到Packet‐in消息后，可以發送flow‐mod消向交換機寫一個流表項。並且將flow‐mod消息中的buffer_id字段設置為packet‐in消息中的buffer_id值。從而
控制器向交換機寫入了一條與數據包相關的流表項，並且指定該數據包按照此流表項的aciton列表處理。

buffer_id packet-in消息所攜帶的數據包在交換機中的緩存ID。

Total_len  幀的長度。

In_port  數據包進入交換機的入端口號。

Reason  packet-in事件的產生原因,分為兩種：OFPR_NO_MATCH和OFPR_ACTION。

data  需要處理的未知數據包。

 

PACKET_OUT

並不是所有的數據包都需要向交換機中添加一條流表項來匹配處理，網絡中還

存在多種數據包，它出現的數量很少（如ARP、IGMP等），以至於沒有必要通
過流表項來指定這一類數據包的處理方法。
此時，控制器可以使用PacketOut消息，告訴交換機某一個數據包如何處理。

In_port  數據包進入交換機的入端口號。

action_len  動作信息的長度。和flow_mod相同。

 

 STATS_REQUEST

OFPT_STATS_REQUEST && REPLY可以獲得統計信息，可以實現：負載平衡， 流量監控等基於流量的操作。
OFPT_STATS_REQUEST類型有很多，回復的類型也很多。
Type：
        0:請求交換機版本信息，制造商家等信息。
        1:單流請求信息
        2:多流請求信息
        3:流表請求信息
        4:端口信息請求
        5:隊列請求信息

 

 STATS_REPLYstats_reply是對stats_request消息的回復。回復具體內容視查詢內容而定。

Type 該字段決定傳遞的消息類型。類型如下：

OFPST_DESC 整體信息。請求類型提供了制造商、軟件、硬件版本、序列號等整體信息。

OFPST_FLOW 請求類型則可以獲取針對某個流的單獨信息。

OFPST_AGGREGATE 請求類型可以獲取多流信息。

OFPST_TABLE  表統計信息請求，請求信息回復為數組，包括流統計表，動作，時間等。

OFPST_PORT 端口狀態的請求消息類型。

OFPST_QUEUE 隊列消息請求，需要查詢的端口和隊列。端口和對列。

OFPST_VENDOR  生產商信息請求類型。

 

 

OpenFLow協議1.3版本

 

 

OpenFLow協議1.3版本的交互過程如下：

從下圖可以看出，1.3版本比1.0版本常用協議增加了兩個：MULTIPART_REQUEST MULTIPART_REPLY.

 

OpenFlow 1.3協議將‘stats’框架更名為‘multipart’框架，並且將端口描述移植到multipart消息中。

MULTIPART_REQUEST

multipart_request是控制器用來查詢交換機的端口信息的消息。如下圖可見消息體為：OFPMP_PORT_DESC。

 請求的類型和stats類似，一共有五種。具體參見stats類型消息。

 MULTIPART_REPLY

multipart_reply用來回復控制器的查詢，回復的內容交換機端口的性能，特性等。

port  端口信息

state   端口狀態，up或者down

current  方向，數據包方向

supported  支持的操作