在SDN的初期階段，各種可能性大量存在。這樣的想法讓從業者非常興奮，并且吸引了大批的開發人員。OpenFlow就是早期的一顆SDN明星，這個出自斯坦福大學的驗證概念指出了規劃網絡的一種全新的方法。很多人甚至將SDN與OpenFlow混為一談，好像除此之外SDN就沒有其他可能性存在了。

情況當然并非如此，但在SDN初期的炒作階段，這種想法也是可以理解的。OpenFlow進展神速，因為有開放網絡基金會(ONF)在后面推動，很快便連續發布了已迭代多次的OpenFlow主規范版本。

然而最近一段時間，OpenFlow的進展似乎陷入了停滯。業界對它的熱情也在逐漸減退。ONF發布OpenFlow主規范的步伐也已放緩。這些天來，就連廠商自己舉辦的SDN發布會，也不再強調OpenFlow有多么多么神奇了。

SDN已經用多個品類的產品創造出了屬于自己的行業，其中一些產品根本沒有用到OpenFlow。而在今年春季于美國紐約召開的開放網絡用戶組會議上，OpenFlow也不再是一個主要的討論話題。有些廠商對在自己的產品中增加對OpenFlow的支持興趣不高，甚至表現出厭惡情緒——這其中就包括大牌廠商思科和Juniper。不過另一些廠商，像惠普和博科，則依然將OpenFlow視為其生態系統的重要組成部分。

OpenFlow似乎已走到了一個十字路口。從用戶的角度來看，這種情形似乎頗讓人驚訝，也引發了一個疑問：長期來看，OpenFlow在SDN的發展中究竟還能不能發揮重要作用?

這個問題的答案在于要理解OpenFlow究竟是什么。簡單來說，OpenFlow其實就是為網絡設備編程轉發表的一種工具而已。

可是……事實就是如此。OpenFlow就是一個工具。但也不要因此而貶低OpenFlow。OpenFlow的確是一個工具，但它是一個有用的強大的工具。OpenFlow可提供的功能有如下一些：

●一個標準化的界面，可將廠商特定的硬件抽象出來。而可與OpenFlow對話的控制器則可針對支持OpenFlow的設備進行編程。

●一種對網絡進行集中編程的方法。

●一種可進行“例外編程”的簡易方法，用于處理網絡中不能遵循正常***路徑的例外流量。

一直在使用OpenFlow的廠商自然會指出，OpenFlow并未完全標準化。從某種意義上說，一些廠商為其添加了很多附加功能，對其做了擴展。事實的確如此，不過值得指出的是，這些廠商(包括Big Switch、NEC和VMware)正在與ONF合作，力圖將這些擴展納入到OpenFlow的標準中去。這樣的進程頗類似于過去其他廠商處理擴展與標準的情形。要說業界要完全拋棄OpenFlow似乎不太可能。一直在使用OpenFlow的廠商則試圖與業界同行盡量保持一致。

有些廠商可能會認為OpenFlow貶低了硬件的作用，OpenFlow作為一個標準化的界面不可能完全展現出硬件芯片所具備的所有功能。畢竟像思科和Juniper這類廠商是希望用其硬件芯片來實現差異化的。這樣做并沒錯，但卻改變不了所有網絡都擁有一個與流量轉發和訪問控制相關的通用功能根集合的事實。這一點的確是與芯片無關的。

那么，假如OpenFlow只是一個工具，又有什么特殊的理由要強調其重要性呢?

在SDN的初期，業界為這些新工具而興奮也屬正常，因為如果沒有這些工具，SDN就無法將其想法變為現實。作為一個行業來說，我們已經開始了超越工具而進入這些工具給網絡所帶來的現實階段。因此，關注的重點也開始向各種用例、產品和SDN的運營轉移。換句話說，普通的網絡消費者不會去買SDN或者OpenFlow，而是會在SDN逐漸成為主流時，去購買這些工具所帶來的各種功能。#p#

廠商如何使用OpenFlow

我們現在知道SDN不僅僅意味著OpenFlow。我們也知道，網絡的軟件編程就是不用OpenFlow也能完成任務。OpenFlow只是很多工具中已被證明對于軟件定義范式很有用的一種而已。但我們也不能犯輕易放棄OpenFlow或者將其已有影響貶低到一文不值的錯誤。所以，有些廠商已開始在自己的幾款商用產品中用到了OpenFlow。下面就是一些實例。

●惠普在其多款產品中用到了OpenFlow。惠普的VAN控制器利用OpenFlow，可以在一些應用如網絡優化器中對交換機進行編程。該優化器可為微軟Skype商用版(即Lync)提供動態QoS編程能力。

