软件学报  2016, Vol. 27 Issue (4): 993-1008   PDF    
软件定义网络中北向接口语言综述
于洋1, 2, 3, 王之梁1, 3 , 毕军1, 3, 施新刚1, 3, 尹霞2, 3    
1. 清华大学 网络科学与网络空间研究院, 北京 100084;
2. 清华大学 计算机科学与技术系, 北京 100084;
3. 清华信息科学与技术国家实验室(筹)(清华大学), 北京 100084
摘要: 软件定义网络(software defined networking,简称SDN)的产生使得网络中的数据平面与控制平面相分离,网络中的控制逻辑集中于控制器上,运行于控制器上的网络应用使得网络变得更加简单可控和灵活.软件定义网络中的北向接口是指控制器与网络应用之间进行通信的接口.在软件定义网络应用研究与开发的过程中,北向接口占据着一个重要的地位.综述了SDN中北向接口的编程语言,首先介绍北向接口编程语言的研究背景,然后根据编程语言的抽象程度、编程模型、实现机制以及是否引入新功能这4个方面将编程语言分类,详细介绍每个类别下各种北向接口语言的结构和核心特性,最后结合语言的应用场景对编程语言进行横向比较,进而展望了北向接口编程语言未来的研究方向.
关键词: 软件定义网络    北向接口    编程语言    
Survey on the Languages in the Northbound Interface of Software Defined Networking
YU Yang1, 2, 3, WANG Zhi-Liang1, 3 , BI Jun1, 3, SHI Xin-Gang1, 3, YIN Xia2, 3    
1. Institute for the Network Sciences and Cyberspace, Tsinghua University, Beijing 100084, China;
2. Department of Computer Science and Technology, Tsinghua University, Beijing 100084, China;
3. Tsinghua National Laboratory for Information Science and Technology(Tsinghua University), Beijing 100084, China
Abstract: Software defined networking(SDN) is a research trend as it decouples the control plane from the data plane. SDN applications are essential since they can be used to make the network simple to manage, flexible, more secure and more powerful. Northbound Interface is the communication interface between the controller and applications, it plays an important role in the process of the research and development of SDN. The state of the art of the programming languages in the SDN Northbound Interface is surveyed in this paper. It first summarizes the research background of the programming languages in the Northbound Interface. By classifying these languages into different categories according to their abstraction, programming model, implementation mechanisms and whether introducing new features, the study analyzes the key characteristic and language structure in each category. Incorporating with application scenarios in SDN, this paper compares the advantages and disadvantages of each language, and at the end discusses the future research trend.
Key words: software defined network    northbound interface    programming language    

随着互联网的发展,网络结构越来越复杂,网络上部署的应用也越来越多,在传统的网络体系结构下很难部署新型的网络功能.在这种情况下,软件定义网络(software defined networking,简称SDN)[1]应运而生,SDN通过将网络中的数据平面和控制平面分离开来,实现对网络设备的灵活控制.这种数据和控制平面分离技术给网络带来了更大的灵活性和可操作性.在SDN中,网络由中心控制器集中控制下层的一系列分布式的网络设备,包括交换机、路由器以及中间盒(middlebox)等,控制器可以获取网络中各个资源的详细信息,下层的设备(例如交换机)仅仅实现简单的报文转发功能.图 1是SDN标准化组织开放网络基金会(Open Networking Foundation,简称ONF)提出的SDN体系结构,下层的网络设备是SDN中的数据平面,构成了SDN的基础设施层(infrastructure layer);SDN的中心控制器软件是SDN中的控制平面,构成了SDN的控制器层(controller layer);运行于控制器之上的便是SDN中的业务应用,构成了SDN的应用层(application layer).SDN中的控制器通过南向接口与基础设施层的网络设备进行通信,实现对数据平面的控制,通过北向接口的API(application programming interface,应用编程接口)为上层的应用服务.

Fig. 1 SDN architecture[1]图 1 SDN体系结构图[1]

SDN让网络的可控性变强.传统网络的灵活性和可控性较差,增加部署协议或规则是很繁琐的一项工作;但在SDN中,由于网络设备的所有控制逻辑已被集中在SDN的中心控制器中,使得网络的灵活性和可控性得到显著增强.因为网络设备的所有控制逻辑已被集中在SDN的中心控制器中.控制器可以提供网络的全局视图以及下层设备的信息,所以,编程者可以在控制器上编写策略,例如负载均衡、防火墙、网络地址转换(NAT)、虚拟专用网络(VPN)等功能,进而控制下层的设备.可以说,SDN中的应用可以体现SDN可编程的这一核心特性.

北向接口(north bound interface,简称NBI)的出现繁荣了SDN中的应用.北向接口主要是指SDN中的控制器与网络应用之间进行通信的接口,一般表现为控制器为应用提供的API编程接口.北向接口可以将控制器内的信息暴露给SDN中的应用以及管理系统,从而可以利用这些接口去进行,如请求网络中设备的状态、请求网络视图、操纵下层的网络设备等等操作.利用北向接口提供的网络资源,编程者可以定制自己的网络策略并与网络进行交互,充分利用SDN带来的网络可编程的优点.SDN中的北向接口不仅可以让编程者充分利用网络资源,还可以细粒度地在流的级别上控制网络资源.为了让一个应用或者服务正确地运行于网络之上,网络的管理员不再需要对现有网络设备进行升级以及复杂的配置,只需要向控制器请求相应需要的资源.

鉴于北向接口有这样的优势,ONF成立了相关的北向接口工作组North Bound Interface Working Group(简称NBI-WG),它致力于建立SDN中北向接口的原型及其信息模型,为应用开发者制定标准化的北向接口.近几年也纷纷涌现了众多针对北向接口的编程语言,它们的出现让编写SDN网络应用的开发部署等工作变得更加简捷.关于北向接口语言的情况,在最近的几篇SDN综述[2, 3, 4, 5]中均有提及.但是,目前仍然还没有一篇关于北向接口语言的详细综述,所以本文针对北向接口的编程语言,分类介绍它们的详细特征,同时重点针对编程模式讨论各个语言的不同,进而为后续研究北向接口的工作指明方向.

本文第1节首先介绍SDN中北向接口的编程语言出现的背景.第2节对各种语言进行纵向的分类.第3节针对每一类语言给出各个语言的详细特征,包括语言产生的动机、核心思想、应用领域等.第4节横向比较总结各个分类下的编程语言.第5节对北向接口的研究领域做出展望.第6节给出总结.

1 SDN 中北向接口语言的研究背景

SDN中的北向接口加强了网络的可编程的特性.SDN应用的逐渐繁荣,北向接口充当着重要的角色.因为编程者可以利用北向接口提供的网络资源部署自己的网络策略,即网络应用,运行于SDN控制器之上,进而控制网络的行为.

