面向SDN和NFV融合機制的標準化業務鏈平臺研究

丁萬夫,須成忠,古 亮

1(中國科學院 深圳先進技術研究院,廣東 深圳 518000)2(深信服科技股份有限公司,廣東 深圳 518000)

1 引 言

網絡報文在傳輸過程中,只有依次按序經過定制的業務功能,才能確保網絡可以按照設計的要求,為用戶提供更加安全、可用的網絡服務[1].業務鏈中的業務節點通常包括防火墻、入侵檢測、負載均衡等等[2,3].因此,如何保證網絡流量按照業務邏輯所要求的既定順序穿過這些業務節點,以實現所需要的安全業務,已成為學術界和工業界的研究熱點.

業務鏈在企業場景和運營商場景下有大量的應用訴求,其中應用較多的兩大場景是:

1)云計算數據中心場景[4].業務鏈功能可以為數據中心的租戶提供多種網絡功能的業務鏈編排.云計算數據中心的主要特點是多個租戶共存,每個租戶對業務鏈編排的需求差異很大,因此業務鏈需具有易擴展及靈活部署的特點.

2)Gi-LAN場景[5].隨著網絡數據流量的顯著增長,運營商在Gi-LAN場景下需要應對網絡流量的激增壓力以及用戶的個性化需求,網絡業務鏈不僅需要具有彈性伸縮的特點,還需要針對用戶的網絡流量進行更加精細化的流量管控.

傳統業務鏈部署通常采用專用的硬件設備,基于物理拓撲,通過手工配置路由策略,將安全設備部署到業務流量路徑當中,這種部署模式存在高成本支出和高運維費用等一系列亟待解決的問題[6].軟件定義網絡(SDN,Software Defined Network)[7,8]的概念由斯坦福大學提出.其核心思想是將轉發設備的數據平面和控制平面進行分離,并讓控制邏輯以軟件方式運行于邏輯上獨立的控制環境.SDN的本質是邏輯集中控制面的可編程化[9,10].網絡功能虛擬化(NFV,Network Function Virtualization)[11]的概念由電信運營商提出.其核心思想是通過使用通用性的硬件平臺以及虛擬化平臺運行網絡虛擬化單元,從而大幅降低網絡設備的成本.NFV的本質是實現新業務的快速開發和部署[12].

本文面向SDN和NFV的融合機制,首先提出了一種基于標準化架構MANO[13]的業務鏈平臺,然后分別對控制平面和數據轉發平面的關鍵技術進行研究,解決了業務鏈平臺的可靠性和可擴展性等問題.

2 相關工作

2.1 業務鏈平臺架構的研究

當前網絡中使用的各種設備,均是基于私有平臺部署的,各種專有設備之間的硬件平臺無法復用,而設備擴容需要采購硬件,且縮容后又存在硬件平臺閑置的問題[14].在NFV理念下,所有硬件設備轉變為應用程序,能夠部署在基于x86標準的物理服務器上,通過將軟硬件進行解耦,所有應用均能夠實現快速的擴縮容的功能,進而顯著提升部署彈性.NFV雖然有諸多好處,但其會帶來跨廠商的協同和互通問題,進而提高運維成本[15].為此,歐洲電信標準協會ETSI成立了網絡功能虛擬化管理和編排(NFV MANO)標準組,致力于降低NFV推廣后帶來的維護復雜性.如圖1所示,MANO系統架構由三部分組成,從下至上分別為VIM(Virtual Infrastructure Management)、VNF-M(VNF-Manager)以及NFV-O(NFV-Orchestrator),分別完成NFVI的資源管理、VNF的管理以及網絡服務與資源的編排.其中,VIM與網絡功能虛擬化基礎設置(NFVI)交互,VMF-M與單元管理系統(EMS)和虛擬網絡功能(VNF)交互,NFV-O與運營支撐系統(OSS)和業務支撐系統(BSS)交互.基于這樣的編排流程,任何一個業務網絡均可以通過MANO自頂向下進行分解.

圖1 NFV MANO系統架構圖Fig.1 NFV MANO system architecture

2.2 業務鏈平臺控制平面的研究

雖然目前業界對業務鏈平臺的架構沒有統一,但是總的來看業務鏈系統架構通常包括三個層次,分別是編排層,控制層以及數據層[16,17].最上層為編排層,通常由不同功能的組件構成,可通過Restful API的方式與對應的控制層進行交互,用戶可以通過可拖拽的方式對業務進行不同的組合形成統一的業務.中間為控制層,負責對網絡轉發設備進行統一的管理和控制,同時維護一致的網絡拓撲.最底層的轉發層主要包括三部分,分別是流分類器,網絡轉發設備以及業務功能組件.在典型的SDN系統架構的基礎上,學術界設計了多種業務鏈控制面架構.總體來說,可以分為兩類.

1)單控制器架構.如圖2所示,OpenNF[18]在SIGCOMM′2014提出了一種全局統一的控制面架構,在OpenNF控制器內集成了流規則管理器和網絡狀態管理器,分別用于管理網絡轉發狀態和網絡功能狀態.

