SFCDSL:一種服務功能鏈領域專用語言

阮宏瑋,李 華,王顯榮

(內蒙古大學 計算機學院,呼和浩特 010021)

1 引 言

網絡功能虛擬化(Network Function Virtualization,NFV)和軟件定義網絡(Software-defined Networking,SDN)作為目前網絡研究的熱點,是促進當今網絡發展變革的重要動力,二者融合產生的直接技術價值是能夠支持網絡服務功能虛擬化,從而實現對用戶網絡功能需求靈活優化的配置響應,而其影響更大的市場價值則是體現在支持服務功能鏈(Service Function Chain,SFC)的編排定制[1,2].SFC是描述一組按一定關聯關系構成的需求服務邏輯組合拓撲結構,可由用戶或系統靜態配置或者動態編排.雖然傳統網絡也有SFC概念,并且盡管在上層設計是抽象的、獨立于拓撲等限制,但在底層網絡實際部署SFC時經常受拓撲結構條件約束,部署難度大,在網絡重構變更時需進行重配置.

NFV與SDN相結合可促使SFC適應云環境下的動態性、多租戶、集中控制等,因而受到研究者的普遍關注,并在SFC模型驗證、控制平面建模、服務編排和優化、需求刻畫和北向接口等方面進行研究.NFV和SDN的重要目標是希望通過虛擬化和軟件化,幫助用戶將原本復雜的SFC服務配置、部署和管理透明化、簡單化.從這一目標出發分析,現有研究多是側重于局部性關鍵技術研究,關注北向平面及其以下特別是網絡部分,主要面向系統管理人員、編程人員提供一系列北向接口語言和網絡管理語言,從各自研究關注的需求目的、資源分配、服務部署等相對獨立部分當中的重點問題開展研究.相對于局部性的關鍵問題,在實際應用中,服務應用管理人員和高級服務開發人員側重于整體性SFC方案,主要關注于由北向需求至南向部署的應用解決方案的整體設計、自動化部署和運行.為此,本文設計提出一種SFC領域專用語言,能夠作為支持貫穿連接各部分自動化運行的全流程整體方案,節省常規編程工作和子系統集成環節,專用于服務更高層面的SFC服務領域,為應用管理人員和高級服務開發人員提供統一的高層服務管理抽象和自動化服務支持.

本文的主要貢獻如下:

1)提出了SFC抽象化層次架構.

2)給出了SFCDSL內基于軟件定義SF和面向對象的SFC形式化分析

3)設計實現了面向SFC領域的專用語言SFCDSL.

本文組織如下:第2節介紹相關工作研究,第3節給出SFC抽象化層次架構,第4節介紹SF和SFC的形式化分析,第5節說明SFCDSL的設計實現原理,第6節結合典型場景示例演示SFCDSL應用并與其它常規SFC技術進行功能性對比分析,最后進行總結.

2 相關工作

在SFC結構相關方面,已標準化的有SFC問題說明[3]、SFC體系結構[4]、SFC NSH協議[5]等.NFP(Network Function Parallelism)并發架構[6]基于NF對于數據流讀寫訪問模型最大化優化NF間可并發部分,并通過實驗驗證了并發算法有效性,說明了SFC模型需要支持并發而不僅僅是線形的必要性.對于SFC結構,SFC定義以及大多數研究是基于SFC拓撲表現,一般多基于直觀拓撲結構即線形結構或服務圖(Service Graph)結構附加約束條件方式簡化定義SFC.

