基于分布式服务框架的SDN跨域协作方法与流程

本发明属于sdn网络技术领域，更为具体地讲，涉及一种基于分布式服务框架的sdn跨域协作方法。

背景技术：

软件定义网络(softwaredefinednetwork，sdn)作为一种将控制平面和数据平面相分离的新型网络架构，相比于传统网络，由于其灵活高效可配置特性与对下层设备的集中控制特性，近年来在很多领域已经得到了应用。在传统网络中，以路由器为代表的网络设备内部既包含数据平面，也包含控制平面，它们之间是紧耦合的，而sdn将控制平面与数据平面解耦合，并将控制平面从设备内部剥离出来，使数据平面的网络设备仅负责报文的转发，而网络的控制与管理由集中式的控制器负责。

但sdn也存在一些天然的不足。sdn中逻辑集中的控制平面可以收集到全网的资源状态信息，并维护一个全局的网络视图，这极大地简化了上层应用的开发，但是也造成了中央控制器负载过大，这限制了网络的规模。单控制器架构下的sdn将管理和控制的功能都交由一个中央控制器完成，然而受限于cpu、内存、带宽等因素，单个控制器自身性能存在上限，随着网络规模不断扩大、数据请求不断增多导致中央控制器负载过重，中央控制器就会出现明显的性能下降以及控制平面的处理延迟增加，甚至导致无法正常处理到达的请求。

特别的，目前工业界与学术界始终没有提出合理的、得到广泛认可的sdn控制器间东西向接口规范及标准，这就使得不同种类的sdn控制器难以实现有效的信息交互。因此当网络规模较大，且不同网络域归属不同机构时，如何有效地实现跨域业务的联合部署成为难题。

在传统的ip网络中，跨域路由主要依靠边界网关协议(bgp)来实现，bgp由于其完全分布式的特性，在策略执行、可伸缩性和复杂性等方面存在诸多限制；例如更改路由后，控制平面可能需要数分钟才能收敛，这在某些实时性要求较高的场景下是不可接受的。而对于sdn网络来说，由于控制器提供了一个集中式的全局控制平面，其在策略执行、安全性和复杂性等方面显著地优于传统的ip网络，相比传统ip网络下的bgp，提供了集中式控制平面的sdn在跨域路由方面有着天然的优势，基于sdn实现跨域路由具有极大的实用价值。

sdn下的跨域协作，本质上是一个分布式协调的问题，国内外的研究人员提出的解决方案主要有以下几种，扁平化体系架构、层次化体系架构以及混合体系架构等。

在扁平化体系架构中，所有的控制器都在同一层次，所有控制器都实时掌握着全网的信息状态，通过控制器之间的信息交互来进行网络状态的实时同步；而层次式体系结构，其做法是将网络划分为互不相交的域，每个sdn控制器只能控制所属域内的网络设备；域内的控制器称为本地控制器，为了应对跨域的访问需求，在全局网络设置一个根控制器用于管理各个本地控制器，并汇总各个本地控制器的数据形成一个全局的网络视图。至于混合体系架构则是以上两种方法的综合使用。

扁平化体系结构对同步的要求较高，并且在sdn由不同组织管理的场景下，各组织出于安全隐私等因素的考虑，可能不希望暴露内部信息，让所有控制器都实时掌握着全网的信息状态这一点较难实施；而层次化体系结构虽然放宽了同步的需求，但是该架构下的根控制器面临着类似单控制器架构的性能瓶颈与单点失效问题。混合体系架构通过将根控制器集群化解决了其单点失效问题，但是极大地增加了系统的复杂性。

技术实现要素：

本发明的目的在于克服现有技术的不足，提供一种基于分布式服务框架的sdn跨域协作方法，引入分布式跨域协作模块和代理模块，解决跨域协作问题。

为了实现以上发明目的，本发明基于分布式服务框架的sdn跨域协作方法包括以下步骤：

s1：设置用于实现分布式应用协调服务的分布式跨域协作模块，每个sdn网络配置一个或多个sdn控制器，为每个sdn控制器对应设置一个代理模块，该代理模块用于实现sdn控制器和分布式跨域协作模块之间的通信；

s2：预先为每个sdn网络规定一个在分布式跨域协作模块中的事务注册路径，并为每个代理模块规定一个在分布式跨域协作模块中的注册路径，当需要启动代理模块时，首先需要检查该代理模块在分布式跨域协作模块中对应的注册路径是否已经被占用，如果是，说明当前sdn网络中已经有其他sdn控制器的代理模块在该注册路径进行了注册，此时需要等待注册路径释放；如果未被占用，则代理模块创建对应的注册路径表示已占用；然后检测分布式跨域协作模块中是否存在所在sdn网络的事务注册路径，如果不存在则创建该事务注册路径，并创建对应的任务请求路径与任务回复路径，如果存在则关联该事务注册路径下的任务请求路径与任务回复路径；最后启动代理模块的剩余部分；

