OpenFlow瀏覽次數：947次  最近更新：2015-11-25 19:10:51

概述

OpenFlow論壇起源于斯坦福大學一個名為“Clean Slate”的以重新設計互聯網為目標的計劃，創立于2008年。該論壇最早的成員只有斯坦福大學的高性能網絡研究組(The High Performance Networking Group)。隨著論壇的發展，OpenFlow論壇已經變成一個由大學研究者和網絡管理者共同組成的開放論壇，吸引了來自麻省理工學院、加州理工學院等著名高校的教授以及德國電信等許多大型運營商的一線創立于2008年，工程師加盟。為防止制造商的利益沖突被引入論壇，OpenFlow論壇不歡迎來自網絡設備制造商的人員加入。

OpenFlow論壇主要解決的是重新設計互聯網的實驗環境問題。在純的實驗網上總難以有足夠多的實際用戶或者足夠大的網絡拓撲來測試新協議的性能和功能，最好的方法是將運行新協議的實驗網絡嵌入實際運營的網絡，利用實際的網絡環境來檢驗新協議的可行性和存在的問題。

傳統的解決方案有兩種，要求設備制造商完全開放平臺接口或實驗者自行制造設備。設備制造商完全開放平臺接口讓研究者可以使用商用網絡設備進行二次開發，尋找實驗協議與傳統協議并存的方法。但是，直接開放網絡設備的開發接口對設備提供商而言是一場噩夢，一方面與商用平臺的封閉性相沖突，開放開發的二次接口無疑會有暴露自身技術細節的風險，為競爭對手提供了機會，或者為新興廠家提供了進入行業的門檻。

OpenFlow的特點

開發者自行制造設備的方法一般是使用PC服務器或專用硬件搭建自己的交換路由設備，受限于主機能裝備的網卡數量， 這種方法不能獲得足夠大密度的端口(一般交換機很容易達到48或者更多的端口，而主機即使插上多塊網卡也很難有這么多的端口)，而且研究設備的交換性能一般也遠不如同價格的商用設備。在這種情況下，OpenFlow論壇提出新的交換設備解決方案必須具有以下四點性質：
第一，設備必須具有商用設備的高性能和低價格的特點；
第二，設備必須能支持各種不同的研究范圍；
第三，設備必須能隔絕實驗流量和運行流量；
第四，設備必須滿足設備制造商封閉平臺的要求。

仿效計算機領域軟硬件分離的做法，OpenFlow交換機將原來完全由交換機/路由器控制的報文轉發過程轉化為由OpenFlow交換機（OpenFlow Switch）和控制服務器（Controller）來共同完成，從而實現了數據轉發和路由控制的分離?？刂破骺梢酝ㄟ^事先規定好的接口操作來控制OpenFlow交換機中的流表，從而達到控制數據轉發的目的。

OpenFlow網絡由OpenFlow交換機、FlowVisor（網絡虛擬化層）和Controller（控制器）三部分組成。OpenFlow交換機進行數據層的轉發；FlowVisor對網絡進行虛擬化；Controller對網絡進行集中控制，實現控制層的功能。

OpenFlow交換機

OpenFlow交換機是整個OpenFlow網絡的核心部件，主要管理數據層的轉發。OpenFlowSwitch擁有一個FlowTable（流表），它只按照流表進行轉發，FlowTable的生成、維護和下發由外置的Controller來實現。這里的FlowTable并非是指IP五元組（IP源地址、IP目的地址、協議號、源端口、目的端口），OpenFlow1.0規范定義了包括輸入端口、MAC源地址、MAC目的地址、以太網類型、VLANID、IP源地址、IP目的地址、IP端口、TCP源端口、TCP目的端口在內的10個關鍵字（十元組）。FlowTable中的每個關鍵字都可以通配，網絡的運營商可以決定使用何種粒度的流，比如運營商只需要根據目的IP進行路由，那么FlowTable中就可以只有IP目的地址字段是有效的，其它全為通配。傳統網絡中數據包的流向是人為指定的，雖然交換機、路由器擁有控制權，卻沒有數據流的概念，只進行數據包級別的交換；而在OpenFlow網絡中，統一的Controller取代路由，決定了所有數據包在網絡中傳輸路徑。

OpenFlow采用控制和轉發分離的架構，意味著MAC地址的學習由Controller來實現，VLAN和基本的路由配置也由Controller下發給OpenFlowSwitch。對于三層網絡設備，各類路由器運行在Controller之上，Controller根據需要下發給相應的路由器。當一個Controller同時控制多個OpenFlowSwitch時，它們看起來就像一個大的邏輯交換機。FlowTable的下發可以是主動的，也可以是被動的。

