OpenFlow相關的歷史、新聞：http://blog.csdn.net/jincm13/article/details/7825754
起源與發展【https://36kr.com/p/5035985】
OpenFlow起源於斯坦福大學的Clean Slate項目組 [1] 。CleanSlate項目的最終目的是要重新發明英特網，旨在改變設計已略顯不合時宜，且難以進化發展的現有網絡基礎架構。在2006年，斯坦福的學生Martin Casado領導了一個關於網絡安全與管理的項目Ethane[2]，該項目試圖通過一個集中式的控制器，讓網絡管理員可以方便地定義基於網絡流的安全控制策略，並將這些安全策略應用到各種網絡設備中，從而實現對整個網絡通訊的安全控制。受此項目（及Ethane的前續項目Sane[3]）啟發，Martin和他的導師Nick McKeown教授（時任Clean Slate項目的Faculty Director）發現，如果將Ethane的設計更一般化，將傳統網絡設備的數據轉發（data plane）和路由控制（control plane）兩個功能模塊相分離，通過集中式的控制器（Controller）以標准化的接口對各種網絡設備進行管理和配置，那么這將為網絡資源的設計、管理和使用提供更多的可能性，從而更容易推動網絡的革新與發展。於是，他們便提出了OpenFlow的概念，並且Nick McKeown等人於2008年在ACM SIGCOMM發表了題為OpenFlow: Enabling Innovation in Campus Networks[4]的論文，首次詳細地介紹了OpenFlow的概念。該篇論文除了闡述OpenFlow的工作原理外，還列舉了OpenFlow幾大應用場景，包括：
1）校園網絡中對實驗性通訊協議的支持（如其標題所示）；
2 )網絡管理和訪問控制；
3）網絡隔離和VLAN；
4）基於WiFi的移動網絡；
5）非IP網絡；
6）基於網絡包的處理。當然，目前關於OpenFlow的研究已經遠遠超出了這些領域。
基於OpenFlow為網絡帶來的可編程的特性，Nick和他的團隊（包括加州大學伯克利分校的Scott Shenker教授）進一步提出了SDN（Software Defined Network, 目前國內多直譯為“軟件定義網絡”）的概念--其實，SDN的概念據說最早是由KateGreene於2009年在TechnologyReview網站上評選年度十大前沿技術時提出[5]。如果將網絡中所有的網絡設備視為被管理的資源，那么參考操作系統的原理，可以抽象出一個網絡操作系統（Network OS）的概念—這個網絡操作系統一方面抽象了底層網絡設備的具體細節，同時還為上層應用提供了統一的管理視圖和編程接口。這樣，基於網絡操作系統這個平台，用戶可以開發各種應用程序，通過軟件來定義邏輯上的網絡拓撲，以滿足對網絡資源的不同需求，而無需關心底層網絡的物理拓撲結構。關於SDN的概念和原理，可以參考開放網絡基金會（Open NetworkingFoundation）於2012年4月份發表的SDN白皮書Software Defined Networking：The New Norm forNetworks [6] 。
從上面的描述中，可以看出OpenFlow/SDN的原理其實並不復雜，從嚴格意義上講也很難算是具有革命性的創新。然而OpenFlow/SDN卻引來了業界越來越多的關注，成為近年來名副其實的熱門技術。目前，包括HP、IBM、Cisco、NEC以及國內的華為和中興等傳統網絡設備制造商都已紛紛加入到OpenFlow的陣營，同時有一些支持OpenFlow的網絡硬件設備已經面世。2011年，開放網絡基金會（Open Networking Foundation）在Nick等人的推動下成立，專門負責OpenFlow標准和規范的維護和發展；同年，第一屆開放網絡峰會（OpenNetworking Summit）召開，為OpenFlow和SDN在學術界和工業界都做了很好的介紹和推廣。2012年初召開的第二屆峰會上，來自Google的Urs Hölzle在以OpenFlow@Google[7]為題的Keynote演講中宣布Google已經在其全球各地的數據中心骨干網絡中大規模地使用OpenFlow/SDN，從而證明了OpenFlow不再僅僅是停留在學術界的一個研究模型，而是已經完全具備了可以在產品環境中應用的技術成熟度。最近，Facebook也宣布其數據中心中使用了OpenFlow/SDN的技術。
自2010年初發布第一個版本（v1.0）以來，OpenFlow規范已經經歷了1.1、1.2以及最近剛發布的1.3等版本。同時，今年(2012)年初OpenFlow管理和配置協議也發布了第一個版本(OF-CONFIG 1.0 & 1.1)
在這里，我們將詳細介紹一下OpenFlow Switch的最新規范(即OF-1.3)。下圖選自Nick等人的論文OpenFlow：EnablingInnovation in Campus Networks 。這張圖常被用來說明OpenFlow的原理和基本架構。其實，這張圖還很好地表明了OpenFlow Switch規范所定義的范圍—從圖上可以看出，OpenFlow Switch規范主要定義了Switch的功能模塊以及其與Controller之間的通信信道等方面。
在進行OpenFlow原理說明前，先了解一些基本情況:
OpenFlow規范是什么？
OpenFlow是一套軟件API，它允許一個“控制器”將配置信息發送給交換機。這個配置往往指的是一個“流”及其附屬的某些“操作”。
“流”是一組定義的幀或者數據包（類似於一個MPLS流）與一組操作。例如：
Source IP/Port、Destination IP/Port和Drop。
Source IP、Destination IP和QoS Action。
Source MAC、Destination MAC和L2 Path。
通過OpenFlow，您可以將一組規則發送給一台“配置”設備的交換機或者路由器。然后每個設備會根據它的類型使用這些數據。交換機會更新它的MAC地址表以轉發幀，路由器會添加訪問列表，而防火牆會更新它的規則。
軟件定義網絡是什么？
當組織將網絡配置從設備遷移到軟件平台時，交換機就變得更加簡單和廉價了。但是主要的受益是網絡配置可以由中央控制器管理。
控制者是一個包含算法、數學、分析和規則的軟件，它來自規則組，並使用OpenFlow將配置下載到網絡設備中。因此，當控制器評估和重新平衡配置時，網絡就可能動態地進行重新配置。這就是所謂的軟件定義網絡。
SDN（Software Defined Network）：
它是基於OpenFlow實現的。在SDN中，交換設備的數據轉發層和控制層是分離的，因此網絡協議和交換策略的升級只需要改動控制層。OpenFlow在OpenFlow交換機上實現數據轉發，而在控制器上實現數據的轉發控制，從而實現了數據轉發層和控制層的分離。基於OpenFlow實現SDN，則在網絡中實現了軟硬件的分離以及底層硬件的虛擬化，從而為網絡的發展提供了一個良好的發展平台。
OpenFlow網絡由OpenFlow交換機、FlowVisor和Controller三部分組成。
OpenFlow交換機進行數據層的轉發；
FlowVisor對網絡進行虛擬化；
Controller對網絡進行集中控制，實現控制層的功能。
OpenFlow交換機是整個OpenFlow網絡的核心部件，主要管理數據層的轉發。OpenFlow交換機接收到數據包后，首先在本地的流表上查找轉發目標端口，如果沒有匹配，則把數據包轉發給Controller，由控制層決定轉發端口。
Controller
OpenFlow實現了數據層和控制層的分離，其中OpenFlow交換機進行數據層的轉發，而Controller實現了控制層的功能。Controller通過OpenFlow協議這個標准接口對OpenFlow交換機中的流表進行控制，從而實現對整個網絡進行集中控制。Controller的這一切功能都要通過運行NOX來實現，因此NOX就像是OpenFlow網絡的操作系統。此外，在NOX上還可以運行Plug-n-serve、OpenRoads以及OpenPipes等應用程序。
Plug-n-Serve 通過規定數據傳輸路徑來控制網絡以及服務器上的負載，從而使得負載均衡並降低響應時間。
OpenRoads 是支持OpenFlow無線網絡移動性研究的框架。
OpenPipes 可以在網絡系統中通過移動每個子模塊來測試每個子模塊，並可以決定如何划分設計單元。
OpenFlow交換機的組成
OpenFlow交換機由流表、安全通道和OpenFlow協議三部分組成。
安全通道是連接OpenFlow交換機到控制器的接口。控制器通過這個接口控制和管理交換機，同時控制器接收來自交換機的事件並向交換機發送數據包。交換機和控制器通過安全通道進行通信，而且所有的信息必須按照OpenFlow協議規定的格式來執行。
OpenFlow協議用來描述控制器和交換機之間交互所用信息的標准，以及控制器和交換機的接口標准。協議的核心部分是用於OpenFlow協議信息結構的集合。
OpenFlow協議支持三種信息類型：Controller-to-Switch，Asynchronous和Symmetric，每一個類型都有多個子類型。
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的規范還規定了如何為Controller和Switch之間的信道加密、如何建立多連接等(主連接和輔助連接)。
OpenFlow交換機的分類
按照對OpenFlow的支持程度，OpenFlow交換機可以分為兩類：
專用的OpenFlow交換機：
它是專門為支持OpenFlow而設計的。它不支持現有的商用交換機上的正常處理流程，所有經過該交換機的數據都按照OpenFlow的模式進行轉發。專用的OpenFlow交換機中不再具有控制邏輯，因此專用的OpenFlow交換機是用來在端口間轉發數據包的一個簡單的路徑部件。
支持OpenFlow的交換機：
它是在商業交換機的基礎上添加流表、安全通道和OpenFlow協議來獲得了OpenFlow特性的交換機。其既具有常用的商業交換機的轉發模塊，又具有OpenFlow的轉發邏輯，因此支持OpenFlow的交換機可以采用兩種不同的方式處理接收到的數據包。
按照OpenFlow交換機的發展程度來分，OpenFlow交換機也可以分為兩類：
“Type0”交換機：
它僅僅支持十元組以及以下四個操作：
1. 轉發這個流的數據包給一個給定的端口（或者幾個端口）；
2. 壓縮並轉發這個流的數據包給控制器；
3. 丟棄這個流的數據包；
4. 通過交換機的正常處理流程來轉發這個流的數據包。
“Type1”交換機：
由於“Type0”交換機的這些功能是不能滿足復雜試驗要求的，因此就定義“Type1”交換機來支持更多的功能，從而支持復雜的網絡試驗，“Type1”交換機將具有一個新的功能集合。
在一條規則中，可以根據網絡包在L2、L3或者L4等網絡報文頭的任意字段進行匹配，比如以太網幀的源MAC地址，IP包的協議類型和IP地址，或者TCP/UDP的端口號等。目前OpenFlow的規范中還規定了Switch設備廠商可以選擇性地支持通配符進行匹配。據說，OpenFlow在未來還計划支持對整個數據包的任意字段進行匹配。
所有OpenFlow的規則都被組織在不同的FlowTable中，在同一個FlowTable中按規則的優先級進行先后匹配。一個OpenFlow的Switch可以包含一個或者多個FlowTable，從0依次編號排列。OpenFlow規范中定義了流水線式的處理流程，如下圖所示。當數據包進入Switch后，必須從FlowTable 0開始依次匹配;
FlowTable可以按次序從小到大越級跳轉，但不能從某一FlowTable向前跳轉至編號更小的FlowTable。當數據包成功匹配一條規則后，將首先更新該規則對應的統計數據(如成功匹配數據包總數目和總字節數等)，然后根據規則中的指令進行相應操作--比如跳轉至后續某一FlowTable繼續處理，修改或者立即執行該數據包對應的Action Set等。
當數據包已經處於最后一個FlowTable時，其對應的Action Set中的所有Action將被執行，包括轉發至某一端口，修改數據包某一字段，丟棄數據包等。OpenFlow規范中對目前所支持的Instructions(指令)和Actions進行了完整詳細的說明和定義。
另外，OpenFlow規范中還定義了很多其他功能和行為，比如OpenFlow對於QoS的支持(即MeterTable和Meter Bands的定義等)，對於GroupTable的定義，以及規則的超時處理等。
OpenFlow規范主要分為如下四大部分，
1. OpenFlow的端口(Port)
OpenFlow規范將Switch上的端口分為3種類別：
a) 物理端口，即設備上物理可見的端口;
b) 邏輯端口，在物理端口基礎上由Switch設備抽象出來的邏輯端口，如為tunnel或者聚合等功能而實現的邏輯端口;
c) OpenFlow定義的端口。OpenFlow目前總共定義了ALL、CONTROLLER、TABLE、IN_PORT、ANY、LOCAL、
NORMAL和FLOOD等8種端口，其中后3種為非必需的端口，只在混合型的OpenFlow Switch(OpenFlow-hybrid Switch，即同時支持傳統網絡協議棧和OpenFlow協議的Switch設備中存在。
2. OpenFlow的FlowTable(國內有直譯為“流表”的)
OpenFlow通過用戶定義的或者預設的規則來匹配和處理網絡包。一條OpenFlow的規則由匹配域(Match Fields)、優先級(Priority)、處理指令(Instructions)和統計數據(如Counters)等字段組成，如下圖所示。
Openflow的思路很簡單，網絡設備維護一個FlowTable並且只按照FlowTable進行轉發，Flowtable本身的生成、維護、下發完全由外置的Controller來實現，注意這里的FlowTable並非是指IP五元組，事實上OpenFlow 1.0定義的了包括端口號、VLAN、L2/L3/L4信息的10個關鍵字，但是每個字段都是可以通配的，網絡的運營商可以決定使用何種粒度的流，比如運營商只需要根據目的IP進行路由，那么流表中就可以只有目的IP字段是有效的，其它全為通配。
這種控制和轉發分離的架構對於L2交換設備而言，意味着Controller將負責二層MAC學習，VLAN划分，還要負責三層路由協議的學習，最后下發給路由器和交換機，對於L3設備，各類IGP/EGP路由運行在Controller之上，Controller根據需要下發流表（對於L3應該是路由表）給相應的路由器。
流表的下發方式有兩種模式:
主動： Controller將自己收集的流表信息主動下發給網絡設備，隨后網絡設備可以直接根據流表進行轉發；
被動：是指網絡設備收到一個報文沒有匹配的FlowTable記錄時，將該報文轉發給Controller，由后者進行決策該如何轉發，並下發相應的流表。被動模式的好處是網絡設備無需維護全部的流表，只有當實際的流量產生時才向Controller獲取流表記錄並存儲，當老化定時器超時后可以刪除相應的流表，故可以大大節省TCAM空間。當一個Controller同時控制多個交換機/路由器設備時，它們看起來就像一個大的邏輯交換機，各個交換機/路由器硬件就如同這個邏輯網絡設備的遠程線卡，類似的概念在Cisco的Nexus 1000/1000v、ASR9000/9000v和Juniper的Q-Fabric架構中可以看到影子，Cisco稱之為nV(Network Virtualization)技術。
OpenFlow之下的網絡架構組成:
目前主要的OpenFlow解決方案包含一個三層架構，第一層架構由關鍵的具備OpenFlow 協議許可的以太網交換機組成。通常情況下，它們是具備OpenFlow功能的物理以太網交換機。我們還能看到一些具備OpenFlow功能的虛擬層/軟件交換機和路由器。今后這類設備肯定會越來越多。
然后是兩層服務器端軟件：OpenFlow控制器和OpenFlow軟件應用建立在控制器頂端。
控制器是一個平台，該平台向下可以直接與使用OpenFlow協議的交換機進行對話。向上，控制器可為OpenFlow軟件應用提供大量功能，包括將交換機資源編入統一的網絡視窗內，為應用提供協同和通用庫。
在頂層，OpenFlow軟件應用為網絡執行實際控制功能，如交換與路由。應用是寫在由控制器提供的統一網絡視窗和通用庫頂層的簡單軟件。因此，這些應用能夠着重執行特定控制算法，並能夠調整其下層的OpenFlow層以實例化網絡中的算法。
目前，OpenFlow術語有兩個意思，可以指“OpenFlow協議”，明確指稱用於網絡的x86指令集，也可以指“OpenFlow架構”，主要是交換機、控制器和應用層。
SDN與網絡虛擬化:
參考摘錄:https://www.sdnlab.com/15475.html
SDN不是網絡虛擬化，網絡虛擬化也不是SDN。
SDN是一種集中控制的網絡架構，可將網絡划分為數據層面和控制層面。
在數據中心等場景中，為實現快速部署和動態調整，必須使用自動化的業務部署。SDN的出現給網絡虛擬化業務部署提供了新的解決方案。通過集中控制的方式，網絡管理員可以通過控制器的API來編寫程序，從而實現自動化的業務部署，大大縮短業務部署周期，同時也實現隨需動態調整。
網絡虛擬化是一種網絡技術，可以在物理拓撲上創建虛擬網絡。
傳統的網絡虛擬化部署需要手動逐跳部署，其效率低下，人力成本很高。
SDN實現網絡虛擬化需要完成三部分工作: 物理網絡管理，網絡資源虛擬化和網絡隔離
虛擬化平台
虛擬化平台是介於數據網絡拓撲和租戶控制器之間的中間層。面向數據平面，虛擬化平面就是控制器，而面向租戶控制器，虛擬化平台就是數據平面。所以虛擬化平台本質上具有數據平面和控制層面兩種屬性。在虛擬化的核心層，虛擬化平台需要完成物理網絡資源到虛擬資源的虛擬化映射過程。面向租戶控制器，虛擬化平台充當數據平面角色，將模擬出來的虛擬網絡呈現給租戶控制器。從租戶控制器上往下看，只能看到屬於自己的虛擬網絡，而並不了解真實的物理網絡。而在數據層面的角度看，虛擬化平台就是控制器，而交換機並不知道虛擬平面的存在。所以虛擬化平台的存在實現了面向租戶和面向底層網絡的透明虛擬化，其管理全部的物理網絡拓撲，並向租戶提供隔離的虛擬網絡。
虛擬化平台不僅可以實現物理拓撲到虛擬拓撲“一對一”的映射，也應該能實現物理拓撲“多對一”的映射。而由於租戶網絡無法獨占物理平面的交換機，所以本質上虛擬網絡實現了“一虛多”和“多虛一”的虛擬化。此處的“一虛多”是指單個物理交換機可以虛擬映射成多個虛擬租戶網中的邏輯交換機，從而被不同的租戶共享；“多虛一”是指多個物理交換機和鏈路資源被虛擬成一個大型的邏輯交換機。即租戶眼中的一個交換機可能在物理上由多個物理交換機連接而成。
網絡資源虛擬化
為實現網絡虛擬化，虛擬化平台需要對物理網絡資源進行抽象虛擬化，其中包括 拓撲虛擬化，節點資源虛擬化和鏈路資源虛擬化
• 拓撲虛擬化【核心: 將物理節點映射給一個或多個用戶/租戶】
拓撲虛擬化是網絡虛擬化平台最基本的功能。虛擬平台需要完成租戶虛網中的虛擬節點和虛擬鏈路到物理節點和鏈路的映射。其中包括“一對一”和“一對多”的映射。
“一對一”的映射中，一個虛擬節點將會映射成一個物理節點，同理虛擬鏈路也是。
“一對多”的映射中，一個虛擬節點可以映射成由多個連接在一起的物理節點；一條邏輯鏈路也可能映射成由鏈接在一起的多條鏈路。而對於物理節點而言，一個物理節點可以被多個邏輯節點映射。
• 節點資源虛擬化【核心: 控制每個用戶/租戶能使用物理設備上多少資源】
節點資源的虛擬化包括對節點Flow tables（流表）、CPU等資源的抽象虛擬化。
流表資源本身是交換機節點的稀缺資源，如果能對其進行虛擬化，然后由虛擬化平台對其進行分配，分配給不同的租戶，那么就可以實現不同租戶對節點資源使用的分配和限制。拓撲抽象僅僅完成了虛擬節點到物理節點的映射，而沒有規定不同用戶/租戶對物理節點資源使用的分配情況。若希望進行更細粒度的網絡虛擬化，節點資源虛擬化非常有必要。
• 鏈路資源虛擬化【核心: 控制不同用戶/租戶能使用多少鏈路帶寬，端口隊列長度】
和節點資源一樣，鏈路資源也是網絡中重要的資源，而拓撲抽象並沒有規定某些用戶可使用的鏈路資源的多少。所以在進行更細粒度的虛擬化時，有必要對鏈路資源進行虛擬化，從而實現鏈路資源的合理分配，這樣就能夠抽象虛擬化的鏈路資源包括租戶可使用的帶寬以及端口的隊列資源等等。
網絡隔離
網絡資源虛擬化僅僅完成了物理資源到虛擬資源的抽象過程，為實現完全的網絡虛擬化，還需要對不同的租戶提供隔離的網絡資源。網絡隔離需要對SDN的控制平面和數據平面進行隔離，從而保證不同租戶控制器之間互補干擾，不同虛網之間彼此隔離。此外，為了滿足用戶對地址空間自定義的需求，虛擬化平台還需要對網絡地址進行虛擬化。
控制面隔離
控制器的性能對SDN整體的性能產生極大的影響，所以虛擬化平台需保證租戶的控制器在運行時不受其他租戶控制器的影響，保證租戶對虛擬化平台資源的使用。虛擬化平台在連接租戶控制器時需保證該進程可以得到一定的資源保障，比如CPU資源。而虛擬化平台本身所處的位置就可以輕易實現租戶的控制器之間的相互隔離。
數據面隔離
數據面的資源包括節點的CPU、Flow Tables等資源以及鏈路的帶寬，端口的隊列資源等。為保證各個租戶的正常使用，需對數據面的資源進行相應的隔離，從而保證租戶的資源不被其他租戶所占據。若在數據面上不進行資源的隔離，則會產生租戶數據在數據面上的競爭，從而無法保障租戶對網絡資源的需求，所以很有必要在數據面對資源進行隔離。
地址隔離
為使租戶能在自己的虛擬租戶網中任意使用地址，虛擬化平台需要完成地址的隔離。實現地址隔離主要通過地址映射來完成。租戶可任意定制地址空間，而這些地址對於虛擬化平台而言是面向租戶的虛擬地址。虛擬化平台在轉發租戶控制器南向協議報文(即:發送的報文)時，需要將虛擬地址轉化成全網唯一的物理地址。租戶的服務器的地址在發送到接入交換機時就會被修改成物理地址【注意: 這里不是NAT轉換地址，而是通過FlowTable來修改報文字段的】，然后數據包的轉發會基於修改之后的物理地址進行轉發。當數據到達租戶目的地址主機出端口，控制器需將地址轉換成原來租戶設定的地址，從而完成地址的虛擬化映射。地址的虛擬化映射使得租戶可以使用完全的地址空間，可以使用任意的FlowSpace（流空間：流表匹配項所組成的多維空間），而面向物理層面則實現了地址的隔離，使得不同的租戶使用特定的物理地址，數據之間互不干擾。
關於SDN的摘錄補充：
它的核心是SDN擁有一個集中或分布式智能實體，它具有網絡的整體視圖，可以根據該視圖做出路由和切換決策，”Capuano說。“通常，網絡路由器和交換機只知道它們的相鄰網絡設備。但是，通過正確配置的SDN環境，該中央實體可以控制一切，從而輕松更改策略，簡化整個企業的配置和自動化。“
通常在SDN環境中，客戶可以看到他們所有的設備和TCP流，這意味着他們可以從數據或管理平面切斷網絡，以支持各種應用和配置，Capuano說。因此，用戶可以根據需要更輕松地從生產環境中對IoT應用程序進行細分。
一些SDN控制器能夠智能地“看到”網絡正在變得擁擠。作為響應，SDN控制器將增加帶寬或做出其他處理，以確保遠程和邊緣組件不會受到延遲影響。
網絡可以分為兩部分，一部分可以是面向公眾的低安全性網絡，在這部分網絡中不會觸及任何敏感信息。另一個細分的網絡可以通過基於軟件的防火牆和加密策略實現更細粒度的遠程訪問控制，允許敏感數據在該網絡上傳輸。“例如，如果客戶擁有一個物聯網組，但該網絡在安全性方面並不是那么成熟，通過SDN控制器，您可以將該組從企業關鍵流量中分離出來，”Capuano說。“SDN用戶可以在網絡范圍內推出從數據中心到邊緣的安全策略，如果你在白盒子上完成所有這些工作，部署可以比傳統設備便宜30-60％。
OpenFlow實現上面架構的核心:
OpenFlow規范實際上是一整套軟件應用程序接口，控制網絡數據如何轉發，可基於硬件實現，OpenFlow增加了定制轉發數據的控制程度，減少了支撐復雜控制所需的硬件成本。OpenFlow網絡控制節點可以通過規范與支持OpenFlow的交換節點溝通配置信息，決定數據轉發平面的轉發表，控制器與轉發節點間通過SSL加密傳輸。OpenFlow支持定義的“信息流”主要是從1層到4層的關鍵信息包括端口號、VLAN、MAC、以太網包頭、IP地址、 IP協議號、TCP端口號等。配置信息通常包括“信息流”和與之對於的動作。每個“信息流”有符合某種特征的數據包及動作組成，比如源IP/源Port，目的IP/目的Port，5種不同轉發動作。
OpenFlow架構圖:
OpenFlow “信息流”定義:
用戶可以通過OpenFlow預設通用規則，每種不同網絡節點可以根據設備特點更新轉發平面規則，比如轉發交換機更新MAC地址轉發表、VLAN端口轉發表、1到4層轉發表，路由器修改訪問控制IP列表，防火牆修改進出端口規則等。
這里就是OpenFlow可定義規則的10元組：
OpenFlow它增加了網絡靈活控制能力，位於底層的分布式網絡設備節點的智能性通過OpenFlow指令得以實現，集中式的OpenFlow Controller節點的實時控制底層物理網絡的變化，並為各個分布式物理節點生成快速轉發表，而無須各個物理節點進行復雜智能分析計算，它們就可專心執行網絡轉發平面的功能。當新的轉發節點加入到OpenFlow網絡時，自動從中央控制節點得的最新網絡配置信息，完成網絡自動化感知。而中央控制節點基於x86標准服務器架構，強大計算能力和橫向擴展特性保證了控制平面擴展性和經濟性。
OpenFlow獨立控制平面的出現，TRILL或Shortest Path Bridging協議變得不是那么重要，因為OpenFlow控制器可以擁有有全網視圖，所以動態防止環路發生。OpenFlow不但提高了傳統轉發平面的效率，在提供高級網絡服務方面還可以展現獨特的價值，比如多對一的網絡虛擬化，分布式負載均衡和分布式防火牆或入侵檢測，非常不同於傳統模式的一對多網絡虛擬化模式。每一類分布式網絡資源服務與單獨雲租戶對應，每個雲租戶都有獨立的跨物理節點的虛擬化網絡，比如不同虛擬網絡交換機，對不同租戶管理員來說，它所對應的物理網絡端口是透明，邏輯化網絡派生於在物理網絡資源上抽象出的虛擬網絡資源池。虛擬機移動后，當虛擬機相應“信息流”的第一個數據包到達移動后的本地(物理/虛擬)交換機節點，如果本地交換機節點沒有發現匹配的轉發規則，整個數據報文會被送到中央管理節點，中央管理節點根據定義轉發規則邏輯下發相應的轉發規則，並應用到本地交換機的轉發表建立新的匹配項，之后的“信息流”不再通過管理節點，由轉發節點直接完成。
OpenFlow的應用
隨着OpenFlow/SDN概念的發展和推廣，其研究和應用領域也得到了不斷拓展。目前，關於OpenFlow/SDN的研究領域主要包括網絡虛擬化、安全和訪問控制、負載均衡、聚合網絡和綠色節能等方面。另外，還有關於OpenFlow和傳統網絡設備交互和整合等方面的研究。
下面將舉幾個典型的研究案例來展示OpenFlow的應用。
1. 網絡虛擬化 – FlowVisor
網絡虛擬化的本質是要能夠抽象底層網絡的物理拓撲，能夠在邏輯上對網絡資源進行分片或者整合，從而滿足各種應用對於網絡的不同需求。為了達到網絡分片的目的，FlowVisor實現了一種特殊的OpenFlow Controller，可以看作其他不同用戶或應用的Controllers與網絡設備之間的一層代理。
因此，不同用戶或應用可以使用自己的Controllers來定義不同的網絡拓撲，同時FlowVisor又可以保證這些Controllers之間能夠互相隔離而互不影響。
用計算機的虛擬化來類比，則FlowVisor就是位於硬件結構元件和軟件之間的網絡虛擬層。FlowVisor允許多個控制同時控制一台OpenFlow交換機，但是每個控制器僅僅可以控制經過這個OpenFlow交換機的某一個虛擬網絡（即slice）。因此通過FlowVisor建立的試驗平台可以在不影響商業流的轉發速度的情況下，允許多個網絡試驗在不同的虛擬網絡上同時進行。FlowVisor與一般的商用交換機是兼容的，而不需要使用FPGA和網絡處理器等可編程硬件。
下圖展示了使用FlowVisor可以在同一個物理網絡上定義出不同的邏輯拓撲。FlowVisor不僅是一個典型的OpenFlow應用案例，同時還是一個很好的研究平台，目前已經有很多研究和應用都是基於FlowVisor做的。
2. 負載均衡 – Aster*x
傳統的負載均衡方案一般需要在服務器集群的入口處，通過一個gateway或者router來監測、統計服務器工作負載，並據此動態分配用戶請求到負載相對較輕的服務器上。既然網絡中所有的網絡設備都可以通過OpenFlow進行集中式的控制和管理，同時應用服務器的負載可以及時地反饋到OpenFlowController那里，那么OpenFlow就非常適合做負載均衡的工作。
Aster*x通過Host Manager和Net Manager來分別監測服務器和網絡的工作負載，然后將這些信息反饋給FlowManager，這樣Flow Manager就可以根據這些實時的負載信息，重新定義網絡設備上的OpenFlow規則，從而將用戶請求(即網絡包)按照服務器的能力進行調整和分發。
3. 綠色節能的網絡服務 – ElasticTree
在數據中心和雲計算環境中，如何降低運營成本是一個重要的研究課題。能夠根據工作負荷按需分配、動態規划資源，不僅可以提高資源的利用率，還可以達到節能環保的目的。
ElasticTree創新性地使用OpenFlow，在不影響性能的前提下，根據網絡負載動態規划路由，從而可以在網絡負載不高的情況下選擇性地關閉或者掛起部分網絡設備，使其進入節電模式達到節能環保、降低運營成本的目的。
OpenFlow的面臨的難題和優勢【摘錄片段】
OpenFlow 1.0的流表分為Match Fields、計數器和指令集三個部分，Match Fields是報文匹配的輸入關鍵字，計數器是管理所需，指令集是決定報文如何轉發，最基本的轉發行為包括轉發給某個端口、封裝改寫報文后轉發以及丟棄。OpenFlow 1.1增加了對MPLS以及UDP/SCTP傳輸層協議的支持，同時針對流表開銷過大的情況設計了多級流表，並增加分組策略功能。
openflow的價值到底在哪里，是Open還是Flow？這個問題首先可以否認”Flow”的價值，原因很簡單，是否控制到細粒度的Flow取決於應用，應用沒有控制流的需求，則Flow毫無價值，”Flow”只是Openflow能提供的最大限度的控制能力而已，目前在ONF關注的數據中心交換網中沒有誰打算控制精確到n(n>=5)元組的流，除非是應用在防火牆控制上。
那么”Open”呢？的確包括Nick本人在內一直強調的都是”Open”是價值之所在，Open之后，研究者、運營商可以采購任意廠商的標准接口設備，自己DIY網絡，甚至可以采用交換信息廠商提供的公版設計交換機加上OpenFlow Controller就可以組成自己所需的網絡，並且Controller的開放軟件架構使得網絡控制的實現就像Web編程一樣簡單，采用Python、JAVA Script這樣的腳本加上開源算法庫、一個不需要了解太多網絡協議細節的開發者幾天就可以實現一個新的網絡拓撲算法開發、部署。這在流量模型尤為復雜運營級數據中心確實非常有吸引力。在這樣的一種場景中，網絡設備市場就變成了如同PC那樣的市場，賣網絡設備硬件的就成了賣大白菜的，大家最后只能比拼價格和工藝設計了。但是，即使這種悲慘的場景成為事實，誰又會是PC化的網絡市場中提供Windows的微軟呢，Openflow體系的NOS（Network OS）將會誰是贏家？交換網絡相對簡單，但是L3之上各種協議散落在數十年積累的數千篇IETF RFC中，誰能夠有實力實現一個如此復雜的網絡操作系統而又讓運營商放心呢？我想仍然可能是今天的網絡設備巨頭Cisco、Juniper們，產生意外的可能極小。
Arista定義了軟件定義雲網絡的四大“支柱：雲拓撲、分布式控制、網絡虛擬化和管理/自動化。OpenFlow只是實現基於控制器的SDN管理/自動化支柱中的多種方法中的一種而已。其他的實現方法還有CLI、SNMP、XMPP、Netconf、OpenStack、VMware vSphere虛擬化軟件等等。
在今年的VMworld大會上，Arista演示了如何用虛擬機的簡單預配置來構建雲，利用其EOS操作系統軟件和CloudVision接口最多可實現5萬個網絡節點。XMPP是其CloudVision中的API。
“沒有任何理由認為，明天不會出現一個OpenFlow或者OpenStack API，Ullal說。“但是現在就有一個完善定義的接口。我們今天用Netconf和XMPP，就是因為它很容易實現，各種規范定義完善，而且我們的一些客戶對此很感興趣。