基于OpenFlowSDN技術(shù)研究

1、軟件學(xué)報 Journal of Software,2013基于 OpenFlow 的 SDN 技術(shù)研究摘 要首先總結(jié)了邏輯控制和數(shù)據(jù)轉(zhuǎn)發(fā)分離架構(gòu)的研究背景,并介紹了其關(guān)鍵組件和研究進展,包括 OpenFlow 交換機、控制器和 SDN技術(shù)然后從 4 個方面分析了基于 OpenFlow 的 SDN 技術(shù)目前所面臨的問題和解決思路結(jié)合近年來的發(fā)展現(xiàn)狀,歸納了在校園網(wǎng)、數(shù)據(jù)中心以及面向網(wǎng)絡(luò)管理和網(wǎng)絡(luò)安全方面的應(yīng)用,最后探討了未來的研究趨勢.1 SDN 研究背景:邏輯控制和數(shù)據(jù)轉(zhuǎn)發(fā)分離 傳統(tǒng)因特網(wǎng)把控制邏輯和數(shù)據(jù)轉(zhuǎn)發(fā)緊耦合在網(wǎng)絡(luò)設(shè)備上,導(dǎo)致網(wǎng)絡(luò)控制平面管理的復(fù)雜化,也使得網(wǎng)絡(luò)控制層面新技術(shù)的更新和發(fā)展

2、很難直接部署在現(xiàn)有網(wǎng)絡(luò)上,靈活性和擴展性很難適應(yīng)網(wǎng)絡(luò)的飛速發(fā)展.網(wǎng)絡(luò)的控制轉(zhuǎn)發(fā)分離架構(gòu)提出由專有設(shè)備來部署高層策略,網(wǎng)絡(luò)設(shè)備在高層策略指導(dǎo)下進行數(shù)據(jù)轉(zhuǎn)發(fā),減少了網(wǎng)絡(luò)設(shè)備承載的諸多復(fù)雜功能,提高了網(wǎng)絡(luò)新技術(shù)和新協(xié)議實現(xiàn)和部署的靈活性和可操作性.邏輯控制和數(shù)據(jù)轉(zhuǎn)發(fā)分離的這種管控思想是SDN 技術(shù)的研究基礎(chǔ),前期已經(jīng)在學(xué)術(shù)界引起較大關(guān)注,典型工作包括ForCES 6、4D 7架構(gòu)、RCP 8、SANE 9和 Ethane 10 .基于 OpenFlow 的 SDN 技術(shù)打破了傳統(tǒng)網(wǎng)絡(luò)的分布式架構(gòu),顛覆了傳統(tǒng)網(wǎng)絡(luò)的運行模式,在實現(xiàn)方式上與上述文獻的要求不完全相同,在面臨類似挑戰(zhàn)時還需要滿足新的技術(shù)和市

3、場需求,目前,學(xué)術(shù)界和產(chǎn)業(yè)界已經(jīng)展開大量研究來尋找解決方案.2 基于 OpenFlow 的 SDN 關(guān)鍵組件及架構(gòu) 2.1 OpenFlow交換機 OpenFlow 交換機負責數(shù)據(jù)轉(zhuǎn)發(fā)功能，主要技術(shù)細節(jié)由 3 部分組成:流表(flow table)、安全信道(secure channel)和 OpenFlow協(xié)議(OpenFlow protocol)流表項主要由匹配字段、計數(shù)器和操作這3部分.2.2 控制器 NOX-Based OpenFlow network FlowVisor-Based OpenFlow virtualization2.3 SDN 3 基于 OpenFlow 的 SDN

