http://www.h3c.com/cn/d_201811/1131080_30005_0.htm#

1 OpenFlow背景

轉發和控制分離是SDN網路的本質特點之一 。在SDN網路架構中，控制平面與轉發平面分離，網路的管理和狀態在邏輯上集中到一起，底層的網路基礎從應用中獨立出來，由此，網路獲得前所未有的可程式設計、可控制和自動化能力。這使使用者可以很容易根據業務需求，建立高度可擴充套件的彈性網路。要實現SDN網路的轉控分離架構，就需要在SDN控制器與資料轉發層之間建立一個通訊介面標準。

2008年，斯坦福大學成立了一個名為Clean Slate的特別工作小組，這個小組在2009年開發出了一個可以滿足SDN網路轉控分離架構的標準，即OpenFlow 1.0。同時該小組還開發出了OpenFlow的參考交換機和NOX控制器。OpenFlow標準協議允許控制器直接訪問和操作網路裝置的轉發平面，這些裝置可以是物理裝置，也可以是虛擬的路由器或者交換機。轉發平面則採用基於流的方式進行轉發。

OpenFlow 1.0問世後不久就引起了業界關注。2011年3月21日，德國電信、臉書、谷歌、微軟、雅虎等公司共同成立的了ONF（Open Networking Foundation）組織，旨在推廣SDN，並加大OpenFlow的標準化力度。晶片商Broadcom，裝置商Cisco、Juniper、HP等，各資料中心解決方案提供者以及眾多運營商紛紛參與。該組織陸續制定了OpenFlow 1.1、1.2、1.3、1.4等標準，目前仍在繼續完善中。隨著越來越多的公司加入ONF，OpenFlow及SDN技術的影響力也越來越大。

圖1給出了OpenFlow協議各個版本的演進過程和主要變化，目前使用和支援最多的是OpenFlow1.3版本。

 

圖1 OpenFlow版本更新

2 OpenFlow基本概念

2.1 OpenFlow元件

OpenFlow網路由OpenFlow網路裝置（OpenFlow 交換機）、控制器（OpenFlow控制器）、用於連線裝置和控制器的安全通道（Secure Channel）以及OpenFlow表項組成。其中，OpenFlow 交換機裝置和OpenFlow控制器是組成OpenFlow網路的實體，要求能夠支援安全通道和OpenFlow表項。

 

圖2 OpenFlow元件

2.1.1 OpenFlow控制器

OpenFlow控制器位於SDN架構中的控制層，通過OpenFlow協議南向指導裝置的轉發。目前主流的OpenFlow控制器分為兩大類：開源控制器和廠商開發的商用控制器。這裡簡要介紹幾款較為知名的開源控制器。

1、NOX/POX

NOX是第一款真正的SDN OpenFlow控制器，由Nicira公司在08年開發，並且捐贈給了開源組織。NOX支援OpenFlow V1.0，並提供相關C++的API，採用非同步的、基於時間的程式設計模型。而POX可以視作是更新的、基於Python的NOX版本，支援Windows，Mac OS和Linux系統上的Python開發，主要用於研究和教育領域。

2、ONOS

ONOS（Open Network Operating System）控制器是由The Open Networking Lab使用Java及Apache實現釋出的首款開源SDN網路作業系統，主要面向服務提供商和企業骨幹網。ONOS的設計宗旨是實現可靠性強、效能好、靈活度高的SDN控制器。

3、OpenDaylight

OpenDaylight是一個Linux 基金合作專案，該專案以開源社群為主導，使用Java語言實現開源框架，旨在推動創新實施以及軟體定義網路透明化。面對SDN型網路，OpenDaylight作為專案核心，擁有一套模組化、可插拔且極為靈活的控制器，還包含一套模組合集，能夠執行需要快速完成的網路任務。OpenDaylight控制器的命名以化學元素為名，最初的產品是Hydrogen（氫），當前已經發布了第八個版本Oxygen（氧），並且實現了OpenDaylight與NFV開放平臺OPNFV(Open Platform for NFV)、開源雲平臺OpenStack和開放網路自動化平臺ONAP(Open Network Automation Platform)同步。

