現如今，在網絡界炒作的最熱鬧的概念莫過于軟件定義網絡(SDN, Software Defined Networking)。一時間，SDN風生水起，凡是提到網絡，言必稱SDN。仿佛有了SDN，從此網絡就要走上一條鋪滿鮮花的康莊大道了。但熱鬧了一陣子之后，SDN的應用卻是雷聲大，雨點小，只聽樓梯響，不見人下來，真正端得上臺面的只有可憐兮兮的Google一個案例，用來連接Google各個數據中心的B4 WAN網絡，勉強算得上差強人意，卻也看不出有什么普遍推廣的意義。其他的所謂殺手級的應用(Killer Application)不過是存在于宣傳家的噱頭和運行在研究者實驗室的Mininet上。也許如下幾點可以解釋其中的原因。

首先，SDN是模式遷移(Paradigm Shift)的大動作。SDN所謀者大，不是原有技術之上的添磚加瓦，也不是原有系統框架的修繕補闕。SDN時代的到來，網絡界將面臨數十年未有之變局。正如Thomas S. Kuhn的著作The Structure of Scientific Revolutions中所描述的科學革命的模式遷移一樣，SDN是網絡技術領域的結構性的革命性的模式遷移。這種模式遷移都不是一朝一夕能夠完成的?？茖W發展的歷史上，從Ptolemaic的地心說到Copernicus的日心說(Copernican Revolution)，從Aristotle的力學到Newton的力學，從Newton的萬有引力到Einstein的相對論，以及原子理論的發現，無不經過了長期的痛苦的掙扎，才得以從舊的理論過渡到新的理論。雖然SDN不能和上面列舉的科學革命相提并論，但是SDN絕不是傳統L2/L3網絡的development-by-accumulation式的量變過程。眾所周知，SDN最基本的原則包括隔離控制平面(Control Plane)和數據平面(Data Plane)，管理集中化(Management Centralization)，和可編程(Programmable)。這就決定了SDN是另起爐灶從而重建傳統網絡的運行模式、管理模式和開發模式的質變跳躍。與此同時，SDN的出現，也改變了網絡提供商和客戶之間的關系。交換芯片(ASIC)商業化的實現，網絡客戶有機會實施白盒子(White Box)策略。在建設網絡設施時，能夠以BYOD( Bring Your Own Device )和BYOA( Bring Your Own Application )的方式采購組合不同供應商的軟硬件產品，不僅節約了成本，也大大減少了網絡客戶與單一供應商綁定的風險。傳統網絡供應商的收益也因此受到影響，利益所關，他們會或多或少抵制這一轉變的進程。所有這一切都決定了SDN不可能一蹴而就。

其次，SDN的實現面臨諸多挑戰。控制平面和數據平面的分離使得Controller要管理成千上萬臺交換機，并且還要滿足網絡規模動態的(Dynamic)可伸縮的需求。實現這種可伸縮性(Scalibility)，對于大規模的網絡，當然不是單獨的一個Controller所能承受之重，需要采取分而治之(divide and conquer)的策略，即將網絡分成不同的部分，由多個Controller分別管理。這又會引起其他問題，為了向上層應用提供統一的網絡視圖(Network View)和北向開發接口(North-bound API)，使得上層應用的開發者可以只面對單一的邏輯的基于Controller的應用開發平臺，Controller之間需要做復雜的數據同步，這些數據包括網絡拓撲變更、鏈路端口狀態、流量(Traffic)統計信息等等。Controller也可能因故障退出或宕機，所以，還必須有相應的機制保證系統的可靠性(Reliability)，比如采用Master/Slave的架構，這無疑又增加了數據同步的復雜性。實踐證明，越是復雜的系統越是難以部署和維護。必須使用有效的技術，來解決可伸縮性和可靠性的問題，從而得到高可用性(Availability)的SDN解決方案。聲勢浩大的Open Source項目OpenDaylight迄今也才發布一個開發者版本，也許可以作為SDN具有高難度和高挑戰性的一個明證。SDN的實現還要克服硬件的限制，目前，市場上真正的SDN的芯片還不多見。比如說所謂的OpenFlow交換機，大都是采用變通的方法來實現的。因為昂貴的TCAM表的大小非常有限，就只能拿交換機L2的轉發表(FIB)和L3的路由表(RIB)來湊數。這樣一來，Controller給交換機下發的Flow Entry必須要和轉發表的表項或路由表的表項相一致，因此Flow Entry的匹配條件(match)和動作(action)就要受限于MAC表和路由表的表達能力。開發者會不經意間發現，表面上做的東西看起來是高大上的OpenFlow和SDN，到頭來玩的還是原來的L2的轉發(Forwarding)和L3的路由(routing)。就好像夢中以為自己是在開飛機了，醒來一看屁股底下坐的還是原來的拖拉機埃因此，Google的B4網絡就只好使用自己定制開發的OpenFlow交換機。另外，SDN還要實現自身網絡與外部L2/L3網絡的路由轉換，以達到SDN網絡和L2/L3網絡的互聯互通的目的。