4、面臨的問題和解決思路 SDN 轉(zhuǎn)發(fā)平面的設(shè)計問題控制平面的可擴展性SDN 控制邏輯的一致性運作模式和演進趨勢問題3.1 SDN轉(zhuǎn)發(fā)平面的設(shè)計問題 OpenFlow交換機采用流表結(jié)構(gòu)處理數(shù)據(jù)分組,為了實現(xiàn)功能的擴展（0.8.9 版只支持最初的十元組-1.0版里的十二元組長度為250比特左右-OpenFlow1.1版里則長達356比特）, 流表項的匹配長度一直在增加,既影響 OpenFlow交換機的性能又極大地增加硬件成本。 OpenFlow1.1版提出了多級流表和流水線結(jié)構(gòu),在一定程度上減少 OpenFlow 交換機中 TCAM 資源的消耗,給報文的匹配增加了靈活性. 控制平面需要知曉每個 Op

5、enFlow 交換機的流水線結(jié)構(gòu),OpenFlow 規(guī)約標準還在不斷更新,控制平面需要維護異構(gòu)的OpenFlow交換機流表結(jié)構(gòu),這將增加控制平面的維護成本和復(fù)雜性.這也是OpenFlow 交換機設(shè)計需要考慮的問題. 3.2 控制平面的可擴展性制約 SDN 控制平面可擴展性的主要原因有以下幾點: (1) 流的細粒度處理需求使得控制器需要響應(yīng)更多的流請求事件. （雖然提前部署，但是動態(tài)的網(wǎng)絡(luò)拓撲和移動節(jié)點）(2) 接入控制、負載均衡、資源遷移等新型應(yīng)用需求逐漸增加到控制平面當中,控制器需要對日趨復(fù)雜的管控功能進行有效的整合,這進一步增加了控制平面的處理開銷. (3) 傳統(tǒng)分布式網(wǎng)絡(luò)設(shè)備僅根據(jù)局部的

6、路由信息來實現(xiàn)路由轉(zhuǎn)發(fā),而控制平面需要維護全局的網(wǎng)絡(luò)狀態(tài)信息,這也使得控制平面的可擴展性不僅需要考慮性能的需求,而且要考慮網(wǎng)絡(luò)狀態(tài)的一致性. (4) 在網(wǎng)絡(luò)規(guī)模增大、數(shù)據(jù)平面轉(zhuǎn)發(fā)設(shè)備數(shù)量增多的環(huán)境下,單控制器設(shè)備可能難以滿足性能需求. 當前針對控制平面可擴展性的相關(guān)研究：3.2.1 DIFANE針對當前基于流的網(wǎng)絡(luò)對控制器依賴過重的實際場景,DIFANE 33結(jié)合了主動和被動兩種安裝流表的方式將流量保持在數(shù)據(jù)平面,從而減小控制器負載.每個權(quán)威交換機管理一定區(qū)域內(nèi)交換機DIFANE 中的分區(qū)規(guī)則和權(quán)威規(guī)則一般僅需在網(wǎng)絡(luò)發(fā)生變化時進行處理,因此不需要頻繁地更新,從而減輕了控制器負載.然而,這種實現(xiàn)

7、方式需要權(quán)威交換機具備規(guī)則安裝功能,而傳統(tǒng)的 OpenFlow 交換機無法實現(xiàn),因此降低了實際部署過程的通用性.3.2.2 DevoFlow Andrew 等人考慮到當前的 OpenFlow交換機流建立過程和統(tǒng)計信息收集過程將會消耗大量數(shù)據(jù)平面和控制平面之間的帶寬,提出的DevoFlow 采取了兩種方式來減小 OpenFlow交換機和控制器的信息交互:規(guī)則復(fù)制和局部操作.規(guī)則復(fù)制方式在流表項中“操作”字段上增加了CLONE標志,標志清零,則匹配按正常情況處理,由硬件TCAM 實現(xiàn);如標志被置位,則由軟件實現(xiàn)建立精確匹配的微流.同時也減少了 TCAM 資源的消耗.局部操作方式包括多路徑支持和快速