大多數開源的SDN控制器是完全基於OpenFlow協議開發的，這是因為其設計多數源自於Onix（一種分散式控制器框架）。相比之下，大部分商用控制器會將OpenFlow和其他協議進行聯合使用，以完成更復雜的功能。在當下SDN網路大行其道的時代，大多數主流網路廠商例如VMware、Cisco、H3C等都推出了自己的商用控制器。例如，H3C的VCFC（Virtual Converged Framework Controller，虛擬應用融合架構控制器）南向通過OpenFlow、OVSDB、NETCONF協議對SDN網路裝置（主要是OpenFlow交換機）進行管控和指導轉發，北向提供開放的Rest API以及JAVA程式設計介面。整體架構如下所示：

 

圖3 VCFC整體架構

2.1.2 OpenFlow交換機

OpenFlow交換機由硬體平面上的OpenFlow表項和軟體平面上的安全通道構成，OpenFlow表項為OpenFlow的關鍵組成部分，由Controller下發來實現控制平面對轉發平面的控制。

OpenFlow 交換機主要有下面兩種：

• OpenFlow-Only Switch：僅支援OpenFlow轉發。

• OpenFlow-Hybrid Switch：既支援OpenFlow轉發，也支援普通二三層轉發。

一個OpenFlow交換機可以有若干個OpenFlow例項，每個OpenFlow例項可以單獨連線控制器，相當於一臺獨立的交換機，根據控制器下發的流表項指導流量轉發。OpenFlow例項使得一個OpenFlow交換機同時被多組控制器控制成為可能。

 

圖4 OpenFlow交換機與控制器

OpenFlow交換機實際在轉發過程中，依賴於OpenFlow表項，轉發動作則是由交換機的OpenFlow介面完成。OpenFlow介面有下面三類。

物理介面：比如交換機的乙太網口等。可以作為匹配的入介面和出介面。

邏輯介面：比如聚合介面、Tunnel介面等。可以作為匹配的入介面和出介面。

保留介面：由轉發動作定義的介面，實現OpenFlow轉發功能。

2.2 OpenFlow表項詳解

OpenFlow的表項在V1.0階段，只有普通的單播表項，也即我們通常所說的OpenFlow流表。隨著OpenFlow協議的發展，更多的OpenFlow表項被新增進來，如組表（Group Table），計量表（Meter Table）等，以實現更多的轉發特性以及QoS功能。

2.2.1 OpenFlow流表

狹義的OpenFlow流表是指OpenFlow單播表項，廣義的OpenFlow流表則包含了所有型別的OpenFlow表項。OpenFlow通過使用者定義的流表來匹配和處理報文。所有流表項都被組織在不同的Flow Table中，在同一個Flow Table中按流表項的優先順序進行先後匹配。一個OpenFlow的裝置可以包含一個或者多個Flow Table。

1、流表項組成

一條OpenFlow的表項（Flow Entry）由匹配域（Match Fields）、優先順序（Priority）、處理指令（Instructions）和統計資料（如Counters）等欄位組成，流表項的結構隨著OpenFlow版本的演進不斷豐富，不同協議版本的流表項結構如下。

 

圖5 流表項組成

(1)Match Fields

流表項匹配規則，可以匹配入介面、物理入介面，流表間資料，二層報文頭，三層報文頭，四層埠號等報文欄位等。

(2)Priority

流表項優先順序，定義流表項之間的匹配順序，優先順序高的先匹配。

(3)Counters

流表項統計計數，統計有多少個報文和位元組匹配到該流表項。

(4)Instructions & Actions

流表項動作指令（Instructions & Actions）集，定義匹配到該流表項的報文需要進行的處理。當報文匹配流表項時，每個流表項包含的指令集就會執行。這些指令會影響到報文、動作集以及管道流程。 交換機不需要支援所有的指令型別，並且控制器可以詢問OpenFlow交換機所支援的指令型別。 具體的指令型別參見下表：

Instruction	處理
Meter	對匹配到流表項的報文進行限速
Apply-Actions	立即執行Action
Clear-Actions	清除動作集（Action Set）中的所有Action。
Write-Actions	更改動作集（Action Set）中的所有Action。
Write-Metadata	更改流表間資料，在支援多級流表時使用。
Goto-Table	進入下一級流表。

表1流表項動作指令

每個流表表項的指令集中每種指令型別最多隻能有一個，指令的執行的優先順序為：

Meter –> Apply-Actions -> Clear Actions -> Write-Actions -> Write-Metadata -> Goto-Table

當OpenFlow交換機無法執行某個流表項中的動作時，該交換機可以拒絕這個流表項，並向Controller返回unsupported flow error 資訊。

常見Action動作的型別如下：

