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

[[125627]]

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

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

在電信運營商領(lǐng)域，2014年有不少基于SDN的回傳網(wǎng)絡(luò)、光傳輸、CPE和流量優(yōu)化等POC測試的發(fā)布，但是實際上它們大多都是基于現(xiàn)有產(chǎn)品的部分開放接口或集中管控改造的實驗產(chǎn)品，很大程度上是已有技術(shù)的演進(jìn)——包括基于邊緣網(wǎng)絡(luò)虛擬化、PCE技術(shù)乃至網(wǎng)絡(luò)管理技術(shù)的演進(jìn)。在運營商網(wǎng)絡(luò)中，穩(wěn)定可靠、性能的要求要高于靈活性，引入標(biāo)準(zhǔn)意義上SDN的門檻被抬高，而客戶價值降低，這使得運營商在基礎(chǔ)網(wǎng)絡(luò)上始終屬于技術(shù)上的保守派?？深惐鹊膶嵗?，2009年就有不少運營商開始評估測試電信網(wǎng)元的虛擬化，但是時至今日，NFV的大熱才真正開啟了運營商基礎(chǔ)網(wǎng)絡(luò)設(shè)施的虛擬化應(yīng)用進(jìn)程。

SDN的路線之爭

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

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

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

當(dāng)然出于市場推廣的需要，他們基本都會聲稱是完全開放的接口，甚至?xí)贗ETF進(jìn)行部分的標(biāo)準(zhǔn)化推進(jìn)。這些方案和OpenFlow的根本性區(qū)別在于轉(zhuǎn)發(fā)面仍然是自在的網(wǎng)絡(luò)，脫離集中的控制器仍然可以運行基本轉(zhuǎn)發(fā)業(yè)務(wù)，只開放通過API控制、影響部分轉(zhuǎn)發(fā)面智能邏輯的能力，從而保留了硬件設(shè)備的差異化競爭能力。而ONF的架構(gòu)文檔中特別標(biāo)明，SDN控制器必須具備對轉(zhuǎn)發(fā)面的完全控制權(quán)，從而將此類方案統(tǒng)統(tǒng)劃歸在了“偽SDN”的范疇。

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

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

開源社區(qū)的影響力

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

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

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

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

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

2015年展望

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

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