在现有的主流控制器,如NOX[6],POX[7],FloodLight[8],Beacon[9],OpenDaylight[10],OpenContrail[11]中,都存在这样的北向接口,编程者如果需要部署一项新的应用,只需利用它们提供的相应API,便可以实现对下层设备流级别的控制,但是,这些控制器中提供的都是一个低级的流表规则的管理系统,存在着如下缺点:

(1) 为了让一个网络策略或是管理系统能够正确运行,编程者需要不停地适应SDN中的内部结构,需要考虑更多的便是系统的内部细节,而不是算法或是策略本身,这可能会导致算法出现错误或是软件层面上的错误.同时,利用OpenFlow[12]协议的细节编写的北向接口中低层次的指令系统很难去阅读和维护,也很难调试.那么用低级语言去编写应用的过程便成为了一个既耗时又容易出错的过程.

(2) 低层次的编程语言让应用的并行运行变得困难,因为不同的应用有不同的转发规则,而且它们的转发规则很容易产生冲突.例如,在同一个网络拓扑中,应用A需要过滤来自源地址为10.0.0.1/8的流量,然而另一个应用B需要转发源地址为10.0.0.1/8的流量,这两个应用如果并行运行就可能会产生冲突,在低级语言中,为了解决这样的冲突问题,需要编程者手动设置每一条流表的优先级,这个过程又提高了编程的复杂度.

(3) 在众多SDN的应用中,很多应用需要将下层的物理网络切片为虚拟网络.应用需要获取一个虚拟的网络拓扑,然后在虚拟的网络上进行模块化的编程;或者是把同一个物理交换机抽象为一系列虚拟交换机并出现在不同的虚拟网络中.这两个过程即便采用低级语言也都很难实现,所以,简化网络切片的过程需要一个高度抽象的北向接口.

基于这样的问题,创建易于维护的高层次的北向接口编程语言是很有必要的,北向接口需要一个高层次的抽象以方便应用的编写.北向接口中高级的编程语言可以屏蔽底层设备的信息,使得应用的编写过程不再依赖于底层的细节.另外,高级语言比低级语言更加抽象、简洁,易于学习与维护,也有利于代码的重利用和编程的模块化.

2 SDN 北向接口编程语言的分类

近年来,编程语言经历着飞速的发展,从汇编等低级语言,逐渐发展到Java,Python这样的高级语言,这个过程给计算机领域的发展带来了极大的飞跃.与此类似,SDN中的编程语言也在经历着类似的进步,从类机器语言的低级语言,逐渐发展到高层次的编程语言.高级的编程语言都有一个共同的特征,就是能够更加简洁地表达网络应用,给编程者、网络参与者都带来方便,使得网络应用的设计实现和部署过程变得简单.本节从抽象程度、编程模型、实现机制以及是否引入新功能这4个方面对北向接口的高级编程语言做出了分类.然后针对每一类编程语言,给出了典型代表.

2.1 北向接口语言的分类

北向接口语言从不同的角度可以存在不同的分类标准,主要标准为以下几个方面,如图 2所示,有抽象程度、编程模型、实现机制以及是否引入新功能这4个方面.在不同的分类标准下,还有更加详细的分类,下面将对北向接口语言的4个分类标准进行详细介绍.

Fig. 2 Classification standard of languages in the northbound interface图 2 北向接口语言的分类标准
2.2 以抽象程度为标准分类

从北向接口中的语言对底层设备的抽象程度来区分,分为低级语言和高级语言.类比于计算机编程语言的分类,与编程语言中按照是否封装计算机硬件指令作为区分高级语言和低级语言的标准一样,按照抽象程度分类是希望根据SDN北向接口语言是否封装了控制器与硬件的配置细节以及它们之间的南向接口指令来作为区分.北向接口中的高级语言是指封装了SDN控制器中不同的性质和功能的[1]、具有更高可读性的、更加方便于编写应用的语言,抽象程度较高;而低级语言是指与硬件设备配置信息相关的、需要处理硬件层面流表细节的语言,抽象程度较低.它们之间存在语言表达能力上的区别,高级语言的表达能力更强.

在低级语言中,典型代表有基于OpenFlow、P4[13]、POF(protocol-oblivious forwarding)[14]设计的控制器中提供的北向接口,例如NOX提供的C++以及Python的APIs,还有Beacon、FloodLight、OpenDaylight中提供的Java的APIs.另外,tinyNBI[15]也属于低级语言中的一种.

其中,tinyNBI与上面所述的接口不同的是,它重构了现有的5个版本的OpenFlow协议提供的API,把这5个版本整合为一个简单的兼容所有标准OpenFlow的API,tinyNBI的核心功能在于通过对SDN数据平面原语的准确抽象,为高级的编程语言提供更加清晰的底层接口.

另外,对于控制器中提供的RESTful API(representational state transfer API),这类北向接口也与其他有所不同,它可以被任何语言所编写的应用所用,体现为Web请求的方式,例如在Juniper的Contrail和FloodLight中的图形化用户界面(graphical user interface,简称GUI)里面都利用了RESTful API来编写.

北向接口中的低级语言直接利用交换机的硬件接口去编写转发行为的流表,编程者需要充分考虑硬件的细节,还需要手动去维护策略生成的流表的优先级信息.同时,由于流表下发到交换机中的异步的行为,在这个过程中,数据平面内可能会存在未被处理的报文,所以编程者还需要手动维护数据平面的一致性,以确保规则可以正确指导下层设备中报文的转发行为.这些低层次的语言给开发者带来了麻烦,同时也不利于应用的模块化以及代码的重构.

与低级语言相对的便是北向接口中的高级语言,占据了北向接口语言中的绝大部分,典型代表有pyretic[16]等,高级语言对底层设备提供的接口进行了封装,可以让编程者关注于网络协议和策略的相关逻辑,而不用关心数据平面的细节,简化了编程者的工作.同时,利用高级语言可以进行模块化的编程,甚至可以支持网络策略的并行编程,代码易读且便于维护,加快了网络协议开发与部署的过程.

2.3 以编程模式为标准分类

从各个编程语言的编程模式上来区分,还可以将编程语言分为命令式语言(imperative language)、声明式语言(declarative language)、面向对象语言(object-oriented language).类比于计算机编程语言中的编程模式,北向接口语言也可以通过语言的基础风格以及语言中组织元素和数据结构的方式作为分类标准.所以,低级语言的编程模式是在使用时需要考虑不同设备的配置细节、控制器内部的实现细节,甚至还有流表是否会存在冲突、如何维持数据平面的一致性等等.低级语言的编程模式大部分都是命令式的,而高级语言的编程模式则可以分为命令式语言、声明式语言(包括逻辑型、交互式、函数型语言等)及面向对象语言[17]等.这种分类方式借鉴了文献[3]中的关于编程语言的分类,在本文中对各类北向接口编程语言进行了更细致的分类.在计算机编程语言中,命令式语言[17],如Python、C、Ruby等,它们的编程模式是命令系统如何去做事情,无论编程者想要的是什么,这种语言都会按照程序的指令完成任务.与此相对,声明式语言[18],如SQL等,更强调于编程者想要实现的是什么,而语言自身可以对问题进行描述.面向对象语言,如C++、Java等,则是将对象作为程序的基本单元,将程序和数据封装其中,可以提高软件的重用性、灵活性和扩展性.例如,声明式语言SQL封装了检索时数据库是如何获取数据的信息,而让使用者关注于自己希望获取什么样的数据或是自己需要做何种操作;而在命令式语言中,检索数据的过程则需要编写一系列的指令去指明执行的流程.由于在一种语言中,可能存在多种编程模型,所以一种语言可能不仅仅只属于一种类型.