主動模式：Controller將自己收集的FlowTable信息主動下發給OpenFlowSwitch，隨后OpenFlowSwitch可以直接根據FlowTable進行轉發。

被動模式：OpenFlowSwitch收到數據包后，首先在本地的FlowTable上查找轉發目標端口，如果沒有匹配，則把數據包轉發給Controller，由控制層決定轉發端口，并下發相應的FlowTable。被動模式的好處是網絡設備無需維護全部的FlowTable，只有當實際的流量產生時才向Controller獲取FlowTable記錄并存儲，當記錄老化時可以刪除相應的FlowTable，故可以大大節省存儲器空間。

FlowVisor

類比計算機的虛擬化，FlowVisor就是位于硬件結構元件和軟件之間的網絡虛擬層。FlowVisor允許多個控制器同時控制一臺OpenFlow交換機，但是每個控制器僅僅可以控制經過這個OpenFlow交換機的某一個虛擬網絡（即slice）。因此通過FlowVisor建立的試驗平臺可以在不影響商業流的轉發速度的情況下，允許多個網絡試驗在不同的虛擬網絡上同時進行。FlowVisor與一般的商用交換機是兼容的，而不需要使用FPGA和網絡處理器等可編程硬件。

Controller

Controller通過OpenFlow協議這個標準接口對OpenFlow交換機中的流表進行控制，從而實現對整個網絡進行集中控制。Controller的這一切功能都要通過運行NOX來實現，因此NOX就像是OpenFlow網絡的操作系統。此外，在NOX上還可以運行Plug-n-serve、OpenRoads以及OpenPipes等應用程序。

OpenFlow的發展

2008年以來，OpenFlow論壇已經在硬件和軟件支持方面取得了長足的發展。包括思科，Juniper,NEC,華為等許多公司推出了支持OpenFlow的交換機、路由器、無線網絡接入點（AP）等網絡設備。此外，具有OpenFlow功能的AP也已在斯坦福大學進行了部署，標志著OpenFlow已不再局限于固網。2009年12月，OpenFlow規范發布了具有里程碑意義的可用于商業化產品的1.0版本，而且支持規范1.0的軟件indigo也已發布了Beta版本。OpenFlow已經在美國斯坦福大學、Internet2、日本的JGN2plus以及其他的10-15個科研機構中部署，并將在國家科研骨干網以及其他科研和生產中應用。OpenFlow的國際覆蓋已經包括日本、葡萄牙、意大利、西班牙、波蘭和瑞典等。

2015年11月24日，華為宣布其交換機符合OpenFlow V1.3標準

OpenFlow與SDN

OpenFlow作為SDN底層實現的一個理想選擇，在轉發層面確實有很多優勢，但是也有很多需要注意的點[1]：將控制平面和轉發平面進行分離，減少了控制點，增加了控制平面的負擔，需要比以往有更強的CPU計算能力的設備才能堪重負；    SDN強調管理員在管理網絡方面的能力，這些無疑對管理員的技能和對所管理的業務熟悉度有了更高一步的要求，這點與網絡設備智能化、自動化、傻瓜化的發展思想多少是有點相悖的；
    OpenFlow的多表項為業務實現提供了靈活性，但是這無疑增加了設備的成本，并且為交換芯片驅動開發人員在軟件中記錄和維護配置表項、容錯等研發工作提供相當大的復雜度；
    OpenFlow在轉發層面相比于傳統方式有了很大提高，應該是先兼容以前所有的轉發方式，但是現在的標準中，還有很多傳統轉發方式支持但是OpenFlow中不支持的，比如我要實現某個出端口中SIP=1.1.1.1的報文全丟棄，標準中暫時沒有出現匹配出端口的的內容，希望OpenFlow標準盡快得到完善；
    傳統交換機中還有很多非產生直接轉發意義或動作方面的功能，比如流控、隊列調度、WRED等方面都要涉及交換芯片MMU，而這些OpenFlow是很難對各個廠家通過標準而統一的，所以OpenFlow標準化方面還有很多的工作要做；

參考文獻

關于OpenFlow的更多信息，可以參考網址 https://www.opennetworking.org/
關于OpenFlow的歷史信息可以參考：archive.openflow.org.
[1]http://www.csdn.net/article/2014-03-14/2818768-SDN-OpenFlow