基于協議無感知轉發的服務功能鏈①

劉正印,葛敬國,李 佟,韓春靜,吳嘉磊

1(中國科學院大學 網絡空間安全學院,北京 100093)

2(中國科學院 信息工程研究所,北京 100093)

3(南京理工大學 計算機科學與工程學院，南京 210094)

服務功能在部署時,功能與專屬硬件緊密耦合,每個功能都嵌入在特定的硬件設備中,導致運營成本不斷提高,網絡靈活性變差,服務部署十分困難[1].為此,IETF提出一種服務功能鏈(Service Function Chain,SFC)架構來解決服務功能在部署過程中拓撲獨立性和配置復雜性等問題[2].NSH以一種報頭的格式被添加到網絡流量中,用于支持服務功能鏈架構的實現[3].

當前,利用軟件定義網絡[4](Software Defined Network,SDN)和網絡功能虛擬化(Network Function Virtualization,NFV)技術實現服務功能鏈已經成為了研究熱點.SDN和NFV技術高度互補,彼此互利但并不相互依賴.SDN被視為一種全新的網絡技術,通過分離網絡設備的控制平面與數據平面,將網絡能力抽象為應用程序接口提供給應用層,從而構建開放可編程的網絡環境,在對底層各種網絡資源虛擬化的基礎上,實現對網絡的集中控制和管理.NFV利用IT虛擬化技術定義網絡功能,通過通用硬件以及虛擬化技術,來承載相關網絡功能,從而降低網絡成本并提升業務開發部署能力,將硬件和軟件解耦,使網絡功能不再依賴于專用硬件.

到目前為止,SFC已經在多個平臺上實現,包括OpenDaylight(ODL)[5],ONOS[6]和 OpenStack Networking[7].其中,只有 ODL 平臺完全采用 IETF SFC架構,包括所有核心組件、NSH協議等.ODL平臺通過對OpenFlow協議的私有擴展實現了NSH協議,然而,這種實現方式造成了OpenFlow的兼容性問題.由于 ODL平臺中OpenVSwitch(OVS)交換機[8]通過OpenFlow協議與控制器通信,因此,OVS交換機需要修改自身代碼以實現NSH協議,實現過程復雜.OVS交換機首先對L2或L3層的數據包添加NSH,然后利用現有封裝協議,如MPLS、VXLAN/VXLANGPE在L3或L4層對數據包再次封裝.利用現有協議封裝、轉發NSH報文,增加了不必要的報文處理過程,導致網絡傳輸效率降低.

POF協議是對SDN南向接口協議OpenFlow的擴展,其提供了SDN控制器直接指定規則匹配字段和指令操作字段的偏移量和長度的能力,定義了字段修改、插入、刪除等指令集用于對報文進行各種操作,從而實現了數據平面的深度可編程,更加有效地支持新協議的實現.

本文根據IETF提出的有關服務功能鏈的標準,提出了一種基于協議無感知轉發的服務功能鏈,該服務功能鏈主要是基于SDN和NFV技術,基于Floodlight開源控制器,利用POF協議數據平面深度可編程的能力,提供了對NSH協議的支持,從而構建了服務功能鏈.實驗結果表明,該架構有效地實現了服務功能的部署.

本文其余小節組織如下:第1節介紹服務功能鏈的相關背景;第2節提出基于SDN和NFV技術的服務功能鏈的架構設計;第3節中,詳細介紹該服務功能鏈架構的實現過程;第4節,通過設計實驗并驗證了該架構的可行性和系統性能.最后,對下一步工作進行相關介紹.

1 背景

1.1 服務功能鏈概述

SFC是指定義和實例化一組有序的服務功能,例如防火墻、深度報文檢測系統等,通過控制網絡流量的處理順序,高效靈活地為用戶提供所需的服務[2].

