SDN(Software Defined Network)是個有意思的概念。ONF(Open Network Foundation)這樣定義SDN：

In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications.

　　用普通話說就是軟件獨立于硬件，讓硬件標準化，軟件平臺化，信息中心化。

硬件標準化/軟件平臺化

這概念說新穎不新穎，軟件行業(yè)從OS誕生的那一天，就已經(jīng)這么做了。Wintel主導(dǎo)的PC革命讓整個行業(yè)圍繞著一致的硬件體系，統(tǒng)一的，向后兼容的API(Windows SDK)開發(fā)硬件和軟件的各種應(yīng)用。用個不太恰當?shù)念惐龋荷蠄D的infrastructure layer相當于PC的硬件，control layer相當于windows/SDK或*nix/POSIX，application layer相當于OS之上的各種軟件。

可是網(wǎng)絡(luò)設(shè)備行業(yè)卻一直沒有形成這樣的生態(tài)圈。我覺得是兩個方面的原因：

整個行業(yè)沒有意識。網(wǎng)絡(luò)設(shè)備的優(yōu)劣基本上在performance上見分曉，上流的vendor各出奇招，在ASIC設(shè)計上絞盡腦汁，所以就一直沒形成標準的硬件(使用標準硬件的基本上是下流的vendor)。各個vendor在推出自己的設(shè)備時，軟硬件已經(jīng)緊密綁定，一定程度上把這三個layer做在了一起。

大玩家沒有意愿。即使有vendor意識到PC生態(tài)圈的好處，也沒有驅(qū)動力這么做。你想啊，PC vendor的前車之鑒擺在那里，一旦decouple好了，自己若做不了control layer的leader，掌管著生態(tài)圈，豈不就淪為Compaq，Dell這樣的純硬件vendor，只能在供應(yīng)鏈上比拼越來越低的行業(yè)利潤。逮你你愿意嗎?

所以CISCO/Juniper等一票vendor就這樣軟硬兼施地做了若干年，慢慢把市場培養(yǎng)成現(xiàn)在的樣子：沒有第三方，一切軟件，從系統(tǒng)到應(yīng)用，從package forwarding到VoIP，只能是我自己提供。所以當08年還是09年，Juniper依然壯士斷腕，轟轟烈烈地推動One JUNOS，開放SDK，試圖打造一個類似Windows的生態(tài)圈，似乎為時已晚，應(yīng)者寥寥，因為愿意和有能力接盤的軟件公司已經(jīng)不多。

但是網(wǎng)絡(luò)設(shè)備的發(fā)展的相對滯后，越來越趕不上mobile internet/cloud computing時代的步伐。成千上萬的應(yīng)用被不斷地創(chuàng)造出來，就幾個vendor的一幫苦逼程序猿咬牙應(yīng)對，肯定是杯水車薪。

信息中心化

信息中心化是對傳統(tǒng)網(wǎng)絡(luò)的一大挑戰(zhàn)。Internet的前身，ARPANET，在創(chuàng)建之初就有一個前提：這個網(wǎng)絡(luò)是個自制的，無中心的系統(tǒng)，網(wǎng)絡(luò)遭受任何局部損失都不會影響其他部分的正常通訊。所以，所有的RFC都圍繞著這個前提來構(gòu)建，所有的網(wǎng)絡(luò)設(shè)備也遵循著這一前提來研發(fā)。

但是SDN將這一前提打破。所謂天下合久必分，分久必合。網(wǎng)絡(luò)世界也不能免俗。Cloud computing引發(fā)的互聯(lián)網(wǎng)革命新浪潮將計算和存儲中心化，SDN順應(yīng)了這一趨勢。通過硬件，軟件平臺的支持，信息(網(wǎng)絡(luò)狀態(tài))被共享到一個邏輯上集中的中心。相對于去中心化的傳統(tǒng)網(wǎng)絡(luò)，SDN帶來很多很多優(yōu)勢。本文將著重討論信息中心化對網(wǎng)絡(luò)設(shè)備的革命性意義。

溫馨提示：作者對還未系統(tǒng)研讀過關(guān)于SDN的ONF white paper，也沒有實際研發(fā)過SDN相關(guān)的軟件，所以本文中的一些想法均屬臆測，既不完整，也不完備，可能經(jīng)不起進一步的推敲，不當之處，還望指正。

轉(zhuǎn)發(fā)

