隨著社會的進步，網絡規模急劇膨脹、傳輸數據量的劇烈增長和應用類型的持續增多，導致傳統 IP 網絡的結構和功能日趨復雜，尤其是作為網絡核心的路由器，通過不斷增長的 ＲFC 數量對現行網絡進行修補和網絡協議的多樣化［1］，使其變得臃腫不堪。這與路由器最初的定義目標背道而馳。與此同時，由于專有的硬件設備和操作系統，網絡在很大程度上是封閉的，從而造成了創新的艱難。但是，縱觀當前網絡行業的發展趨勢，現有網絡中所大量部署的網絡設備和網絡協議也將在相當長一段時間內延續現有的網絡體系結構［2］。

為解決當前傳統網絡所面臨的上述問題，世界各國都開始了對下一代互聯網的研究，比如美國的 GENI［3］、歐盟的 FIＲE［4］、日本的 JGN2plus［5］和我國的 SOFIA［6］等。在經過包括 ForCES［7］、4D［8］架構、ＲCP［9］、SANE［10］和 Ethane［11］在內的前期工作基礎上，于 2008 年，斯坦福大學的 Nick McKeown 教授提出了 OpenFlow［12］概念，并逐漸推廣到 SDN 概念。其核心思想是: 將路由決策控制功能從傳統 IP 網絡互聯節點解耦出來，即與數據轉發平面分開，支持集中化的網絡狀態控制，實現底層網絡設施對上層應用的透明，能夠通過軟件編程實現硬件對數據的轉發規則的控制。這是一種新型的網絡架構，設計之初是為了方便研究員在真實的網絡流量環境中利用現有基礎設施來進行實驗，驗證其觀點，進行創新［2］。

SDN 一經提出便受到了學術界和產業界的高度重視，給傳統網絡帶來巨大沖擊的同時，也為解決傳統網絡所面臨的問題提出了新的思路。

1 基于 OpenFlow 的 SDN 組件

基于 OpenFlow 的 SDN 構架主要由兩部分組成:

OpenFlow 交換機和控制器。OpenFlow 交換機是數據轉發平面，根據流表負責數據的轉發; 而控制器則是路由管控平面，負責抽象底層設備，維護全網視圖。如圖 1所示?！?】

OpenFlow 交換機至少包含 3 部分: 流表 \\( FlowTable\\) 、安全通道 \\( Secture Channel\\) 和 OpenFlow 協議\\( OpenFlow Protocol\\) 。其中流表主要由流表項組成，即匹配字段\\( Match Field\\) 、計數器\\( Counter\\) 和操作\\( Action\\)等; 安全通道則用于連接交換機和控制器的通道接口，負責兩者互相通信; 而 OpenFlow 協議則是為控制器提供了一種標準格式來配置和管理 OpenFlow 交換機。

控制器\\( Controller\\) : 如圖 2 所示，在 ONF 給出的軟件定義網絡體系架構中［13］，控制層中的控制軟件，與基礎設施中的交換/路由等網絡設備經由控制和數據平面接口交互，與應用層各種 APP 經由開放 API 交互?？傊?，控制器對下負責底層網絡設備的抽象，對上負責提供并維護全局視圖，提供應用層的各種 APP 的接口?！?】

2 現有控制平面擴展性問題及解決

隨著 SDN 關注度的提升，隨之而來的是研究投入的加強和應用的增加，機遇增加的同時也帶來了挑戰。

如在擴展平面方面，隨著網絡規模的增加，一味提升集中控制器的性能不能解決，必須增加控制器數量來分擔任務; 再者控制器數量的增加，又會帶來控制器的放置問題，根據不同的性能指標，放置問題也會多種多樣。下面將列舉出 SDN 控制平面所遇到的問題即解決方案，介紹 SDN 擴展平面的發展。

2. 1 控制器數量的變化

在 SDN 提出初期，其控制平面的一種設計就是將所有的控制功能移到一個集中控制器上，即單控制器。

一經提出，研究人員便將全部精力集中在控制器性能及應用的高效性、創新性和實用性上，尤其是在數據中心網絡，經常利用中央控制器來進行協調和資源調度，其在文獻［14 ～ 20］中均有體現。文獻［14］中實時地為流再次計算新的路徑，文獻［16］中強制性的為包路由使其能夠符合策略，文獻［18］中主服務器存儲分布式文件系統的元數據\\( Metadata\\) ，通過大量實驗拓撲結構證明，在大多數情況下，單控制器足夠管理一個較大的網絡。

然而將來是大數據時代，在對大規模網絡進行管控時，控制器中存儲的數據量過大，所需處理的請求事件過于頻繁，必將導致 SDN 控制器流表的爆炸性增長，流的映射及查詢開銷劇烈增加; 同時，單一控制器的處理能力及 I/O 能力均有限，在面對大規模網絡的復雜應用，必然會產生系統性能瓶頸。文獻［19］介紹了一種解決方案，即將簡單的控制功能移植到交換機上，減少了提交給交換機的事件請求，諸如此類思想的產品有 DIFANE 和 DevoFlow。雖也提高了控制平面的可擴展性，但交換機需要特殊的 ASIC\\( Application －Specific － Integrated Circuits\\) 和一般性能的 CPU 來實現這些簡單功能，這就需要生產商的支持，從而增加了難度，且這種思想也違背了 SDN 設計理念。