在现有的北向接口的语言中,命令式语言、声明式语言、面向对象语言的概念都与计算机编程语言中的概念相应地保持一致.其中,声明式编程语言占据大部分.其中,又可以分为逻辑型语言、函数型语言以及交互式语言.这种分类是基于语言的编程模式的,鉴于有些语言,如Nettle[19],同时存在交互式编程模型和函数型编程模型,所以它便可能出现在多个分类中.交互式语言的代表有FML[20],Nettle,Procera[21];函数型语言如FatTire[22], FlowLog[23],Frenetic[24, 25],HFT[26],Maple[27],Nettle,NetCore[28, 29],Procera等;逻辑型语言的例子有Flog[30],HFT, Merlin[31],Assertion Language[32];面向对象类语言如pyretic,Splendid Isolation[33],NCL[34];命令式语言的代表有pyretic.下一节我们将针对每一个分类介绍SDN中北向接口编程语言的详细信息.

2.4 按照是否提供新功能分类

北向接口出现的主要目的是简化编程者的工作,让网络协议的开发和部署过程变得更加简洁.北向接口可以提供的基本功能是提供控制器与应用或者更高层控制程序之间的通信,如从控制器获取信息,应用策略的下发等;但在众多北向接口语言中,还有一类语言能够提供新的网络功能,如网络验证、网络切片等功能.例如, FatTire、FlowLog、NetKAT[35]、Flog、Merlin,还有Splendid Isolation.它们的出现除了简化网络编程,还让网络中的其余功能,如模型检查、动态验证、网络虚拟化等过程变得更加简单.

FatTire利用正则表达式描述网络路径,保证每一条流在其原始路径出现故障时还有可选路径.FlowLog和Flog可以处理模型检查、动态验证等过程,NetKAT可以提供一个完备的数学理论基础去指导网络原语,同时也可以提供便捷的网络验证功能.Assertion Language可以提供嵌入应用的网络验证功能.而Splendid Isolation则让网络虚拟化、网络切片、流量隔离等过程更加简单.

2.5 按照语言的实现机制分类

各类语言在实现机制上存在一个共同点,即基本上所有的高级语言都由两部分组成:上层的高级语言以及下层的编译器.高级语言可以方便编程者利用语言提供的抽象接口完成自己所需的网络策略,而下层的编译器负责将编程者编写的策略编译为流表规则下发到数据平面的设备中.在这样的实现机制中,也存在两种语言,一类是嵌入到现有的高级语言中,一类是自己定义一套语法和语义规则.前者主要包括Procera,HFT, PANE[36],Maple,FlowLog,FatTire,NetKAT,Flog,Merlin;后者主要包括FML,Netttle,Frenetic,pyretic,NetCore,NCL, Splendid Isolation,Assertion Language.

在嵌入到现有的高级语言的北向接口语言中,FML基于非递归的DATALOG[37]语言,Nettle嵌入到Haskell语言中,Frenetic-OCaml基于OCaml语言,pyretic基于Python,NCL基于Java,Splendid Isolation基于Python.

3 SDN 北向接口的编程语言

上一节介绍了北向接口中编程语言的分类,下面将详细介绍北向接口中的各类编程语言的详细信息,如产生背景、核心功能、优缺点等等.由于在北向接口的编程语言中,大部分是编程模型为声明式语言的高级语言,同时,编程模型这个分类标准下的子类也最多,所以本节将按照编程模型这个分类标准来详细介绍各种语言.

3.1 北向接口中的交互式语言

交互式语言利用交互式编程模型,交互式编程模型主要面向数据流或者动态变化的变量编程,既能很方便地描述静态的数据流,也能轻松地表达动态变化的函数.交互式编程语言能够利用事件作为触发点驱动网络中的交互行为,强调利用网络编程而代替对于网络参数的配置.举一个简单的例子,在a=b这条命令式的语句中,是把变量b的值赋给了变量a,然而如果改变b的值,在命令式编程模型中并不会改变a的值.但是,在交互式语言中,b的变化可以反映给a,实现了变化的传播过程.与此类似,在北向接口中,交互式语言也可以将网络中的事件作为驱动,如果网络中存在一个事件的变化,这个变化也会反映给相关的网络事件,驱动它们做出改变,从而实现变化的传播.在北向接口的交互式语言中,典型代表有FML、Nettle和Procera,其中,由于Nettle和Procera也存在函数型编程模型,所以它们也属于函数型语言.利用这3种语言可以处理如权限控制(ACLs)、虚拟网络(VLANs)等应用.在这种语言的基础上编写的应用都会转化为一些类如allow,deny等策略,这些策略会被编译为流表下发到下层的设备中去,进而指导网络的行为.但是,这3类语言也有不同点,见表 1.

Table 1 Main difference in reactive languages 表 1 交互式语言之间的不同点
3.1.1 FML[20]

FML(flow-based management language)[20]是可以方便地管理企业网络配置的声明式语言,它是专门针对OpenFlow设备提出的一种交互式语言.它的实现基于NOX控制器,采用NOX中用回调函数实现事件驱动的机制,把NOX里面的细节语句封装为语言的关键字,实现网络中的交互过程.

FML被设计为可以替代现有的网络配置的方案,编程者可以利用FML所作的抽象,方便地表达网络中的各种常见配置.FML是针对网络中流的管理而设计出的高级语言,针对每一个应用,编程者都可以利用FML定义一系列其需要的关键字(如deny,allow等等),同时由网络中的超级用户(一般指管理员)对网络中的用户、主机分配权限.FML中可以利用关键字的优先级去处理流表的优先级,解决了多个应用带来的流表规则冲突的问题.

经过测量发现,FML生成的流表规则确实能够在线性的时间内匹配大部分的流量,运行效率较高.同时,对于每一个应用,也可以引入新的关键字来处理复杂场景下的问题.

总体来说,FML主要是为了简化网络策略的配置而产生的对流控制的抽象,它灵活、准确,可以同时被多个网络编程者所用;并且方便用户学习;也可以用作SDN北向接口的抽象语言,这是它的主要优点.但是它也有自身的局限性:比如只限于产生对网络中流级别的控制,不能用于转发策略随时间变化的动态协议.