IETF對服務功能鏈進行了標準化定義,對架構框架、使用場景、路由轉發和報文格式等進行了詳細闡述[2].圖 1展示了 IETF 提出的 SFC 架構,其包括 4個核心組件:分類器(Classifier)、服務功能轉發器(SFF)、服務功能(SF)和 SFC 代理(SFC Proxy).當數據包進入到一個支持SFC報文的網絡區域即SFCEnabled Domain 中后,Classifier根據匹配策略匹配數據包,將其分配到不同的SFC中;SFF根據SFC報文中攜帶的信息將數據包轉發到一個或多個SF中,并且處理從SF返回的數據包;SF負責對收到的數據包做特定功能的處理,SF在具體實現的上可以是一個虛擬的元素,或者是嵌入在具體網絡設備上的某種功能,如防火墻,深度報文檢測系統等;對于不能識別SFC報文的設備,可以使用SFC代理.

圖1 SFC 邏輯組件

在服務功能鏈中,服務功能路徑(Service Function Path,SFP)是指數據包必須按照指定順序轉發的限制規范,而數據包在網絡中實際訪問SFF和SF的順序稱為呈現服務路徑(Rendered Service Path,RSP).從 SFP到RSP,是一個從抽象定義到具體實現的逐步細化的過程.

1.2 NSH協議

為引導網絡流量在服務功能鏈的各個邏輯組件中正確傳遞,解決SF之間信息交互,拓撲獨立性等問題,IETF提出了用于創建動態服務功能鏈的NSH協議.通常,數據包在網絡入口處被添加NSH,數據平面根據NSH報文完成服務流量的控制和轉發.如圖2所示,一個NSH包含3部分:四個字節的基本報頭、四個字節的服務路徑信息和上下文信息(固定長度和可變長度兩種).其中,四個字節的基本報頭提供有關NSH報文本身的信息以及有效負載的信息;服務路徑信息主要是提供服務路徑中的路徑標識和位置;上下文信息用來攜帶元數據(metadata).

圖2 NSH 報文

2 系統架構設計

在IETF關于服務功能鏈的RFC文檔中提出了服務功能鏈架構的實現原則,其中包括拓撲獨立性、平面分離、數據包分類和共享元數據等[2].本文基于SDN和NFV技術,將服務功能鏈的系統架構分為控制平面和數據平面(圖3).控制平面通過北向接口獲取用戶對于服務功能鏈的描述,生成相應的策略和流表信息,通過控制平面和數據平面間的南向接口傳遞到數據平面,數據平面根據控制平面下發的策略和流表,將各個邏輯組件實例化,并使數據包按照指定的順序經過各個SF,實現用戶所需的服務.

控制平面主要功能包括:(1)提供北向接口,接收用戶對于服務功能鏈的描述信息;(2)管理底層網絡基礎設施、鏈路狀態、拓撲結構;(3)負責資源的統一分配,各個邏輯組件的創建和生命周期的管理;(4)管理SFC的相關信息,初始化各個監聽服務,持久化相關信息;(5)構建 SFP,生成相關策略和流表;(6)提供南向接口與數據平面進行信息傳遞.控制平面通過北向接口,獲取到用戶對于服務功能鏈的描述,資源管理模塊根據描述分配相應的計算和網絡資源,SFP路徑規劃模塊根據服務功能鏈的描述和資源管理模塊資源分配結果,利用Floodlight控制器中原有的對底層網絡拓撲管理的模塊,初始化SFP,NSH流表生成模塊根據實例化的結果,生成相應的流表,通過控制平面和數據平面之間的南向接口下發至數據平面,控制平面的數據庫模塊對SFC的相關信息做持久化工作.

圖3 SFC 架構

當數據包進入數據平面的SFC-Enabled Domain時,入口處Classifier根據控制平面下發的流表決定哪些包能夠進入SFC-Enabled Domain,并根據下發的匹配規則為這些數據包添加不同的NSH,轉發至相應的SFF中.SFF會根據NSH報文中服務路徑標識(Service Path Identifier,SPI)和服務序號(Service Index,SI)確定下一跳地址,其中,SPI是 SFP 的唯一標識,SI表示SF在SFP中的位置.當SF不能識別NSH時,SFF會將數據包發送給相應的SFC Proxy進行處理.

