SFCDSL:一种服务功能链领域专用语言

阮宏玮,李 华,王显荣

(内蒙古大学 计算机学院,呼和浩特 010021)

网络功能虚拟化(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技术进行功能性对比分析,最后进行总结.

在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设计和评价.

从规范化、可扩展性角度考虑,本文参照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程序,通过“南向适配”对接不同南向层.

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.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间的最短路径

以上介绍了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技术功能性对比分析

针对SFC领域需求复杂缺乏编程能力现状,本文首先给出基于软件定义SF和面向对象的SFC形式化定义,在此基础上设计实现了面向SFC领域的内部DSL风格的SFCDSL,并实现了一个基于SFCDSL的SFC框架.下一步,一方面继续扩展提升语言描述领域能力,另一方面将在所提出的SFC其它层面开展研究,增强自动化验证和高级查询能力等.

猜你喜欢 面向对象链路编程 一种移动感知的混合FSO/RF 下行链路方案*火力与指挥控制(2022年8期)2022-09-16GEE平台下利用物候特征进行面向对象的水稻种植分布提取农业工程学报(2022年12期)2022-09-09基于深度学习与融合地形特征的黄土陷穴面向对象提取方法农业工程学报(2022年10期)2022-08-22玩游戏学编程，Blockly Games上手玩电脑报(2020年31期)2020-08-20纺织机上诞生的编程数学大王·低年级(2020年3期)2020-03-12编程屋完成数百元万天使轮融资中国经济信息(2018年21期)2018-11-29学编程，先画画知识就是力量(2018年4期)2018-04-13一种IS?IS网络中的链路异常检测方法、系统、装置、芯片科技创新导报(2016年27期)2017-03-14基于Web的科研项目管理系统的设计与实现电脑知识与技术(2016年27期)2016-12-15基于热备份提升微波站点传输稳定性中国新通信(2016年13期)2016-08-12 相关热词搜索：专用，领域，语言，