必選的	Output	轉發到指定的OpenFlow埠
	Drop	無直接動作，指令集中無output動作則丟棄該報文
	Group	處理報文到指定Group
可選的	Set-Queue	設定報文的佇列id
	Push-Tag/Pop-Tag	寫入/彈出標籤 例如VLAN, MPLS等
	Set-Field	修改報文的頭欄位
	Change-TTL	修改TTL，Hop Limit等欄位

表2 Action動作

(5)Timeouts

流表項的超時時間，包括了Idle Time和Hard Time。

Idle Time：在Idle Time時間超時後如果沒有報文匹配到該流表項，則此流表項被刪除。

Hard Time：在Hard Time時間超時後，無論是否有報文匹配到該流表項，此流表項都會被刪除。

(6)Cookie

Controller下發的流表項的標識

2、流表處理流程

OpenFlow規範中定義了流水線式的處理流程，報文匹配處理流程如下圖所示：

 

圖6 流表處理流程

當報文進入Switch後，必須從最小的Flow Table開始依次匹配。Flow Table可以按次序從小到大越級跳轉，但不能從某一Flow Table向前跳轉至編號更小的Flow Table。當報文成功匹配一條Flow Entry後，將首先更新該Flow Entry對應的統計資料（如成功匹配資料包總數目和總位元組數等），然後根據Flow Table中的指令進行相應操作，比如跳轉至後續某一Flow Table繼續處理，修改或者立即執行該資料包對應的Action Set等。當資料包已經處於最後一個Flow Table時，其對應的Action Set中的所有Action將被執行，包括轉發至某一埠，修改資料包某一欄位，丟棄資料包等。具體實現時，OpenFlow交換機還需要對匹配表項次數進行計數、更新匹配集和元資料等操作。

 

圖7 流表匹配流程

3、Table Miss表項

每個流表（Flow Table）都包含一個Table Miss流表項，該表項用於定義在流表中沒有匹配的報文的處理方式，該表項的匹配域為通配，即匹配任何報文，優先順序為0，Instructions與正常表項相同。通常，如果Table-Miss表項不存在，預設行為是丟棄報文。

4、Flow Remove

Flow Entry可以由Controller通過OpenFlow訊息進行刪除，也可以在Idle Time超時或者Hard Time超時後自動刪除。Idle Time超時有兩種情況：某個流表表項長時間不匹配報文則idle_timeout欄位設定為非0；某個流表表項一定時間過後，無論是否匹配報文 hard_timeout欄位設定為非0。如果Controller在建立表項時，攜帶了Flow Remove標記，則表項在刪除時，裝置需要通知Controller Flow Remove訊息。

2.2.2 OpenFlow組表

OpenFlow組表的表項被流表項（Flow Entry）所引用，提供組播報文轉發功能。一系列的Group表項組成了Group Table，每個表項結構如圖：

 

圖8 OpenFlow組表

根據Group ID可檢索到相應Group表項，每個Group表項包含多個動作Bucket，每個Bucket包含多個動作，Bucket內的動作執行順序依照Action Set的順序。

2.2.3 OpenFlow Meter表

Meter計量表項被流表項（Flow Entry）所引用，為所有引用Meter表項的流表項提供報文限速的功能。一系列的Meter表項組成了Meter Table， 每個Meter表項的組織結構如下：

 

圖9 OpenFlow計量表

一個Meter表項可以包含一個或者多個Meter Bands，每個Meter Band定義了速率以及動作，報文的速率超過了某些MeterBand，根據這些MeterBand中速率最大的那個定義的動作進行處理。

2.3 OpenFlow安全通道

OpenFlow裝置與Controller通過建立OpenFlow通道，進行OpenFlow訊息互動，實現表項下發，查詢以及狀態上報等功能。通過OpenFlow通道的報文都是根據OpenFlow協議定義的，通常採用TLS（Transport Layer Security）加密，但也支援簡單的TCP直接傳輸。如果安全通道採用TLS連線加密，當交換機啟動時，會嘗試連線到控制器的6633 TCP埠（Openflow埠通常預設建議設定為6633）。雙方通過交換證書進行認證。因此，在加密時，每個交換機至少需配置兩個證書。

3 OpenFlow執行機制

3.1 OpenFlow通道建立

3.1.1 OpenFlow訊息型別

要了解OpenFlow通道的建立過程，首先需要了解OpenFlow協議目前支援的三種報文型別：