在SFC服務需求描述方面,可以基于傳統的描述Web服務的各類xSDL描述語言,還可使用語義Web服務OWL-S(1)http://www.w3c.org/submission/owl-s/通過提供信息語義進一步增強服務描述,并且通過研究將BPEL4WS(2)http://msdn.microsoft.com/en-us/library/Aa479358或OWL-S映射為形式化組合模型,還可完善服務建模與測試驗證.相比傳統實現技術,基于Intent(意圖)方式是SFC服務需求研究熱點.文獻[7]介紹了在ETSI NVF平臺上實現基于Intent的SFC,采用了基于JSON形式格式化封裝的Intent請求,被轉換為YAML格式的網絡服務描述符后最終部署在Openstack上.文獻[8]對基于意圖的網絡(IBN)研究進行綜述,介紹了IBN體系結構并概述了IBN實現的閉環內容及各方面關鍵技術研究現狀,指出當前Intent研究仍主要是局限于特定環境的格式化意圖描述.文獻[9]通過對近期IBN取得的進展進行綜述對比,得出IBN近年并沒有突破性進展結論,并指出自然語言處理對于IBN發展的重要性.Intent的設計目標是用戶可通過意圖接口設置網絡目標狀態,在經過意圖轉譯后,內部實現過程希望由網絡自動配置完成,除基于現有控制器協議或API技術外,為提高管理能力效率一般基于領域編程語言支持實現.

在相關領域編程研究方面,研究人員基于不同抽象化層次需求提出了諸多語言.文獻[10]從分類角度對基于OpenFlow的SDN編程語言進行綜述,一方面從底層編程、API編程和領域專用語言(Domain Specific Language,DSL)編程舉例介紹SDN編程三級層次,另一方面從SDN編程語言特征,按照流安裝、策略定義、編程方式和抽象化分類,重點分析對比了FML、Nettle、Frenetic、Flog、Merlin等15種SDN主流編程語言.文獻[11]采用類似的分類方法,根據編程語言、編程模型、實現機制以及新功能程度4個方面分類綜述各類語言特性.P4[12]語言定位于統一操作管理南向數據平面設備,定義抽象交換機模型和基礎數據類型,基于編程操作數據轉發平面設備處理數據包,通過北向接口調用和內部編譯支持隱藏SDN編程的復雜性和減少出錯概率.Nemo[13]是借鑒SQL語言方式設計的聲明式語言,通過將intent設計為OOR(對象-操作-結果)模型以管理網絡.以上語言服務設計定位靠近網絡層,為更便利上層應用,研究人員基于面向對象方法設計面向SFC的語言和應用.文獻[14]提出了面向對象的NAPL編程語言,可在將JSON格式的網絡拓撲請求轉為NAPL語言程序后,編譯為在目標SDN控制器上可運行的C++程序,實現用戶網絡連接需求到SDN控制器程序的自動化編程支持.SDNSOC[15]作為一個基于面向對象的安全操作框架,將SFC認為是由一系列內在可有面向對象關系關聯的虛擬網絡服務VNF(Virtual Network Function)構成,因而通過自動化判定構成不同SFC的VNF或者網絡域間的面向對象關聯關系,檢測相關SFC間的規則沖突.

當前SFC結構缺少深入分析服務關系研究,研究出發點主要關注同平面(業務平面或網絡平面)服務構成的平面拓撲關系,不直接支持體現跨平面(業務平面和網絡平面)層次化服務組合,須代以分層管控服務.這樣的分類研究方法也影響到以結構作為實現理念基礎的面向SFC的領域語言和應用設計,前述的NAPL語言僅關注網絡平面的轉發節點、鏈路、服務構成的拓撲連接關系,SDNSOC僅關注VNF間的關聯關系.當前領域語言研究面向單一層面,缺少適用于云網融合整體架構的組織和設計.本文參照領域語言設計原則和云系統應用、設備管理、并行編程、深度學習等不同領域語言設計場景[16-20],通過設計一套面向云網融合環境的自定義語言SFCDSL(SFC Domain Specific Language)以提高SFC應用能力和效率.為此,需要研究解決以下3方面問題:

1)SFCDSL編程框架.

2)SF和SFC統一規范抽象.

3)SFCDSL設計和評價.

3 SFCDSL編程架構

從規范化、可擴展性角度考慮,本文參照NFV和SDN控制器抽象化層次架構[21],進一步細化SFC領域層次,首先提出SFC抽象化層次框架,明確SFCDSL語言的定位,如圖1所示,說明如下.

圖1 SFC抽象化層次框架

1)SFC北向應用層:面向北向用戶提供透明服務的需求應用層,通過需求應用接口向用戶或第三方應用提供服務,如基于YANG語言的API程序接口、基于查詢語言的高級管理接口等.

