##通道 Channel
在前面的OpenFlow的內容中，我們提到了在交換層所采用的流表是控制層的Controller下發的，那么Controller是如何下發流表的呢？中間經過了哪些的流程和步驟？控制器和交換機的會話是如何建立的？ 這就是我們今天要介紹的內容，Channel。
###連接建立
Hello包會定期的交換，其中最核心的就是OpenFlow的版本號。
Hello1：Switch → Controller 你支持版本1.3嗎？ Hello2：Controller → Switch 我支持啊 就像之前的OSPF的Hello報文要交換RID等等的信息一樣，比較好理解。
Feature request：Controller → Switch 你的OF支持哪一些特性？你的接口信息是什么？也就是詢問交換機所能提供的功能。 Feature reply：Switch → Controller 交換機回復一個非常大的包，把它的所有配置信息，所有接口信息都回復給Controller。 Set config：Controller → Switch Controller下發命令，根據交換機提供的信息對交換機進行簡單的設置。
至此，Controller和交換機建立起了一個聯系。
packet in：Switch → Controller 當交換機本地沒有匹配到與流相符合的表項 或者說 沒有FlowTable(默認)的時候，會將數據包丟給Controller。 packet out：Controller → Switch Controller回復指示信息，給Switch處理該數據包提供了方法，或者說選擇的路徑。
port status：Switch → Controller 當交換機的端口狀態發生變化的時候，交換機通知Controller，告訴Controller這個變化，讓Controller刷新路徑信息。
###消息列表
三類消息：
- Controller-to-Switch 消息：有控制器發起，用來管理或者獲取Switch狀態。例子：上面的 Feature Request 和 packet out。
- asynchronous 消息：由 Switch 發起，用來將網絡事件或者交換機狀態變化更新到控制器。例子：上面的 port status。
- symmetric 消息：有 Switch 或者 Controller 發起。
第一類消息顧名思義，是由控制器下發到交換機的，比如下發流表。 而第二類消息可以理解為由 交換機向控制器 發送的消息類型，比如端口狀態辨認等等。asynchronous直譯是 “異步的”。 第三類消息，這類消息是控制器和交換機的 交互，也就是說，既有控制器發送給交換機的消息，也有交換機發送給控制器的消息。symmetric 也就是 “同步的”。典型的第三類消息是Hello報文，你Hello來我Hello過去。
1、Controller‐to‐Switch
控制器至交換機消息此類消息由控制器主動發出
Features 用來獲取交換機特性
Configuration 用來配置Openflow交換機
Modify‐State 用來修改交換機狀態(修改流表)
Read‐Stats 用來讀取交換機狀態
Send‐Packet 用來發送數據包
Barrier 阻塞消息
2、Asynchronous
異步消息此類消息由交換機主動發出
Packet‐in 用來告知控制器交換機接收到數據包
Flow‐Removed 用來告知控制器交換機流表被刪除
Port‐Status 用來告知控制器交換機端口狀態更新
Error 用來告知控制器交換機發生錯誤
3、Symmetric
對稱消息，可以由控制器或交換機主動發起
Hello 用來建立Openflow連接
Echo 用來確認交換機與控制器之間的連接狀態
Vendor 廠商自定義消息
更進一步的細節，可以參考：OpenFlow消息
###協議交互
我們選用的模擬器，首選Mininet，僅使用一條命令 sudo mn 直接就創建了一台控制器，一台交換機，兩台電腦的網絡拓撲。 甚至，我們可以用Mininet的一條指令，創建一個數據中心！It‘s amazing！
視頻教程介紹了傳統網絡協議和OpenFlow交互的一個案例。 使用 sudo mn 建立一個 含有一個Controller，一個Switch，兩個PC的簡單網絡拓撲。
簡單的介紹一下名稱：兩台PC，h1和h2；連接在h1上的接口eth0；連接在h2上的接口eth0；Switch，S1；在S1上和h1連接的接口eth1；在S1上和h2連接的接口eth2；Controller，簡稱C；在S1上和C連接的接口L0.
h1想向h2發送一個數據報文，但是不知道MAC地址；傳統網絡的解決方法是ARP泛洪獲知MAC地址，那么在SDN是如何實現的呢？
(1)h1通過ARP協議，向所有接口泛洪ARP請求：報文通過eth1接口來到了S1。 (2)S1不知道這個報文要發到哪里去，並沒有合適的表項讓它匹配；於是乎，將請求報文轉給了控制器：Packet-in消息。 (3)控制器也不知道這個報文要到哪里去(可能是因為剛剛建立連接，還沒有建立一個合適的網絡拓撲)，於是向交換機S1下發指令，向所有接口(除了eth1)泛洪該數據報：Packet-out消息。 (4)S1向eth2接口發送該ARP請求報文，來到了h2. (5)👌，h2是目的地，它想向目標MAC地址為h1的MAC地址返回一個ARP回復，但是它也不知道h1在哪里，於是也向eth0-eth2這條鏈路泛洪了這個ARP回復。來到了S1。 (6)由於沒有匹配的表項，S1把它交給了控制器：Packet-in。 (7)控制器這個時候大致知道了網絡拓撲的結構，根據這個網絡拓撲結構，計算最優路徑；決定向S1下發流表更新流表項：Modify‐State。 (8)S1拿到了這個更新消息，向h1轉發這個ARP回復，h1就得到了目的的MAC地址，可以開始愉快的通信了~
傳統網絡的做法，中間的交換機是有“學習功能”的；在SDN網絡中，中間的交換機是傻逼，只能通過具有大腦的控制器來指定下發表項，告訴交換機轉發的路徑才OK。
###交換機
純OpenFlow交換機 混合OpenFlow交換機 虛擬OpenFlow交換機(OVS)
2016/9/9