1、Controller to Switch訊息

由Controller發起、Switch接收並處理的訊息。這些訊息主要用於Controller對Switch進行狀態查詢和修改配置等管理操作，可能不需要交換機響應。

 

圖10 Controller to Switch

Controller to Switch訊息主要包含以下幾種型別：

l Features：用於控制器傳送請求來了解交換機的效能，交換機必須迴應該報文。

l Modify-State：用於管理交換機的狀態，如流表項和埠狀態。該命令主要用於增加、刪除、修改OpenFlow交換機內的流表表項，組表表項以及交換機埠的屬性。

l Read-State：用於控制器收集交換機各方面的資訊，例如當前配置，統計資訊等 。

l Flow-Mod：Flow-Mod訊息用來新增、刪除、修改OpenFlow交換機的流表資訊。Flow-Mod訊息共有五種型別：ADD、DELETE、DELETE-STRICT、MODIFY、MODIFY-STRICT。

l Packet-out：用於通過交換機特定埠傳送報文 ，這些報文是通過Packet-in訊息接收到的。通常Packet-out訊息包含整個之前接收到的Packet-in訊息所攜帶的報文或者buffer ID（用於指示儲存在交換機內的特定報文）。這個訊息需要包含一個動作列表，當OpenFlow交換機收到該動作列表後會對Packet-out訊息所攜帶的報文執行該動作列表。如果動作列表為空，Packet-out訊息所攜帶的報文將被OpenFlow交換機丟棄。

l Asynchronous-Configuration：控制器使用該報文設定非同步訊息過濾器來接收其只希望接收到的非同步訊息報文，或者向OpenFlow交換機查詢該過濾器。該訊息通常用於OpenFlow交換機和多個控制器相連的情況。

2、非同步（Asynchronous）訊息

由Switch傳送給Controller，用來通知Switch上發生的某些非同步事件的訊息，主要包括Packet-in、Flow-Removed、Port-Status和Error等。例如，當某一條規則因為超時而被刪除時，Switch將自動傳送一條Flow-Removed訊息通知Controller，以方便Controller作出相應的操作，如重新設定相關規則等。

 

圖11 Switch to Controller

非同步訊息具體包含以下幾種型別：

l Packet-in：轉移報文的控制權到控制器。對於所有通過匹配流表項或者Table Miss後轉發到Controller埠的報文均要通過Packet-in訊息送到Controller。也有部分其他流程（如TTL檢查等）也需要通過該訊息和Controller互動。Packet-in既可以攜帶整個需要轉移控制權的報文，也可以通過在交換機內部設定報文的Buffer來僅攜帶報文頭以及其Buffer ID傳輸給Controller。Controller在接收到Packet-in訊息後會對其接收到的報文或者報文頭和Buffer ID進行處理，併發回Packet-out訊息通知OpenFlow交換機如何處理該報文。

l Flow-Removed：通知控制器將某個流表項從流表的移除。通常該訊息在控制器傳送刪除流表項的訊息或者流表項的定時器其超時後產生。

l Port-Status：通知控制器埠狀態或設定的改變。

3、同步（Symmetric）訊息

顧名思義，同步（Symmetric）訊息是雙向對稱的訊息，主要用來建立連線、檢測對方是否線上等，是控制器和OpenFlow交換機都會在無請求情況下發送的訊息，包括Hello、Echo和Experimenter三種訊息，這裡我們介紹應用最常見的前兩種：

 

圖12 同步訊息

l Hello：當連線啟動時交換機和控制器會發送Hello互動。

l Echo：用於驗證控制器與交換機之間連線的存活，控制器和OpenFlow交換機都會發送Echo Request/Reply訊息。對於接收到的Echo Request訊息必須能返回Echo Reply訊息。Echo訊息也可用於測量控制器與交換機之間鏈路的延遲和頻寬。

3.1.2 通道建立過程解析

OpenFlow控制器和OpenFlow交換機之間建立通道連線的基本過程，具體步驟如下：

1. OpenFlow交換機與OpenFlow控制器之間通過TCP三次握手過程建立連線，使用的TCP埠號為6633。

2. TCP連線建立後，交換機和控制器就會互相傳送hello報文。Hello報文負責在交換機和控制器之間進行版本協商，該報文中OpenFlow資料頭的型別值為0。

3. 功能請求（Feature Request）：控制器發向交換機的一條OpenFlow 訊息，目的是為了獲取交換機效能，功能以及一些系統引數。該報文中OpenFlow 資料頭的型別值為5。