2)SFC南向管理層:面向南向系統管理控制器提供規范跨異構的管理層,如NFV控制器、SDN控制器、SFC編排層控制器等,通過封裝適配南向控制器API、通信協議或者程序等以交互和實現用戶需求應用.

3)SFC驗證層:支持SFC需求和實現等驗證,包括靜態驗證(如模型驗證)和動態驗證(如測試驗證).

4)SFC中間層:關聯支持SFC相關各層面的核心中間層.本文通過自定義領域編程語言方式實現自動化支持.

從圖1可以得出,SFC抽象層次框架的核心是中間層.本文通過實現SFC領域語言SFCDSL以向各方提供編程能力支持.需要說明的是,SFCDSL本身關注的是為用戶提供統一編程服務,具體平臺最終資源配置管理和實現依賴一般通過適配器封裝轉換為平臺控制器調用完成.圖2是SFCDSL編程架構,分為模型層、算法層和實現層.

圖2 SFCDSL編程架構

1)模型層:SF和SFC抽象描述,可通過“北向適配”將上層應用層需求轉為SFCDSL支持的模型格式.

2)算法層:包括內置算法和語言特性.內置算法提供優化算法代碼片段或完整實現,語言特性包括語法糖、面向對象設計等.

3)實現層:編譯SFCDSL程序,通過“南向適配”對接不同南向層.

4 SF和SFC統一規范抽象

SFC是基于SF構造的,本質反映的不僅是用戶對于服務本身的需求,也有服務間的關聯的需求.云網融合架構下的服務種類繁多類型各異,不同技術基于關注服務的角度區別,對服務會有不同理解,進而會側重創建不同類型的SFC.比如NFV著重于業務處理,一般通過業務功能鏈構建SFC,SDN著重于網絡轉發,一般通過網絡功能鏈構建SFC.現有實現融合理念的關鍵主要是通過基于并結合現有云、網兩部分,在支持交互的基礎上各自定義并管理本域范圍內的具體“服務”.由于缺少一致的SF和SFC定義,所以較難實現統一的云網交叉應用管理.因此本文設計領域語言須首先規范SF和SFC的模型.

深入分析SFC結構可以發現SFC與SF間是具有遞歸特征的,即:SFC既可以是扁平化的,也可以分層的,SFC既可內在表現為一組相關聯的SF,還可以一般地外化表現為統一的邏輯實體SF,進而與其它SFC或SF通過關聯組合構造更高一級的SFC,反過來一個SFC也可以分解為若干SF(或子SFC).由此,借鑒Web服務和OWL-S統一規格化服務理念,對于云網架構中的每類服務,從軟件角度都可以作為服務分類,由此可以按照對象化方式,即通過刻畫對象的屬性、行為方式以體現服務.

定義.軟件定義的服務功能(Software-Defined Service Function)

泛指通過軟件對象化方式體現服務屬性、服務行為以表現服務能力的功能單元.業務服務和網絡服務均可統一視為軟件定義的服務功能.

根據前述SFC與SF間的遞歸特征,本文給出基于EBNF[22]的以面向關系抽象化的SFC定義:

SFC = SF | "(" SF,SFC ")" //SFC是SF或者一系列SF

SF =(Property,Action) | SFOOConstruction //SF可由屬性、行為和約束直接刻畫,可基于SF構造

SFOOConstruction = Generation | Realization |Composition | Aggregation | Dependency //基于面向對象關系構造

Generation =("extends" SF) //繼承泛化

Realization =(SF "implements" Interface)

Composition =(SF "compose" SF) //組合

Aggregation =(SF "aggregate" SF) //聚合

Dependency =("<" SF,SF ">")//依賴

通過以上分析,各類SFC技術均可以規范化表示為對象關系,下面將基于這一理念設計SFCDSL.

5 SFCDSL設計

5.1 SFCDSL對象關系設計

雖然本文中的SF面向所有可提供服務的功能單元,但在設計時是以云網結合為背景,關注NFV+SDN場景下涉及的需求對象關系.