早期關于 SDN 的提議均是基于流的，其都會產生額外的流初始化時延，文獻［20］中詳細闡述了單控制器在擴展性方面所面臨此的問題，即若網絡直徑足夠大，控制器的部署位置同樣會對流的建立延遲產生影響。

圖 3 較好地說明了此問題: 相比右圖，左圖中僅有一個控制器，當跨區域建立流表和通信時均會產生額外的時延。早期在 NOX［21］上進行的基準實驗，表明單控制能每秒處理 3 000 個流初始化，其中包含 0. 1 ms 的流安裝時間。在該種情況下，多控制器的思想便應運而生。其思想是用多個獨立的控制器來替代一個全能的控制器，每個控制器只負責部分網絡，使其共同管控整個網絡，邏輯上相當于一個中央控制器?！?】

2. 2 控制器布控問題

多控制器解決了單控制器的性能瓶頸問題，但同時也帶了許多新的問題，其中最相關的是控制器的數量和部署以及全局狀態的一致性問題。

部署問題，即對于給定的網絡拓撲，控制器該如何放置、每個控制器管理哪些交換機等。以不同的性能指標為標準，比如可靠性、安全性和一致性等，又有不同的放置方案。國外已有了相關研究，文獻［22］通過大量的實驗，以平均時延和最壞時延為衡量標準，針對不同拓撲結構，來研究控制器所需數量以及控制器在拓撲中所放置的位置對時延的影響，也證明了隨機部署與科學部署對時延的影響。但本文并未得出一個一般性的、適用于所有的網絡拓撲的結論，控制器的數量和位置隨拓撲的變化而變化。

而控制器的部署，重點是分區問題，即對于廣域網，需要將其劃分為多個子網，多個控制器分別管理其域內交換機。文獻［37］中，介紹了更具有普遍性的多控制器管控網絡的區域劃分算法，引入了 DevolvedController 的概念。提出了 Path － partition 和 Partition －path 兩種啟發式算法，前者先路由再劃分區域; 而后者是先劃分區域再路由。通過測試分析，兩者各有優略，前者能夠使每個控制器監控的鏈路數更少，但由于其需要考慮每個控制器中已劃分的鏈路，故其所找到的路徑更長，更適合常規網絡，而后者更適合非常規網絡，如 fat － tree 網絡等。具體情況需具體分析，恰當地選取更合適算法。

時延只是控制器部署所需考慮的一個方面因素，可靠性也是一個必須考慮的因素?？煽啃灾饕侵缚刂破髋c交換機、控制器之間的通信。之間某條鏈路或者交換機出了故障，都會破壞正常的數據轉發或者全局的一致性。文獻［38］提出了“受保護”交換機概念，使故障快速恢復的可能性最大，但只適合單控制器情況。文獻［23］提出了一種貪婪的控制器放置算法，但其可靠性近似公式準確性欠佳。而文獻［24］在兩者基礎上提出了基于聚類的控制器放置算法和基于貪婪的控制器放置算法，分別實現了全局和局部的可靠性優化效果。但其結果與隨機放置算法相對比，無法證明其算法的優勢。文獻［25］也提出了類似的控制器優化部署，在一定程度上增強了故障恢復能力，但也均有局限性。

另外，在 SDN 控制平面安全性方面，相比前者，相關研究較少。集中化的控制面承載著網絡環境中的所有控制流，是網絡服務的中樞機構，其安全性直接關系著網絡服務的可用性、可靠性和數據安全性，是 SDN安全首先要解決的問題。文獻［26］提出了 AVANT －GUAＲD 這種新的架構，通過在 OpenFlow 數據平面增加相關功能，來應對 SDN 安全問題。其能夠抵御侵透攻擊，比如 TCP － SYN 洪，增強了 SDN 網絡的彈性和可擴展性。但為了實現此功能，OpenFlow 交換機需足夠的指令來處理模塊操作。文獻［27］提出了一種檢測 DDOS 攻擊的方法; 文獻［28］則設計了一種識別大的聚集流量功能，用于檢測網絡異常的方法。

2. 3 SDN 控制器架構

近年來，學術界和工業界研究人員已開始探索建立分布式 SDN 控制器架構，用于解決控制平面所面臨的擴展性和可靠性問題，使得網絡的運營管理達到最佳的狀態。文獻［29］對控制器的平面結構做了高度的概括和總結可分為 3 類: \\( 1\\) 集中控制器，即單控制器，如 NOX 等。\\( 2\\) 去中心化結構，平面類型，每個控制器地位相等，根據每個控制器的邏輯拓撲視圖，又可分為兩類: 一種為每個控制器擁有相同的全局試圖，如HyperFlow、Onix; 另一種為每個控制器只擁有局部試圖。\\( 3\\) 分層結構，即控制器分為不同的等級，等級越低監控的區域越小，等級越高監控的范圍越大，如Kandoo。