●博客的Vyatta控制器運行OpenDaylight代碼，并可將OpenFlow作為編程選項之一。

●就連思科也在其為數有限的幾款交換機平臺上提供一些OpenFlow支持。

●別忘了，OpenFlow還是Open vSwitch中的重要工具，而后者正在持續普及中。

我們還可舉出更多的例子來，但關鍵是要認識到很多廠商要么是在應用中使用OpenFlow的，要么是在某個硬件平臺上對其提供支持的。OpenFlow還遠未達到無所不在的程度。作為行業來說，我們尚未達到可以假定任何一個交換機平臺都具備OpenFlow功能的地步。即便OpenFlow成了一種標配，我們也不能確定哪些具體功能獲得了支持，或者得到支持的功能是否能用于規模化擴展。

為了解決這些問題，并讓OpenFlow在未來具有更多的可預見性，ONF專門成立了各種工作組、社區和提案組。

其中一個工作組是轉發抽象工作組(FAWG)。FAWG正在制定描述OpenFlow功能的一種方法，目的是為了便于硬件抽象層(HAL)的編寫者們更容易在其芯片中實現OpenFlow。

FAWG的一個重要關注點就是表類型范式(TTP)。FAWG的主席Curt Beckmann稱，“TTP的一個(可選)用途就是分清兩件事：在給定的上下文中如何使用轉發功能，以及如何通過OpenFlow來控制轉發功能。”總之，TTP的目的就是要為更便捷地使用復雜的OpenFlow指令鋪平道路，因為在OpenFlow 1.0版之后，有些指令內容會變得越來越具挑戰性。

FAWG是一個例證，說明ONF正在與行業合作(+微信關注網絡世界)，力圖讓越來越復雜的OpenFlow功能更便于使用。這樣的合作需要時間，但已經有了一些初期的成果。

例如領先的以太網芯片供應商博通就已在2014年12月發布了“下一代”開放交換機傳輸規范，稱為OF-DPA 2.0。OF-DPA 2.0采用了TTP，還有OF 1.3.1中可以找到的很多豐富的功能。關鍵之點在于，這一進展正在讓OpenFlow這一具有強大能力的網絡編程工具變得更容易使用，更能夠清晰地表達出復雜的應用需求。

OpenFlow的未來看上去一片光明。本文作者在研究了SDN的很多企業用例之后發現，普遍來說，企業正在轉向可以進行流量操控、流量安全和實現網絡虛擬化的技術。更有趣的是，在大多數情況下，上述分類中的很多解決方案都將OpenFlow作為了編程工具。

而OpenFlow的互操作性也已成為廠商們嚴肅討論的話題。例如NEC最近就宣布了與阿朗企業集團的合作，在這一合作中，NEC早已存在的ProgrammableFlow控制器將采用OpenFlow對阿朗企業的交換機硬件編程。

正因為有了這些進展，我才敢說OpenFlow的未來的確是一片光明的。OpenFlow已經在準備成為一個杰出的平均器——成為不斷成長的開放網絡運動中的一個關鍵性要素。

我說“杰出的平均器”，意思是指OpenFlow可用于消費芯片上復雜而豐富的各種功能，而且是在跨多個硬件平臺的規模化擴展中使用，如此一來，垂直集成的堆棧就會變得不那么重要了。網絡業者一般所用的網絡硬件都配有自帶的芯片、與之相伴隨的CLI(命令行接口)以及某種特殊類型的API(應用接口)，這些組件一般都是緊密集成在一起的。假如OpenFlow最終能夠變得無處不在，那么交換平臺本身也會變得不那么重要了，至少不會比在其上運行的應用更重要了。

這將在開放網絡的解耦進程中發揮很好的作用，企業或服務提供商可以選擇白盒交換機來運行他們自行選定的可兼容的網絡操作系統。這將為他們提供多種運營選擇、降低廠商鎖定風險，并有可能帶來成本節約。

OpenFlow能與這些價值觀很好地吻合，為SDN控制器的開發人員提供一種可預測的方式來對硬件編程。一旦網絡業進入這個開放的世界，爆發式的創新就會發生。一旦一個可預測的、抽象的網絡平臺能夠投入使用，那么面向SDN應用、運營靈活性以及提升整體IT效率的市場就將被打開。

OpenFlow或許正處在一個十字路口，但它不會迷路，更不會消失。我個人的強烈感覺是，OpenFlow***的未來還沒有到來。