CN112087385B - 一种基于多控制器协商的sdn一致性更新方法 - Google Patents

Abstract

本发明公开了一种多控制器协商的SDN一致性更新方法，采用多控制器布局方式的层次控制器的部署模式，对多个域中每个均设置自己的局部控制器，并在其中一个域内设置一个掌控全局状态的全局控制器，控制器中设置网络监控模块、本地决策模块、更新协调模块，在全局和本地更新模块中完成对流表的修改等。本发明考虑到涉及的网络设备之间的异构性，结合常用的通用场景下的一致性更新算法，通过层次控制器和策略协商机制避免更新冲突；通过考虑网络中的设备异构性、跨域网络时延等因素选择合适的算法，针对应用特点和网络能力选择最合适的一致性更新算法，提升一致性更新的灵活性，更有效地满足应用需求。

Description

一种基于多控制器协商的SDN一致性更新方法

技术领域

本发明涉及计算机网络技术领域，尤其涉及一种基于多控制器协商的SDN一致性更新方法。

背景技术

随着工业智能化逐渐加深，单纯的云计算无法满足工业场景对数据的实时性和隐私性的要求，通过增加边缘节点作为中心云的延伸对这两点进行弥补，是云计算研究领域的热点，而边缘计算中网络资源的协调分配则是一个核心问题。基于OpenFlow软件定义网络解耦了网络设备的控制与转发，控制器集中控制向转发节点下发转发策略实现网络连通，具有灵活配置、快速部署的特点，能够改善网络配置繁杂和资源跨域访问等问题。

由于服务变更、流量工程变动等不稳定因素，常常出现链路更换、链路删除、链路带宽降低或提升等情况，由此引发转发策略的变更，即对同一目的地址的包的操作变更。控制器计算得到的转发策略经由网络传输给转发节点进行策略更新，其实是一种分布式进行网络更新的方式。由于同一套转发策略异构的不同分段在不同的设备上分别写入，而这些设备的网络时延、运算能力等方面存在差异，策略更新时会不同步不一致，由此引发拥塞、黑洞、回环、死锁等问题，继而造成网络传输时延增大、丢包甚至局部网络瘫痪，最终导致对网络状态要求较高的服务运行异常。

一致性更新问题从级别上分为包一致性更新与流一致性更新，即一个包或一条数据流在转发时候是否遵从同一个版本的规则，而不发生混用。网络更新时候常见每包一致性更新问题。如图1，主机1与2之间通过五个虚拟交换机相连，当AB之间的旧规则被删去，而AC之间的新规则尚未添加，则此时到达A的包将会无处转发；当AB连接未被删去，而AC、CB之间规则已被更新，则会出现ACB不断转发的情况。以上都是没有满足包的一致性更新造成的。

在云边协同的场景中，存在多控制器跨域进行网络更新的情况，其与传统的一致性更新的研究场景不同之处在于边缘设备的计算资源和计算能力有限，云端整体能力较强，二者在设备、资源和能力等方面的异构性对更新方案的实现有着一定的限制；边缘与云端同时存在的控制平面使得整体的控制布局具有复杂性，也会对协调更新产生影响。

包的一致性更新通用做法有很多种，包括标记版本、缓存未处理的包、计时更新等，但多数方法都设定上述交换机的设备规格是相同的，而不考虑设备异构等条件，也因此有较多问题。例如多版本流表项的方式会占用大量空间，如图1，若交换机B能够存储流表项的空间很小，则不适用该方法；而缓存方式将更新过程中的包存储在控制器缓冲区中，若某个缓冲区很小也不合适。

包的一致性更新的现有技术主要有：一种软件定义车载网络转发策略的一致性更新方法CN105404667A，一种解决SDN流级别配置一致性更新的方法和装置CN104202183A，一种SDN中实现流有序的一致性更新方法CN104980431A，流表更新方法、控制器及流表分析设备CN105282057B。