通過前述分析可以看出,SFC的結構特性恰好體現了面向對象設計中對象之間的關系,各種SFC演化的需求行為,例如SFC組合分解、SFC彈性、SFC鏈路分裂聚合等的實質,都可以看做是服務對象間的泛化、組合、依賴等一系列邏輯關系.因此基于軟件定義SF構建SFC,可以將SFC領域中的服務和服務連接統一映射為面向對象關系表示,即服務及服務間關系兩類.本文基于UML圖描述對象關系,說明如下.

1)SF以及基于SF自身的彈性擴展:泛化、實現.SF的屬性和行為均可以定義為接口,SF通過實現接口和泛化繼承進行擴充.

例如:對于入侵檢測服務,可以認為是虛擬服務VNF的泛化擴展,并且實現檢測接口.

2)基于SF的組合演化:組合、聚合.組合與聚合的差別體現在組合整體代表各部分的生命周期.

例如:對于應用防火墻WAF,可以認為是防火墻與入侵檢測設備的組合,建立或刪除WAF服務則各部分服務同時建立或刪除.而對于冗余應用服務,可以認為是主服務和備份服務的聚合,某一部分失效并不影響其余部分.

3)SF間的連接:依賴.須注意,依賴表現為服務關聯的有向性,如果是對稱鏈路通信,應建立相互依賴.

設計原則主要考慮以下兩點:

1)可演化性

NFV和SDN的設計角度分別是以業務服務為核心和以網絡鏈路為核心,但在實際應用場景中卻存在大量個性化需求,經常是云網環境跨層需求交織疊加.比如有需求從性能和安全考慮,要求對于一個由若干SF構成的NFV SFC鏈,在特定交換機間按規定規則轉發.一般控制器默認功能行為僅針對各自關注點,不支持異構平臺集成統一編程環境,需要用戶根據具體要求和環境進行有針對性編程,編程難度和實現成本高,程序可演化性較差.

2)可擴展性

不同場景對象各異,屬性、行為差異很大,設計應允許在核心基礎上具備充分可擴展性.

按照上述設計原則要求,云網融合環境主要核心類圖如圖3所示,具體說明如下.

圖3 SFCDSL類圖

1)Property:屬性.抽象列舉元素對象常規屬性,如性能屬性延遲、吞吐量等等,個性化屬性可由具體SF派生擴展.

2)Action:行為.抽象說明元素對象常規功能和事件,如功能性說明、周期性行為等,具體功能由具體SF設計實現.

3)Constraint:約束.抽象說明元素對象約束條件,如云網環境服務基于策略(Policy)規則(Rule),由具體SF設置并解釋策略規則內容.

4)Element:抽象基類元素.

5)SF和SFC:服務功能和服務功能鏈.

6)VNF、NF和VM、LINK、Path和Switch:不同視角不同層次下的服務功能.

7)Flow:數據流.

5.2 SFCDSL風格設計

領域特定語言(domain-specific language、DSL)是專注于某個應用程序領域的計算機語言,可分為外部DSL和內部DSL.外部DSL不同于宿主語言,通常自定義語法,宿主應用代碼通過文本解析執行外部DSL腳本,難度高但可靈活實現,如SQL語言.內部DSL采用宿主語言語法結構定義,受限于宿主語言功能特性但可具有特定風格,如Scala語言.構建一個DSL須符合3個原則,即該DSL應能完整描述領域、簡單易用并且隱藏實現細節.

根據SFC形式化定義,SFCDSL語言應是支持面向對象的,應可以靈活支持適于SFC領域的自定義操作.Scala語言是兼容Java語言的,具有多繼承、支持特征trait、隱式類型轉換、符號重載等特性,可通過增加庫等形式設計符合領域需求的自定義DSL.綜合以上情況,本文基于Scala語言設計內部DSL類型的SFCDSL.

SFCDSL文法規則遵循Scala語言,支持類定義和各類常規運算符操作.在此基礎上,本文主要基于SFCDSL對象關系設計,利用Scala隱式轉換特性,構建符合SFC領域描述應用風格的自定義DSL文法.

1)對于SFC領域對象間的關系,通過重載運算符以實現SFC的建立、刪除和彈性擴展.