網(wǎng)絡(luò)設(shè)備的核心是轉(zhuǎn)發(fā)，即packet從接口X轉(zhuǎn)發(fā)到接口Y。轉(zhuǎn)發(fā)的依據(jù)是選路，路由協(xié)議會告訴系統(tǒng)如何選路。轉(zhuǎn)發(fā)最頭疼的問題是link down，無論是physcial還是logic link down，對于拓撲中的一臺網(wǎng)絡(luò)設(shè)備來說，link down意味著重新選路并通知其他網(wǎng)絡(luò)設(shè)備。這直接導(dǎo)致一段時間的丟包。選路時間越長，丟包越多。

link down帶來兩個問題：

1、路由的收斂(convergence)。

2、重新選路的不確定性。

先看收斂問題。一臺運行OSPF(其他協(xié)議大致如此)的網(wǎng)絡(luò)設(shè)備的convergence time大概可以這樣算出：

Convergence = 鏈路狀態(tài)變化發(fā)現(xiàn)時間 + 協(xié)議消息傳遞時間 + SPF計算時間 + RIB/FIB更新時間

所需時間：

● 鏈路狀態(tài)變化發(fā)現(xiàn)時間: ~5ms

● 協(xié)議消息傳遞時間: LSA生成時間 + LSA發(fā)送時間 + LSA接收時間 + LSA處理時間 + 網(wǎng)絡(luò)傳遞時間，~20ms+log(N) N為鄰居數(shù)量

● SPF計算時間: O(L+N*log(N))，L為受影響的鏈路數(shù)，N為拓撲中節(jié)點數(shù)

● RIB/FIB更新時間: ~5ms

由以上公式大概可以看出，convergence的瓶頸在SPF計算和協(xié)議消息傳遞上，網(wǎng)絡(luò)越大，SPF和協(xié)議消息傳遞所需時間越長。此外，一般網(wǎng)絡(luò)設(shè)備對計算量大的任務(wù)，如SPF，跑在相對低優(yōu)先級的task上，無形中又降低了SPF的速度。

在眾多路由協(xié)議中，OSPF和IS-IS這樣的鏈路狀態(tài)協(xié)議，由于每臺設(shè)備都擁有局部甚至全局的網(wǎng)絡(luò)拓撲信息，收斂速度已算上佳。

再看重新選路的不確定性。由于拓撲中其他設(shè)備的影響，某臺設(shè)備的同一條鏈路先后幾次link down的選路不一定相同。所以，每次link down發(fā)生，路由需要重新收斂，不能依照之前的歷史來做出決定。

SDN的優(yōu)勢

如果能夠?qū)⒙酚尚畔⒅行幕?，即一個云端計算中心實時掌握全網(wǎng)的拓撲狀態(tài)，則可以做很多很有價值的處理。比如：

● 加快路由計算的速度。對于OSPF來說，如果SPF能過放在云端計算，計算性能將大有改觀，能夠支持比現(xiàn)有應(yīng)用更大的網(wǎng)絡(luò)。

● 預(yù)先做出某種判斷。如果說加快路由計算的速度帶來的好處可能被網(wǎng)絡(luò)傳輸?shù)难舆t所抵消，那么，當云端擁有了整個拓撲狀態(tài)時，可以預(yù)先計算出一些特定的解決方案并提前發(fā)送給設(shè)備。當符合解決方案的情況出現(xiàn)時，設(shè)備可以即刻應(yīng)用解決方案選擇特定的路由。

配置管理

配過防火墻，或者見過大型網(wǎng)絡(luò)下防火墻在生產(chǎn)環(huán)境下實際配置的同學(xué)都知道，這玩意兒不是一個好配置的主。動輒成百上千的address book, policy, VPN等無論是CLI還是WebUI配置都是一種折磨。雖然大型的企業(yè)會順帶購買網(wǎng)管系統(tǒng)來統(tǒng)一配置旗下的各臺設(shè)備，但那玩意還是一個局部的，純靜態(tài)的配置。

配置麻煩是傳統(tǒng)網(wǎng)絡(luò)設(shè)備的一大問題。

另一個問題是服務(wù)器動態(tài)遷移帶來的網(wǎng)絡(luò)管理問題。這個問題是服務(wù)器虛擬化革命帶來的，現(xiàn)在的網(wǎng)絡(luò)設(shè)備對此基本無解。為了便于說明，我們看下圖：