3.1.2 Nettle[19]

Nettle[19]是仅支持OpenFlow设备的交互式编程语言,意在简化SDN中控制平面编程模型的复杂性、低级性以及容易出错等缺点.Nettle借鉴了领域专用语言(domain specific language,简称DSL)[38]以及功能交互语言的设计思想,继承了交互式编程模型的表达性强、拥有完备的数学基础等优点.

在Nettle的层级结构中,底层为OpenFlow设备,上一层的Haskell[39]是Nettle的宿主语言,供Nettle内嵌于其中.基于Haskell上层的HOpenFlow把OpenFlow协议进行了抽象,再上一层便是功能交互的语言模型,模型的上层便是对领域专用语言DSL[38]的扩展.每一种扩展都是一个应用的模型,例如可以有一个DSL用来做访问控制,另一个用来做流量工程,或者其他的网络应用.如图 3所示.

Fig. 3 Nettle layered system architecture[19]图 3 Nettle 层级的系统结构图[19]

Nettle聚焦于OpenFlow交换机之间的控制信息流,把来自交换机的信息作为一个个信号,都分别转换为事件流,细粒度地控制交换机行为.传统的语言事件驱动采用回调或者循环的方式进行,但是,Nettle通过不连续的周期性随时间变化的信号组成的事件流来带动事件驱动的过程.它不仅向编程者屏蔽了底层设备细节,更可以根据编程者的输入随时调整需要统计的网络信息,对编程者更加友好.

3.1.3 Procera[21]

Procera[21]也是一种交互式语言,然而,它却不仅仅能支持OpenFlow设备.Procera的架构更像是基于一般SDN控制器的一个上层控制器,这个上层控制器会给编程者一些特定的接口,让编程者轻松编写事件驱动的程序.经由Procera控制器的输出可以直接被底层的控制器运用.

如果网络中的应用有实时性处理网络状态改变的需求,仅仅利用FML是无法实现的,所以在这些应用中, Procera的事件驱动的编程模型便体现出其重要性.

Procera适用于交互性的网络策略(reactive policy),利用它定义出的策略可以转化为随时间变化的事件流.例如在网络用户设备流量监测这个应用中,管理员会给这个网络的所有设备分配一个最大使用的带宽和流量,如果在一段时间内监测到某些设备或用户的使用量超过了阈值,就会禁掉这个用户或设备的访问权限.由于每一个用户的月使用流量情况会通过一个接口被控制器所收集,监测到用户的使用量超过阈值这个过程并不困难,甚至是用传统的FML便可以方便测量,但是,如果一个被禁掉的用户下个月的使用量回到正常值,此时再利用FML就不方便描述和处理这个过程了,相比之下,Procera可以通过如图 4所示的代码片段表达这个事件驱动的过程,第2行中的useTableSF函数定期地将用户的使用情况累计到useTable中,第6行是查询用户的使用情况,第7行是查询监控情况,如果用户流量的使用量还未超过监控阈值,则允许继续使用,否则,禁掉用户使用流量的权限.由于系统每秒都会从设备中收集用户使用网络情况的监控日志,这个过程便是一个事件驱动的交互式过程.图 4所示的代码片段也代表了交互式语言一般的实现形式.

Fig. 4 Example: Device usage caps[21]图 4 例子:设备流量使用监控[21]
3.2 北向接口中的函数型语言

函数型语言[17]占据了北向接口高级语言的大部分,它们同时也都属于声明式语言.函数型语言会像定义数学上的函数那样定义程序以及子程序,函数型编程模型主要把运算过程尽量写成一系列嵌套的函数调用.例如:在数学表达式(2-1)×3+4中,如果用传统面向过程的编程语言(C语言)可能写成这样:

int a=2-1;

int b=3×a;

int c=b+4;

但在函数型编程中,就可以写成int result=add(multiply(subtract(2,1),3),4),主要思想是把运算过程定义为不同的函数.但是,现在的大部分函数型语言都是“不纯”的,因为它们除了具备函数型编程模型外,还具备交互式,甚至命令式编程模型.不过,与其他语言相同的是,北向接口中的函数型语言也强调对网络编程过程的抽象与简化.函数型语言的代表有FatTire,FlogLog,Frenetic,HFT,PANE,Maple,Nettle,NetCore,Procera,NetKAT等.在这些函数型语言中,Frenetic,HFT,PANE,Maple,NetCore侧重于简化编写报文转发策略,处理生成的流表规则出现冲突的情况;Nettle和Procera在上一小节已经提到过,它们也同时属于交互式语言;其余的函数型语言也都相应地引入了不同的特性.例如FateTire重在依赖正则表达式去描述网络策略,FlowLog可以编写模型检查、动态验证、有状态的中间盒等应用,NetKAT重点在于提供了一个完备的数学理论基础来指导网络原语,不仅简化了编程模型,还可以提供网络验证等功能.

下面将会在侧重于简化编写报文转发策略的语言中选取Frenetic、在侧重于引入新的网络特性的语言中选取FlowLog来介绍它们的详细特征.同时,由于NetCore的服务能力强于Frenetic,所以也会详细介绍这种语言,并与Frenetic做出比较.其余语言由于在语法结构或实现形式上有相似的地方,所以集中在一个小节内加以介绍.

3.2.1 Frenetic[24, 25]

Frenetic属于专门针对SDN北向接口而设计的领域专用语言(domain specific language,简称DSL),它可以为上层应用提供相关函数的封装,所以属于函数型编程语言.主要解决SDN北向接口存在的以下问题:

(1) 控制器的可见性是有限的;

(2) 在控制器上的编程没有支持模块化;

(3) 交换机与控制器之间的通信采用的是异步的模式,这样,在规则下发之前的报文容易匹配不正确的流表规则,从而被不正确地转发或丢弃.

针对上面的情况,Frenetic包含一个能产生高层次抽象的编程语言和一个实时的编译系统,前者支持模块化和并行化,有利于编程者简捷地编写网络应用,后者可以处理底层设备复杂的细节.Frenetic采用类SQL语法定义查询性语言,重点在于描述报文的转发规则,处理报文级别的数据.利用Frenetic可以简化的过程分为以下3类.

(1) 查询网络状态.例如在MAC(media access control address)地址学习的过程中,如果当mac地址srcmac出现在新的端口inport时,程序希望收到一个报文,此时的查询语句可以描述为

Select(packets)*GroupBy([srcmac])*SplitWhen([inport])*Limit 1;

(2) 寻找符合特定规则的报文信息.例如流量监控的协议可以表述为

def web_monitor():

     q=(Select(bytes)*Where (inport=2 & srcport=80)*Every(30))

     q>>Print()

(3) 生成报文转发规则并由实时的编译系统下发到交换机上去.下面的语句表述了利用Frenetic表达网络协议安装流表的过程:

def repeater():

     rules=[Rule(inport:1,[fwd(2)]),Rule(inport:2,[fwd(1)])]

     register(rules)