圖2 OpenNF系統架構圖Fig.2 OpenNF system architecture

2)雙控制器架構.如圖3所示,Stratos[19]提出了一種雙控制器架構,其中轉發控制器用于管理和控制轉發設備,而業務功能控制器用于監視和控制中間件設備,二者由租戶業務鏈模塊進行統一調度.

圖3 Stratos系統架構圖Fig.3 Stratos system architecture

2.3 業務鏈平臺轉發平面的研究

業務鏈數據平面轉發技術的演進過程如圖4所示.傳統業務鏈數據面轉發技術通常采用策略路由(PBR,Policy-Based Routing)方案[20],PBR方案提供了一種比基于目的地址進行路由轉發更加靈活的數據包路由轉發機制,可以根據IP報文源地址、目的地址、端口等內容進行路由選擇.PBR方案主要存在4個方面問題:

1)靈活性問題.匹配域類型相對固定且有限,導致靈活性較差.

2)可擴展性問題.不具有微流匯聚能力,導致表項增多.

3)可靠性問題.PBR表項需要靜態配置,導致拓撲依賴且不支持部署自動化.

4)性能問題.PBR屬于分布式DPI方案,每一跳均需與策略路由表項進行匹配,影響轉發性能.

圖4 業務鏈數據平面轉發技術的演進過程Fig.4 Evolution process of service chain forwarding technology

為解決傳統業務鏈存在的問題,產業界和學術界開始嘗試通過SDN架構帶來的可編程性來解決PBR方案存在的問題.流轉發規則方案基于SDN架構[21,22],通過使用OpenFlow協議[23],能夠自動生成轉發規則,解決了PBR存在的拓撲依賴和靈活性問題,但無法解決可擴展性和性能問題.之后業界開始探索引入業務鏈ID方案[24],通過部署流分類器為流量打上相應的業務鏈ID標簽,進而實現了轉發過程中不再依賴具體匹配域,而是依據ID字段進行轉發,能夠更好地解決PBR方案和流轉發規則方案存在的問題.

3 面向SDN和NFV融合機制的業務鏈平臺

本文設計并實現了面向SDN和NFV融合機制的標準化業務鏈平臺,接下來將介紹平臺的系統架構以及架構所實現的核心關鍵技術.

3.1 平臺系統架構

業務鏈平臺的系統架構如圖5所示,核心功能組件主要包括業務鏈編排器、策略控制器、SDN控制器、NFV控制器以及流分類器等.編排器可以將用戶自定義服務所需的資源和配置發給相應的控制器,編排器由業務鏈定義、業務鏈配置以及拓撲管理等模塊組成.策略控制器負責根據用戶的需求選擇業務鏈策略,同時將網絡流量的轉發策略傳給流分類器.SDN控制器主要對網絡轉發單元進行管理和控制,以及路徑計算、下發流表項等功能.NFV控制器負責對VNF進行功能管理以及資源配置.流分類器負責基于策略控制器的策略,對進入網絡業務流量進行分類及標識.數據轉發面主要負責對網絡業務流量進行轉發,是由SDN交換機構建的網絡.VNF是各種功能的中間件,負責對業務流進行相應的處理.

圖5 標準化業務鏈平臺系統架構圖Fig.5 General framework of standardized service chain platform

3.2 平臺關鍵技術

3.2.1 基于多控制器的控制平面

從圖6可以看出,整個業務鏈架構自頂向下包括3層,分別是管理面、控制面和數據面.本節重點介紹控制平面.單控制器和雙控制器均存在可靠性問題,因此本文采用了多控制器的控制平面.控制平面由3個控制器組成,分別是策略控制器、SDN控制器以及NFV控制器.其中,策略控制器負責根據業務鏈ID的策略生成相應流表至流分類器,主要模塊包括業務鏈策略控制以及業務鏈ID分配,SDN控制器負責根據網絡拓撲生成相應流表至轉發單元,主要模塊包括拓撲管理以及流表管理,NFV控制器負責根據對VNF進行全生命周期管理,主要模塊包括VNF管理器以及NVF拓撲管理.

圖6 標準化業務鏈平臺分層架構圖Fig.6 Hierarchical framework of standardized service chain platform

3.2.2 基于業務鏈ID的轉發平面

傳統業務鏈轉發方式采用的是基于策略路由PRR的方案,由于PBR存在靈活性和可靠性等問題,業界主流方案采用基于業務鏈ID的方案[25].如圖7所示,目前基于業務鏈ID的轉發技術可以分為3類:

1)基于已有標簽字段的方案,如VLAN/VXLAN/MPLS字段.

2)基于數據報文已有字段的方案,如三層的TOS字段以及四層的TCP Option字段.

3)基于新增報文頭的方案,即IETF SFC工作組建議使用專用的網絡業務包頭(NSH,Network Service Header)[26].NSH格式中包含了24位的業務路徑(SPI),控制器將SPI作為匹配參數下發給網絡轉發設備完成轉發.