对上述专利中存在的没有考虑网络中的交换机之间计算能力、存储空间、控制器等方面的异构性、没有考虑多域共存的网络跨域更新时域间网络时延较大情况、没有考虑多控制器之间规则存在冲突以及优先级排序情况等问题，现有技术的解决方式在于通过多控制器协商机制与基于该机制的包级别一致性更新方案，首先考虑到涉及的网络设备之间的异构性，结合应用特征确定本次更新适宜使用的传统算法，并考虑跨域时延等因素，将协商流程缩短，降低协商成本。

但现有技术解决其技术问题仅通过对流表项进行分类、协调不同类别的流表项更新顺序，对云边协同场景与通用场景之间的区别没有给予考虑，也不能够针对应用的特征进行协调。

而边缘计算应当满足边缘计算云边协同的一致性更新方案应具有以下特点：

1.能够针对不同设备与链路情形，对应选用的一致性的更新算法进行筛选并得到结论，可以使用多维度的评分机制；

2.在多控制器的场景下，能够协调冲突的更新规则与控制器之间的优先级；

3.针对跨域场景的网络时延，能够减少控制器与控制器、控制器与交换机之间的交互，降低一致性更新的协商成本。

发明内容

为了解决目前包级别一致性更新方案的一些弊端，我们提出一种基于多控制器协商的SDN一致性更新方法。

具体地，采用多控制器布局方式的层次控制器的部署模式，对多个域中每个均设置自己的局部控制器，并在其中一个域内设置一个掌控全局状态的全局控制器，所述局部控制器由网络监控模块和状态库、本地决策模块和局部更新模块组成，所述全局控制器由网络监控模块和状态库、更新协调模块和全局更新模块组成，所述全局控制器产生所述局部控制器应该使用的一致性更新方案序列，并返回至局部控制器：

网络监控模块和状态库：所述局部控制器中的网络监控模块获取本地网络中的状态库信息作为网络状态信息，在存入本地状态库的同时上传给所述全局控制器；所述全局控制器中的网络监控模块汇聚从各个所述局部控制器发来的状态，并存入全局状态库；

本地决策模块和更新协调模块：所述局部控制器中的本地决策模块根据状态为可用更新算法进行优先级排序，并交予所述全局控制器与之对应的更新协调模块进行评估；所述全局控制器中的所述更新协调模块根据全局状态与各局部控制器传来的算法优先级和丢包率、传输时延与更新时长信息计算得到最佳的更新方式，并交还所述本地决策模块，并在产生异议的时候进行协商；

局部更新模块和全局更新模块：所述局部更新模块为实际的更新执行者，即根据决策模块的指令选择更新算法并与交换机进行交互；所述全局更新模块在各局部网络进行更新时进行全局通信与更新操作，防止各局部更新不一致。

所述网络监控模块收集各所述全局控制器和所述局部控制器、交换机状态和短时内的链路状态，并将其存入本地与全局的状态库中，所述交换机定时对所述局部控制器和所述全局控制器汇报自身状态与网络状态，所述局部控制器定时对所述全局控制器汇报自身状态与网络状态，网络中不同域之间的链路状态由所述全局控制器的网络监控进行探测。

所述汇报与所述探测过程的具体时间间隔根据网络负载与策略出现变化的频率决定，所述状态库信息中设置控制表、交换机表和链路表三个表格，所述控制表字段包括：控制器ID、控制器所在域、控制器IP地址、包缓存空间大小、剩余包缓存空间；所述交换机表字段包括：交换机id、交换机所在域、交换机IP地址、流表空间大小、剩余流表空间、新增流表项耗时、删除流表项耗时；所述链路表字段包括：链路ID、链路起点、链路终点、链路负载、链路带宽。

所述更新协调模块设置于所述全局服务器，接收所述全局状态库的数据，并与所述本地决策模块进行信息交互，并将信息发送至所述全局更新模块，其具体过程包括6步，