在各个代理模块启动后，对其在分布式跨域协作模块的事务注册路径下的任务请求路径进行监听；

s3：各代理模块对所对应的sdn控制器所属sdn网络中的上层应用进行监听，假设sdn网络a中某个代理模块agent_a接收到来自上层应用的任务请求，首先代理模块agent_a对该任务请求进行合法性判定，如果判定为不合法，则直接丢弃该任务请求，如果判定为合法，进入步骤s4；

s4：代理模块agent_a对所接收的任务请求进行解析，判断该任务请求的目标域是否为当前sdn网络，即sdn网络a，如果是，进入步骤s5，否则进入步骤s6；

s5：代理模块agent_a将任务请求转换为sdn网络a中sdn控制器的消息格式并发送至该sdn控制器，sdn控制器接收到任务请求后进行处理，将处理结果反馈至代理模块agent_a，代理模块agent_a将处理结果转发至上层应用；

s6：记目标域为sdn网络b，代理模块agent_a将任务请求注册至sdn网络b在分布式跨域协作模块中对应的任务请求路径，并对sdn网络b在分布式跨域协作模块中对应的任务回复路径进行监听；

当sdn网络b中的代理模块agent_b监听到sdn网络b在分布式跨域协作模块中任务请求路径下有新节点被创建，即有新任务请求到来，则提取该任务请求，转换为sdn网络b中sdn控制器的消息格式并发送至该sdn控制器，sdn控制器接收到任务请求后进行处理，将处理结果反馈至代理模块agent_b，代理模块agent_b将处理结果写入至sdn网络b在分布式跨域协作模块中对应的任务回复路径下；

当代理模块agent_a监听到sdn网络b在分布式跨域协作模块中对应的任务回复路径中有回复数据到来时，则提取该处理结果并转发至上层应用。

本发明基于分布式服务框架的sdn跨域协作方法，设置用于实现分布式应用协调服务的分布式跨域协作模块，并为各个sdn网络中的sdn控制器设置一个代理模块，该代理模块用于实现sdn控制器和分布式跨域协作模块之间的通信；上层应用将任务请求发送至代理模块，如果是域内任务请求则由代理模块发送给域内控制器进行处理，如果是域外任务请求，则通过分布式跨域协作模块将任务请求转发至目标域的代理模块，再由目标域的代理模块发送给目标域的sdn控制器进行处理，处理结果也通过分布式跨域协作模块反馈。

本发明具有以下有益效果：

1)本发明设置分布式跨域协作模块充当全局数据总线与分布式注册中心来解决跨域数据共享的问题；

2)本发明通过为sdn控制器设置代理模块，屏蔽外部应用对sdn控制器的直接访问，外部应用只需与代理模块进行信息交互，再借助分布式跨域协作模块的协作机制来完成跨域信息交互。

附图说明

图1是本发明基于分布式服务框架的sdn跨域协作方法的具体实施方式流程图；

图2是本发明中代理模块启动流程图；

图3是本发明中域外任务请求处理流程图；

图4是本实施例中sdn网络系统架构图；

图5是本实施例中sdn网络域内架构图。

具体实施方式

下面结合附图对本发明的具体实施方式进行描述，以便本领域的技术人员更好地理解本发明。需要特别提醒注意的是，在以下的描述中，当已知功能和设计的详细描述也许会淡化本发明的主要内容时，这些描述在这里将被忽略。

实施例

图1是本发明基于分布式服务框架的sdn跨域协作方法的具体实施方式流程图。如图1所示，本发明基于分布式服务框架的sdn跨域协作方法的具体步骤包括：

s101：跨域协作网络设置：

设置用于实现分布式应用协调服务的分布式跨域协作模块，每个sdn网络配置一个或多个sdn控制器，为每个sdn控制器设置一个代理模块(agent)，用于实现sdn控制器和分布式跨域协作模块之间的通信。

本发明中通过设置代理模块，将sdn控制器与外部的分布式跨域协作集解耦。当某个sdn网络设置有超过一个sdn控制器时，这些sdn控制器即可构成控制器集群，由于代理模块与sdn控制器是一一对应的关系，此时代理模块也可构成一个集群，可以避免单点失效的问题。代理模块一般可分为前端与后端两个模块，前端负责接收应用的请求，后端负责实际的请求处理，前后端之间通过线程间通信方式传输数据。前端模块可应对多个应用的并发访问，前端模块会对每个上层应用连接维护对应的数据，不必担心数据被污染。在约定好上层应用与代理模块之间传输消息格式后便可以进行交互。

