OpenFlow協議分析

學習SDN相關的學習也已經有快半年了，期間從一無所知到懵懵懂懂，再到如今的有所熟悉，經歷了許多，也走了很多彎路，其中，最爲忌諱的即是，我在學習過程當中，還沒有搞明白OpenFlow協議的狀況下，便開始對SDN進行相關操做，今天寫這篇博客，一方面是爲了鞏固我之前所學的東西，另外一方面，從新學習SDN相關的協議，以改正我以前的錯誤認知，固然，因爲仍是初學者，仍會存在一些錯誤的認識，歡迎各位留言指正。

OpenFlow協議的思路，即便網絡設備維護一個FlowTable，而且只經過FlowTable對報文進行處理，FlowTable自己的生成、維護和下發徹底由外置的控制器Controller來實現。

此外，OpenFlow交換機把傳統網絡中，徹底由交換機/路由器控制的報文轉換爲由交換機和控制器來共同完成數據的

轉發操做，從而實現數據的轉發與路由控制的分離。控制器則經過事先規定好的接口操做OpenFlow交換機中的流表，從而達到數據轉發的目的。

OpenFlow控制器與交換機的交互通訊圖

在OpenFlow交換機中，包含安全通道，多級流表和組表。經過安全通道，OpenFlow交換機能夠和控制器創建基於OpenFlow協議的鏈接；而流表則用來匹配OpenFlow交換機收到的報文；組表用來定義流表須要執行的動做。

本文基於mininet和ryu，對OpenFlow協議報文進行分析。

OpenFlow協議主要是經過對不一樣類型消息的處理來實現控制器與交換機之間的路由控制的。目前OpenFlow協議主要支持三種消息類型，分別是controller-to-switch、symmetric(對稱型消息)以及asynchronous(異步消息類型)。每種消息類型分別對應多種事件，如異步消息類型中咱們最多見的PacketIn事件，也是咱們等下所主要闡述的事件。

OpenFlow協議所支持的三種消息類型

經常使用的消息主要是Hello消息、Feature消息，Echo消息，以及Packet_in、Packet_out和Flow_mod等。其中Hello、Feature、Echo消息分別包含REQUEST與REPLY消息，每個消息REQUEST與REPLY的Transaction ID相同，交換機經過ID進行識別對應事件端口。

在一般的交換機事件發生時，主要通過以下幾個交互步驟：

OpenFlow協議下的交換機與控制器交互流程

其中，Hello消息是在OpenFlow初始化中就已經實現，基於ryu的消息獲取，在我目前這個階段還沒有獲知如何截獲。而交換機特徵報文以及PacketIn報文都可獲取。OpenFlow協議的報文通常爲以下格式：

OpenFlow協議基本報文格式

正如圖中看到的，報文分爲協議版本、消息類型、消息包(包括頭部)長度、與包有關的事件ID(回覆配對請求時使用相同的ID)以及所對應消息類型的報文信息。其中，不一樣的消息類型所對應的 報文信息是不一樣的。

爲了更好的說明這一點，本文分別截獲了PacketIn以及switch_features兩種報文格式：

PacketIn報文

switch_features報文

顯然，兩種報文總的來看，形式相同，惟有最後一部分的格式不一樣，這是因爲不一樣事件所致使的。報文的截取，能夠經過在ryu控制器中，輸出經OpenFlow協議描述後的msg消息獲得。

而在總的消息報文中，觸發的不一樣事件，其最後一部分所對應的報文亦是不一樣，以PacketIn報文爲例,它的基本格式爲：

PacketIn報文格式

PacketIn報文包含緩存ID號、控制器的標識符、數據、匹配字段、包被髮送的緣由、被查詢流表的標識符以及幀的全長。不一樣的消息類型的報文，因爲觸發的消息不一樣，所描述的信息不一樣，故致使這部分報文存在差別，這一點經過比較所截獲的兩種報文信息能夠看出。

報文的定義格式能夠在相應的RYU源碼中看到。