·算術運算符:+ |-| * | /分別表示建立服務鏈接、刪除服務鏈接、服務數擴展和服務數收縮.

需要說明,由于服務鏈路的有向性,+和-并不滿足交換律,即服務u+服務v不等于服務v+服務u.

舉例:

u+v //建立服務u和服務v連接

u-v //刪除服務u和服務v連接

u*2 //服務u數量擴展2倍

u/2 //服務u數量收縮一半,同時刪除所有與刪除服務間的關聯

·關系運算符:> | < | = 同類服務可比較屬性間的大小關系.

舉例:

u>v //u和v之間的屬性關系,如用于服務質量性能比較

·二元邏輯運算符:判定服務間的訪問邏輯關系.多重鏈路間默認為并發關系,&&表示并發,‖表示選擇.

舉例:

link(u,v)&& link(u,w) //uv和uw之間是否為并發關系.

2)對于查詢拓撲、最短路徑等SFC領域常用功能,通過隱式轉換方式實現內嵌算法.

舉例:

sfc select topology //查詢sfc的拓撲

u shortpath v //搜索服務u和v間的最短路徑

6 應用及分析

以上介紹了SFCDSL基本設計原理和實現,下面通過示例展示SFCDSL在SFC編程應用方面的整體性自動化支持能力,然后與其它常規技術進行功能性對比分析.

6.1 SFCDSL在SFC架構原型中的應用

根據前述架構設計,SFCDSL作為中間層為SFC各層提供支持服務,SFCDSL內部以面向對象關系組織服務.所以從可擴展性、兼容性考慮,對于SFC北向應用層接口描述,本文首先通過北向適配器統一轉換為基于UML的面向對象關系,然后基于UML圖的對象關系轉換為SFCDSL程序,之后通過南向適配器完成SFC實際部署.圖4是本文設計了一個在Floodlight SDN環境下擴展文獻[7]設計的ETSI NFV環境Intent的SFC架構實現原型,在該原型下通過結合如下需求變更示例演示SFCDSL的可擴展應用步驟.

圖4 SFC架構示例

需求示例演示兩階段變更:

·S1:構建1個由入口防火墻FW經指定交換機SW至WebService構成的SFC,要求FW至WebService的帶寬應達到100M.

·S2:因業務擴大,WebService擴大數量為2個,須為WebService增加負載均衡LB服務.

1)擴展的ETSI NFV環境Intent

文獻[7]設計的ETSI NFV環境下Intent主體結構如下所示,其中service_block塊部分聲明各種服務,如防火墻、入侵檢測服務等,其中order表示服務次序;service_requirements塊部分聲明服務需求,如帶寬、延遲等.

{"name":

"service_blocks":[

{

"block":"service_block_name",

"order":int:Order_inside_SFP,

"symmetric":Bool:Block_On_Reverse_path

},],

"service_requirements":{}}

與文獻[7]僅關注ETSI NFV平臺服務不同,本文是將所有服務均作為基于SFCDSL服務類圖擴展的可編排對象,所以在其基礎上增加可識別服務類型的type字段.

根據S1需求構建的擴展的ETSI NFV環境Intent關鍵描述如下:

"service_blocks":[

{

"block":"FW",

"order":1,

"type":VM,

},

{

"block":"SW",

"order":2,

"type":Switch,

},

{

"block":"WebService",

"order":3,

"type":VNF,

},],

"service_requirements":{

"bandwidth":"100M",

}

2)擴展的ETST NVF 環境Intent轉換為UML圖

主要映射規則如下:

·將service_blocks塊中的各block轉換為繼承于SFCDSL已定義的type類型的UML類UMLClass

·按照order次序建立UML類間的依賴UMLDependency

·將service_requirements中的需求轉為UML類或者依賴的約束(Constraints)

以擴展的ETSI NFV環境Intent描述的S1需求經轉換后的UML如圖5所示.

圖5 Intent到UML圖示例

3)UML圖轉換為SFCDSL程序

讀入并解析XML格式的UML圖數據,提取其中的UMLClass和UMLDependency等關鍵代碼塊,轉為SFCDSL程序代碼,生成代碼片段示例如下.

var sfcreq = FW composition SW composition WebService //構造sfc請求

