從2009年業內***次提出SDN概念開始算起，到今年已是第6個年頭;從2011年開放網絡基金會(ONF，Open Networking Foundation)成立開始計算，也已是第4個年頭。相對于往年SDN的熱炒，2014年無疑顯得略微平淡，但是這一年SDN的商用進程悄悄加速，越來越多的廠商推出商用或試商用產品，也有更多的客戶開始進行SDN部署或POC測試。

[[125627]]

另外一方面，開源社區在SDN商用發展中所起到的作用也越來越顯著：OpenDayLight(ODL)發布了氦版本，在集群以及SAL架構上做了很大的改進;ONLab推出了醞釀已久的ONOS開源SDN控制器，Open vSwitch(OVS)也加快了對OpenFlow協議的支持，從2.3版本開始正式全面支持OpenFlow 1.3以及OpenFlow 1.4部分特性;越來越多的SDN方案被用于OpenStack等云管理系統的網絡底層實現方式。

相比之下，在SDN的ASIC芯片支持上進展相對緩慢。這使得數據中心主流的解決方案仍然是以Overlay方案為主，硬件交換機和控制器多廠商互通方案仍然離商用尚有距離。在非OpenFlow的SDN領域，廠商私有解決方案進展或許較快，無論是思科的ACI方案還是VMWare的NSX都贏得了一定的眼球。

在電信運營商領域，2014年有不少基于SDN的回傳網絡、光傳輸、CPE和流量優化等POC測試的發布，但是實際上它們大多都是基于現有產品的部分開放接口或集中管控改造的實驗產品，很大程度上是已有技術的演進——包括基于邊緣網絡虛擬化、PCE技術乃至網絡管理技術的演進。在運營商網絡中，穩定可靠、性能的要求要高于靈活性，引入標準意義上SDN的門檻被抬高，而客戶價值降低，這使得運營商在基礎網絡上始終屬于技術上的保守派。可類比的實例是，2009年就有不少運營商開始評估測試電信網元的虛擬化，但是時至今日，NFV的大熱才真正開啟了運營商基礎網絡設施的虛擬化應用進程。

SDN的路線之爭

SDN作為一種網絡集中管控、開放接口的理念在ONF不遺余力的推廣下得到業界認同，但是到底采用什么樣的技術路線，卻因為廠商觀點和利益立場的原因并沒有快速收斂，反而因為思科ACI解決方案、OpenDayLight開源項目影響力增加而日趨模糊。

從OpenFlow的理念來看，其將智能全部匯聚于集中的控制器，而轉發面機械地執行轉發指令即可，因而完全同質化。這樣勢必導致目前在網絡產業中占據主要市場份額的硬件設備市場進入門檻大大降低，主導廠商地位因此受到威脅。他們從一開始抗拒SDN，繼而擁抱SDN理念，然后力推和OpenFlow有顯著差異的解決方案。

從已有的廠商SDN解決方案來看，絕大部分都在南向接口上支持OpenFlow 1.0或1.3，但是不少廠商都同時擁有自己的私有協議接口或已有IETF協議的變種，比如ONEPK，OpFlex，BGP、XMPP、NetConf和私有的RESTful接口。

當然出于市場推廣的需要，他們基本都會聲稱是完全開放的接口，甚至會在IETF進行部分的標準化推進。這些方案和OpenFlow的根本性區別在于轉發面仍然是自在的網絡，脫離集中的控制器仍然可以運行基本轉發業務，只開放通過API控制、影響部分轉發面智能邏輯的能力，從而保留了硬件設備的差異化競爭能力。而ONF的架構文檔中特別標明，SDN控制器必須具備對轉發面的完全控制權，從而將此類方案統統劃歸在了“偽SDN”的范疇。

即使排除廠商的利益因素，單純從技術角度來看，OpenFlow的完全控制轉發分離架構對協議體系成熟度、控制器產品的實現難度而言更高。一個離開邏輯上集中的控制器就無法運轉的網絡架構，本身就蘊含了額外的風險和成本。類似的場景是上個世紀90年代初電信網絡在由隨路信令向共路信令遷移的過程中，運營商新建設了一個更加可靠的控制平面來解決這個問題(當然其驅動力還包含信令數字化后帶來信令容量提升、更快的接續速度、新業務支持等優勢)。而在SDN的初期推廣過程中，對于已有網絡的SDN改造就面臨額外支出的控制平面成本問題。如果初期SDN帶來的收益不足以讓客戶付出此部分額外的成本，則部署本身可能會從反面證明SDN的可靠性的確存在問題。

