openflow控制器和交換機之間的消息

openflow控制器和交換機之間的消息

消息格式

openflow消息由64bit，8個字節組成

Openflow協議數據包由Openflow Header和Openflow Message兩部分組成

Openflow頭

全部的open flow消息都是從open flow頭開始，其格式以下

wireshark分析以下

Openflow Message結構與具體消息類型有關：

Openflow消息類型：

安全通道的創建和初始化設置

安全通道創建的步驟

1.由OpenFlow交換機對OpenFlow控制器創建未加密的TCP鏈接或基於
TLS的鏈接
2.肯定安全通道中要使用的OpenFlow版本
3.握手
4.交換其餘必要的設置等（任意）

肯定要使用的openflow版本

創建安全通道後，要肯定經過安全通道進行交換的OpenFlow協議的版本。安全通道創建後的初始動做以下圖

創建安全通道後，爲了肯定將要使用的版本，OpenFlow交換機和OpenFlow控制器都將發送Hello消息。Hello消息僅由OpenFlow頭構成。

發送的Hello消息中攜帶各自支持的最大版本號。安全通道中要使用的版本號就是基於這些信息肯定的。具體而言，就是將採用OpenFlow交換機和OpenFlow控制器所發送的版本號中較小的那一個版本。
對於要使用的OpenFlow版本未取得相一致的意見時，須要發送包含OFPET_HELLO_FAILED的Error 消息

握手

經過交換Hello消息創建安全通道後，執行OpenFlow 控制器和OpenFlow交換機的握手。OpenFlow 控制器經過握手掌握OpenFlow交換機的相關信息後，便可對OpenFlow交換機進行控制。握手以前的步驟皆爲創建安全通道後的初始設置。

OpenFlow 控制器向OpenFlow交換機發送問詢功能的Features請求消息，OpenFlow交換機返回Features響應消息，從而完成握手。與Hello消息相同，Features請求消息也僅由OpenFlow頭構成。

Features響應消息中包含的各字段內容如表2.11所示。從表2.11可知，Features響應消息把與OpenFlow交換機相關的基本信息都提供給了OpenFlow控制器。OpenFlow控制器可獲知OpenFlow交換機支持的行動、傳輸容量以及存在什麼樣的物理端口等信息。

SET_CONFIG、GET_CONFIG

請求消息規範中雖未規定握手後必須這樣作，但OpenFlow控制器有時會向OpenFlow
交換機發送SET_CONFIG消息以發送設置信息，或發送GET_CONFIG請求消息以查詢OpenFlow交換機的設置狀態。

Flow-Mod消息

packet-in

packet-out

port-status

在OpenFlow交換機中添加、刪除或修改物理端口時，須要發送Port-
Status 消息來通知OpenFlow 控制器。
Port-Status消息的結構如圖2.20所示。做爲表示發送該消息理由的reason，定義了OFPPR_ADD（0）、OFPPR_DELETE（1）、OFPPR_MODIFY（2）
這3種數值。ofp phy port結構體與圖2.12所示相同。

Flow-Removed 消息

當OpenFlow交換機中設置的流表項超時時，OpenFlow交換機要向OpenFlow控制器發送Flow-Removed消息。爲確保OpenFlow控制器收到該消息，僅在其發出請求時才發送。

Error 消息

Error 消息的做用是通知出現了某種錯誤。OpenFlow交換機和OpenFlow控制器均可發送Error消息

Barrier消息

在OpenFlow協議中，並不是每個經過安全通道進行交換的消息都須要響應。例如，初始設置後有時會使用的SETCONFIG消息就並不須要響應。所以，使用安全通道發送消息的一方有時並不知道接收信息方處理消息的程度。
爲了解決相似問題，在OpenFlow協議中備有稱爲Barrier消息的機制。Barrier消息的目的是掌握消息的處理程度，雖然很普通，但倒是OpenFlow協議的重要消息機制之一

Echo 消息

OpenFlow 控制器和OpenFlow交換機可經過發送Echo請求消息來確認兩者之間是否鏈接、檢測通訊延遲、測量通訊帶寬等。接收Echo請求消息的一方會向對方返回Echo響應消息（圖2.24）。

相關連接

【OpenFlow 交換機與控制器交互步驟】

Openflow協議詳解