2. 3. 1 單控制器模型單控制器比較成熟的模型有 NOX［30］、Beacon［31］、Meastro［32］等，其在一定程度上能代表單控制器模型。

文中將從各個單控制器開閉源、開發語言、是否支持OpenFlow 協議、是否支持多線程、開發單位及適用化境等進行比較?！?】

2. 3. 2 多控制器控制平面模型HyperFlow［33］，基于事件的分布式控制平臺。HyperFlow平面采用邏輯集中物理分散方式，是 OpenFlow 方面的第一個分布式控制平面。HyperFlow 通過在網絡中部署多臺控制來管理 OpenFlow 交換機，每臺交換機同步共享全局網絡視圖的同時，只需管理本區域內的OpenFlow 交換機?？刂破髦g通過數據信道、控制信道和自身的信道，發布/訂閱模式，來互相通信。經分析測試結果發現: 在足夠的控制帶寬下，HyperFlow 能夠處理頻率 ＜ 1 000 次/s 的網絡事件，略有不足; 再者，全網視圖的更新和控制器之間的信息發布與傳輸時延緊密相關等等。所以，HyperFlow 在面臨一致性要求高、網絡事件更新頻繁之類的大型網絡中，可能會面臨瓶頸。

Onix［34］在可靠性、可擴展性和通用性方面，更勝一籌。Onix 網絡構架由物理網絡基礎設施、網絡連接基礎設施、Onix 和網絡控制邏輯等部分組成，通過 NIB\\( Network Information Base\\) 來維護網絡全局的狀態，通過 3 種策略來實現控制平面的可擴展性: 分區、聚合、一致性和穩定性。此外，Onix 的全局網絡視圖分布在低層次不同的分布式控制器上，在上層邏輯節點進行聚合決策。雖 Onix 的 NIB 采用的是較成熟的分布式系統，但也繼承了其缺點?？傮w而言，Onix 是基于OpenFlow 的 SDN 發展的一個方向: 多控制器分區管控。使用 Python/C ++ 語言基于 Linux 平臺上開發，用于解決較大規模真實網絡的部署方案。

Kandoo［35］一種分層結構，其中有兩種等級的控制器: 擁有全局視圖的邏輯中心根控制器\\( Ｒoot Controller\\)和只擁有局部視圖的局部控制器\\( Local Controller\\) ，每個交換機只能被一個 Kandoo 控制器控制，每個 Kandoo控制器可控制多個交換機。其使用 C、C ++ 和 Python共同開發，較低的內存成本，支持動態可加載的插件，插件可由 C、Python 和 Java 實現。支持 OpenFlow 協議實驗證明，單 Kandoo 控制器在 Xeon E7 － 4807 使用單線程，可接收來自512 個交換機超過每秒1 MB 的吞吐量?！?】

3 研究方向展望

傳統網絡創新的艱難和緩慢，與 SDN 形成了鮮明的對比，引起了越來越多的機構和組織的關注。但其帶來機遇的同時也提出了挑戰，尤其是可擴展性方面。

文獻［36］指出可擴展性既不是 SDN 引起的，也不是SDN 特有的，可在不失去 SDN 優勢的同時解決可擴展性問題。但根據不同的性能指標，擴展性方面的側重類型也不同，在可靠性和區域劃分方面研究的較多，但安全方面卻較少，屬于起步階段。一個成熟的網絡應該全面發展，不能厚此薄彼。再者，如上所述的 SDN控制平面的 3 種架構，每種均有其適用環境、優點和缺點，但未來發展的趨勢并未達成共識，有利于促進其共同發展的同時，也不利于統一化標準的制定，如 API等。最后，SDN 提供了一個新的網絡架構，但在發展中也遇到了問題，這些問題在傳統網絡發展中也曾遇到過，如區域的劃分，控制器\\( 服務器\\) 的部署等等，這些解決方法可借鑒到 SDN 網絡當中。

4 結束語

本文介紹了基于 OpenFlow 的 SDN 網絡的發展背景和趨勢以及其組件，并重點介紹了 SDN 控制平面可擴展性方面遇到的問題及解決方案，對 SDN 可擴展性方面未來研究方向進行了展望。在現階段，虛擬控制器的發展也成為了熱點，下一階段應結合多控制器和虛擬化中的虛擬控制器，提出針對大規模網絡的資源調度問題的解決方案。

參考文獻

［1］ 張順淼，鄒復民． 軟件定義網絡研究綜述［J］． 計算機應用研究，2014，30\\( 8\\) : 2246 －2251．
［2］ Mckeown N，Anderson T，Balakrishnan H，et al． OpenFlow:enabling innovation in campus networks ［J］． ACM SIG-COMM Computer Communication Ｒeview，2008，38 \\( 2 \\) :69 － 74．