另外一方面，OpenFlow持續增長的復雜性也引起了產業界的顧慮。為了兼顧各種場景，OpenFlow必須在協議中增加對不同報文格式以及操作指令的支持，這使得ASIC來支持完全的OpenFlow標準越來越困難。為此ONF推出了可協商數據平面模型(NDM)的規范。在此規范下，OpenFlow可以支持特定ASIC能力的控制，但是其需要在控制器上增加相應的硬件驅動程序。即使拋卻基本不可實現的理想全標準化NDM模型，也還意味著如果要實現完全互通，工作量和轉發硬件數量*控制器數量正相關，每一種硬件都需要在一種控制器上實現一種驅動——除非我們像PC硬件產業那樣最終聚焦到1~2種操作系統為核心的生態鏈上。而在SDN領域，目前尚無這樣可以一統天下的控制器。Linux花了十年才成為服務器的主流操作系統之一，而OpenDayLight、ONOS尚為時過早，就更不要談SDN早期那些偏學術實驗性質的OpenFlow控制器了。網絡面向的是企業/運營級市場，其訂制化需求更多，對售后服務依賴更多，因此對于設備提供商的可持續發展能力要求甚高，因此SDN以及白牌交換機所許諾的完全開放網絡的實現仍需假以時日。

開源社區的影響力

盡管早期業界就出現了大量的OpenFlow控制器，包括NOX、POX、FloodLight等，但是他們比較單薄的架構無法滿足商用環境下多廠商互操作、高可用性的要求，因此在產業界的影響力較小。這一狀況隨著OpenDayLight開源項目的發布得到根本性的改觀——目前已經有40多個廠商參與到OpenDayLight項目中。這使得ONF倍感威脅。2014年ONF加大了對開源社區的投入，其資助了幾個開源社區項目，包括開源OpenFlow協議棧Libfluid;同時OpenFlow的發源地斯坦福大學也通過ONLab在12月份推出了ONOS開源SDN控制器。在已知的廠商中，博科完全采用了OpenDayLight作為其SDN解決方案的控制器，思科的非主流控制器XNC也是和OpenDayLight采用了相同的內核。

另外一方面，Open vSwitch從2.1.2版本開始基本支持了完整的OpenFlow標準，絕大部分基于OpenFlow 1.3的方案均可以通過OVS來進行組網或驗證。尤其是基于SDN的Overlay方案，SDN控制器+OVS就可以搞定。Open vSwitch下一個2.4版本將加入對DPDK的支持，以進一步提升OVS轉發性能，從而使得OVS在性能上接近目前商用的vSwitch，滿足在更高流量場景下的應用。

在OpenStack領域，絕大部分SDN控制器均有了自己的Neutron Plug-In(插件)。同時對于業務鏈、L4~L7 層服務和SDN網絡協同等議題及項目，也已經在OpenStack Juno版本及以后版本中支持，比如Group Based Policy項目在OpenStack Juno版本和OpenDayLight Helium版本就已經同步支持。

從SDN本身的產業鏈來講(+微信關注網絡世界)，控制器仍然位居核心地位，開源社區目前的影響力焦點也在與此。OpenDayLight在思科的控制下，毫無疑問和ONF有意無意地唱對臺戲。從分裂SDN陣營的角度來看，其無疑已經成功了一半。OpenDayLight中支持了OpenFlow以外的不少南向接口，包括思科自己的OpFlex、LISP，以及OVSDB、BGP-LS、PCEP等接口。而對于ONF規范，目前尚不支持多OpenFlow版本同時運行，其對于OpenFlow多表轉發模型的支持也流于形式，也無計劃支持OF-Config。這使得要想在商用環境下部署ODL、使用OpenFlow接口，需要大量的開發工作。

當然，即使不使用OpenFlow，ODL離商用的距離也未必有顯著差異。OpenDayLight的亮點在于模型驅動的開發方式以及SAL抽象層，但是其缺乏基本的網絡模型、轉發模型的公共抽象層，使得在其上開發的應用需要以煙囪形式開發。這對于應付單一的應用場景來說問題不大，但是對于希望構建一個通用的控制器平臺來說，還有不小的距離。此外從代碼質量上來講，其和同樣是Java為主的Android這樣的單一廠商控制的開源項目相比差距較大。

2015年展望

SDN在數據中心中的應用已無懸念，業界已經基本準備好，無論是Overlay的架構，還是非Overlay的架構，2015年開始具備規模商用部署的能力。但是，這也僅僅是起點，SDN并沒有走向如同網絡產業東西向協議那樣充分互操作的道路，而是如同IT業一樣，采用了廠商聯合的小集團方式構建一個完整的的解決方案。這其中OpenFlow和非OpenFlow方案都占據一席之地。筆者作為一個樂觀派，仍然認為經過2~3年的博弈后，OpenFlow這樣的標準協議仍然會成為南向協議的主流。

在運營商領域，NFV中應用SDN的步伐可能會緊跟數據中心應用之后。而在其他領域，主要場景包括IPRAN、PTN、WAN流量調度、OTN、EPC、vCPE等領域，SDN的集中管控理念將進一步貫徹，將出現更多的POC或試點。不過這肯定不是ONF定義的“控制器具有完全控制權”的SDN，而是會混合部分私有技術、部分傳統技術以及可能的部分OpenFlow技術。即使如此，其商用化的進程也還尚未進入正軌，不僅廠商沒有準備好，運營商更加沒有準備好。這一過程，將持續3~5年的時間。或許更有可能的是，SDN在運營商網絡退化或演進成一種高級網絡管理架構，而非一種控制架構。