一個典型的企業(yè)intranet會將不同部門間的訪問權(quán)限分隔開，比如說engineering team只能訪問engineering server，finance team只能訪問finance server。傳統(tǒng)防火墻對此表示毫無壓力。

from eng-clients-zone to eng-server-zone any-source any-dest permit

from finance-clients-zone to finance-server-zone any-source any-dest permit

但是有一天，機房里的服務(wù)器全部都被虛擬化了，物理上已經(jīng)沒有了zone的概念。所以配置需要變成：

from eng-clients-zone to intranet-server-zone eng-client-ips eng-server-ips permit

from finance-clients-zone to intranet-server-zone finance-client-ips finance-server-ips permit

在同一臺防火墻的管理下，這可以運行地很好，即使virtualized server在physical server間跑來跑去，只要IP不變，policy就不用發(fā)生改變。

但是，當網(wǎng)絡(luò)變大，支撐業(yè)務(wù)運作的服務(wù)器和網(wǎng)絡(luò)設(shè)備都增加時，會發(fā)生問題。想像一下，上述網(wǎng)絡(luò)由兩臺防火墻保護，virtual server從一臺防火墻后面遷移到另一臺防火墻后會發(fā)生什么情況?

已有的配置將無法適應(yīng)這種變化。管理員需要手工去調(diào)整配置。但是，virtual server的靈活性和physical server不可同日而語：一周甚至一個月內(nèi)，physical server可能都不會有太多的變化(遷移，部署)，但virtual server可能朝生暮死(想像一下aws)。

SDN的優(yōu)勢

同樣地，有了全網(wǎng)的實時拓撲信息后，SDN可以動態(tài)調(diào)整網(wǎng)絡(luò)的配置，甚至都不需要人工干預(yù)。不用細談，想想看：

1、policy auto push

2、traffic shaping

3、load balancing

頓時覺得無限可能，盡在SDN。

Debug

沒做過網(wǎng)絡(luò)設(shè)備的人可能不知道網(wǎng)絡(luò)軟件的Debug有多么辛苦。一般軟件Debug步驟：

1、信息搜集

2、縮小問題空間，直至找到root cause

3、goto 1

對于網(wǎng)絡(luò)軟件而言，信息搜集是一道坎，你要能拿到topology下面各個相關(guān)網(wǎng)絡(luò)設(shè)備的配置和問題出現(xiàn)時的log。這絕對不是一件容易的事兒。不信你問customer escalation engineer。他們每天要死要活地抓log，一次很難成功，兩次，三次成功都算蒼天有眼。

就算成功抓到了需要的log，想想AT&T給你個路由震蕩的issue，一個大topology下數(shù)十臺設(shè)備，數(shù)兆的configuration，數(shù)十兆的log。相關(guān)的，不相關(guān)的，反正都拋給你，你死的心都有了。

SDN的優(yōu)勢

SDN太有優(yōu)勢了，因為集中控制，所以可以：

● 指定相關(guān)的網(wǎng)絡(luò)設(shè)備同時打開需要的debug開關(guān)(這個相當關(guān)鍵)

● 將log(甚至packets)收集到central cloud上

● 運行一組predefined analysis tool分析問題的所在(這個可以根據(jù)平時的case不斷積累)

● 建立一個virtualized environment，replay packets

最后，可能有80%的case都能找到一個前例;剩下那20%，到engineer手上，也是narrow down的有價值的數(shù)據(jù)，甚至分析報告。

后記

瞎扯了一些SDN的也許不著邊際的應(yīng)用場景，立此存照，來年再看。我對SDN商業(yè)上的看法是：

● CISCO/Juniper推動的決心和力度不會太大，除非壯士斷腕;反而是大型互聯(lián)網(wǎng)公司，如google, amazon才是這場革命的主角。據(jù)說google在其intranet上已經(jīng)將SDN/openflow的優(yōu)勢發(fā)揮地淋漓盡致。

● SDN的核心，central control plane很可能是個開源的標準化的system，很難為某家硬件廠商掌控。這也是我不看好CISCO/Juniper做為的原因。唯有開源和標準化，才能吸引小的硬件玩家進入并顛覆這一市場。

● 如果前一點成立，那么第三方的應(yīng)用市場將有極大的想像空間，也許能催生一批又一批網(wǎng)絡(luò)領(lǐng)域的Borland，Adobe，etc.