S1：所述更新协调模块收集更新消息；

S2：判断是否不涉及其他域和控制器，判断这次更新是否涉及多个域，由于本地决策模块已为本地进行了最优方案的计算，当仅涉及到单个域的域内更新则不涉及更多的协商过程，进入S6，所述更新协调模块将更新方法信息传递给所述全局更新模块，并反馈给本地决策模块；若更新涉及多个域和多个控制器，则进入S3；

S3：针对最优目标进行更新的方案编排，所述更新协调模块将根据局部策略和应用对网络的要求，计算最佳的更新方案；

S4：向全部需要进行更新操作的控制器发送S3中的编排结果，所述全局控制器得到更新方案的组合后反馈给局部控制器的决策模块，所述本地决策模块再进行计算，并发送反馈；

S5：根据回应判断是否达成共识或协商超时，若达成共识则进入S6，若未达成共识则进入S3，再进行一次优先级协调，超过协商可用最长时长仍未共识则停止协商；

S6：向全局更新模块发送最终的更新方案。

所述本地决策模块通过8个步骤实现其功能，具体地，

S1：得到要更新的规则与指令；

S2：获取涉及到的控制器与交换机的全局状态，在规则变化时，将涉及变化的局部控制器、交换机与链路状态取出；

S3：根据状态针对应用的传输时延、丢包率和更新时长的需求、对一致性更新算法计算可行性优先级并排序，所述可行性优先级是得到更新时长与丢包率后与目标更新时长和丢包率进行比较，所述一致性更新算法采用版本标记算法、缓存更新算法、计算顺序算法；

S4：将排序好的算法及相关信息提交给全局控制器，发起协商；

S5：等待全局控制器的反馈；

S6：若达成共识或已超过协商时长则进入S7,否则进入S4；

S7：按照最后的协商结果为生成更新方法；

S8：向所述本地更新模块发送。

更新是指发生规则变化，需要对交换机上的规则进行修改；

更新消息是指出现更新的时候，全局控制器得到的出现了更新的通知。

更新方法信息是指本文中全局控制器协调好了进行更新的方式之后，发送给局部控制器的信息，包含局部控制器应使用的更新方法和开始更新的时间等。

所述全局更新模块进行全局视图的策略规整，并发送到局部控制器中的更新模块执行流表更新的操作。

所述局部控制器中分别进行规则变更，在完成更新后向全局控制器发送信息，当全局控制器的更新模块收到全部的更新完毕消息，认为本次更新已经完成。

与现有技术相比，本发明的方法具有以下优势：

本发明所涉及的一种评定网络设备与链路状态的控制器协商机制，与基于该机制的一致性更新方案，结合常用的通用场景下的一致性更新算法，通过考虑到云边协同场景中多控制平面的因素导致的规则变更冲突等问题，利用层次控制器将视图统一并通过策略协商机制避免更新冲突；通过考虑网络中的设备异构性、跨域网络中存在的网络时延等因素，建立算法可行度模型，并根据可行度选择合适的算法，减少或避免网络中多域并行更新时这些差异造成的不一致，能够根据网络中设备在存储空间、计算能力与环境网络负载等多方面的不同条件，并针对应用特点选择最合适的一致性更新算法，提升一致性更新的灵活性，更有效地满足应用需求。

本发明相比于原有的通用算法，更适用于云边共存并协同工作、有着大量异构设备与不同链路状态与控制平面的边缘计算场景。

附图说明

图1现有技术一致性更新举例；

图2层次控制器；

图3系统模块图；

图4更新协调模块工作流程；

图5本地决策模块流程

具体实施方式

以下是本发明的优选实施例并结合附图，对本发明的技术方案作进一步的描述，但本发明并不限于此实施例。