本发明中的分布式跨域协作模块实际上代替了传统层次体系架构中的根控制器的角色，每个注册到分布式跨域协作模块的代理模块都可以获取全局共享的数据。与传统的sdn跨域不同，这里的网络虚拟化等计算过程可以放到代理模块上，与下层设备解耦，可以便捷地实现各种分布式事务，这是传统sdn跨域方法不容易做到的。

在实际应用中，分布式跨域协作模块可以是由多个分布式跨域协作节点所构成的集群，采用此方式可以提高吞吐量，并且避免单点失效问题。

s102：代理模块启动：

预先为每个sdn网络规定一个在分布式跨域协作模块中的事务注册路径，并为每个代理模块规定一个在分布式跨域协作模块中的注册路径，以供代理模块使用。图2是本发明中代理模块启动流程图。如图2所示，当需要启动代理模块时，首先需要检查该代理模块在分布式跨域协作模块中对应的注册路径是否已经被占用，如果是，说明当前sdn网络中已经有其他sdn控制器的代理模块在该注册路径进行了注册，此时需要等待注册路径释放；如果未被占用，则代理模块创建对应的注册路径表示已占用。然后检测分布式跨域协作模块中是否存在所在sdn网络的事务注册路径，如果不存在则创建该事务注册路径，并创建对应的任务请求路径与任务回复路径，如果存在则读取该事务注册路径下的任务请求路径与任务回复路径。最后启动代理模块的剩余部分，一般来说，需要相继启动代理模块的前端模块以接收上层应用的请求、启动后端模块以真正处理请求。

在各个代理模块启动后，对其在分布式跨域协作模块的事务注册路径下的任务请求路径和任务回复路径进行监听，以便及时获知域外任务请求的到来与转发数据。

s103：接收上层应用的任务请求：

各代理模块对所对应的sdn控制器所属sdn网络中的上层应用进行监听，假设sdn网络a中某个代理模块agent_a接收到来自上层应用的任务请求，首先代理模块agent_a对该任务请求进行合法性判定，如果判定为不合法，则直接丢弃该任务请求，如果判定为合法，进入步骤s104。

当sdn网络配置有sdn控制器集群时，那么代理模块也会有多个，因此在处理上层应用的任务请求时，可以根据预先设置的策略选择一个代理模块来执行，例如可以设置主用、备用代理模块，由主用代理模块来执行，也可以采用负载均衡策略，这样就可以避免单点失效问题。

s104：代理模块agent_a对所接收的任务请求进行解析，判断该任务请求的目标域是否为当前sdn网络，即sdn网络a，如果是，进入步骤s105，否则进入步骤s106。

s105：域内任务请求处理：

由于属于同一sdn网络的域内任务请求，不涉及到外部信息，因此代理模块agent_a将任务请求转换为sdn网络a中sdn控制器的消息格式并发送至该sdn控制器，sdn控制器接收到任务请求后进行处理，将处理结果反馈至代理模块agent_a，代理模块agent_a将处理结果转发至上层应用。

s106：域外任务请求处理：

此时该请求涉及跨域，图3是域外任务请求处理流程图。如图3所示，记目标域为sdn网络b，代理模块agent_a将任务请求注册至分布式跨域协作模块的对应路径下，即注册到sdn网络b在分布式跨域协作模块中对应的任务请求路径，并对sdn网络b在分布式跨域协作模块中对应的任务回复路径进行监听。

当sdn网络b中的代理模块agent_b监听到sdn网络b在分布式跨域协作模块中任务请求路径下有新节点被创建，即有新任务请求到来，则提取该任务请求，转换为sdn网络b中sdn控制器的消息格式并发送至该sdn控制器，sdn控制器接收到任务请求后进行处理，将处理结果反馈至代理模块agent_b，代理模块agent_b将处理结果写入至sdn网络b在分布式跨域协作模块中对应的任务回复路径下。

当代理模块agent_a监听到sdn网络b在分布式跨域协作模块中对应的任务回复路径中有回复数据到来，则提取该处理结果并转发至上层应用。

为了更好地说明本发明，采用一个具体实施例对本发明进行详细说明。

本实施例中分布式跨域协作模块基于zookeeper实现。zookeeper是一个开源的、成熟的、高可靠的分布式协调服务框架，它是一个为分布式应用提供一致性服务保障的软件框架，提供的主要功能包括：分布式同步、配置中心、注册中心服务等。zookeeper的架构类似于一个文件系统，zookeeper中的每个znode都是一个路径，znode可以存储状态信息、配置信息等数据。本实施例中采用zookeeper集群方式，对于集群化的zookeeper，主要划分了以下几个角色：leader(群首)、follower(追随者)与observer(观察者)。在zookeeper集群中，leader节点处理写请求并将数据变化会同步到集群中的其它角色节点。follower主要处理读请求并且参与leader的选举，当集群中的leader挂掉时，新的leader将从剩下的follower中产生。而observer虽然也是处理读请求，但是其不参与leader的选举，该角色的设置主要是为了提高集群读操作的吞吐量并且不增加leader选举的代价。leader与follower是zookeeper集群中必要的角色，而observer是可选的。

