1. 概述
OpenFlow是由斯坦福大學的Nick McKeown教授在2008年4月ACM Communications Review上發表的一篇論文OpenFlow: enabling innovation in campus networks首先詳細論述了OpenFlow的原理。由該論文課題可知OpenFlow提出的最初出發點是用於校園內網絡研究人員實驗其創新網絡架構、協議，考慮到實際的網絡創新思想需要在實際網絡上才能更好地驗證，而研究人員又無法修改在網的網絡設備，故而提出了OpenFlow的控制轉發分離架構，將控制邏輯從網絡設備盒子中引出來，研究者可以對其進行任意的編程從而實現新型的網絡協議、拓撲架構而無需改動網絡設備本身。該想法首先在美國的GENI研究項目中得到應用，實現了一個從主機到網絡的端到端創新實驗平台。OpenFlow的架構見下圖：
圖1 OpenFlow概念架構
OpenFlow的思路很簡單，網絡設備（OpenFlow交換機）維護一個FlowTable並且只按照FlowTable進行轉發，Flowtable本身的生成、維護、下發完全由外置的Controller來實現，注意這里的FlowTable並非是指IP五元組，事實上OpenFlow 1.0定義了包括端口號、VLAN、L2/L3/L4信息的12個關鍵字，但是每個字段都是可以通配的，網絡的運營商可以決定使用何種粒度的流，比如運營商只需要根據目的IP進行路由，那么流表中就可以只有目的IP字段是有效的，其它全為通配。
這種控制和轉發分離的架構對於L2交換設備而言，意味着MAC地址的學習由Controller來實現，V-LAN和基本的L3路由配置也由Controller下發給交換機。對於L3設備，各類IGP/EGP路由運行在Controller之上，Controller根據需要下發給相應的路由器。流表的下發可以是主動的，也可以是被動的，主動模式下，Controller將自己收集的流表信息主動下發給網絡設備，隨后網絡設備可以直接根據流表進行轉發；被動模式是指網絡設備收到一個報文沒有匹配的FlowTable記錄時，將該報文轉發給Controller，由后者進行決策該如何轉發，並下發相應的流表。被動模式的好處是網絡設備無需維護全部的流表，只有當實際的流量產生時才向Controller獲取流表記錄並存儲，當老化定時器超時后可以刪除相應的流表，故可以大大節省TCAM空間。
2. 縮寫和術語
GRE (Generic Routing Encapsulation):通用路由封裝
L2overgre(layer 2 Generic Routing Encapsulation):二層報文路由封裝
OpenFlow控制端：OpenFlow實現了數據層和控制層的分離，其中OpenFlow交換機進行數據層的轉發，而Controller實現了控制層的功能。Controller通過OpenFlow協議這個標准接口對OpenFlow交換機中的流表進行控制，從而實現對整個網絡進行集中控制。
OpenFlow交換機：OpenFlow交換機是整個OpenFlow網絡的核心部件，主要管理數據層的轉發。OpenFlow交換機接收到數據包后，首先在本地的流表上查找轉發目標端口，如果沒有匹配，則把數據包轉發給Controller，由控制層決定轉發端口。
OpenFlow協議：OpenFlow協議用來描述控制器和交換機之間交互所用信息的標准，以及控制器和交換機的接口標准。
Diffserve（Differentiated Service）：差分服務。
3. 技術介紹
3.1 OpenFlow交換機架構
OpenFlow交換機是整個OpenFlow網絡的核心部件，主要管理數據層的轉發。OpenFlow交換機接收到數據包后，首先在本地的流表上查找轉發目標端口，如果沒有匹配，則把數據包轉發給Controller，由控制層決定轉發端口。
OpenFlow交換機由流表、安全通道和OpenFlow協議三部分組成。
圖2 OpenFlow交換機的構成和分類
流表由很多個流表項組成，每個流表項就是一個轉發規則。進入交換機的數據包通過查詢流表來獲得轉發的目的端口。流表項由頭域、計數器和操作組成；其中頭域是個十二元組，是流表項的標識；計數器用來計數流表項的統計數據；操作標明了與該流表項匹配的數據包應該執行的操作。
OpenFlow協議用來描述控制器和交換機之間交互所用信息的標准，以及控制器和交換機的接口標准。協議的核心部分是用於OpenFlow協議信息結構的集合。OpenFlow協議支持三種信息類型：Controller-to-Switch，Asynchronous和Symmetric，每一個類型都有多個子類型。Controller-to-Switch信息由控制器發起並且直接用於檢測交換機的狀態。Asynchronous信息由交換機發起並通常用於更新控制器的網絡事件和改變交換機的狀態。Symmetric信息可以在沒有請求的情況下由控制器或交換機發起。
按照對OpenFlow的支持程度，OpenFlow交換機可以分為兩類：專用的OpenFlow交換機和支持OpenFlow的交換機。專用的OpenFlow交換機是專門為支持OpenFlow而設計的。它不支持現有的商用交換。機上的正常處理流程，所有經過該交換機的數據都按照OpenFlow的模式進行轉發。專用的OpenFlow交換機中不再具有控制邏輯，因此專用的OpenFlow交換機是用來在端口間轉發數據包的一個簡單的路徑部件。支持OpenFlow的交換機是在商業交換機的基礎上添加流表、安全通道和OpenFlow協議來獲得了OpenFlow特性的交換機。其既具有常用的商業交換機的轉發模塊，又具有OpenFlow的轉發邏輯，因此支持OpenFlow的交換機可以采用兩種不同的方式處理接收到的數據包。
3.2 OpenFlow連接維護
支持照協議規范定義的HELLO、ECHO_REQUEST、ECHO_REPLY消息, 維護交換機與OpenFlow控制端之間的連接。
3.3 OpenFlow控制vlan
（1）由於DCN目前實現支持OpenFlow的交換機，所以提供命令配置OpenFlow控制的VLAN，這樣OpenFlow下發的規則等只會在OpenFlow控制的VLAN內生效，不會影響其他VLAN的流量。
（2）與OpenFlow控制器連接的交換機端口不包含在啟用OpenFlow的VLAN中，由用戶自行控制。
3.4 規則處理
受交換機硬件芯片的限制，交換機不能通過硬件實現OpenFlow協議定義的所有action，為此引入了多業務卡，通過軟件實現硬件不能支持的這部分action。當OpenFlow控制端下發一個規則的時候，交換機上的OpenFlow任務把規則下發到主控卡和多業務卡兩個地方，其中多業務卡由於支持所有的action，所以上面下發了所有規則；主控卡由於只支持部分action，所以可以成功下發部分規則，其他規則下發到主控硬件上時都把動作改為轉發到多業務卡，由多業務卡對匹配規則的報文進行處理。
3.4.1 規則匹配字段
（1） 支持二層字段的匹配, 包括入端口、源MAC、目的MAC、以太網協議類型、VLAN_ID、VLAN PRIORITY六個基本字段和源MAC掩碼、目的MAC掩碼兩個擴展字段,共8個字段。
（2） 支持三層字段的匹配, 包括源IP地址、目的IP地址、源端口、目的端口、傳輸層協議號、TOS六個基本字段和源IP地址掩碼、目的IP地址掩碼兩個擴展字段, 共8個字段。
3.4.2 規則動作
（1） 支持向指定端口發包動作。
（2） 支持向啟用OpenFlow的VLAN所有端口發包, 協議中定義為ALL和FLOOD動作。
（3）支持向OpenFlow控制器發包，如果報文原來沒有Vlan Tag，則發給控制器的包也不帶Vlan Tag， 協議中定義為CONTROLLER動作。
（4）支持向入端口發包， 協議中定義為IN_PORT動作。
（5）支持丟棄報文的動作。協議中定義為DROP動作。
（6）支持數據包入隊列動作。 協議中定義為QUEUE動作。
（7）支持修改報文字段動作。.
3.4.3 規則維護
（1）OpenFlow規則的增加, 支持OFPFF_CHECK_OVERLAP標志，在加入規則時檢查是否存在沖突。如果增加操作不設置OFPFF_CHECK_OVERLAP標志，規則匹配后的行為由OpenFlow控制器負責。
（2）支持規則的刪除, 包括帶_STRICT后綴及不帶后綴兩個類型.
3.4.4 規則老化
（1）提供規則的定期老化, 用戶可以通過設置hard-timeout時間, 讓規則在hard-timeout時間到的時候老化刪除.
（2） 提供規則的不活躍老化, 用戶可以通過設置idle-timeout時間, 如果規則在idle-timeout時間內沒有匹配報文, 則老化刪除.
3.5 報文轉發
主控收到一個報文，首先進行規則匹配，如果匹配上規則，並且actions是主控支持的，則在主控進行處理，否則，主控上雖然有規則，但是action是送往多業務卡處理，則把報文轉發到多業務卡上，報文到多業務卡上重新進行規則匹配，找到對應的處理action，進行處理。如果報文在主控上沒有找到匹配的規則，則把報文送往OpenFlow控制端，由控制端決定報文的處理行為。
3.6 二層GRE隧道（l2overgre）
用戶可以通過配置和規則下發，實現對二層報文的GRE隧道功能，包括對二層報文的l2overgre封裝和l2overgre報文的解封裝。這里注意隧道配置的源IP地址必須是交換機上一個有效的IP地址，並且該地址所在的VLAN必須是OpenFlow未控制的VLAN。
用戶配置完隧道后，交換機根據源IP、目的IP生成L2overGRE隧道虛端口，並為該虛端口生成對應的index，name（由l2GreTunnel + index組成），創建並注冊成功后，把端口以HybridTag的方式加入VLAN ID指定的VLAN，該vlan應與OpenFlow控制的vlan需要一致，用戶配置時需要注意。當成功配置后，OpenFlow交換機會構建OFPT_CSTNET_GRE_TUNNEL_REPLY消息發送給控制端，該消息包含隧道配置的源IP地址、目的IP地址、VLAN ID以及隧道虛端口對應的index值，控制端可以根據這些信息來識別對應的隧道並保留該index值。配置成功后，控制端即可下發相應規則，對符合規則的報文進行隧道，比如用戶通過指定報文的出端口為隧道口對應的index即可對報文進行隧道。
3.7 QoS
1) 支持隊列的方式, 通過控制隊列所占帶寬配置及WRR隊列調度算法提供服務質量保證。
2) 支持差分服務的方式提供服務質量保證。
3.8 交換機信息收集
3.8.1 端口信息
1）提供端口基本信息，包括端口索引值（index），端口的MAC地址，端口的名稱。
2）提供端口配置信息，不包括STP的配置。
3）提供端口狀態信息和特征信息。
4）提供擴展端口信息，如果端口是L2OverGRE隧道端口, 提供隧道的源、目的IP地址。
5) 在收到控制端發送OFPT_FEATURES_REQUEST請求消息, 或者端口up/down、端口速率發生變化時通知OpenFlow 控制端端口信息.
3.8.2 統計信息
1) 提供單個flow信息統計， 提供符合OpenFlow控制端請求的流的匹配字段，action老化時間， 優先級， 匹配報文字節數等信息。
2) 提供流聚合統計信息，提供符合匹配規則的所有流的個數, 以及總的匹配報文個數。
3) 提供端口收發包相關統計。
4) 提供隊列收發包相關統計。
4. 主要特性
該功能主要的特性為：
該功能實現了OpenFlow1.0協議，並擴展實現了l2overgre和QoS的功能，能夠滿足用戶的需求。
5. 技術特色與優勢
在OpenFlow1.0協議定義的基礎上，擴展實現了l2overgre和QoS的功能，這些是DCN獨有的。