在過去，openflow一度是sdn的代名詞，只要是sdn出現的地方就不得不談到openflow。不過現今，sdn似乎對openflow並不是很熱情，在談論sdn時，openflow也不再是標配了。這個曾經的唯一選擇究竟遇到了什麼，難道這是openflow協議之殤？
下面我們好好分析一下這個問題。這裡首先得提到的就是onf，openflow協議標準的發起組織。openflow的官方解釋是這樣的：openflow是定義在sdn架構中的首個控制平面和資料平面的標準通訊介面。openflow可直接接入並且控制物理或虛擬裝置的**平面。從本質上講，openflow允許對**平面進行深度定製，可以通過sdn控制器下發流規則的途徑去設定流量的**方式。這就意味著他能繞過交換機的控制平面，對上層應用展現乙個開放、簡單的交換機。在業界也有很多openflow部署的成功案例，例如google、ntt、goldman sachs等。裝置商也在研發openflow裝置上投入了大量資金，並且很多人認為2023年將會帶來openflow應用的爆發。不過，劇情並未按劇本發展。下面將分析一下openflow並未席捲全球的原因。
openflow
交換機缺少互聯互通
至今，很多所謂支援openflow的裝置都僅支援到openflow 1.0，裝置商對openflow 1.3協議的支援動力不足。很大一部分原因在於現有的協議還未成熟，很多裝置商並未對其所定義的tlv進行支援。現在只有onf在全力推動，為提公升互操作性做了大量的測試和**優化工作。但是從投入產出比來看，裝置商認為其價值不具有足夠的**力。
晶元級的openflow流表支援延緩
無論是定製晶元還是商用晶元，都不得不去對其晶元結構做調整以適配openflow的巨型流表。這樣直接造成工程師不得不放棄放棄高速的三重內容定址儲存解決方案，可用晶元的延遲減緩了了openflow適配節奏。
大量網工並不懂如何部署openflow
由於sdn、openflow新技術的出現，直接增加了網工的學習成本，他們剛剛學習完傳統的網路架構又不得不去學習新的技術。網工學習協議對控制平面的關注明顯多於**平面。然而部署openflow需要對不同裝置的類似於交換機流水線程序等屬性進行學習。
在業界公司忙於解決openflow問題的時候，其他新定義的介面的出現導致了南向介面的混亂。同時，裝置商製造openflow交換機並且僱傭市場團隊，讓後者認為openflow是產品的大賣點。市場人員因此重新包裝openflow以提供所謂的更廣的sdn解決方案。即使這些方案一直在使用openflow協議，但在使用者案例上還是老調重彈。
sdn
和openflow的未來
所以，openflow已死？這麼說的確很片面，但不得不說他將與其他協議友好共存。當然，裝置商仍在高調的用openflow進行產品包裝。但是這並不意味著openflow將只是作為噱頭存在，或許將會有更多的應用案例出現。不過我們可以學習到：我們應該將更大的精力投入到如何解決問題上，而不要糾結使用哪種協議。openflow不會死，他會存在並且會有更多的應用場景出現。所以，他的發展將以使用者案例來驅動，並且openflow的確是sdn發展路線中的重要部分。
SDN原理 OpenFlow協議 3
of1.1版本 這是of1.1版本的操作，引入了多流表，1.0版本並沒有多流表。of1.3版本的流表匹配相比of1.1版本，改變了很多 1 當匹配到流表項的時候，首先更新計數器，然後檢視指令集 之前有提過，指令是從動作層抽象出來的層次，便於管理動作 由指令決定動作是立即執行，或者是新增到位址集中 然...
SDN原理 OpenFlow協議 3
of1.1版本 這是of1.1版本的操作，引入了多流表，1.0版本並沒有多流表。of1.3版本的流表匹配相比of1.1版本，改變了很多 1 當匹配到流表項的時候，首先更新計數器，然後檢視指令集 之前有提過，指令是從動作層抽象出來的層次，便於管理動作 由指令決定動作是立即執行，或者是新增到位址集中 然...
OpenFlow協議 整體結構和協議篇
openflow sdn結構的乙個例項，一系列規範的集合，由open networking forum onf 維護。這些規範的關鍵是乙個抽象的包處理機定義，called switch.switch使用乙個資料報內容集合和交換機配置狀態來處理資料報。protocol定義來管理switch的配置狀態以...