var dependency1 = FW + SW

var dependency2 = SW + WebService

sfcreq addlink dependency1

sfcreq addlink dependency2

sfcreq compute shortpath //按照最短路徑計算SFC鏈路

4)基于Floodlight SDN的部署

根據不同南向環境的,構建不同的南向適配器.對于基于Floodlight的SDN環境,根據鏈路需求約束計算的相應鏈路,通過調用Floodlight REST API接口或者命令行配置方式下發流表建立符合需求的鏈路.

var adapter = new FloodlightAdapter

adapter create sfcreq

典型Floodlight下發流表規則方式如下:

curl-X POST-d ′{"switch":"00:00:00:00:00:00:00:01","name":"flow-mod-1","cookie":"0","priority":"32768","in_port":"1","active":"true","actions":"output=2"}′http://controller_ip:8080/wm/staticentrypusher/json

3https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

4https://wiki.opendaylight.org/view/Service_Function_Chaining:Main

5)基于UML的負載均衡需求變更實現優化

對于基于S1產生的S2負載均衡需求變更,在設計時首先為WebService增加“服務集群”屬性說明,對于變更實現可采用兩種流程方式:

第1種方式,一般流程.按照前述方式構造目標Intent,轉換為UML圖,生成SFCDSL程序執行.可以通過編輯S1的UML圖方式簡化Intent至UML步驟.

第2種方式,變更流程.通過增加service_operation塊操作擴展Intent描述能力,增加建立和刪除鏈路的操作說明,直接生成如下相關變更代碼:

SW-WebService

SW+LB

LB+WebService[0]

LB+WebService[1]

在實現方面,相比常規構造LB服務以及增加相應鏈路的一般方式,本設計在實現時考慮到Floodlight quantum已支持負載均衡服務池實現,所以實現是通過南向適配器調用Floodlight API實現負載均衡.

通過以上技術實現分析可以看出,相比于一般分階段局部化結合多段接口的非全流程自動化方案,本文研究通過北向適配將目的轉換為UML圖,然后基于統一服務鏈描述的SFCDSL特性,自動生成集成內置優化算法的SFCDSL代碼,之后通過南向適配進行自動化部署,能夠實現完成整體服務管理方案的自動化支持,為用戶提供了可用的統一抽象簡便的SFC領域編程服務,節省了常規編程工作和子系統集成環節.

6.2 SFC相關技術功能性對比分析

現有技術一般均采用租戶理念設計,為不同SFC建立獨立連接.基于VLAN[23]隔離性劃分服務鏈租戶,技術復雜度低,實現了不同VLAN服務不同SFC,但不支持VLAN內的服務編排.基于Openstack+OVS的NFV方案雖提供編程和協議配置實現SFC的管理和部署,但缺少面向高級管理人員的服務管理抽象和全流程的自動化配置服務支持,需要較高能力和較多環節的的編程服務,技術復雜度高.PCE[24]、LISP[25]、GRE[26]和MPLS[27]等協議方式側重于實現服務間的鏈路,配置相對方便但設備技術有特定要求,服務編排靈活性響應方面較弱.NSH協議雖然獨立于北向控制器并抽象南向設備,但其因用于實現南向平面轉發而與具體跳轉聯系緊密,抽象層次不高,并且相關實現沒有考慮基于對象的演化擴展設計.相比而言,SFCDSL定位服務于SFC管理應用,服務于自北向南的整體自動化服務支持,所以在需求描述能力、自動化、靈活性、易用性等方面相比較強,但系統設計實現相對復雜,在部署時需要配套底層實現技術適配器以具體實現.具體比較見表1.

表1 SFC技術功能性對比分析

7 總 結

針對SFC領域需求復雜缺乏編程能力現狀,本文首先給出基于軟件定義SF和面向對象的SFC形式化定義,在此基礎上設計實現了面向SFC領域的內部DSL風格的SFCDSL,并實現了一個基于SFCDSL的SFC框架.下一步,一方面繼續擴展提升語言描述領域能力,另一方面將在所提出的SFC其它層面開展研究,增強自動化驗證和高級查詢能力等.