图4是本实施例中sdn网络系统架构图。如图4所示，本实施例的sdn网络系统包含3个sdn网络，即sdncluster1、sdncluster2和sdncluster3，分布式跨域协作模块包含3个节点，分别为node1、node2和node3。

图5是本实施例中sdn网络域内架构图。如图5所示，本实施例中每个sdn网络配置3个sdn控制器，每个sdn控制器配置一个代理模块agent。本实施例中将代理模块放到单独的宿主机去运行，当然也可以将代理模块设置在对应sdn控制器的主机上运行。代理模块与上层应用之间通过域名来交互。上层应用采用域名服务将一个域名映射到代理模块的地址，该域名服务可以基于现有的sdn网络环境下的域名服务。使用域名服务的好处是即使当某些代理模块agent发生故障而宕机，上层应用依然能够通过域名服务访问到可用的代理模块agent。代理模块agent与sdn控制器之间通过控制器的北向rest接口来通信。

接下来将代理模块agent注册至zookeeper集群的注册中心上，具体过程如下：

在启动代理模块时，首先需要检查该代理模块在zookeeper集群注册中心中的注册路径是否已经被占用，如果是，说明所属sdn网络的sdn控制器集群中已经有其他sdn控制器的代理模块在该注册路径进行了注册，需要等待注册路径释放，如果未被占用，则代理模块创建对应的注册路径表示已占用。然后检测zookeeper集群注册中心中是否存在所在sdn网络的事务注册路径，如果不存在则创建该事务注册路径，并创建对应的任务请求路径与任务回复路径，如果存在则关联该事务注册路径下的任务请求路径与任务回复路径；最后启动代理模块的剩余部分。

代理模块agent启动好以后，上层应用就可以开始发送请求了，就域内任务请求而言，其处理过程比较简单，在此不再赘述。接下来对域外任务请求进行举例说明。

假设sdncluster1内的某上层应用app1通过域名www.agent1.com向sdncluster1内的代理模块agent_1发送任务请求，该任务请求的目的是获取sdncluster2的网络拓扑信息，具体处理过程如下：

1)代理模块agent_1在接收到任务请求并通过合法性验证后，确定该任务请求的目的域是sdncluster2。因此代理模块agent_1向zookeeper集群创建一个请求节点，例如是“/cluster2_reg/request/1234”，并写入任务请求信息，这里的“1234”是任务请求id，是从上层应用app1的任务请求消息中解析得到的。此外还要创建一个回复节点，例如是“/cluster2_reg/response/1234”，然后sdncluster1的代理模块agent_1对“/cluster2_reg/response/1234”进行监听，等待处理数据到来。

2)sdncluster2中的代理模块agent_2是一直监听“/cluster2_reg/request/”的，因此可以立即监听到有新请求到来，提取该请求转换成rest请求并删除“/cluster2_reg/request/1234”，发送该rest请求到sdncluster2内的sdn控制器，sdn控制器处理完成后将处理结果发送给代理模块agent_2。代理模块agent_2将处理结果上传至任务回复路径“/cluster2_reg/response/1234”中。

3)sdncluster1中的代理模块agent_1监听到处理结果到来，提取该处理结果数据并删除“/cluster2_reg/response/1234”，最后将其转发给上层应用app1。

至此，sdncluster1中的上层应用app1就获得了域外sdncluster2的网络拓扑数据。类似的，sdncluster2内的上层应用app2也可以通过向代理模块agent_2的域名www.agent2.com发送任务请求，获取sdncluster1的网络拓扑数据。对于域内任务请求，由于不涉及外部网络，代理模块会直接去访问域内控制器。当双方都掌握了全局的网络拓扑数据后，各个域的应用就可以发送一些跨域路由请求，再由代理模块agent计算路由路径并形成对应的rest请求，最后通过控制器的北向接口来下发流表，从而实现域间通信。

尽管上面对本发明说明性的具体实施方式进行了描述，以便于本技术领域的技术人员理解本发明，但应该清楚，本发明不限于具体实施方式的范围，对本技术领域的普通技术人员来讲，只要各种变化在所附的权利要求限定和确定的本发明的精神和范围内，这些变化是显而易见的，一切利用本发明构思的发明创造均在保护之列。