Frenetic在这3类事件中可以提供高级的查询语言或协议语言,或者一个高层次的抽象,编程者不用去考虑协议生成流表的细节,因为这个过程完全交给实时编译系统去处理了.编程者只需考虑自己需要什么.

Frenetic抽象出的接口可以控制网络中的报文.利用Frenetic,网络中的每一个报文对于编程者都是可见的.同时,为了进一步简化编程,对于交换机发送给控制器的报文,编程者还可以选择只关注第1个packetin 消息,屏蔽其余的报文.这样既提高了编程者的效率,也防止不重要的报文(例如在流表同步的过程中网络中的包)影响网络策略的整体逻辑,降低了控制器的负载.

Frenetic将查询网络状态与更改网络状态这两个过程隔离开,同时支持并行化的编程,允许多个应用同时编写并运行于SDN控制器之上.另外,对于缓存的报文可以自动生成转发规则防止网络拥堵的状态出现.值得关注的是,Frenetic通过给不同的流表规定一个整数的优先级来解决多应用之间存在的冲突问题.

此外,Frenetic还可以支持在源码的级别进行网络验证,验证网络中的重要性质,比如网络验证中常见的3个问题:(1) 主机A和主机B之间是否可达;(2) 到主机C的路径中是否存在回路;(3) 是否所有的SSH流量都被隔离了.Frenetic都可以通过编写高层次代码而做出回答.

3.2.2 NetCore[28]

与Frenetic类似,NetCore也由两部分组成,表达报文转发策略的编程模型以及一个编译器可以将利用NetCore编写的策略编译为流表安装到下层交换机上.NetCore是基于Frenetic的改进版本,它有Frenetic的3个基本功能,同时还有区别于Frenetic的如下特性.

(1) NetCore包含了一个简化的“查询语言”,可以分析流量历史记录.

(2) NetCore里面的编译器采用了一种新的算法,这种算法可以生成高效的交换机类.首先,通配的流表替代了Frenetic中简单的精确匹配的流表去处理更多的报文;其次,安装流表的过程采用主动的方式,即不是通过报文触发控制器再生成流表,而是在报文到达控制器之前先把流表下发到交换机中,这样既减轻了控制器的负载,同时也减少了网络中缓存的报文.

NetCore的核心提升在于一个可以支持应用并行运行的编译器,利用NetCore编写的策略如下所示:

SrcAddr:10.0.0.0/8\(SrcAddr:10.0.0.1→DstPort:80)→{Switch 1}

经过NetCore的编译器之后,生成的流表规则如下所示:

SrcAddr:10.0.0.1:{}

DstPort:80 :{}

SrcAddr:10.0.0.0/8:{switch 1}

经过对NetCore的性能评价,NetCore在编译器上确实作了优化,流表的命中率相比于Frenetic也有显著的提高.

3.2.3 FlowLog[23]

FlowLog属于声明型语言中的函数型语言,与前几个重在抽象处理报文过程的语言不同,FlowLog引入了新的特性,侧重点在于网络验证.主要解决网络验证领域的如下问题:

(1) 网络中会存在大量的缓存报文;

(2) 交换机里会安装大量的流表;

(3) 网络拓扑可能会相当复杂.

现有的对于SDN的验证大部分需要基于网络配置在数据平面进行,如报文头空间的分析[40](header space analysis).基于这样的问题,如果要在网络应用的层面进行网络验证,必须要将底层的细节做出抽象,屏蔽流表信息、报文信息以及复杂的拓扑信息,从而方便编程者编写验证逻辑.编程者只需验证一个或几个配置,便可以检测网络的可达性信息是否存在循环、回路等等.

FlowLog的表达性强,而且分析能力也强,每一个FlowLog的程序都会定义为一个在控制器状态层面上的有限状态的传感器.FlowLog可以掌握控制器状态,也可以改变控制器状态,并且对报文可以做出变量的修改,不局限于流级别的控制.同时,FlowLog的编译器也可以将编程者编写的策略转化为交换机上的流表,这个过程同样在简化编程者的工作.

3.2.4 其他函数型语言

在函数型语言中,HFT[26],PANE[36],Maple[27]等与Frenetic类似,侧重于简化编写报文转发策略,处理生成的流表规则出现冲突的情况.它们又有各自的特点,HFT提出了有优先级的流表的概念,用于定义和实现SDN中具备优先级属性的策略框架.而PANE则属于在HFT的基础之上,让网络上编写策略的过程变成一个人人可参与的过程.PANE的核心是在描述什么样的网络参与者拥有什么样的权限去做出什么样的网络策略.Maple的提出则是基于交换机的流表不支持否定匹配的情况,Maple中的编译器可以自动生成具有优先级的流表规则,简化编程者的工作.

从实现层面上看,HFT,PANE和Maple也有相似的地方,即都是用树状的数据结构去组织流表或策略.HFT将SDN上的策略组织成一棵树状结构,树的每一部分可以独立地决定一个报文的转发行为.PANE则采用共享树(share tree)这样的结构让管理员给网络参与者分配读或写的权限,中心化的控制器可以通过更改网络配置完成网络参与者(principal)的高层次的意图.Maple提出了追踪树(trace tree,简称TT)这样的模型,其重点也是在对TT模型进行改进和优化.

另外,在函数型语言中,还有一类语言类似于FlowLog[23]一样引入了新特性,例如,FatTire[22]的新特性在于可以用正则表达式来描述网络的路径,可以发现网络链路中错误的配置.FatTire利用网络容错的正则表达式,使得网络中各种容错的场景更容易理解.NetKAT[35]以Kleene algebra为理论基础去描述全网的结构,利用Boolean algebra为理论基础去描述下层交换机的行为,任何违背KAT公理的行为都会被NetKAT拒绝,这样也给网络验证带来了便利.

3.3 北向接口中的逻辑型语言

逻辑型语言[17]也属于声明式语言的一种,逻辑型语言主要基于形式逻辑,通过设定规则而不是设定步骤来解决问题,它由众多具有逻辑形式的句子组成,表达了某个领域问题的事实和规则.SDN的编程语言中,Flog, HFT以及Merlin都属于逻辑型编程语言,它们的共同点是利用逻辑型的编程模型去编写网络协议,从而简化协议中的逻辑模型.例如,Flog将模型检查的功能简化,HFT可以将生成网络中流表优先级的过程简化,Merlin可以将权限分发给子网的过程简化等等.下面的表 2从对设备的要求、控制对象级别、核心特征这3个方面描述了它们的不同点.HFT作为函数型语言的一种,已经在上一小节提到.下面将详细介绍Flog、Merlin以及Assertion Language.

Table 2 Main difference in logical languages 表 2 逻辑型语言的不同点
3.3.1 Flog[30]