最后，網絡向SDN的變遷(Migration)尚沒有可行的廉價的解決之道。盡管SDN的優越性和美好前景被傳說的活靈活現。如利用SDN可以大規模減少客戶的CAPEX(Capital Expenditure)和OPEX(Operating Expense)，提高設備的投資回報率(Return on Investment)，如2015年SDN的市場規模將達到幾十億美元。但對客戶而言，包括運營商、云計算數據中心(Data Center)，以及企業，都不會傻到立馬將自己網絡基礎設施切換到SDN模式，因為對自身業務的影響和風險沒有辦法準確評估。另外，從上面對SDN的技術難度的分析可以看出，傳統網絡到SDN的轉換也絕非易事。在傳統網絡和SDN之間并不存在一個雙向開關，只要簡單地把這個開關置為SDN模式就萬事大吉了，必要的時候，還可以再切換回來。因此，大多數客戶對SDN還是會選擇謹慎的態度，或持續觀望，或以小的項目進行探索性的嘗試。

從另一方面講，網絡的確到了不得不變革的時候了，這基本上是一個業界的共識。一方面，傳統網絡的控制平面分布在五花八門的不同提供商的設備上，通過各種網絡協議將這些設備連接在一起，需要一個設備一個設備的人工配制。因此，這是一個靜態配制的復雜的脆弱的系統，部署一個網絡系統頗費時日，往往需要幾天甚至幾個星期的時間。難得的是，網絡的這一模式已經保持了20多年基本沒有變化了。另一方面，運行在網絡平臺上的應用伴隨著互聯網革命的興起卻發生了深刻的變化。尤其是云計算和移動計算的到來，要求應用或服務的部署要以妙級的速度完成，而不是幾天或幾個星期。而且這些服務或應用要求很高的彈性(Resiliency)和靈活性(Flexibility)。如臭名昭著的火車票網上訂票系統12036就是沒有解決好服務的彈性和靈活性的問題，在節假日的售票高峰期，系統基本處于癱瘓狀態。大規模多租戶云計算數據中心(Multi-tenant Cloud Computing Data Center)要求隔離不同租戶的應用，而動態變化的應用之間要建立成千上萬的網絡連接。比如，一般地，一個Web/Cloud Application分為表示層(Presentation Tier)、業務邏輯層(Business Tier)和數據層(Data Storage Tier)。這樣的層次結構就是為了滿足應用的靈活性和安全性。在三層之間必須建立多條網絡連接以進行數據交換。網絡連接的建立需要一個設備一個設備的人工配置。隨著應用數量的增長，當前的靜態的網絡模型承受的壓力也會越來越大?；ヂ摼W應用和服務的這種變化和網絡模型的不變是一個尖銳的矛盾，傳統的網路模型面對互聯網的應用和服務需求就好像電影《讓子彈飛》中用馬匹來拖動沉重火車頭一樣力不從心。雖然，電影里面看起來幾匹馬拉著火車頭在鐵軌上歡快地奔馳如飛，但電影畢竟是電影。解決這個矛盾的技術是虛擬化(Virtualization)，計算資源和存儲資源的虛擬化已經基本完成，因此，普遍認為，網絡業已成為虛擬化和云計算的最后一塊絆腳石，而SDN是解決網絡虛擬化的有效手段?？偠灾瑢τ赟DN的起步公司(Start-up)而言，SDN是大勢所趨，一定會發生，所以要有信心;SDN是一個過程，不會馬上發生，所以要有耐心。我篤信，一定會有致力于SDN的起步公司在網絡模式遷移的大潮中取得巨大的成功，甚至會替代當前網絡產業界如Cisco那樣的大鱷。但究竟鹿死誰手呢?我沒有足夠的數據來給出可信的分析和預測。以下的幾點看法是我的一些小見識。