8、重路由，提供多個可能的輸出端口、指定 多條備用路徑.DevoFlow功能需要通過修改 OpenFlow 交換機的流表結(jié)構(gòu)和硬件架構(gòu)來實現(xiàn),實際上增加了數(shù)據(jù)平面的部分控制功能,同樣降低了實際部署過程的通用性. 3.2.3 HyperFlow通過減小控制器的處理開銷,無法從根源上解決單點性能瓶頸問題.多控制器管控的分布式控制平面的設(shè)計思想是未來基于 OpenFlow 的 SDN 面向較大規(guī)模網(wǎng)絡(luò)部署的必經(jīng)之路. HyperFlow 是基于為廣域網(wǎng)設(shè)計的分布式文件系統(tǒng) WheelFS 而設(shè)計的,網(wǎng)絡(luò)事件在不同控制器之間以文件的更新形式來實現(xiàn). 從實現(xiàn)和測試的性能來看,在保證控制帶寬和限定網(wǎng)絡(luò)延遲的情

9、況下,HyperFlow能夠處理的網(wǎng)絡(luò)事件小于1000 次/秒,性能還不夠高. .對于網(wǎng)絡(luò)狀態(tài)事件頻繁網(wǎng)絡(luò),或?qū)τ跀?shù)據(jù)中心或較大規(guī)模網(wǎng)絡(luò),HyperFlow有可能面臨性能瓶頸.3.2.4 Onix針對控制平面在可擴展性、可靠性和通用性等方面的不足,Onix 31提出了一整套面向大規(guī)模網(wǎng)絡(luò)的分布式SDN 部署方案.網(wǎng)絡(luò)信息庫(network information base,簡稱 NIB)用于維護網(wǎng)絡(luò)全局的狀態(tài),Onix 的設(shè)計關(guān)鍵就在于維護 NIB 的分發(fā)機制,從而保證整個網(wǎng)絡(luò)狀態(tài)信息的一致性.Onix 主要通過 3 種策略來實現(xiàn)控制平面的可擴展性: (1) 分區(qū). 和 HyperFlow 一

10、樣,隨著網(wǎng)絡(luò)規(guī)模的增大, Onix 通過不同的實例管理每個域 (2) 聚合. 整個Onix 網(wǎng)絡(luò)將形成一個分層的拓撲結(jié)構(gòu),每個Onix 實例需要維護本分區(qū)的路由決策,分區(qū)間的路由決策則由 Onix 實例構(gòu)成的集群共同決策. (3) 一致性和穩(wěn)定性.根據(jù)不同的網(wǎng)絡(luò)需求,Onix 提供兩種方式來實現(xiàn) NIB 的更新分發(fā)機制:帶復(fù)制的事務(wù)性數(shù)據(jù)庫模式和 DHT 模式. 前者的主要目標是提供一種可靠的分發(fā)機制,適用于網(wǎng)絡(luò)事件更新緩慢、對穩(wěn)定性和一致性要求較高的網(wǎng)絡(luò);后者則通過通用 API、軟狀態(tài)觸發(fā)器和坐標機制等 DHT 實現(xiàn)機理,構(gòu)建快速響應(yīng)的分布式拓撲結(jié)構(gòu),適用于事件更新頻繁、對網(wǎng)絡(luò)可用性要求較高

11、的網(wǎng)絡(luò). Onix 已經(jīng)作為許多組織機構(gòu)構(gòu)建商業(yè)應(yīng)用的基礎(chǔ)平臺.從 Onix 的應(yīng)用場景來看, Onix 能夠應(yīng)用于主機數(shù)量達到數(shù)萬量級的較大規(guī)模網(wǎng)絡(luò). 3.2.5 Devolved controller HyperFlow 和 Onix 并未針對控制器如何分區(qū)提出具體的分區(qū)算法.鑒于多路徑區(qū)域劃分問題在圖論中是NP 難問題,Devolved controller 36針對多控制器管控區(qū)域劃分問題提出了兩種啟發(fā)式算法:路徑-分區(qū)算法(path- partition approach)和分區(qū)-路徑算法(partition-path) 這兩種啟發(fā)式算法都降低了實際分區(qū)算法的復(fù)雜度.從分區(qū)結(jié)果來看,