Flog属于逻辑型编程语言,也是声明式语言的一种,它结合了上文提到的FML和Frenetic,把SDN的报文转发规则抽象为断言+行为+优先级的模式,属于事件驱动,也是在流级别上控制报文.与前两者不同的是,Flog引入了新的编程特性,如模型检查、动态验证以及编写有状态的中间盒,这一点与FlowLog类似.以有状态的防火墙这个应用为例,利用Flog只需以下5行代码便可以实现这样的功能.由代码可以看到,Flog是基于形式逻辑的语言,与函数型语言不同的是,并不是靠复杂的函数调用来解决问题.如图 5所示.

Fig. 5 Stateful firewall[30]图 5 有状态的防火墙[30]

Flog结合了FML以及Frenetic的优点,并且克服了FML编程模型不灵活的缺点,但是,Flog由于只限于流级别的控制,因而也存在一定的局限性.

3.3.2 Merlin[31]

Merlin是一种基于正则表达式的高级逻辑型语言.第3.2.3节中介绍的函数型语言FatTire也利用了正则表达式,不过,在FatTire中,可以用正则表达式表达网络路径,保证每一条流在它的原始路径出现故障时还有可选路径,采用函数型编程模型;而在Merlin中,支持将抽象出来的网络函数应用于中间盒、终端以及硬件中,可以为网络里的中间盒的控制提供一个统一的框架,兼容已有的网络系统,采用逻辑型编程模型.同样,Merlin也是以策略的定义作为输入,输出底层的指令,并同时允许管理员将权限分发给网络用户.

Merlin同样由上层的高级语言和编译器组成,它允许网络管理员鉴别流量的类型、控制转发策略以及定义特殊的流量限制.同时,Merlin的运行时系统(runtime system)还为动态改变网络协议提供了一个灵活的框架.

3.3.3 Assertion Language[32]

Assertion Language是为了方便网络验证而提出的高级逻辑型语言.SDN中虽然可以有全网的视图以及全网设备的行为记录,但是现有的SDN中的网络验证大部分都是基于静态的网络配置或是在数据平面进行分析验证,所以无法根据上层应用逻辑的动态变化而做出实时性的验证.在这种情况下,Assertion Language便是能够对数据平面不断变化的网络做出验证的一种语言,它不仅能够做出可达性、是否存在循环以及切片是否分离这种一般性的验证,还可以利用本文提出的语言做出“有状态的防火墙”,“在MAC学习的过程中减少控制器的开销”这样的验证.

Assertion Language可以针对变化的网络做出实时性的验证,采用数据平面的事件作为驱动的方式,利用正则表达式描述不同种类的报文的路径特征,采用逻辑型编程模型.但与其他语言不同的是,本文提出的语言不是为了抽象现有北向接口而提出来的,而是专门针对网络验证的高级接口.属于为了实现SDN中的某个新功能而做出的北向控制平面的抽象.

3.4 北向接口中的命令式语言

命令式语言由于更强调如何去实现一个过程,而不是强调实现什么过程,所以更加注重怎么做网络策略.前几种SDN北向接口的语言都重在抽象出一个接口,供编程者用它去获取自己需要的策略资源.而命令式语言更加关注的是让编程者去想如何实现这个算法策略.命令式语言的典型代表便是Pyretic.

3.4.1 Pyretic[16]

Pyretic也是对SDN北向接口语言的抽象,是Frenetic编程语言的python子类.Pyretic可以让网络编程者和管理者写出模块化的网络应用,它基于python,实时的编译系统可以将利用pyretic写出的程序转化为流表规则下发到交换机中,Pyretic也是仅支持OpenFlow设备.

Pyretic处理报文,对于编程者来说,屏蔽了底层OpenFlow规则被使用的细节,利用高级语言编写转换函数,把packetin报文转化为packetout报文,同时编译出相应的无冲突的流表规则.Pyretic支持模块化编程,支持报文各个字段层次的或与非的操作,支持网络虚拟化,还可以利用事件的监听回调机制处理动态的策略等等.

3.5 北向接口中的面向对象编程语言

在SDN的北向接口的高级编程语言中,有一类语言专门为了实现网络虚拟化的功能,它们的编程模式更像面向对象的编程模型,即每一个对象都应该能够接受数据、处理数据并将数据传达给其他对象.这种编程模式的好处是可以将网络中的元素抽象为一个个对象,灵活且利于维护.SDN中这类语言的典型代表有上文提到的Pyretic,还有文献[33].

3.5.1 Splendid Isolation[33]

特定种类的流量彼此分离是很多网络操作得以正确进行的前提,例如高等院校要保护学生的记录,情报局的认证系统的流量要与常规流量分离,数据中心的租户之间的流量要分离等等.但是,在当今网络虚拟化的机制中,有很多机制都是临时的,比如VLAN(虚拟局域网)虽然可以隔离处理网络中不同类型的报文,但加重了原本复杂的网络配置;防火墙虽然可以阻止特定类型的报文进入特定的网络切片中,但需要在控制层加入hypervisor(例如Flowvisor[41])并且需要可信.总之,没有一种方案能够提供一个完全满意的隔离机制,而且这些机制都不能提供一个验证网络是否被有效隔离的功能.

基于以上问题,文献[33]提出了一个可以允许多个网络程序并行运行的网络切片机制,同一个物理拓扑可以被多个应用程序所用,它可以实现流量隔离、物理隔离以及控制隔离.通过这种语言编写的程序易读,并且对用户友好,采用网络隔离的抽象接口,可以编写简单、灵活的程序,进而把物理网络分为多个虚拟切片,再在这个切片上编写应用程序.

3.5.2 Network Control Language(简称NCL)[34]

NCL是由华为公司提出的北向接口的高级语言,它基于Java,编程者同样不用关心设备的实现细节,只关注应用的需求.由于已将NCL嵌入到Java中,所以用户可以直接用Java编写网络应用,NCL中的编译器可以将策略编译为数据平面的低级语言.利用NCL面向对象的语法模式可以完成如下功能:(1) 方便地定义自己的虚拟网络;(2) 时间监听与回调机制可以处理网络中的协议和通知;(3) 可以应对上层的拓扑查询等应用.

NCL的系统结构如图 6所示.

Fig. 6 NCL architecture[34]图 6 NCL系统结构[34]
3.6 小结

以上便是北向接口中的高级语言,总结北向接口中的各种编程语言,它们的共同点都是为了给网络编程带来简捷,通过抽象底层硬件设备细节,抽象流表生成及下发细节,抽象网络配置的细节,简化编程者的工作,使得网络管理员甚至是一般的网络参与者都能配置自己需要的网络策略,进而指导网络的行为.同时,某些北向接口的语言还可以提供网络验证、兼容各种网络中间盒设备、网络虚拟化等特性,使得SDN的可编程特性得到效益的最大化.下一节将对北向接口中的高级语言进行横向比较.

4 北向接口语言的横向比较