针对现有技术存在的缺点，本发明提出了一种基于多控制器协商的SDN一致性更新方法的技术方案。具体地，方案选取多控制器中的层次控制器的部署模式。如图2所示，多个域各自存在自己的局部控制器，而在其中一个域内存在一个掌控全局状态的全局控制器，这种布局的方式中局部控制器之间的协商工作主要由全局控制器完成，即全局控制器在掌握了全局的设备与链路状态以及各局部控制器的更新指令后进行协调。多控制器的另一种布局方式，扁平控制器中所有的局部控制器都具有全局视图，分别进行计算，并在控制器之间自行协商，效果与层次控制器的实现相似。

基于控制器协商机制的一致性更新方案由以下几个模块组成，如图3。

局部控制器中网络监控模块获取本地网络中的链路带宽等网络状态信息，在存入本地状态库的同时上传给全局控制器；全局控制器中的网络监控模块汇聚从各个局部控制器发来的状态，并存入全局状态库；

局部控制器中的决策模块根据状态为可用更新算法进行优先级排序，并交予全局控制器进行评估；全局控制器中的更新协调模块根据全局状态与各局部控制器传来的算法优先级等信息计算得到最佳的更新方式，并交还本地决策模块，并在产生异议的时候进行协商；

局部控制器的更新模块为实际的更新执行者，即根据决策模块的指令选择更新算法并与交换机中的流表等部件进行交互；而全局控制器中的全局更新模块则在各局部网络进行更新时进行全局通信等操作，防止各局部更新不一致。

此外交换机中也应存在为相应通用算法设计的新功能，如版本标记法的版本对比、计时法的全局时钟等，图中未详细画出。下文将对上述模块分别进行介绍。

网络监控与状态库

网络监控模块主要收集各控制器全局和本地的控制器、交换机状态和短时内的链路状态并将其存入本地与全局的状态库中。规定交换机与控制器定时对上层控制器汇报自身状态与网络状态，而网络中不同域之间的链路状态由全局控制器的网络监控进行探测。汇报与探测的具体时间间隔视网络负载与策略出现变化的频率而定。状态库中的主要内容如表1。

表1状态库信息

更新协调模块

该模块负责监控更新请求，判断这次更新是否涉及多个域。由于局部策略产生模块已为本地进行了最优方案的计算，所以当仅涉及到单个域的域内更新则不涉及更多的协商过程，此时更新协调模块将更新方法等信息传递给全局更新模块，并反馈给本地决策模块；若更新涉及多个域和多个控制器，更新协调模块将根据局部策略和应用对网络的要求，计算最佳的更新方案，原因在于各局部最优方案的简单组合未必能够达成最佳效果，如假设两控制器的最短更新时间差值较大，则可令较短的一方晚些开始更新，或使用次优方案进行更新，这在节省缓存空间或流表空间上具有一定作用。全局控制器得到更新方案的组合后反馈给局部控制器的决策模块，本地决策模块再进行计算，并发送反馈，若未达成共识则再进行一次优先级协调，超过协商可用最长时长仍未共识则停止协商。流程如图4。

S1：更新协调模块收集更新消息

S2：判断是否不涉及其他域和控制器，是则进入S6否则，进入S3

S3：针对最优目标进行更新的方案编排

S4：向全部需要进行更新操作的控制器发送S3中的编排结果

S5：根据回应判断是否达成共识或协商超时，是则进入S6，否则进入S3

S6：向全局更新模块发送最终的更新方案。

本地决策模块

该模块负责在规则变化时，将涉及变化的局部控制器、交换机与链路状态取出，并针对应用的传输时延和丢包率等需求、对几种常见的一致性更新算法计算可行性优先级，并排序。可行性优先级是指各种算法的基础要求与真实环境的匹配程度。如某域内的局部控制器中缓存空间充足，链路带宽充足，但交换机的流表空间有限，我们可以认为与其存储多版本流表项占大量流表空间，不如将更新过程中的表缓存到交换机、控制器甚至相邻控制器中，因此第二种方法的可行优先级更高。

