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.

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

硬件標準化/軟件平臺化

這概念說新穎不新穎，軟件行業從OS誕生的那一天，就已經這么做了。Wintel主導的PC革命讓整個行業圍繞著一致的硬件體系，統一的，向后兼容的API(Windows SDK)開發硬件和軟件的各種應用。用個不太恰當的類比：上圖的infrastructure layer相當于PC的硬件，control layer相當于windows/SDK或*nix/POSIX，application layer相當于OS之上的各種軟件。

可是網絡設備行業卻一直沒有形成這樣的生態圈。我覺得是兩個方面的原因：

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

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

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

但是網絡設備的發展的相對滯后，越來越趕不上mobile internet/cloud computing時代的步伐。成千上萬的應用被不斷地創造出來，就幾個vendor的一幫苦逼程序猿咬牙應對，肯定是杯水車薪。

信息中心化

信息中心化是對傳統網絡的一大挑戰。Internet的前身，ARPANET，在創建之初就有一個前提：這個網絡是個自制的，無中心的系統，網絡遭受任何局部損失都不會影響其他部分的正常通訊。所以，所有的RFC都圍繞著這個前提來構建，所有的網絡設備也遵循著這一前提來研發。

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

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

轉發

網絡設備的核心是轉發，即packet從接口X轉發到接口Y。轉發的依據是選路，路由協議會告訴系統如何選路。轉發最頭疼的問題是link down，無論是physcial還是logic link down，對于拓撲中的一臺網絡設備來說，link down意味著重新選路并通知其他網絡設備。這直接導致一段時間的丟包。選路時間越長，丟包越多。

link down帶來兩個問題：

1、路由的收斂(convergence)。

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

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

Convergence = 鏈路狀態變化發現時間 + 協議消息傳遞時間 + SPF計算時間 + RIB/FIB更新時間

所需時間：

● 鏈路狀態變化發現時間: ~5ms

● 協議消息傳遞時間: LSA生成時間 + LSA發送時間 + LSA接收時間 + LSA處理時間 + 網絡傳遞時間，~20ms+log(N) N為鄰居數量

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

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

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

在眾多路由協議中，OSPF和IS-IS這樣的鏈路狀態協議，由于每臺設備都擁有局部甚至全局的網絡拓撲信息，收斂速度已算上佳。

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

SDN的優勢

如果能夠將路由信息中心化，即一個云端計算中心實時掌握全網的拓撲狀態，則可以做很多很有價值的處理。比如：

● 加快路由計算的速度。對于OSPF來說，如果SPF能過放在云端計算，計算性能將大有改觀，能夠支持比現有應用更大的網絡。

● 預先做出某種判斷。如果說加快路由計算的速度帶來的好處可能被網絡傳輸的延遲所抵消，那么，當云端擁有了整個拓撲狀態時，可以預先計算出一些特定的解決方案并提前發送給設備。當符合解決方案的情況出現時，設備可以即刻應用解決方案選擇特定的路由。

配置管理

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

配置麻煩是傳統網絡設備的一大問題。

另一個問題是服務器動態遷移帶來的網絡管理問題。這個問題是服務器虛擬化革命帶來的，現在的網絡設備對此基本無解。為了便于說明，我們看下圖：

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

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

但是有一天，機房里的服務器全部都被虛擬化了，物理上已經沒有了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就不用發生改變。

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

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

SDN的優勢

同樣地，有了全網的實時拓撲信息后，SDN可以動態調整網絡的配置，甚至都不需要人工干預。不用細談，想想看：

1、policy auto push

2、traffic shaping

3、load balancing

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

Debug

沒做過網絡設備的人可能不知道網絡軟件的Debug有多么辛苦。一般軟件Debug步驟：

1、信息搜集

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

3、goto 1

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

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

SDN的優勢

SDN太有優勢了，因為集中控制，所以可以：

● 指定相關的網絡設備同時打開需要的debug開關(這個相當關鍵)

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

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

● 建立一個virtualized environment，replay packets

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

后記

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

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

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

● 如果前一點成立，那么第三方的應用市場將有極大的想像空間，也許能催生一批又一批網絡領域的Borland，Adobe，etc.