不能迷信SDN。SDN不是像一些中醫神棍胡吹的包治百病的“神藥”，人世間，這樣的“神藥”從來就沒有存在過。SDN是新的模式(Paradigm)，所以很適合用來空談吹牛。但SDN的確給出了特有的方法論和相應的工具或模型，但從來不是具體的解決方案。所以，起步公司要根據用戶的具體需求，給出自己的SDN解決方案，開發出相應的產品，來幫助用戶解決問題，在給用戶帶來實實在在的價值的同時，實現自己的價值。在開始一個SDN項目之前，要清楚的知道期望解決的問題是什么，達到的目標是什么，得到的好處是什么。B4之所以成功，就是因為問題和目標非常明確，那就是通過基于SDN的流量工程(Traffic Engineering)提高WAN的物理連接的利用率。#p#

不能為SDN而SDN。如上文所述，在網絡模式遷移的浪潮中，我們要理解這一根本變化對網絡世界的意義和影響。抱殘守缺，腳步向前走，眼睛往后看，都不會有所作為。這就意味著我們不能再固守原有的L2/L3的網絡技術了，不能將SDN視為對現有網絡模型的重新實現。若認識水平局限于此，就將錯過SDN的大風景。比如，如果把下面的例子看作SDN的全部就大錯特錯了：基于OpenFlow/Open Virtual Switch的技術框架，做一個Web界面，通過簡單的Controller，以OVSDB方式配置OpenFlow的交換機(如創建Bridge，將端口加入Bridge)，并向Controller控制的交換機下發OpenFlow Entries，更新交換機L2表和L3表，最終定義L2轉發的行為和L3路由的行為。這不過是用Web GUI替代原來的ssh/telnet，非但沒有簡化配置，甚至配置變得更為復雜。因此，只是為SDN而SDN，不過是新瓶裝老酒，沒有任何價值。其實，對于開發者而言，相對過去的分布式的控制平面，SDN帶來的最大的好處當然是可編程，而可編程的基礎和前提是可以通過Controller提供的應用開發平臺的API獲取全局的網絡視圖(View)，包括網絡拓撲(Network Topology)、網絡設備和連接的狀態以及流量統計數據(Counters)。有了這些，就能以直接的方式比較快的開發出更具智能的網絡應用，如流量工程(Traffic Engineering)、負載均衡(Workload Balance)、防火墻等。另外，還有一些更為具體的應用，比如兩個運營商的網絡之間只允許交換特定服務(如Web Application)的數據流(Application-Specific peering)，將特定的數據流重定向到事先配置好的目的網絡(Redirection Through Middleboxes)?？梢哉f，網絡視圖之于SDN，就如同地圖和交通數據之于汽車導航系統一樣必不可少。汽車導航系統當然要根據地圖和交通狀況來為用戶算出合理的路線(Route)，若把每輛使用導航系統的車看作是網絡中的數據包(Frame/Package)，那么，這看起來不就是流量工程的概念嗎?

利用開源(Open Source)的力量。與SDN相關的開源的項目著實不少，Controller的開源項目就有NOX/POX、NodeFlow、Floodlight、OpenDaylight、Ryu、ovs-controller等。L3路由系統有Xorp、Quaqqa和EXaBGP等。另外，還有一些特殊的應用，如Google的RouteFlow提供了基于OpenFlow的虛擬IP路由服務(virtualized IP routing services)，很有想象力(+微信關注網絡世界)，而Flowvisor可作為在OpenFlow交換機和Controller之間的代理服務，實現虛擬化的網絡切片(Slice)。Frenetic竟給出了一種網絡編程語言，支持以模塊化的方式開發網絡應用，很值得關注。文獻[2]使用Frenetic和BGPExa實現了SDX(Software Defined Internet Exchange)的實驗系統。而Google的B4也用到了Quagga和Onix。有些SDN開源項目對于上文提的SDN的技術挑戰給出了解決方案，因此，利用開源，可以使資源非常有限的起步公司更加專注在開發網絡應用來滿足用戶需求上。Brocade基于OpenDaylight的Helium版本，發布了自己商業化的Vyatta Controller，這是一個很值得SDN的起步公司關注的事件。開源的精神是開放、共享和交流，起步公司在利用開源資源的同時，別忘了為開源做出應有的貢獻，這也是在業界增加影響力的有效途徑。