几种常见方法计算可行度所需参数如表2，更新时间与丢包如表3常见更新算法的时长与丢包。

表2常见更新方法的参数与可行度计算

表3常见更新算法的时长与丢包

方法	更新时间	更新过程中平均丢包
			版本标记	(N<sub>a</sub>*T<sub>a</sub>+N<sub>d</sub>*T<sub>d</sub>)	(N<sub>a</sub>+N<sub>d</sub>-Tcam)*T<sub>d</sub>*R<sub>p</sub>
缓存更新	(N<sub>a</sub>*T<sub>a</sub>+N<sub>d</sub>*T<sub>d</sub>)+(C/Bw)+T<sub>c</sub>	(N<sub>a</sub>*T<sub>a</sub>+N<sub>d</sub>*T<sub>d</sub>+T<sub>c</sub>)*R<sub>p</sub>-C||0
			计算顺序	(N<sub>a</sub>*T<sub>a</sub>+N<sub>d</sub>*T<sub>d</sub>)+T<sub>c</sub>	T<sub>c</sub>*R<sub>p</sub>

在得到更新时长与丢包多少后可与目标的更新时长和丢包率进行比较，并将所得结果上传到全局控制器。图5为评价决策模块流程。

S1：得到要更新的规则与指令

S2：获取涉及到的控制器与交换机的本地状态

S3：根据状态计算各类算法的可行优先级

S4：将排序好的算法及相关信息提交给全局控制器，发起协商

S5：等待全局控制器的反馈

S6：若达成共识或已超过协商时长则进入S7,否则进入S4

S7：按照最后的协商结果为生成更新方法

S8：向更新模块发送

更新是指发生规则变化，需要对交换机上的规则进行修改；

更新消息是指出现更新的时候，全局控制器得到的出现了更新的通知。

更新方法信息是指本文中全局控制器协调好了进行更新的方式之后，发送给局部控制器的信息，包含局部控制器应使用的更新方法和开始更新的时间等

更新模块

控制器计算得到方案后，由全局更新模块进行全局视图的策略规整，并下发到局部控制器，由局部控制器中的更新模块执行流表更新的操作。

局部控制器中分别进行规则变更，在完成更新后向全局控制器发送信息，当全局控制器的更新模块收到全部的更新完毕消息，认为本次更新已经完成。

Claims (5)

1.一种基于多控制器协商的SDN一致性更新方法，通过多控制器协商机制得出多个控制器在更新过程中使用的一致性更新方案序列，再由多个控制器执行具体的网络中交换机的流表更新，其特征在于：采用多控制器布局方式的层次控制器的部署模式，对多个域中每个均设置自己的局部控制器，并在其中一个域内设置一个掌控全局状态的全局控制器，所述局部控制器由网络监控模块和状态库、本地决策模块和局部更新模块组成，所述全局控制器由网络监控模块和状态库、更新协调模块和全局更新模块组成，所述全局控制器产生所述局部控制器应该使用的一致性更新方案序列，并返回至局部控制器：

网络监控模块和状态库：所述局部控制器中的网络监控模块获取本地网络中的状态库信息作为网络状态信息，在存入本地状态库的同时上传给所述全局控制器；所述全局控制器中的网络监控模块汇聚从各个所述局部控制器发来的状态，并存入全局状态库；

本地决策模块和更新协调模块：所述局部控制器中的本地决策模块根据状态为可用更新算法进行优先级排序，并交予所述全局控制器与之对应的更新协调模块进行评估；所述全局控制器中的所述更新协调模块根据全局状态与各局部控制器传来的算法优先级和丢包率、传输时延与更新时长信息计算得到最佳的更新方式，并交还所述本地决策模块，并在产生异议的时候进行协商；

所述更新协调模块设置于所述全局服务器，接收所述全局状态库的数据，并与所述本地决策模块进行信息交互，并将信息发送至所述全局更新模块，其具体过程包括6步，