3 系統實現

根據系統的架構設計,將系統實現分為了控制平面和數據平面的實現兩個部分.控制平面采用Floodlight開源控制器,Floodlight不僅是一款SDN控制器,它也包含一系列模塊化應用,而這些應用可以向上提供REST API,從而幫助應用層的應用更好地管控整個網絡.POF交換機協議無感知轉發的特點,有效的支持了NSH協議在數據平面的實現,Classifier和SFF等網絡功能組件是基于POF交換機開發完成的.由于控制器主要通過流表的形式對POF交換機進行管理,因此,流表生成模塊的構建在控制器中十分關鍵.

3.1 基于Floodlight控制器的控制平面的實現

SFC控制平面主要是基于Floodlight控制器實現的,用戶可以通過控制器提供的北向接口使用SFC的功能,可以創建、更新或者刪除SFC,自定義非透明的metadata數據字段用來實現SF間的數據共享,Floodlight控制器還可以對底層網絡抽象,獲取網絡的拓撲結構.

Floodlight控制器提供了一個模塊加載系統,可以方便的利用IOFMessageListener和IFloodlightModule這兩個接口進行功能擴展[9].通過實現IFloodlightModule接口,我們增加了NSH流表生成模塊,將用戶對于服務功能鏈的路徑描述信息,通過流表的形式下發至數據平面,數據平面的POF交換機根據流表信息對報文添加不同的NSH,實現數據包在數據平面的傳遞.為了實現SFC邏輯組件的自動化部署和管理,利用python語言編寫了資源管理模塊.由于SFC的生成是根據用戶的需求來定義的,因此我們采用了JSON類型的接口格式,通過JSON接口,控制平面可以接收來自用戶層面的SFC需求描述.另外,控制器中還定義了與多個與SFC相關的數據結構,例如NSH報文信息等.

3.2 NSH流表設計

服務功能鏈各個邏輯組件對數據包的處理模式可以歸結為match-action的處理過程,即通過匹配數據包中的某個字段,匹配成功后則用action進行處理,如Classifier匹配到目的地址A的數據包,則封裝NSH并轉發.因此,流表的設計主要是對match-action策略的設定.

由于服務功能鏈中不同的邏輯組件實現的功能不同,因此下發的流表也不一樣.Classifier需要提供對數據包的識別、封裝和轉發等功能.本文中Classifier支持對數據包中五元組(目的IP、源IP、目的端口號、源端口號和協議)的識別,由于POF交換機一次性執行的指令數量的限制,無法一次性完成五元組的識別和匹配功能,需要利用多個流表對同一數據包進行處理,每個流表處理后將結果暫存到POF交換機中的metadata 字段中,metadata 字段設計如圖 4 所示,當POF交換機依次將數據包中的五元組寫入交換機的metadata字段后,Classifier中負責處理NSH報文的流表利用metadata中的五元組,根據POF交換機中設定的匹配域,實現NSH報文的解析與傳遞.

圖4 交換機中的 metadata 字段

根據上述分析,控制平面共下發至Classifier中6個流表,其處理過程如圖5所示,由于POF交換機接收到的是MAC幀報文,包括攜帶VLAN和不攜帶VLAN字段的兩種格式,因此Classifier中的流表首先是對MAC幀的處理,從而確定IP報文開始的位置,接著依次是IP報文和TCP/UDP報文的處理.五元組寫入到POF交換機的metadata中后,將流表的匹配域與metadata中的五元組相對應,從而實現對數據包的匹配.匹配完成后,利用POF協議無感知轉發的特點,只需要通過AddField、ModifyField和DelField等POF交換機指令便能完成對數據包添加NSH報文頭等操作,不需要對其他代碼進行修改,添加完成后將帶有NSH報文轉發到不同的SFC中.

