一种SDN Intent NBI的意图一致性问题解决方法

◆李宇衡 刘晓洁



一种SDN Intent NBI的意图一致性问题解决方法

◆李宇衡 刘晓洁

(四川大学计算机学院 四川 610065)

SDN(Software Defined Network)作为一种新型的网络架构，是当前网络架构研究的热点。随着SDN的发展，其北向接口所暴露的一致性问题越发突出，本文通过对北向接口的发展现状进行分析，提出了一种在新型北向接口Intent NBI的基础上解决意图下发一致性问题的方法，并通过实验的方式验证此方法的可行性。

SDN；网络架构；北向接口；一致性问题

0 引言

SDN业界普遍认可的定义，来源于开放网络基金会(Open Network Foundation,ONF）在白皮书《Software-Defined Networking: The New Norm for Networks》中给出的基于OpenFlow的定义。其核心理念是一种将网络控制功能与转发功能相分离并能实现可编程控制的网络新型框架。ONF的SDN定义的基本框架自上而下由应用层、控制层、基础设施层组成。其中控制层为核心层面，已经衍生出很多开源、非开源的控制器[1]。控制层主要负责处理数据层面资源编排，建立网络拓扑,管理、转发信息等，是SDN框架的核心层面。向上与应用层相连接的是北向接口，负责与网络应用相交互；向下与基础设施层连接的是南向接口，当前已有公认的国际化标准如OpenFlow、BGP等。基础设施层负责数据处理、转发、状态获取[5]。

SDN北向接口可以使网路应用通过控制器（controller）方便地调用底层网络资源，并能及时获得正确的资源状态及反馈。因此，网络应用开发者可以使用软件编程的方式调用底层网络资源，直观地把控整个网络资源的使用情况，实现对网络资源的统一调度。近年来各大厂商开始关注北向接口的研究，但是相比于已经有很多公认国际化标准（如OpenFlow,BGP,PCEP等）的南向接口，北向接口因为其与网络业务的密切联系，呈现出复杂性、多样性的特点，并且北向接口设计是否合理、便捷，是否能被广泛适用于各种SDN控制器，都使得推出一个公认的北向接口标准的难度增加。

传统的SDN北向接口基于PDP(Policy Decision Point)/PEP(Policy Enforcement Point)“决策-控制”的工作模式，由网络应用商根据自己的需求制定策略，通过北向接口将策略传递给SDN控制器，进而由控制器与下层具体网络元件进行交互，再由下层具体网络元件实现网络应用商的既定策略。这种模式将控制行为分割成任务与执行两个部分，决策点和策略下发点（PDP）并非是策略的执行点（PEP），并且假定执行点都会按照指令（策略）执行。策略下发点并不清楚当前执行点的执行能力和环境条件，当出现网络时延或同时多个策略下发点同时下发策略时，下发点彼此之间无法避免可能发生的策略冲突，产生大量的逻辑一致性问题。[2-3]

通常出现这些逻辑一致性问题后，理想解决方法是先在上层解决冲突后，再下发给下层执行无冲突的策略。而目前常见的解决方案没有实现这种理想方法，是由上层应用系统提供额外的补救解决方案，如：在控制器中设置冲突解决器，在收到下层反馈的原始未解决冲突的策略执行结果后，若出现业务逻辑冲突，再由冲突解决器进行冲突解决，最后下发解决后的方案，这种解决方式额外占用SDN控制器大量的资源与能力，影响整个系统的效率。[8-9]

最近几年出现一种面向用户网络意图操作的新型北向接口（Intent NBI）,Intent NBI是一种与网络技术实现无关的NBI，网络应用借助Intent NBI表达其业务意图，不关注网络细节和实现技术，丰富网络应用[7]。这类用户意图的声明式接口，网络用户、应用只需描述想要“What”，而无需关心“How”，向用户隐藏了网络相关的技术信息，大大降低了网络用户、服务的网络操作难度，使得网络更容易被操作和使用[11]。这种对网路应用隐藏下层网络细节和实现技术的理念，为解决一致性问题提供了可行的框架。本文将在Intent NBI接口的基础上通过借鉴承诺理论思想，实现理想的解决意图一致性问题的方法。

1 承诺理论

承诺理论，最初来源于Mark Burgess在挪威奥斯陆大学的博士后研究工作，其初衷是改进基于强制模型的分布式Linux工作站策略。承诺理论采用相反的思路解决冲突问题，即由执行点主动对外承诺，来宣告自身的能力，执行者根据执行点所宣告的能力契合自身的需求，制定策略。这样改变原有网络供应商需要阐述“我应该怎么做”的情形，使用者即网络供应商只需表达“我需要什么服务”的意图[2]。当前，承诺理论已经发展为分布式系统中关于个体、自制系统之间基于自愿机制的协同模型。

对于新型北向接口（Intent NBI），它相对于上层应用程序可以作为一个整体独立的接口。这种独立性，为实现承诺理论提供了可能。根据承诺理论，我们可以把Intent NBI中的执行者定义为基础设施层的交换机，把承诺接收者定义为SDN 控制器。本文将在Intent NBI上添加实现承诺理论的模块，用于解决SDN北向接口逻辑一致性问题。

2 逻辑一致性问题解决方法

本文提出了一种基于承诺理论的逻辑一致性问题解决方法，并实现了冲突解决模块，将此模块以插件形式置于新型北向接口（Intent NBI）上，整体框架如图1所示。

图1 方法实现整体结构

每一个网络设备，如交换机等，在接入SDN网络（基础设施层）后，将会主动的把与自己相邻的网络设备之间的链路流通情况，反馈给上层的SDN控制器，SDN控制器实时保存一个下层网络设备链路连通情况的表，即网络设备的能力集合。应用层下发意图后，冲突解决模块会先对意图进行整合，将整合结果（单一意图省略意图整合过程直接进行下一步），与控制层所维护的网络能力集进行匹配，得到网络最大满足上层意图的能力意图，再交给SDN控制器，下发给基础设施层，进行执行，最后反馈执行结果。

这种在执行意图前就通过在Intent NBI中的意图冲突模块解决冲突的方式，相对于以往在控制器反馈基础设施层执行意图结果后，再由上层应用做出冲突解决的方式，将极大的减轻SDN控制器的压力，提升程序整体效率及质量。

2.1定义数据结构

定义1，节点对（pair）：表示一个源端点和一个对应的目的端点。结构如下：

pair

其中SrcEndpoint表示源端点，DstEndpoint表示目的端点。

定义2，意图集（Intents）：描述一个或多个具体的意图指令的集合，结构如下：

Intents{intent1、intent2、……,

intentm| intenti

{pair1,pair2,……,pairm},

{action1,action2,……，actionm}>,

0

其中uuid在整个工程中唯一标识一条下发的意图指令，pair表示本指令所涉及的2个端点，action表示匹配编号相同的pair端点间执行的动作指令。

定义3，节点（endpoint）：表示交换机节点，结构如下：

endpoint

其中uuid标识唯一节点，InetAddress结构内部封装节点ip值、主机名等信息。

定义4，动作action：表示两个端点之间的动作指令，可以是allow、block或者allow|block。

定义5，网络能力集：表示网络中每一个节点之间的连通情况的集合Capacity{C1，C2，……,Cn| Ci}，其中pair表示涉及的两个端点，action表示两个端点间可以执行的动作指令。

2.2更新网络能力集过程

交换机SWi接入SDN网络后，Controller将通过进行网络拓扑结构更新或者发现添加SWi的具体信息。Controller通过OF Packet Out 指令要求SWi在其所有端口上发出LLDP(Link Layer Discovery Protocol，EEE802.1ab)链路探测包。LLDP的源MAC为Controller分配，这里为00:00:00:00:00:01(对每一个交换机，Controller都会分配一个这样的MAC作为SW标识)，LLDP目的MAC地址为组播地址。相邻的SWj将接收到LLDP，SWj由于无法识别这条流，会将OF协议再发到Controller上[10]。通过LLDP的发送和接收，Controller可计算出交换机之间的拓扑关系。通过上述探测过程，根据SWi和其他SW的连通情况，更新网络能力集（Capacity）。

2.3逻辑一致性问题解决过程

（1）上层应用程序，下发意图intentx（1

①pairs= pairx∩pairc；

②对于每一个pairs中的pair，设actionx、actionc分别为pair在Intentx、Capacity中对应的动作。则最终pair所对应的动作为actionx在actionc取值范围内的值。

最后处理模块把冲突解决后的 intent交给控制器（如图2）。

图2 单一意图处理流程图

（2）多条意图指令

SDN上层应用程序，下发意图集Intents{intent1、intent2、……,intentm}，对于intenti(1<= i

①对于只在intenti中出现的pairj，直接将pairj和对应的action加入intent中,intent中Pair大小更新为Pair = Pair∪pairj;

②对于某一元素pairn既存在于Pair又存在于Pairi，action、actioni分别表示pairn在intent、intenti中的对应的action，则最终pairn所对应的action为actioni覆盖action的结果；

③根据上述方法得到intent后，i加1，循环进行上述步骤，直到处理完最后一个意图，伪代码如下所示：

for （intent1、intent2、……,intentm,i=1;

i<=m ; i++）

{

if(pairj∈Pairi且pairj∉Pair)

{

intent

{pair1,pair2,……,pairm},

{action1,action2,……，actionm} >

+=

}

If (pairn∈ Pair且

pairn∈Pairi)

{

action=actioni

}

}

通过上述循环，得到解决冲突后的最终意图集Intents{intent}，再把Intent按照单一意图处理流程处理，将最终的冲突解决后的意图交给控制器，由控制器下发给基础设施层执行（如图3）。

图3 多意图处理流程图

3 实验及结果分析

本次实验，将在opendaylight平台上的NIC工程下，加入冲突解决模块，为NIC工程提供对下发的意图命令提供解决逻辑一致性问题的功能。具体使用的工具及版本如下OpenDaylight-Boron-SR2、mininet-2.2.1、maven-3.5.0。根据设计的数据结构、构建数据类、意图融合类，添加在NIC项目的compile目录下，编译程序，启动ODL工程并安装NIC插件。利用mininet产生，如图4所示的拓扑：

图4 网络拓扑结构

Host1、Host2、Host3、Host4的ip分别为10.0.0.1、10.0.0.2、10.0.0.3、10.0.0.4

在模拟的网络拓扑基础上，本次实验将下发7条逻辑冲突的意图命令，通过运行本文解决冲突的NIC插件模块对以下7条意图命令进行逻辑冲突解决，并验证冲突解决后的结果。

意图命令1：阻止来自Host1的数据流向Host2,Host3；

意图命令2：允许来自Host1、Host4、Host3的数据流向Host2；

意图命令3：允许来自Host1、Host3的数据流向Host2；

意图命令4：阻止来自Host1的数据流向Host2、Host4；

意图命令5：允许来自Host2的数据流向Host3、Host4;

意图命令6：允许来自Host1的数据流向Host3、Host2；

意图命令7：阻止来自Host3的数据流向Host2。

实验所用上述7条命令，彼此间形成逻辑冲突。选取前3条都涉及HOST1节点的意图命令，直接在NIC插件中下发运行。其结果通过mininet验证各节点间数据连通情况如下图5所示：

图5 未处理意图下发结果图

从图5可以看出，对于h1(Host1)，不能与h2(Host2)连通。对于意图命令2和3 都涉及允许h1的数据流入h2，但是由于下发意图顺序落后于意图命令1（阻止h1数据流如h2），未能实现最终的连通，即没有具备意图冲突解决能力。

在NIC插件中添加意图逻辑冲突解决模块，并且下发所有7条意图命令，运行解决模块，生成的最终命令如图6所示：

图6 意图整合结果图

根据实验结果，可以看到，冲突解决模块，分离每一条意图命令中的原子级动作（ACTION），采用2.3中的方法将所有原子动作进行匹配、整合形成最终的已解决冲突的意图，即：

意图命令1：允许来自Host2的数据流向Host4；

意图命令2：阻止来自Host1的数据流向Host4；

意图命令3：允许来自Host4的数据流向Host2；

意图命令4：阻止来自Host3的数据流向Host2；

意图命令5：允许来自Host1的数据流向Host3；

意图命令6：阻止来自Host1的数据流向Host2；

在mininet端验证端点间数据连通情况如图7：

图7 端点连通图

对于图7结果，Host1(h1)可以与Host2(h2)、Host(3)相互连通，Host2(h2)与Host4(h4)可以相互连通，证明冲突解决后的意图命令集合已经生效。

综上结果，证明了本文方法是解决北向接口逻辑一致性问题的一种有效方式。

4 总结及展望

本文的解决方法虽然是SDN北向接口一致性问题的一种有效解决方式，但是诸多方面还需要进一步发展和验证，如性能问题，在同时面临数量庞大的策略下发情形下，单一控制器处理模块的处理意图冲突能力将受到较大的挑战，其正确率也难以保证。在今后的北向接口发展过程中，将大量的意图分成小的段，分段处理，再合并分段结果的方法，或许会形成一种新的发展趋势。

[1]network.51cto.com/art/201502/464650.htm.

[2]陈世强, 张子剑, 祝烈煌等.基于多控制器的SDN一致性机制研究[J].北京理工大学, 2016.

[3]唐红, 刘汉江, 陈前锋等.opendaylight应用指南[M]. 人民邮电出版社, 2016.

[4]http://docs.opendaylight.org/en/stable-boron/getting-started-guide/overview.html.

[5]软件定义网络机械工业出版社，2004.

[6]程莹, 张云勇. SDN应用及北向接口技术[J].信息通信技术, 2014.

[7]张岩, 张忠平, 张曼君.基于Intent的SDN北向接口研究综述[J].信息通信技术, 2016.

[8]CANINI M,VENZANO D,PERESINI P,et al. A NICE way to test Openflowaplications[C]//Proc of the 9th USENIX SymponNetworked Systems Design and Implemetation(NSDI).San Jose:USENIX ASSOCIATION, 2012.

[9]左青云, 陈鸣, 赵广松等.基于Openflow 的SDN技术[J].软件学报，2013.

[10]李风凯，张亚丽，夏寅贲. NEMO：一种声明式网络编程与业务定制语言[J]. 信息通信技术, 2016.

国家重点研发计划(2016yfb0800604 2016yf b0800605),国家自然科学基金项目(61572334)。