SDN(Software Defined Network)是個(gè)有意思的概念。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.

用普通話說(shuō)就是軟件獨(dú)立于硬件，讓硬件標(biāo)準(zhǔn)化，軟件平臺(tái)化，信息中心化。

硬件標(biāo)準(zhǔn)化/軟件平臺(tái)化

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

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

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

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

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

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

信息中心化

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

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

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

轉(zhuǎn)發(fā)

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

link down帶來(lái)兩個(gè)問(wèn)題：

1、路由的收斂(convergence)。

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

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

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

所需時(shí)間：

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

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

● SPF計(jì)算時(shí)間: O(L+N*log(N))，L為受影響的鏈路數(shù)，N為拓?fù)渲泄?jié)點(diǎn)數(shù)

● RIB/FIB更新時(shí)間: ~5ms

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

在眾多路由協(xié)議中，OSPF和IS-IS這樣的鏈路狀態(tài)協(xié)議，由于每臺(tái)設(shè)備都擁有局部甚至全局的網(wǎng)絡(luò)拓?fù)湫畔ⅲ諗克俣纫阉闵霞选?/p>

再看重新選路的不確定性。由于拓?fù)渲衅渌O(shè)備的影響，某臺(tái)設(shè)備的同一條鏈路先后幾次link down的選路不一定相同。所以，每次link down發(fā)生，路由需要重新收斂，不能依照之前的歷史來(lái)做出決定。

SDN的優(yōu)勢(shì)

如果能夠?qū)⒙酚尚畔⒅行幕匆粋€(gè)云端計(jì)算中心實(shí)時(shí)掌握全網(wǎng)的拓?fù)錉顟B(tài)，則可以做很多很有價(jià)值的處理。比如：

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

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

配置管理

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

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

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

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

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

但是有一天，機(jī)房里的服務(wù)器全部都被虛擬化了，物理上已經(jīng)沒(méi)有了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

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

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

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

SDN的優(yōu)勢(shì)

同樣地，有了全網(wǎng)的實(shí)時(shí)拓?fù)湫畔⒑螅琒DN可以動(dòng)態(tài)調(diào)整網(wǎng)絡(luò)的配置，甚至都不需要人工干預(yù)。不用細(xì)談，想想看：

1、policy auto push

2、traffic shaping

3、load balancing

頓時(shí)覺(jué)得無(wú)限可能，盡在SDN。

Debug

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

1、信息搜集

2、縮小問(wèn)題空間，直至找到root cause

3、goto 1

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

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

SDN的優(yōu)勢(shì)

SDN太有優(yōu)勢(shì)了，因?yàn)榧锌刂疲钥梢裕?/p>

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

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

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

● 建立一個(gè)virtualized environment，replay packets

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

后記

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

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

● SDN的核心，central control plane很可能是個(gè)開(kāi)源的標(biāo)準(zhǔn)化的system，很難為某家硬件廠商掌控。這也是我不看好CISCO/Juniper做為的原因。唯有開(kāi)源和標(biāo)準(zhǔn)化，才能吸引小的硬件玩家進(jìn)入并顛覆這一市場(chǎng)。

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