以做互聯網產品的精神做SDN。在互聯網公司有過工作經驗的人都了解，互聯網產品尤其是移動設備上面的應用的研發與其他軟件的研發有些許不同。最突出的一點就是這些應用和服務的設計和開發完全以用戶體驗(UX, User eXperience)為中心，這一趨勢可能是受到Apple或者說是Steve Jobs的影響。一言以蔽之，好的用戶體驗就是做出來的產品卓爾不群(Good and Different)，如圖中的那把SENZ的傘就是一個較好的例子，它與眾不同，且美觀實用，是我比較喜歡的設計。而在設計研發互聯網產品的過程中，互聯網公司對用戶體驗的追求具體表現在：第一，制造需求。不期望用戶完全了解需求，而認為用戶并不真正知道想要的需求是什么，或者說對需求是模糊的，因此，需求要靠開發團隊發掘出來，在制造需求時，有的公司更多的是靠經驗和直覺，如Apple;有的公司更多的是靠大規模的數據分析，如Google。第二，消除痛點(Pain Point)。不斷地發現用戶在使用產品過程中的所謂痛點，這些痛點，是產品持續改進的動力和目標。第三，崇尚簡約。讓用戶在完成一項功能時，所做的操作盡可能的簡單，且容易明白。Apple的產品常常追求極致的簡單，使得從孩童到老嫗都可以輕而易舉使用iPhone/iPad執行想要的功能。支撐產品使用簡單的背后是開發團隊的才華、創造能力(Creativity)、以及必不可少的艱辛付出。第三，注重細節。對產品的任何部分，哪怕看起來多么的微不足道，都要精雕細琢，精益求精，做得好到不能再好。對照以上四點，讓我們檢查一下當前的網絡系統：第一，有的網絡需求是很明確的，無須發掘，如在IaaS的云計算數據中心中，虛擬機(Virtual Machine)的動態遷移的需求，VLAN的4096個編碼空間已不足用的問題。另外，可以將網絡用戶按照不同的需求梳理分類，分別發掘他們最關切的需求，做到自己的產品或解決方案中。讓用戶看到自己的產品和解決方案之后，會眼前一亮，立馬感覺這就是TA想要的。第二，當前網絡的痛點可謂數不勝數，已經到了虱子多了不癢的程度，需要改進的地方太多，這正是SDN存在的理由。第三，當前網絡的管理配置繁冗復雜，讓管理員疲于奔命，苦不堪言。第四，SDN往往是一個很大的系統，若對系統的每個部分都做到完美無缺，真不是一件容易的事兒。比如說，交換機的失敗多數情況是由于軟件的錯誤引起的，因此，如果對于交換機操作系統的每個細節，不放過任何的內存泄漏和core dump的因素，那么系統的可靠性和穩定性將會大幅提升。我想，對于以上四點，當別人做不到或做不好的時候，你做到了，而且做的很好。那你就是江湖中故老相傳的獨孤求敗，求一敗而不可得，想不成功，不也是很難嗎?!

參考文獻：

Thomas S. Kuhn. The Structure of Scientific Revolutions. The University of Chicago Press, 1996.

Thomas D. Nadeau and Ken Gray. SDN: Software Defined Networks. O’Reilly Media, Inc., 2013

SDX:A Software Defined Internet Exchange. Arpit Gupta, Laurent Vanbever, Muhammad Shahbaz, Sean P. Donovan, Brandon Schlinker, Nick Feamster, Jennifer Rexford,, Scott Shenker, Russ Clark, Ethan Katz-Bassett. SIGCOMM’14, August 17–22, 2014, Chicago, IL, USA. Available athttp://gtnoise.net/papers/2014/gupta-sigcomm2014.pdf

OpenDaylight.http://www.opendaylight.org/

RouteFlow.https://sites.google.com/site/routeflow/

Frenetic.http://frenetic-lang.org/

Software Defined Networking. https://www.coursera.org/course/sdn

Christopher Monsanto, Joshua Reich, Nate Foster, Jennifer Rexford, David Walker. Composing Software-Defined Networks. Available athttp://frenetic-lang.org/publications/composing-nsdi13.pdf

Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, Subbaiah Venkata, Jim Wanderer, Junlan Zhou, Min Zhu, Jonathan Zolla, Urs H?lzle, Stephen Stuart and Amin Vahdat. B4: Experience with a Globally-Deployed Software Defined WAN. SIGCOMM’13, August 12–16, 2013, Hong Kong, China. Available athttp://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf

What is a Software Defined Network.https://www.youtube.com/watch?v=lPL_oQT9tmc&feature=youtu.be

Software Defined Networking(SDN) & Network Virtualization. COPYRIGHT 2013 ALCATEL-LUCENT.

Siamak Azodolmolky. Software Defined Networking with OpenFlow. Packt Publishing, 2013.

SDN The Next Steps. digital spotligh. Network World. Available athttp://resources.idgenterprise.com/original/AST-0124359_NWW_SDN3_6_25_14.pdf

Brocade unveils OpenDaylight SDN controller.http://www.networkworld.com/article/2686047/sdn/brocade-unveils-opendaylight-sdn-controller.html