圖7 業務鏈ID方案分類Fig.7 Classification of service chain ID solutions

本文提出一種基于源MAC的業務鏈ID方案,即通過報文的源MAC字段承載業務鏈ID.如表1所示,我們對各類型的業務鏈ID方案進行了比較.其中,標簽字段與原業務有沖突,L3和L4等報文字段不滿足長度需求,存在可擴展性的問題,新增字段需要修改交換機和中間件,所以只有源MAC方案滿足無需修改交換機、滿足長度需求、與原業務無沖突以及無需修改中間件等四方面要求.此外,我們通過記錄源MAC與業務鏈ID的對應關系,在報文出業務鏈時將業務鏈ID替換為對應的源MAC,從而使得報文在進出業務鏈前后的報文頭信息保持不變.

表1 業務鏈ID方案優缺點比較
Table 1 Comparison of service chain ID solutions

匹配域需求標簽字段MPLSVLANL2L3L4Src-MACToS(DS)IPv4/v6OptionTCPoption新增字段NSH是否無需修改交換機YESYESYESYESYESYESNO是否滿足長度的需求YESNOYESNONONOYES是否與原業務無沖突NONOYESNONONOYES是否無需修改中間件NOYESYESYESYESYESNO

4 實驗分析

業務鏈平臺作為企業網絡和運營商網絡部署的重要應用,重要性不言而喻.因此,經過架構設計和系統編碼后,需要對業務鏈平臺進行全面的系統測試,確保平臺功能的準確性和完備性.為了驗證本文所提出的標準化業務鏈平臺的可行性,我們按照圖8拓撲進行了平臺功能測試和性能測試.測試在商用服務器(CPU為Intel(R)Xeon(R)D1528,主頻為1.9GHz,內存為32G),使用千兆網卡Intel 82575進行.

圖8 業務鏈平臺測試拓撲Fig.8 Test topology of service chain platform

功能測試:用戶通過拖拽方式可以新建兩種業務,其中業務1的業務鏈編號為0001,業務2的業務鏈編號為0002.新建的兩條業務鏈通過控制層將流表項下發至轉發面,主機H1和H2分別對應業務1和業務2,SDN流分類器和SDN交換機的表項如圖所示.我們在H1和H2上運行Iperf客戶端,負責發送報文,而在H3上運行Iperf服務端,負責接收報文.控制器采用開源的OpenDayLight[26],流分類器和SDN交換機運行開源的OVS,版本號均為2.5.0,支持最新版本的OpenFlow協議.由于OpenFlow協議支持SET-FIELD動作,因此能夠直接將源MAC字段修改為業務鏈ID字段使用.防火墻和網絡地址轉換通過開源的ClickOS[27]實現.我們使用Iperf工具進行了小包測試,通過Iperf客戶端發送64字節的報文,在Iperf服務端能夠成功接收到Iperf客戶端發送的報文且無丟包,因此測試結果表明,標準化業務鏈平臺功能正常.

圖9 性能測試效果對比圖Fig.9 Comparison of performance test results

性能測試:為了保證性能測試的準確性,我們采用思博倫測試儀進行發包測試.接收端接收報文后進行統計,如果不丟包則增大流量,直到出現丟包現象后,則回溯到不丟包的臨界值,以此測試最大傳輸速率,測試包長為64字節、128字節、256字節、512字節、1518字節5種長度.圖9比較了業務鏈ID方案與傳統PBR方案的傳輸速率和時延,結果表明, 兩種方案的傳輸速率和時延隨著報文大小的增大均呈現上升趨勢,且相較于PBR方案,基于源MAC的業務鏈ID方案在報文傳輸速率方面增長幅度在15%～20%,報文傳輸時延降低幅度在20%～25%.

5 總 結

在新的網絡架構下,如何利用新的技術將創新業務更好的融合進來,從而提供便捷、安全的網絡架構,是業界的研究重點.為此,提出了面向SDN和NFV融合機制的標準化業務鏈平臺,以應對新形式下基于業務鏈的新需求.本文通過對傳統業務鏈平臺進行深入分析,明確了當前網絡業務鏈平臺所存在的主要問題以及標準化業務鏈平臺對SDN和NFV兩大技術的訴求.然后遵循NFV MANO標準架構設計了面向SDN和NFV融合機制的標準化業務鏈平臺的系統架構,并在此基礎上,設計實現了關鍵的核心技術.基于標準業務鏈平臺,遵循多控制器機制設計一種高可靠性架構,為底層數據轉發提供平臺支撐,以提高業務鏈控制平面的可靠性,同時研究了業務鏈數據面轉發方案,分析比較業務鏈轉發方案的優劣,進而創新性提出一種基于源MAC的業務鏈ID方案,以提高業務鏈數據平臺的可擴展性.最后對該業務鏈平臺進行了可行性驗證,測試結果表明,標準化業務鏈平臺功能正常.