经过了上一节对于北向接口高级语言的分类和详细介绍,下面将对各个分类的语言进行一个横向的比较.

对于高级语言和低级语言而言,高级语言有如下优势:

(1) 屏蔽底层设备接口细节,方便编程者只关注网络策略的算法逻辑;

(2) 支持并行的应用同时运行,不用编程者手动解决流量冲突问题;

(3) 模块化的编程方便代码的复用;

(4) 物理网络可以被切分为隔离好的虚拟网络,方便路由等策略的部署.

而针对高级语言中的声明式语言、命令式语言以及面向对象语言,在不同的应用场景下分别有不同的优势.函数型语言中的Frenetic,HFT,PANE,Maple,NetCore更适合处理对于转发、防火墙等需要处理报文的应用;对于网络验证、编写有状态的防火墙的应用来说,Flog,Frenetic,FlowLog,Assertion Language有明显的优势;对于网络虚拟化以及需要对底层流量做隔离的应用来说,面向对象的编程语言Splendid Isolation,pyretic有明显的优势.表 3给出了在各个分类下的编程语言的详细比较.

Table 3 Programming languages in each category 表 3 各个分类下的编程语言

表 3可以看出,从是否引入新的网络功能这个分类标准来看,对于需要进行网络验证、模型检查的网络,Flog、FlowLog、Merlin、Assertion Language等都存在优势,而对于需要作网络切片、流量隔离的网络来说,Splendid Isolation和NCL是比较不错的选择.同时,如果需要在网络上部署多个协议,可以采用HFT、PANE、Maple、pyretic等能够有效解决流表冲突的语言.

从语言的实现机制上,对于嵌入现有语言的北向接口语言来说,可以利用现有语言丰富的库以及复杂的功能,对于编程者来说也能相对容易些.与此相对应,对于自定义语法规则的语言来说,更容易填写新的功能以及针对网络需求优化编译策略.

在语言的表达能力上,高级语言由于对细节的封装程度高,所以表达性要强于低级语言,更加易读,并且方便学习,所以对于用户也更加友好.在实现形式上,基本上所有的高级语言都由两部分组成:上层的高级语言以及下层的编译器,这一点基本类似.在运行效率上,编译器的效率决定了整体的运行效率,在高级语言中,NetCore和Maple等在编译器上作了很多有效的优化,所以运行效率相对较高.

5 SDN 北向接口语言研究方向的展望

SDN作为一种新型的网络体系结构,用可编程的交换机代替了传统网络中的交换机、路由器、防火墙等设备,通过集中的控制器去管理网络.SDN的上层应用可以利用北向接口获取网络信息并做出网络策略指导下层设备的行为.这样的架构给网络的可编程性带来可能,但是基于SDN的编程却并不简单.针对现在OpenFlow给出的接口过于低级带来的各种问题,SDN北向接口中的高级语言不断涌现,它们都在不同的应用层面上给网络编程者带来方便,克服了低级语言存在的种种问题.

但是目前针对SDN北向接口的研究工作还处于起步阶段,尚未发展成熟,仍有很多值得研究的问题,未来可进一步研究的相关重要方向包括:

(1) 北向接口还没有形成一个统一的标准.针对现在控制器多样化的情况,需要制定一套适用于定义北向接口的通用语义,这样不仅编程者有一个标准的部署应用的流程,开发控制器的人也可以利用这些已标准化的语义去开发各自的北向接口.

(2) 各个北向接口的编程语言都是针对特定场景而提出的,由于语言特性的限制,也只能固定简化某一类网络应用.如果能有一种较为通用的语言可以解决绝大多数场景下的问题,不拘束于语言的特性,则可以极大地提高编程效率.

(3) 对于一些常用的网络应用,北向接口语言可以提供一套常用功能函数库的支持,以提高SDN网络中的编程效率.

(4) 目前北向接口高级语言框架中编译器的性能还有待优化.例如,在提高编译生成流表的效率、尽量减少编译生成流表的优先级等方面,还有很大的提升空间.

(5) 现有的很多语言还仅仅支持单一控制器,如果能让这类语言自动部署运行在分布式控制器中,则可以有效提高控制器的性能以及整个网络的鲁棒性.

(6) 现有的北向接口语言往往只能支持有限的新功能,如何将多种新功能集成到同一个北向接口语言中,有待进一步加以研究.

(7) 对于可以处理网络链路错误配置的北向接口语言(如FatTire等)来说,如何能够发现交换机层级的错误以及如何让链路进行自动恢复也是未来的研究工作.

(8) 对于支持网络隔离和虚拟化的北向接口语言(如Splendid Isolation),现在只限于在拓扑上进行网络切片,未来可以考虑针对网络带宽等更多的网络资源进行切片.

6 总结

本文是一篇针对软件定义网络中北向接口语言的综述,为了简化软件定义网络中的编程模型,给网络策略的开发和部署提供便捷,近年来,北向接口的语言纷纷涌现出来,在这些语言中,根据不同的分类标准,又可以划分为不同的层次,本文详细介绍了学术界和工业界现有的各类北向接口的编程语言,同时对各种语言进行了横向比较,并对未来北向接口的研究工作进行了展望.

