1. OpenFlow信道建立
1.1 OpenFlow消息類型
要了解OpenFlow信道的建立過程，首先需要了解OpenFlow協議目前支持的三種報文類型：
1.Controller to Switch消息)
由Controller發起、Switch接收並處理的消息。這些消息主要用於Controller對Switch進行狀態查詢和修改配置等管理操作，可能不需要交換機響應。
Controller to Switch消息主要包含以下幾種類型：
Features：用於控制器發送請求來了解交換機的性能，交換機必須回應該報文。
Modify-State：用於管理交換機的狀態，如流表項和端口狀態。該命令主要用於增加、刪除、修改OpenFlow交換機內的流表表項，組表表項以及交換機端口的屬性。
Read-State：用於控制器收集交換機各方面的信息，例如當前配置，統計信息等 。
Flow-Mod：Flow-Mod消息用來添加、刪除、修改OpenFlow交換機的流表信息。Flow-Mod消息共有五種類型：ADD、DELETE、DELETE-STRICT、MODIFY、MODIFY-STRICT。
Packet-out：用於通過交換機特定端口發送報文 ，這些報文是通過Packet-in消息接收到的。通常Packet-out消息包含整個之前接收到的Packet-in消息所攜帶的報文或者buffer ID（用於指示存儲在交換機內的特定報文）。這個消息需要包含一個動作列表，當OpenFlow交換機收到該動作列表后會對Packet-out消息所攜帶的報文執行該動作列表。如果動作列表為空，Packet-out消息所攜帶的報文將被OpenFlow交換機丟棄。
Asynchronous-Configuration：控制器使用該報文設定異步消息過濾器來接收其只希望接收到的異步消息報文，或者向OpenFlow交換機查詢該過濾器。該消息通常用於OpenFlow交換機和多個控制器相連的情況。
2.異步（Asynchronous）消息
由Switch發送給Controller，用來通知Switch上發生的某些異步事件的消息，主要包括Packet-in、Flow-Removed、Port-Status和Error等。例如，當某一條規則因為超時而被刪除時，Switch將自動發送一條Flow-Removed消息通知Controller，以方便Controller作出相應的操作，如重新設置相關規則等。
異步消息具體包含以下幾種類型：
Packet-in：轉移報文的控制權到控制器。對於所有通過匹配流表項或者Table Miss后轉發到Controller端口的報文均要通過Packet-in消息送到Controller。也有部分其他流程（如TTL檢查等）也需要通過該消息和Controller交互。Packet-in既可以攜帶整個需要轉移控制權的報文，也可以通過在交換機內部設置報文的Buffer來僅攜帶報文頭以及其Buffer ID傳輸給Controller。Controller在接收到Packet-in消息后會對其接收到的報文或者報文頭和Buffer ID進行處理，並發回Packet-out消息通知OpenFlow交換機如何處理該報文。
Flow-Removed：通知控制器將某個流表項從流表的移除。通常該消息在控制器發送刪除流表項的消息或者流表項的定時器其超時后產生。
Port-Status：通知控制器端口狀態或設置的改變。
3.同步（Symmetric）消息
顧名思義，同步（Symmetric）消息是雙向對稱的消息，主要用來建立連接、檢測對方是否在線等，是控制器和OpenFlow交換機都會在無請求情況下發送的消息，包括Hello、Echo和Experimenter三種消息，這里我們介紹應用最常見的前兩種：
Hello：當連接啟動時交換機和控制器會發送Hello交互。
Echo：用於驗證控制器與交換機之間連接的存活，控制器和OpenFlow交換機都會發送Echo Request/Reply消息。對於接收到的Echo Request消息必須能返回Echo Reply消息。Echo消息也可用於測量控制器與交換機之間鏈路的延遲和帶寬。
1.2 信道建立過程
OpenFlow控制器和OpenFlow交換機之間建立信道連接的基本過程，具體步驟如下：
-
OpenFlow交換機與OpenFlow控制器之間通過TCP三次握手過程建立連接，使用的TCP端口號為6633。
-
TCP連接建立后，交換機和控制器就會互相發送hello報文。Hello報文負責在交換機和控制器之間進行版本協商，該報文中OpenFlow數據頭的類型值為0。
-
功能請求（Feature Request）：控制器發向交換機的一條OpenFlow 消息，目的是為了獲取交換機性能，功能以及一些系統參數。該報文中OpenFlow 數據頭的類型值為5。
-
功能響應（Feature Reply）：由交換機向控制器發送的功能響應（Feature Reply）報文，描述了OpenFlow交換機的詳細細節。控制器獲得交換機功能信息后，OpenFlow協議相關的特定操作就可以開始了。
-
Echo請求（Echo Request）和Echo響應（EchoReply）屬於OpenFlow中的對稱型報文，他們通常用於OpenFlow交換機和OpenFlow 控制器之間的保活。通常echo請求報文中OpenFlow數據頭的類型值為2，echo響應的類型值為3。不同廠商提供的不同實現中，echo請求和響應報文中攜帶的信息也會有所不同。
1.3信道連接斷開模式
當OpenFlow設備與所有Controller斷開連接后，設備進入Fail Open模式。OpenFlow設備存在兩種Fail Open模式：
Fail Secure mode交換機：在該模式下的OpenFlow交換機，流表項繼續生效，直到流表項超時刪除。OpenFlow交換機內的流表表項會正常老化。
Fail Standalone mode交換機：所有報文都會通過保留端口Normal處理。即此時的OpenFlow交換機變成傳統的以太網交換機。Fail Standalone mode只適用於OpenFlow-Hybrid交換機。
安全通道也有兩種模式，不同模式下安全通道重連的機制不同。
並行模式：並行模式下，Switch允許同時與多個Controller建立連接，Switch與每個Controller單獨進行保活和重連，互相之間不影響。當且僅當Switch與所有Controller的連接斷開后，Switch才進入Fail Open狀態。
串行模式：串行模式下，Switch在同一時刻僅允許與一個Controller建立連接。一旦與該Controller連接斷開后，Switch並不會進入Fail Open狀態，而是立即根據Controller的ID順序依次嘗試與Controller連接。如果與所有Controller都無法建立連接，則等待重連時間后，繼續遍歷Controller嘗試建立連接。在三次嘗試后，仍然沒有成功建立連接，則Switch進入Fail Open狀態。
2. OpenFlow消息處理
2.1 OpenFlow流表下發與初始流表
OpenFlow流表下發分為主動和被動兩種機制：
主動模式下，Controller將自己收集的流表信息主動下發給網絡設備，隨后網絡設備可以直接根據流表進行轉發。
被動模式下，網絡設備收到一個報文沒有匹配的FlowTable記錄時，會將該報文轉發給Controller，由后者進行決策該如何轉發，並下發相應的流表。被動模式的好處是網絡設備無需維護全部的流表，只有當實際的流量產生時才向Controller獲取流表記錄並存儲，當老化定時器超時后可以刪除相應的流表，因此可以大大節省交換機芯片空間。
在實際應用中，通常是主動模式與被動模式結合使用。當OpenFlow交換機和Controller建立連接后，Controller需要主動給OpenFlow交換機下發初始流表，否則進入OpenFlow交換機的報文查找不到流表項，就會做丟棄處理。這里的初始流表保證了OpenFlow的未知報文能夠上送控制器。而后續正常業務報文的轉發流表，則在實際流量產生時，由主動下發的初始流表將業務報文的首包上送給控制器后，觸發控制器以被動模式下發。
這里以H3C VCFC控制器給交換機下發的一個初始流表舉例。OpenFlow流表是分級匹配的，通常按0表、1表、2表這樣依次匹配過去，每個級別的表中則由優先級高的表項先進行匹配。
如上圖所示，0表優先級最高為65535的兩條流表匹配到的是端口號為67、68的UDP報文，也就是DHCP報文，匹配動作為goto_table 1，剩下的其他所有報文也命中優先級最低為0的表項后goto_table 1。而在表1中，優先級最低的表項對應的動作為output controller，這保證了虛擬機的DHCP請求可以發送給控制器，由控制器作為網絡中的DHCP Server，避免DHCP請求泛洪，同時還保證了交換機上所有未知的無流表匹配的報文都可以上送控制器，觸發控制器被動下發流表給交換機指導轉發。這里，我們把表1里優先級最低為0，匹配所有未知報文的表項叫做table-miss表項。
在OpenFlow交換機上同樣可以觀察到初始流表，這里以H3C S6800交換機上的一個初始流表舉例。上圖中的這條表項匹配報文類型為以太網報文，UDP端口67、68說明匹配DHCP請求報文，動作為上送控制器：
2.2 OpenFlow報文上送控制器
OpenFlow報文上送控制器詳細過程如下：
1.控制器和交換機建立連接事件是Packet-in事件發生的前提。
2.當OpenFlow交換機收到數據包后，如果明細流表中與數據包沒有任何匹配條目，就會命中table-miss表項，觸發Packet-in事件，交換機會將這個數據包封裝在OpenFlow協議報文中發送至控制器。
3.一旦交換機觸發了Packet-in事件，Packet-in報文就將發送至控制器。
Packet-in數據頭包括了：緩沖ID、數據包長度、輸入端口、Packet-in原因（0: 無匹配；1: 流表中明確提到將數據包發送至控制器）
2.3 控制器回應OpenFlow報文
控制器收到Packet-in消息后，可以發送Flow-Mod消息向交換機寫一個流表項。並且將Flow-Mod消息中的buffer_id字段設置為Packet-in消息中的buffer_id值。從而控制器向交換機寫入了一條與數據包相關的流表項，並且指定該數據包按照此流表項的action列表處理。
Controller根據報文的特征信息（如IP、mac等）下發一條新的流表項到OpenFlow交換機或者做其他處理之后下,發Packet-out消息動作為output到table，具體過程（控制器回應OpenFlow報文過程）如下所示：
1.控制器和交換機之間建立連接事件是Packet-out事件發生的前提；
2.控制器要發送數據包至交換機時，就會觸發Packet-out事件將數據包發送至交換機。這一事件的觸發可以看做是控制器主動通知交換機發送一些數據報文的操作。通常，當控制器想對交換機的某一端口進行操作時，就會使用Packet-out報文。
3.該數據包由控制器發往交換機，內部信息使用Packet-out，並由OpenFlow數據頭封裝。
OpenFlow Packet-out信息包括：緩沖ID、入口端口編號、動作明細（添加為動作描述符）、 輸出動作描述符、VLAN VID動作描述符VLAN PCP動作描述符、 提取VLAN標簽動作描述符、以太網地址動作描述符、IPv4地址動作描述符、IPv4 DSCP動作描述符、TCP/UDP端口動作描述、隊列動作描述符、各廠商動作描述符。
3. OpenFlow交換機轉發
3.1 單播報文轉發流程
當OpenFlow交換機接收到Flow-Mod消息，生成流表后，就可以按照流表轉發接收到的Packet-out報文了，過程舉例如下：
OpenFlow 交換機需要轉發一個從7.7.7.1到9.9.9.1的流量。當流量上送到OpenFlow交換機后，流量的第一個包會先進行Packet-in、Flow-Mod、Packet out的過程，之后同流量的報文就能匹配控制器已經下發的流表進行轉發了。
3.2 組播報文轉發
當終端發出的組播報文到達OpenFlow交換機后，OpenFlow交換機Packet-in給控制器，控制器會為網絡下發指導查詢組表的流表，並進行流表與組表關聯。交換機參考流表，引用組表進行轉發。舉例如下：
組播報文轉發所使用的流表：
上條流表的動作為引用組表4096，組表4096詳細內容如下：