圖5 Classifier流表處理過程

在SFC中,SFF根據NSH報文中攜帶的信息將數據包轉發至一個或多個SF中,并且處理從SF返回的數據包.SFF報文處理流程如圖6所示,當SFF收到報文后,首先根據NSH報文中的SPI和SI字段確定下一跳地址,轉發到相應的SF或SFF中,如果SF不支持NSH報文,則需要先轉發到相應的SFC Proxy中將NSH去掉,轉換成SF可以識別的報文,當SF處理完畢后,SF Proxy需要重新對數據包封裝NSH再由SFF轉發到下一跳.由于Classifier不會對匹配策略之外的數據包封裝NSH報頭,因此在SFF還需要支持對常規報文的轉發.

圖6 SFF 處理過程

4 實驗設計及驗證

為了對該系統的功能和性能進一步分析和研究,本文設計并搭建了與實際網絡環境相近的網絡拓撲.本實驗的實驗環境使用的是ubuntu14.04的系統,內核版本是3.13,網絡拓撲利用mininet搭建而成(mininet是一個輕量級的SDN網絡研發、仿真以及測試平臺).控制器采用Java語言編寫的Floodlight開源控制器,安裝的JDK版本是1.8.

4.1 系統功能測試

本文首先對服務功能鏈的功能效果進行了實驗驗證,實驗模擬的是 Client請求 Web Server服務器的HTTP 服務,其中,Classifier和 SFF 均基于 POF 交換機設計而成.本實驗設計了兩條服務功能鏈,一條功能鏈SFC1經過的服務功能路徑是SF1、SF2、SF3,另一條經過的服務功能路徑SFC2是SF2、SF3.NSH包含3部分:基本頭信息、服務路徑信息和上下文信息.實驗中兩條服務功能鏈的SPI分別設為為1和2,SI的初始值設為 255,Next protocol設為 4(4 表示NSH協議),上下文信息的初始化長度為4個字節固定長度,初始值為 0.在 NSH 報文轉發表中,利用 SPI、SI和 Next Protocol確定下一跳地址,下一跳地址可以是SF或者SFF,每次經過一個SF后,SFF負責將SI減1.在節點通信過程中存在的ARP請求報文,Classifier不會對其進行封裝.表1是控制器下發至SFF1中的NSH報文轉發表,其中*號代表通配符.

表1 SFF1 中的 NSH 報文轉發表

實驗的網絡拓撲如圖7所示,其中Client1主機的IP地址為10.0.0.1,Client2主機的IP地址為10.0.0.2,Server 服務器的地址為:10.0.0.3,控制器的地址為10.10.28.37.實驗使源IP地址為10.0.0.1的數據包經過SFC1,源IP地址為10.0.0.2的數據包經過SFC2.由于mininet網絡中的網絡設備默認只能添加一條鏈路,因此對linux主機添加了虛擬網卡對,SFF和SF間分別關聯了虛擬網卡對.當數據包進入SFC-Enabled Domain 后,Classifier根據流表,匹配數據包并添加NSH,分別將發自Client1和Client2的NSH中SPI字段設為1和2,添加完成后,將NSH報文從 S1-eth3端口轉發至 SFF1,SFF1 根據流表中的 Next protocol、SPI和SI確定下一跳地址,如果匹配到的SPI為1,則將匹配到的數據包從S2-eth2端口轉發之SF1,SF1處理完畢后,將數據包從F1-eth2端口轉發回SFF1,SFF1將數據包中的SI減1后從S2-eth4端口轉發到SFF2處,依次類推,當SF3將處理完的數據包返回給SFF3時,SFF3去掉數據包的NSH報頭后,轉發至web Server服務器.當SFF1匹配到到數據包中的SPI為2時,直接從端口S2-eth4轉發至SFF2.在實驗中,SF1起到了防火墻的功能,本文將防火墻規則設置為不允許目的IP地址為10.0.0.3的請求數據包通過,因此SPI為1的數據包無法收到HTTP響應報文.此外,Client的發起的HTTP請求報文采用NSH協議進行轉發,Web Server返回的數據由于不需要再經過 SF,直接按照常規的數據包進行返回.