4. 功能響應（Feature Reply）：由交換機向控制器傳送的功能響應（Feature Reply）報文，描述了OpenFlow交換機的詳細細節。控制器獲得交換機功能資訊後，OpenFlow協議相關的特定操作就可以開始了。

5. Echo請求（Echo Request）和Echo響應（EchoReply）屬於OpenFlow中的對稱型報文，他們通常用於OpenFlow交換機和OpenFlow控制器之間的保活。通常echo請求報文中OpenFlow資料頭的型別值為2，echo響應的型別值為3。不同廠商提供的不同實現中，echo請求和響應報文中攜帶的資訊也會有所不同。

3.1.3 通道連線斷開模式

當OpenFlow裝置與所有Controller斷開連線後，裝置進入Fail Open模式。OpenFlow裝置存在兩種Fail Open模式：

l Fail Secure mode交換機：在該模式下的OpenFlow交換機，流表項繼續生效，直到流表項超時刪除。OpenFlow交換機內的流表表項會正常老化。

l Fail Standalone mode交換機：所有報文都會通過保留埠Normal處理。即此時的OpenFlow交換機變成傳統的乙太網交換機。Fail Standalone mode只適用於OpenFlow-Hybrid交換機。

安全通道也有兩種模式，不同模式下安全通道重連的機制不同。

l 並行模式：並行模式下，Switch允許同時與多個Controller建立連線，Switch與每個Controller單獨進行保活和重連，互相之間不影響。當且僅當Switch與所有Controller的連線斷開後，Switch才進入Fail Open狀態。

l 序列模式：序列模式下，Switch在同一時刻僅允許與一個Controller建立連線。一旦與該Controller連線斷開後，Switch並不會進入Fail Open狀態，而是立即根據Controller的ID順序依次嘗試與Controller連線。如果與所有Controller都無法建立連線，則等待重連時間後，繼續遍歷Controller嘗試建立連線。在三次嘗試後，仍然沒有成功建立連線，則Switch進入Fail Open狀態。

3.2 OpenFlow訊息處理

3.2.1 OpenFlow流表下發與初始流表

OpenFlow流表下發分為主動和被動兩種機制：

主動模式下，Controller將自己收集的流表資訊主動下發給網路裝置，隨後網路裝置可以直接根據流表進行轉發。

被動模式下，網路裝置收到一個報文沒有匹配的FlowTable記錄時，會將該報文轉發給Controller，由後者進行決策該如何轉發，並下發相應的流表。被動模式的好處是網路裝置無需維護全部的流表，只有當實際的流量產生時才向Controller獲取流表記錄並存儲，當老化定時器超時後可以刪除相應的流表，因此可以大大節省交換機晶片空間。

在實際應用中，通常是主動模式與被動模式結合使用。

當OpenFlow交換機和Controller建立連線後，Controller需要主動給OpenFlow交換機下發初始流表，否則進入OpenFlow交換機的報文查詢不到流表項，就會做丟棄處理。這裡的初始流表保證了OpenFlow的未知報文能夠上送控制器。而後續正常業務報文的轉發流表，則在實際流量產生時，由主動下發的初始流表將業務報文的首包上送給控制器後，觸發控制器以被動模式下發。

這裡我們以H3C VCFC控制器給交換機下發的一個初始流表舉例。

前面我們瞭解到，OpenFlow流表是分級匹配的，通常按0表、1表、2表這樣依次匹配過去，每個級別的表中則由優先順序高的表項先進行匹配。

 

圖13 OpenFlow流表舉例

如上圖所示，0表優先順序最高為65535的兩條流表匹配到的是埠號為67、68的UDP報文，也就是DHCP報文，匹配動作為goto_table 1，剩下的其他所有報文也命中優先順序最低為0的表項後goto_table 1。而在表1中，優先順序最低的表項對應的動作為output controller，這保證了虛擬機器的DHCP請求可以傳送給控制器，由控制器作為網路中的DHCP Server，避免DHCP請求泛洪，同時還保證了交換機上所有未知的無流表匹配的報文都可以上送控制器，觸發控制器被動下發流表給交換機指導轉發。這裡，我們把表1裡優先順序最低為0，匹配所有未知報文的表項叫做table-miss表項。

