目錄
OpenFlow起源與發展
OpenFlow 是 Software Definded Network 的一種，由斯坦福大學的 Nick McKeown 教授在 2008 年 4 月 ACM Communications Review 上發表的一篇論文 OpenFlow: enabling innovation in campus networks 裏首先提出來的。它最初的出發點是用於網絡研究人員實驗其創新網絡架構、協議，考慮到實際的網絡創新思想需要在實際網絡上才能更好地驗證，而研究人員又無法修改在網的網絡設備，故而提出了 OpenFlow 的控制轉發分離架構，將控制邏輯從網絡設備盒子中引出來，研究者可以通過一組定義明確的接口對網絡設備進行任意的編程從而實現新型的網絡協議、拓撲架構而無需改動網絡設備本身。
OpenFlow網絡
所謂OpenFlow網絡指的是相互連接的一組OpenFlow交換機的集合，並且這些交換機全部置於一個OpenFlow Controller或一個OpenFlow Controller的集羣管理之下。
分爲以下三個部分
1、OpenFlow交換機：
主要實現數據層的轉發。下面一節做詳細介紹
2、FlowVisor：
主要作用是對網絡進行虛擬化。FlowVisor是建立在OpenFlow協議上的網絡虛擬化工具。部署在標準OpenFlow控制器與OpenFlow交換機之間，它將物理網絡劃分爲不同的邏輯網絡，使每個控制器控制一個虛網，從而實現虛網劃，並保證各虛網相互隔離分。它讓管理員通過定義流規則來管理網絡，而不是修改路由器和交換機的配置。效果如下圖所示，
FlowVisor的設計原則是：
FlowVisor對控制器和交換機是透明的，它們都感知不到FlowVisor的存在
各虛網之間相互隔離，即使是廣播包，各虛網的流量也相互隔離
劃分虛網的策略是靈活、模塊化、可擴展的
OpenFlow消息在進行傳輸時，FlowVisor會根據配置策略對OpenFlow消息進行攔截、修改、轉發等操作。這樣，控制器就只能控制其被允許控制的流，但是控制器並不知道它所管理的網絡被FlowVisor進行過分片操作。 同樣，交換機發出的消息經過FlowVisor過濾後，也會被髮送到相應的控制器。
3、Controller：
主要是對網絡集中控制OpenFlow將控制層與數據轉發層分離，其中OpenFlow交換機實現了數據轉發功能，而OpenFlow控制器則實現了控制層功能。Controller通過OpenFlow協議提供的標準數據接口，對OpenFlow交換機中的流表進行控制、管理，實現了對整個網絡的集中控制。
在Controller中，可以用python等程序對其功能進行定義，比如下發流表，對Packet_in包進行處理等。
OpenFlow交換機
OpenFlow交換機是OpenFlow網絡得核心部件，主要用於管理數據層得轉發。其結構如上圖方框中所示。
分類
OpenFlow交換機分爲兩類：專用OpenFlow交換機和支持OpenFlow的交換機
- 專用OpenFlow交換機：專門爲OpenFlow設計的交換機。與傳統交換機不同，它不再具有控制邏輯，而僅僅是在端口間轉發數據包的一個簡單部件。
- 支持OpenFlow的交換機：是在傳統商業交換機的基礎上，添加了安全通道、流表、OpenFlow協議，獲得了OpenFlow特性的交換機。它既具有傳統交換機的控制轉發功能，又具有OpenFlow的轉發邏輯。因此該交換機對數據包支持兩種不同的接收處理方式。
整個流程如下：OpenFlow交換機接收到數據包，首先在流表上查找轉發目標端口，如果沒有匹配，將數據包轉發給Controller，由控制層決定轉發端口。
如上圖所示，openflow交換機由以下三個部分組成：
安全通道
安全通道是連接OpenFlow交換機和控制器通信的接口。控制器通過這個接口來控制和管理OpenFlow交換機，同時OpenFlow交換機通過這個接口將事件傳給控制器，發送數據包，並接收來自控制器下發數據包。控制器和交換機必須通過安全通道進行通信，而且進行通信的數據包必須按照OpenFlow協議規定的格式執行。
流表
流表由控制器下發給交換機。下發模式有兩種：主動模式、被動模式。
主動模式——控制器將自己收集的流表信息主動下發給交換機等網絡設備，隨後網絡設備可直接查詢流錶轉發。
被動模式——網絡設備收到一個沒有匹配的FlowTable記錄時，將其封裝成Packet_in數據包，轉發給控制器，由控制器決定如何處理，並下發流表。
由多個流表項組成，每個流表就是一個轉發規則，進入交換機的數據包通過查詢流表來獲得轉發的目的端口。流表項由頭域、計數器和操作組成；其中頭域是個十元組，是流表項的標識；計數器用來計數流表項的統計數據；操作標明瞭與該流表項匹配的數據包應該執行的操作。因此流表是數據轉發的依據，與交換機的mac地址轉發表和IP地址路由表類似，流表中保存了網絡中各個層次的網絡配置信息，因此可以進行更加豐富的轉發規則。
參考文獻2中介紹了一個流表的例子。
OpenFlow協議 ：
OpenFlow協議用來描述控制器和交換機之間交互所用信息的標準，以及控制器和交換機的接口標準。協議的核心部分是用於OpenFlow協議信息結構的集合。OpenFlow協議支持三種信息類型：Controller-to-Switch，Asynchronous和Symmetric，每一個類型都有多個子類型。Controller-to-Switch信息由控制器發起並且直接用於檢測交換機的狀態。Asynchronous信息由交換機發起並通常用於更新控制器的網絡事件和改變交換機的狀態。Symmetric信息可以在沒有請求的情況下由控制器或交換機發起。下面一節將做詳細介紹。
OpenFlow協議
OpenFlow是一種新型的網絡協議，它是控制器和交換機之間的標準協議。自2009年底發佈1.0版本後，OpenFlow協議又經歷了1.1、1.2、1.3及1.4版本的演進過程，目前使用和支持最多的是1.0和1.3版本。OpenFlow1.3在1.0版的基礎上進一步優化及升級，其中添加了很多新的特性及消息，如支持多個流表（flow table）、組表（group table），支持多控制器等。一個流表中包含多個流表項，OpenFlow v1.3中流表項主要由7部分組成，分別是匹配域（用來識別該條表項對應的flow）、優先級（定義流表項的優先順序）、計數器（用於保存與條目相關統計信息），指令（匹配表項後需要對數據分組執行的動作）、Timeouts、Cookie、Flags，如下圖所示。
匹配流程
與OpenFlow v1.0不同的是，OpenFlow v1.3協議中一臺OpenFlowF交換機會有多張流表。具體匹配流程如下圖所示。
當 一 個 數據包到達交換機 ， 從數據包中提取匹配字段從第 一 個流表 開始 查找 匹配 ， 匹配字段 取 決於數據 包 的類 型 ， 通常 包括各種 數 據包 的 頭字段 ， 例如 以 太 網 源地 址或 ＩＰｖ４ 目 的地 地址 等 ， 此 外 ， 還可 以 對 數據 包 關 聯的 字段 （ 如 交換 機 １ ４ 的入端 口 等 ） 進行 匹配 。 如果 數據包和流表項匹配成功 ， 則 更 新計數器並執 行流 表項 中 的 指令。 如果該流表 項使用GOTO 指令指 向 了 某一 其他流表 ， 則執行完本次指令的數據包以及動作集、元數據等信息轉到ＧＯＴＯ 指令指 向 的 流表進行 下 一 步 的 匹 配（也就是圖中的 跳轉到Table n？）； 若 未指 向 另 一 流表則執行動作集 ， 此時流水線處理成功。 如果在 某 個流表 中 並 未 匹配成 功 ， 則 查找該 流表中 是否存在 table-miss流表項 （ 流 表 中 的table-miss流表項 指定如 何 處理未 匹 配成功 的 數據包 ） ， 如 果存在table-miss流 表 項 ， 則 按該流表項中 的 指令執行 ， 如丟棄 數據包 、 將數據包 轉到 另 外 一 個 流表 或者發送給控制器（即通過Packet_In消息傳遞給控制器，由控制器制定數據包的轉發策略而後通過Packet_Out消息下發流表給交換機） 等； 如果在 流表 中 並未 匹配成 功並且該流表項 中 不存在table-miss流 表項， 那麼 交換機將會丟棄該 數據 包。
Ｏｐｅ ｎＦｌｏ ｗ 協議在工作 中 使用 ＧＯＴＯ 指令從一 張流錶轉 到另 一 張流表 ， 該技 術被稱 爲 多級 流表技術 。
消息類型
OpenFlow規範定義了一個OpenFlow交換機如何與Controller建立連接、通信及相關消息類型
a） Controller/Switch消息，是指由Controller發起、Switch接收並處理的消息，主要包括Features、Configuration、Modify-State、Read-State、Packet-out、Barrier和Role-Request等消息。這些消息主要由Controller用來對Switch進行狀態查詢和修改配置等操作。
b） 異步（Asynchronous）消息，是由Switch發送給Controller、用來通知Switch上發生的某些異步事件的消息，主要包括Packet-in、Flow-Removed、Port-status和Error等。例如，當某一條規則因爲超時而被刪除時，Switch將自動發送一條Flow-Removed消息通知Controller，以方便Controller作出相應的操作，如重新設置相關規則等。
c） 對稱（Symmetric）消息，顧名思義，這些都是雙向對稱的消息，主要用來建立連接、檢測對方是否在線等，包括Hello、Echo和Experimenter三種消息。
下圖展示了OpenFlow和Switch之間一次典型的消息交換過程，出於安全和高可用性等方面的考慮，OpenFlow的規範還規定了如何爲Controller和Switch之間的信道加密、如何建立多連接等（主連接和輔助連接）。
OpenFlow應用
隨着OpenFlow/SDN概念的發展和推廣，其研究和應用領域也得到了不斷拓展。目前，關於OpenFlow/SDN的研究領域主要包括網絡虛擬化、安全和訪問控制、負載均衡、聚合網絡和綠色節能等方面。另外，還有關於OpenFlow和傳統網絡設備交互和整合等方面的研究。
下面將舉幾個典型的研究案例來展示OpenFlow的應用。
網絡虛擬化 – FlowVisor
網絡虛擬化的本質是要能夠抽象底層網絡的物理拓撲，能夠在邏輯上對網絡資源進行分片或者整合，從而滿足各種應用對於網絡的不同需求。爲了達到網絡分片的目的，FlowVisor實現了一種特殊的OpenFlow Controller，可以看作其他不同用戶或應用的Controllers與網絡設備之間的一層代理。因此，不同用戶或應用可以使用自己的Controllers來定義不同的網絡拓撲，同時FlowVisor又可以保證這些Controllers之間能夠互相隔離而互不影響。下圖展示了使用FlowVisor可以在同一個物理網絡上定義出不同的邏輯拓撲。FlowVisor不僅是一個典型的OpenFlow應用案例，同時還是一個很好的研究平臺，目前已經有很多研究和應用都是基於FlowVisor做的。
負載均衡 – Aster*x
傳統的負載均衡方案一般需要在服務器集羣的入口處，通過一個gateway或者router來監測、統計服務器工作負載，並據此動態分配用戶請求到負載相對較輕的服務器上。既然網絡中所有的網絡設備都可以通過OpenFlow進行集中式的控制和管理，同時應用服務器的負載可以及時地反饋到OpenFlowController那裏，那麼OpenFlow就非常適合做負載均衡的工作。Aster*x通過Host Manager和Net Manager來分別監測服務器和網絡的工作負載，然後將這些信息反饋給FlowManager，這樣Flow Manager就可以根據這些實時的負載信息，重新定義網絡設備上的OpenFlow規則，從而將用戶請求（即網絡包）按照服務器的能力進行調整和分發。
綠色節能的網絡服務 – ElasticTree
在數據中心和雲計算環境中，如何降低運營成本是一個重要的研究課題。能夠根據工作負荷按需分配、動態規劃資源，不僅可以提高資源的利用率，還可以達到節能環保的目的。ElasticTree創新性地使用OpenFlow，在不影響性能的前提下，根據網絡負載動態規劃路由，從而可以在網絡負載不高的情況下選擇性地關閉或者掛起部分網絡設備，使其進入節電模式達到節能環保、降低運營成本的目的。
參考文獻：
https://blog.csdn.net/Sponge_bobo_herbert/article/details/80535869
https://www.ibm.com/developerworks/cn/cloud/library/1303_silei_openflow/