S1：所述更新协调模块收集更新消息，即全局控制器得到的出现了更新所发生的发生规则变化的通知；

S2：判断是否不涉及其他域和控制器，判断这次更新是否涉及多个域，由于本地决策模块已为本地进行了最优方案的计算，当仅涉及到单个域的域内单个控制器进行的更新则不涉及更多的协商过程，进入S6，所述更新协调模块将更新方法信息传递给所述全局更新模块，并反馈给本地决策模块；若更新涉及多个域和多个控制器，则进入S3；

S3：针对最优目标进行更新的方案编排，所述更新协调模块将根据局部策略和应用对网络的要求，计算最佳的更新方案；

S4：向全部需要进行更新操作的控制器发送S3中的编排结果，所述全局控制器得到更新方案的组合后反馈给局部控制器的决策模块，所述本地决策模块再进行计算，并发送反馈；

S5：根据回应判断是否达成共识或协商超时，若达成共识则进入S6，若未达成共识则进入S3，再进行一次优先级协调，超过协商可用最长时长仍未共识则停止协商；

S6：向全局更新模块发送最终的更新方案；

局部更新模块和全局更新模块：所述局部更新模块为实际的更新执行者，即根据决策模块的指令选择更新算法并与交换机进行交互；所述全局更新模块在各局部网络进行更新时进行全局通信与更新操作，防止各局部更新不一致。

2.如权利要求1所述的一种基于多控制器协商的SDN一致性更新方法，其特征在于：所述网络监控模块收集各所述全局控制器和所述局部控制器、交换机状态和短时内的链路状态，并将其存入本地与全局的状态库中，所述交换机定时对所述局部控制器和所述全局控制器汇报自身状态与网络状态，所述局部控制器定时对所述全局控制器汇报自身状态与网络状态，网络中不同域之间的链路状态由所述全局控制器的网络监控进行探测。

3.如权利要求2所述的一种基于多控制器协商的SDN一致性更新方法，其特征在于：所述汇报与所述探测过程的具体时间间隔根据网络负载与策略出现变化的频率决定，所述状态库信息中设置控制表、交换机表和链路表三个表格，所述控制表字段包括：控制器ID、控制器所在域、控制器IP地址、包缓存空间大小、剩余包缓存空间；所述交换机表字段包括：交换机id、交换机所在域、交换机IP地址、流表空间大小、剩余流表空间、新增流表项耗时、删除流表项耗时；所述链路表字段包括：链路ID、链路起点、链路终点、链路负载、链路带宽。

4.如权利要求3所述的一种基于多控制器协商的SDN一致性更新方法，其特征在于：

所述本地决策模块通过8个步骤实现其功能，具体地，

S1：得到要更新的规则与指令，对交换机上的规则进行修改；

S2：获取涉及到的控制器与交换机的本地状态，在规则变化时，将涉及变化的局部控制器、交换机与链路状态取出；

S3：根据状态针对应用的传输时延、丢包率和更新时长的需求、对一致性更新算法计算可行性优先级并排序，所述可行性优先级是得到更新时长与丢包率后与目标更新时长和丢包率进行比较，所述一致性更新算法采用版本标记算法、缓存更新算法、计算顺序算法；

S4：将排序好的算法及相关信息提交给全局控制器，发起协商；

S5：等待全局控制器的反馈；

S6：若达成共识或已超过协商时长则进入S7,否则进入S4；

S7：按照最后的协商结果为生成更新方法；

S8：向所述本地更新模块发送。

5.如权利要求4所述的一种基于多控制器协商的SDN一致性更新方法，其特征在于：所述全局更新模块进行全局视图的策略规整，并发送到局部控制器中的更新模块执行流表更新的操作；

所述局部控制器中分别进行规则变更，在完成更新后向全局控制器发送信息，当全局控制器的更新模块收到全部的更新完毕消息，认为本次更新已经完成。

Images