基于OpenFlowSDN技術(shù)研究

1、軟件學(xué)報(bào) Journal of Software,2013基于 OpenFlow 的 SDN 技術(shù)研究摘 要首先總結(jié)了邏輯控制和數(shù)據(jù)轉(zhuǎn)發(fā)分離架構(gòu)的研究背景,并介紹了其關(guān)鍵組件和研究進(jìn)展,包括 OpenFlow 交換機(jī)、控制器和 SDN技術(shù)然后從 4 個(gè)方面分析了基于 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ò)上,靈活性和擴(kuò)展性很難適應(yīng)網(wǎng)絡(luò)的飛速發(fā)展.網(wǎng)絡(luò)的控制轉(zhuǎn)發(fā)分離架構(gòu)提出由專有設(shè)備來部署高層策略,網(wǎng)絡(luò)設(shè)備在高層策略指導(dǎo)下進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā),減少了網(wǎng)絡(luò)設(shè)備承載的諸多復(fù)雜功能,提高了網(wǎng)絡(luò)新技術(shù)和新協(xié)議實(shí)現(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ò)的運(yùn)行模式,在實(shí)現(xiàn)方式上與上述文獻(xiàn)的要求不完全相同,在面臨類似挑戰(zhàn)時(shí)還需要滿足新的技術(shù)和市

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

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

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

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

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

8、重路由，提供多個(gè)可能的輸出端口、指定 多條備用路徑.DevoFlow功能需要通過修改 OpenFlow 交換機(jī)的流表結(jié)構(gòu)和硬件架構(gòu)來實(shí)現(xiàn),實(shí)際上增加了數(shù)據(jù)平面的部分控制功能,同樣降低了實(shí)際部署過程的通用性. 3.2.3 HyperFlow通過減小控制器的處理開銷,無法從根源上解決單點(diǎn)性能瓶頸問題.多控制器管控的分布式控制平面的設(shè)計(jì)思想是未來基于 OpenFlow 的 SDN 面向較大規(guī)模網(wǎng)絡(luò)部署的必經(jīng)之路. HyperFlow 是基于為廣域網(wǎng)設(shè)計(jì)的分布式文件系統(tǒng) WheelFS 而設(shè)計(jì)的,網(wǎng)絡(luò)事件在不同控制器之間以文件的更新形式來實(shí)現(xiàn). 從實(shí)現(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針對控制平面在可擴(kuò)展性、可靠性和通用性等方面的不足,Onix 31提出了一整套面向大規(guī)模網(wǎng)絡(luò)的分布式SDN 部署方案.網(wǎng)絡(luò)信息庫(network information base,簡稱 NIB)用于維護(hù)網(wǎng)絡(luò)全局的狀態(tài),Onix 的設(shè)計(jì)關(guān)鍵就在于維護(hù) NIB 的分發(fā)機(jī)制,從而保證整個(gè)網(wǎng)絡(luò)狀態(tài)信息的一致性.Onix 主要通過 3 種策略來實(shí)現(xiàn)控制平面的可擴(kuò)展性: (1) 分區(qū). 和 HyperFlow 一

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

11、的網(wǎng)絡(luò). Onix 已經(jīng)作為許多組織機(jī)構(gòu)構(gòu)建商業(yè)應(yīng)用的基礎(chǔ)平臺.從 Onix 的應(yīng)用場景來看, Onix 能夠應(yīng)用于主機(jī)數(shù)量達(dá)到數(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ā)式算法都降低了實(shí)際分區(qū)算法的復(fù)雜度.從分區(qū)結(jié)果來看,

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

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

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