圖7 實驗拓撲

實驗結果如表2所示,表中第一條記錄是SFC1的HTTP請求結果,第二條記錄是SFC2的HTTP請求結果.

表2 Client請求結果

上述實驗證明,基于協議無感知轉發的服務功能鏈實現了IETF提出的有關SFC的標準,各個邏輯組件功能完備,并基于POF實現了NSH協議.

4.2 系統性能測試

在性能測試時,為了更加接近真實的網絡環境,實驗利用了一臺物理服務器和IXIA網絡測量儀對服務功能鏈的丟包率和時延進行了測試.實驗設計了對照實驗,由于Classifier和SFF是基于POF交換機設計實現的,因此,對比了服務功能鏈環境下和POF交換機環境下,常規TCP報文和NSH報文的在相同網絡環境下的丟包率和時延情況,實驗中數據包的發送速率50 Mbit/s.圖8中左框內是服務功能鏈性能測試的實驗拓撲圖,右框內是POF交換機性能測試的實驗拓撲圖.在服務功能鏈性能測試的實驗中,IXIA測試儀的Port0端口不停發送TCP數據包,Classifier對據包封裝NSH后轉發至SFF,SFF收到NSH報文后,修改NSH中的SPI字段,然后去掉數據包中的NSH,轉發至IXIA測量儀的Port1端口.在對照試驗中,TCP數據包直接通過POF交換機轉發,不經過Classifier和SFF.

圖8 丟包率和時延實驗拓撲圖

兩組對照實驗的報文丟包率均接近于0,數據包的接收時延如圖9所示,基本趨于一致.

接著,實驗利用iPerf3網絡性能測量工具和mininet仿真工具對服務功能鏈的吞吐量進行了測試,測試分為兩組,將服務功能鏈與POF交換機設置為對照實驗,利用iPerf3將數據包的發送速率設置成不同的值,采用UDP模式進行了測試.圖10的上下兩框內分別是服務功能鏈和POF交換機測試吞吐量時的邏輯拓撲圖.

圖9 時延數據

圖10 吞吐量實驗拓撲圖

吞吐量的實驗結果如圖11所示.從實驗結果可知.在一定范圍內,服務功能鏈和POF交換機的吞吐量無明顯差異,隨著發送速率的提高,服務功能鏈網絡吞吐量會逐漸下降,維持在380 Mbit/s左右.

圖11 吞吐量實驗拓撲圖

由于Classifier和SFF均是基于POF交換機設計實現的,根據丟包率、時延和吞吐量的測試結果可知:在一定的數據包發送速率下,利用POF交換機實現NSH報文協議后對交換機本身性能沒有明顯影響,說明了POF協議能夠高效的提供對NSH協議的支持,避免了OpenFlow協議在擴展過程中的兼容性和實現復雜性等問題.說明了基于協議無感知轉發的服務功能鏈在性能方面表現優異.

5 結束語

本文根據IETF提出的關于服務功能鏈的標準,利用POF協議無感知的特點,提出基于SDN和NFV架構的服務功能鏈,實現了NSH協議,避免對OpenFlow協議的私有擴展和實現復雜性等問題.利用Floodlight控制器和POF交換機實現了該服務功能鏈,并對其功能和性能分別進行了驗證,實驗結果表明,基于協議無感知轉發的服務功能鏈功能完備,在性能方面表現優異.由于本文側重SDN的實現模塊,對NFV模塊的研究不夠深入,也沒有考慮到包括故障處理在內的其他因素,下一步工作將圍繞著云計算環境中協議無感知轉發的服務功能鏈的應用進行深入研究.