参考文献
[1] ONF Market Education Committee. Software-Defined Networking: The New Norm for Networks. ONF White Paper. Palo Alto: Open Networking Foundation, 2012.
[2] Nunes BAA, Mendonca M, Nguyen XN, Obraczka K, Turletti T. A survey of software-defined networking: Past, present, and future of programmable networks. IEEE Communication Surveys & Tutorials, 2014,16(3):1617-1634 .
[3] Kreutz D, Ramos FMV, Verissimo PE, Rothenberg CE, Azodolmolky S, Uhlig S. Software-Defined networking: A comprehensive survey. Proc. of the IEEE, 2015,103(1):14-76 .
[4] Hu F, Hao Q, Bao K. A survey on software defined networking (SDN) and OpenFlow: From concept to implementation communications surveys & tutorials. IEEE Communication Surveys & Tutorials, 2014,16(4):2181-2606 .
[5] Zuo QY, Chen M, Zhao GS, Xing CY, Zhang GM, Jiang PC. Research on OpenFlow-based SDN technologies. Ruan Jian Xue Bao/Journal of Software, 2013,24(5):1078-1097 (in Chinese with English abstract). http://www.jos.org.cn/1000-9825/4390.htm
[6] Gude N, Koponen T, Pettit J, Pfaff B, Casado M, McKeown N, Shenker S. NOX: Towards an operating system for networks. Computer Communication Review, 2008,38(3):105-110 .
[7] McCauley M. POX, 2012.
[8] Floodlight Is A Java-Based OpenFlow Controller, 2012.
[9] https://openflow.stanford.edu/display/Beacon/Home
[10] http://www.opendaylight.org/
[11] http://www.juniper.net/us/en/dm/sdn/
[12] Mckeown N, Anderson T, Balakrishnan H, Parulkar G, Peterson L, Rexford J, Shenker S, Turner J. OpenFlow: Enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 2008,38(2):69-74 .
[13] Bosshart P, Dan D, Gibb G, Martin I, McKeown N, Rexford J, Schlesinger C, Talayco D, Vahdat A, Varghese G, Walker D. P4: Programming protocol-independent packet processors. Computer Communication Review, 2014,44(3):87-95 .
[14] Song H. Protocol-Oblivious forwarding: Unleash the power of SDN through a future-proof forwarding plane. In: Proc. of the ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 2013. Hong Kong: ACM, 2013. 127-132 .
[15] Casey CJ, Sutton A, Sprintson A. tinyNBI: Distilling an API from essential OpenFlow abstractions. In: Proc. of the ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 2014. Chicago: ACM, 2014. 37-42 .
[16] Monsanto C, Reich J, Foster N, Rexford J, Walker D. Composing software-defined networks. In: Proc. of the 10th USENIX Conf. on Networked Systems Design and Implementation, ser. NSDI 2013. Berkeley: USENIX Association, 2013. 1-14.
[17] Laird A. The four major programming paradigms topic paper #17. Computer Science, 2009. http://www.alexlaird.com/content/uploads/2009/05/topicpaper17-thefourmajorprogrammingparadigms.pdf
[18] Coenen F. Characteristics of declarative programming languages. 1999. http://cgi.csc.liv.ac.uk/~frans/OldLectures/2CS24/declarative.html
[19] Voellmy A, Hudak P. Nettle: Taking the sting out of programming network routers. In: Proc. of the PADL 2011. Berlin, Heidelberg: Springer-Verlag, 2011. 235-249 .
[20] Hinrichs TL, Gude NS, Casado M, Mitchell JC, Shenker S. Practical declarative network management. In: Proc. of the WREN 2009. Barcelonan: ACM, 2009. 1-10 .
[21] Voellmy A, Kim H, Feamster N. Procera: A language for high-level reactive network control. In: Proc. of the ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 2012. Helsinki: ACM, 2012. 43-48 .
[22] Reitblatt M, Canini M, Guha A, Foster N. Fattire: Declarative fault tolerance for software defined networks. In: Proc. of the ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 2013. Hong Kong: ACM, 2013. 109-114 .
[23] Nelson T, Guha A, Dougherty DJ, Fisler K, Krishnamurthi S. A balance of power: Expressive, analyzable controller programming. In: Proc. of the ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 2013. Hong Kong: ACM, 2013. 79-84 .
[24] Foster N, Harrison R, Freedman MJ, Monsanto C, Rexford J, Story A, Walker D. Frenetic: A network programming language. In: Proc. of the ICPF 2011. Tokyo: ACM, 2011. 279-291 .
[25] Foster N, Guha A, Reitblatt M, Story A, Freedman MJ, Katta N.P, Monsanto C, Reich J, Rexford J, Schlesinger C, Walker D, Harrison MR. Languages for software-defined networks. IEEE Communications Magazine, 2013,51(2):128-134 .
[26] Ferguson AD, Guha A, Liang C, Fonseca R, Krishnamurthi S. Hierarchical policies for software defined networks. In: Proc. of the ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 2012. Helsinki: ACM, 2012. 37-42 .
[27] Voellmy A, Wang J, Yang YR, Ford B, Hudak P. Maple: Simplifying SDN programming using algorithmic policies. In: Proc. of the SIGCOMM 2013. Hong Kong: ACM, 2013. 87-98 .
[28] Monsanto C, Foster N, Harrison R, Walker D. A compiler and run-time system for network programming languages. In: Proc. of the POPL 2012. Philadelphia: ACM, 2012,47(1):217-230 .
[29] Guha A, Reitblatt M, Foster N. Machine-Verified network controllers. In: Proc. of the PLDI 2013. Seattle: ACM, 2013. 483-494 .
[30] Katta NP, Rexford J, Walker D. Logic programming for software-defined networks. In: Proc. of the ACM SIGPLAN Workshop on Cross-Model Language Design and Implementation, ser. XLDI. 2012. https://www.cs.princeton.edu/~dpw/papers/xldi-2012.pdf
[31] Soule R, Basu S, Kleinberg R, Sirer EG, Foster N. Managing the network with Merlin. In: Proc. of the 12th ACM Workshop on Hot Topics in Networks (HotNets-XII). College Park, 2013. 1-7 .
[32] Beckett R, Zou XK, Zhang SY, Malik S, Rexford J, Walker D. An assertion language for debugging SDN applications. In: Proc. of the ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, ser. HotSDN 2014. Chicago: ACM, 2014. 91-96 .
[33] Gutz S, Story A, Schlesinger C, Foster N. Splendid isolation: A slice abstraction for software-defined networks. In: Proc. of the 1st Workshop on Hot Topics in Software Defined Networks, ser. HotSDN 2012. Helsinki: ACM, 2012. 79-84 .
[34] Network Control Language(NCL) Software Defined Networking Research Group. 2014. https://datatracker.ietf.org/meeting/90/agenda/sdnrg/
[35] Anderson CJ, Foster N, Guha A, Jeannin JB, Kozen D, Schlesinger C, Walker D. NetKAT: Semantic foundations for networks. In: Proc. of the POPL 2014. San Diego: ACM, 2014. 113-126 .
[36] Ferguson AD, Guha A, Liang C, Fonseca R, Krishnamurthi S. Participatory networking: An API for application control of SDNs. In: Proc. of the SIGCOMM 2013. Hong Kong: ACM, 2013. 327-338 .
[37] Pfenning F. Logic programming lecture 26 datalog. 2006. http://www.cs.cmu.edu/~fp/courses/lp/
[38] Oliveira N, Pereira MJV, Henriques PR, Cruz D. Domain specific languages: A theoretical survey. In: Proc. of the 3rd Compilers, Programming Languages, Related Technologies and Applications (CoRTA 2009). 2009. http://alfa.di.uminho.pt/~danieladacruz/CoRTA09DSLsurveyvf.pdf
[39] Bird R. Introduction to Functional Programming Using Haskell. New York: Prentice Hall, 1998.
[40] Kazemian P, Varghese G, McKeown N. Header space analysis: Static checking for networks. In: Proc. of the 9th USENIX Conf. on Networked Systems Design and Implementation, ser. NSDI 2012. Lombard: USENIX Association, 2012. 9. https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/kazemian
[41] Sherwood R, Gibb G, Yap KK, Appenzeller G, Casado M, McKeown N, Parulkar G. FlowVisor: A network virtualization layer. Technical Report, OPENFLOW-TR-2009-01, OpenFlow Consortium, 2009. 1-14.
[5] 左青云,陈鸣,赵广松,邢长友,张国敏,蒋培成.基于OpenFlow的SDN技术.软件学报,2013,24(5):1078-1097. http://www.jos.org.cn/1000-9825/4390.htm