12、分區(qū)-路徑算法使得每個控制器監(jiān)控的鏈路更少,從而減小了控制器開銷;但路徑-分區(qū)算法不需要考慮每個控制器已經(jīng)劃分的鏈路,因此通?？梢缘玫阶疃搪窂?3.2.6 小 結(jié)從上述解決方案來看,目前,基于 OpenFlow 的 SDN 可擴展性研究的主要思路有如下兩點: (1) 修改OpenFlow 交換機的處理流程或硬件架構(gòu),或者給OpenFlow 交換機增加部分控制功能,從而減少控制器和 OpenFlow 交換機之間的信息交互,分擔控制器的處理開銷,提高控制器的可擴展性能. (縱向擴展) (2) 多控制器的分布式管控平面,通過分域管理網(wǎng)絡(luò),控制器之間實現(xiàn)基本的狀態(tài)分發(fā)過程. (橫向擴展), 是SDN

13、可擴展性研究的主流方向,適用于數(shù)據(jù)中心、廣域網(wǎng)等規(guī)模較大的網(wǎng)絡(luò). 3.3 SDN控制邏輯的一致性 控制器和交換機之間存在時延影響一致性；控制邏輯本身執(zhí)行的順序也有可能影響到控制邏輯的一致性；目前針對控制邏輯的一致性實現(xiàn)和驗證等方面的相關(guān)研究：3.3.1 控制器部署位置問題研究控制器的部署位置問題,主要針對 SDN 部署在廣域網(wǎng)的情況.實際上,控制器的部署位置在控制器數(shù)量確定的情況下屬于 NP 難問題,但就目前數(shù)據(jù)平面轉(zhuǎn)發(fā)設(shè)備不多的現(xiàn)狀而言,根據(jù)不同的時延指標計算出最優(yōu)的部署位置是能夠?qū)崿F(xiàn)的. 3.3.2 每報文和每流一致性每個報文（流）傳輸過程中要么執(zhí)行舊的控制邏輯,要么執(zhí)行新的控制邏輯,而不

14、能混雜在一起執(zhí)行.即使控制邏輯具備原子性,即規(guī)則安裝在瞬時同步完成.3.3.3 NICE從程序驗證的角度檢測控制器上的應(yīng)用程序的正確性,實際上側(cè)重于檢測由程序帶來的有可能違反控制邏輯一致性的代碼片段.3.4 運作模式和演進趨勢 以學(xué)術(shù)界為技術(shù)依托,并注重產(chǎn)業(yè)界的推廣和應(yīng)用的運作模式,是基于 OpenFlow 的 SDN 技術(shù)取得快速發(fā)展的根本原因. SDN 在要求邏輯控制與數(shù)據(jù)轉(zhuǎn)發(fā)分離的前提下,數(shù)據(jù)平面應(yīng)當維持盡量簡單的轉(zhuǎn)發(fā)功能.然而,為了增加數(shù)據(jù)平面轉(zhuǎn)發(fā)功能的向后兼容性,OpenFlow 標準不斷擴充轉(zhuǎn)發(fā)平面匹配字段,這進一步增加了未來OpenFlow交換機的硬件設(shè)計成本,在一定程度上也增加了控制平面維護的復(fù)雜度,不利于 OpenFlow 的未來演進發(fā)展.在 OpenFlow 標準的不斷演進中,是維持簡單的硬件結(jié)構(gòu)還是在OpenFlow 硬件中繼續(xù)增加更多的功能,需要學(xué)術(shù)界和產(chǎn)業(yè)界的共同關(guān)注.文獻43考慮到目前數(shù)據(jù)平面的設(shè)計復(fù)雜趨勢,提出了一種新的概念:網(wǎng)絡(luò)結(jié)構(gòu)4 基于 OpenFlow 的 SDN 應(yīng)用 4.1 面向校園網(wǎng)的