我們在OpenFlow交換機上同樣可以觀察到初始流表，這裡以H3C S6800交換機上的一個初始流表舉例。上圖中的這條表項匹配報文型別為乙太網報文，UDP埠67、68說明匹配DHCP請求報文，動作為上送控制器：

 

圖14 OpenFlow交換機上流表舉例

3.2.2 OpenFlow報文上送控制器

OpenFlow報文上送控制器詳細過程如下：

 

圖15 OpenFlow報文上送控制器過程

1.控制器和交換機建立連線事件是Packet-in事件發生的前提。

2.當OpenFlow交換機收到資料包後，如果明細流表中與資料包沒有任何匹配條目，就會命中table-miss表項，觸發Packet-in事件，交換機會將這個資料包封裝在OpenFlow協議報文中傳送至控制器。

3.一旦交換機觸發了Packet-in事件，Packet-in報文就將傳送至控制器。

Packet-in資料頭包括了：

l 緩衝ID

l 資料包長度

l 輸入埠

l Packet-in的原因，分兩種：

0: 無匹配

1: 流表中明確提到將資料包傳送至控制器

3.2.3 控制器迴應OpenFlow報文

控制器收到Packet-in訊息後，可以傳送Flow-Mod訊息向交換機寫一個流表項。並且將Flow-Mod訊息中的buffer_id欄位設定為Packet-in訊息中的buffer_id值。從而控制器向交換機寫入了一條與資料包相關的流表項，並且指定該資料包按照此流表項的action列表處理。

Controller根據報文的特徵資訊（如IP、mac等）下發一條新的流表項到OpenFlow交換機或者做其他處理之後下,發Packet-out訊息動作為output到table，具體過程如下所示：

 

圖16 控制器迴應OpenFlow報文過程

1.控制器和交換機之間建立連線事件是Packet-out事件發生的前提；

2.控制器要傳送資料包至交換機時，就會觸發Packet-out事件將資料包傳送至交換機。這一事件的觸發可以看做是控制器主動通知交換機發送一些資料報文的操作。通常，當控制器想對交換機的某一埠進行操作時，就會使用Packet-out報文。

3.該資料包由控制器發往交換機，內部資訊使用Packet-out，並由OpenFlow資料頭封裝。OpenFlow Packet-out資訊包括：

l 緩衝ID

l 入口埠編號

l 動作明細（新增為動作描述符）

l 輸出動作描述符

l VLAN VID動作描述符

l VLAN PCP動作描述符

l 提取VLAN標籤動作描述符

l 乙太網地址動作描述符

l IPv4地址動作描述符

l IPv4 DSCP動作描述符

l TCP/UDP埠動作描述

l 佇列動作描述符

l 各廠商動作描述符

3.3 OpenFlow交換機轉發

3.3.1 單播報文轉發流程

當OpenFlow交換機接收到Flow-Mod訊息，生成流表後，就可以按照流錶轉發接收到的Packet-out報文了，過程舉例如下：

 

圖17 單播報文轉發流表

在本例中，OpenFlow 交換機需要轉發一個從7.7.7.1到9.9.9.1的流量。當流量上送到OpenFlow交換機後，流量的第一個包會先進行Packet-in、Flow-Mod、Packet out的過程，之後同流量的報文就能匹配控制器已經下發的流表進行轉發了。

3.3.2 組播報文轉發

當終端發出的組播報文到達OpenFlow交換機後，OpenFlow交換機Packet-in給控制器，控制器會為網路下發指導查詢組表的流表，並進行流表與組表關聯。交換機參考流表，引用組表進行轉發。舉例如下：

組播報文轉發所使用的流表：

 

圖18 組播報文轉發流表

上條流表的動作為引用組表4096，組表4096詳細內容如下：

 

圖19 組表詳細內容

4 OpenFlow的未來

OpenFlow作為SDN轉控分離架構和可程式設計性的靈魂已經存在近十年了，作為SDN技術家族中的老前輩可謂勞苦功高。然而，從整個網路技術數十年的發展歷程來看，Openflow還只是個剛剛長成的少年，儘管已具備了豐富的功能雛形，在未來的日子裡仍然還有很長的成熟期要度過。我相信伴隨著雲端計算和虛擬化技術的進一步推廣落地，在眾多SDN技術支持者的貢獻下，OpenFlow會更加穩定、強大，最終能夠某種程度上推動全人類科技的發展和生活的改善。最後，套用一句我最喜歡的話來結尾：OpenFlow的征途是星辰大海，諸君努力！