CN107819774A - 一种sdn异构多控制器协同方法及系统 - Google Patents

Abstract

本发明提出了一种SDN异构多控制器协同方法及系统，参照OpenFlow协议并根据控制器通信的特色，提出了控制器通信协议，实现不同的控制器之间无差别的通信，解决异构控制器之间的扩展、协作问题；本发明无需用户参与，控制器东西向扩展机制，实现异构控制器之间的扩展和同构控制器无缝互连，具有普适性，有效提升控制器的计算能力、网络运行稳定性。

Description

一种SDN异构多控制器协同方法及系统

技术领域

本发明涉及通信设备的技术领域，具体涉及一种SDN异构多控制器协同方法及系统。

背景技术

控制器负责对整个SDN(Software Defined Network，软件自定义网络)网络的集中化控制，对于把握全网资源、改善网络资源交付质量具有非常重要的作用。但控制能力的集中化，也使控制器具有了更大的责任，一旦控制器在性能或者安全上不能提供有效保障，随之而来的就是整个SDN网络的服务能力降级甚至全网瘫痪。另外，从组网架构上看，单一的控制器无法应对跨越多个地域的SDN网络问题。因此，需要由多台控制器形成的分布式集群，避免单一的控制器节点造成的在可靠性、扩展性、性能等方面存在的问题。目前，集群技术可以被用来解决上述难题，但用于不同种类控制器之间的通信和协作的东西向接口标准还没有被定义，因此在异构控制器之间进行东西向扩展还存在较多的困难。

在使用分布式集群技术来解决SDN控制器问题上，大体需要解决的问题有三点：第一是主控制器(master controller)的选举，主控制器主要负责生成生成和维护全网范围内的控制器和交换机的状态信息，一旦它出现失效，就需要失效，就需要从集群中的副控制器(slave controller)中选举一个新的主控制器以便面单点失效。需要注意的是，这里主控制器可以有多个，目的是在负载压力较大时实现负载均衡，减少每台控制器的压力，此时，每台主控制器之间的角色为Equal，从控制器的角色不发生变化；第二是控制器集群对交换机的透明化，即在SDN网络的运行过程中，交换机无需关心它当前接受的是哪台控制器发来的控制指令，同时在其想控制器发送数据包时，能够继续保持之前单一控制器时的操作方式，从而保证控制器在逻辑上的集中；第三是制定控制器通信协议，实现异构控制器之间的信息交互，这是以上两点的基础。

现有技术中，HyperFlow是一款基于NOX控制器的分布式解决方案。在该方案中，HyperFlow将网络划分成数个逻辑区域，每个逻辑域内使用一个或者数个控制器对SDN交换机进行管理、控制，交换机和控制器之间的连接采用就近原则。Onix是一个面向广域网、公有云和数据中心等应用场景的具有良好扩展性的分布式SDN部署方案，由Google、NEC和Nicira共同提出。Onix的扩展性依靠三种策略共同实现：分区、聚合、一致性和稳定性。Kandoo[8]是一种基于分层思想的多控制器部署方案。该方案中控制器被分为两种角色：root controller和local controller。同时，根据控制器层的不同，将应用划分为non-local和lcoal两种。前者运行于root controller，根据全局网络信息，处理一些请求不频繁的事件，而后者则运行于local controller，根据网络局部拓扑，完成链路发现、交换机学习等请求频繁的事件处理。Master/slaves主要目标是实现一个高可靠、高性能、易扩展的分布式控制系统。在该架构中，集群中的每一个控制器都有着相同的算法用来发现链路、生成网络拓扑以及更新网络映射，其中主控制器结点负责对全局网络中的控制器与交换机之间的连接进行映射、更新。主控制器角色的选举则通过JGroups提供的分布式原语实现，集群中的其他结点则监听主控制器的状态。当主控制器结点发生故障导致宕机时，其他从控制器则重新进行主控制器角色选举，该过程对于数据转发而言是透明的。

但是，上述解决方案只能应用在同一种控制器之间，不能完成异构控制器之间的协同工作。在SDN控制器标准不能统一的情况下，通过实现东西向接口标准，制定控制器之间的通信协议，成为了异构控制器之间的扩展最关键的途径。

发明内容

基于上述问题，本发明提出了一种SDN异构多控制器协同方法及系统，参照OpenFlow协议并根据控制器通信的特色，提出了控制器通信协议，实现不同的控制器之间无差别的通信，解决异构控制器之间的扩展、协作问题。

本发明提供如下技术方案：

一方面，本发明提供了一种SDN异构多控制器协同方法，包括：

设计控制器之间的通信协议，将所述控制器通信类型分为两类：同步消息类型和异步消息类型；所述控制器间的每个通信数据包包含一个包头和一个指定信息类型的包体；所述指定信息类型的包体包括查询消息和查询应答消息、建立连接消息和建立连接应答消息、角色选取消息、拓扑查询消息和拓扑查询应答消息；所述查询消息查询其他角色的节点信息，所述查询应答消息是对查询消息的回应，告知所查询的节点信息；所述建立连接消息建立控制器之间连接，所述建立连接应答消息对所述建立连接消息的确认；所述角色选取消息选取控制器的角色，时间长者为主控制器，其他为从控制器；所述拓扑查询消息查询控制器之间进行拓扑信息，所述拓扑查询应答消息对所述拓扑查询消息进行回应。

其中，所述同步消息用于控制器之间进行角色问询、建立连接、心跳检测，所述异步消息类型用于控制器之间的网络拓扑信息查询、更新、交换、角色选举以及其他控制器信息交换。

其中，所述查询应答消息包括集群控制策略，所述集群控制策略为主从模式，包括主控制器和多个从控制器，主控制器进行任务调度工作，同时保留全局的具体拓扑信息，并不断监听其他控制器上报的网络事件，更新所述主控制器保存到网络拓扑；所述从控制器负责具体操作，将交换机状态事件报告至所述主控制器。

其中，所述查询消息根据查询类型不同，分为从控制器查询主控制器和主控制器查询所有从控制器。

其中，所述建立连接应答消息是对所述建立连接消息的确认具体为：修改所述建立连接消息包头中的信息类型参数，将所述包头中的会话ID值和所述建立连接消息标记值各加1，设置源MAC地址和源IP地址。

另外，本发明还提供了一种SDN异构多控制器协同系统，所述系统包括：

消息分类模块，用于设计控制器之间的通信协议，将所述控制器通信类型分为两类：同步消息类型和异步消息类型；

协同模块，用于在所述控制器间的每个通信数据包添加一个包头和一个指定信息类型的包体；所述指定信息类型的包体包括查询消息和查询应答消息、建立连接消息和建立连接应答消息、角色选取消息、拓扑查询消息和拓扑查询应答消息；所述查询消息查询其他角色的节点信息，所述查询应答消息是对查询消息的回应，告知所查询的节点信息；所述建立连接消息建立控制器之间连接，所述建立连接应答消息对所述建立连接消息的确认；所述角色选取消息选取控制器的角色，时间长者为主控制器，其他为从控制器；所述拓扑查询消息查询控制器之间进行拓扑信息，所述拓扑查询应答消息对所述拓扑查询消息进行回应。

其中，所述同步消息用于控制器之间进行角色问询、建立连接、心跳检测，所述异步消息类型用于控制器之间的网络拓扑信息查询、更新、交换、角色选举以及其他控制器信息交换。

其中，所述查询应答消息包括集群控制策略，所述集群控制策略为主从模式，包括主控制器和多个从控制器，主控制器进行任务调度工作，同时保留全局的具体拓扑信息，并不断监听其他控制器上报的网络事件，更新所述主控制器保存到网络拓扑；所述从控制器负责具体操作，将交换机状态事件报告至所述主控制器。

其中，所述查询消息根据查询类型不同，分为从控制器查询主控制器和主控制器查询所有从控制器。

其中，所述建立连接应答消息是对所述建立连接消息的确认具体为：修改所述建立连接消息包头中的信息类型参数，将所述包头中的会话ID值和所述建立连接消息标记值各加1，设置源MAC地址和源IP地址。

本发明提出了一种SDN异构多控制器协同方法及系统，参照OpenFlow协议并根据控制器通信的特色，提出了控制器通信协议，实现不同的控制器之间无差别的通信，解决异构控制器之间的扩展、协作问题；本发明无需用户参与，控制器东西向扩展机制，实现异构控制器之间的扩展和同构控制器无缝互连，具有普适性，有效提升控制器的计算能力、网络运行稳定性。

附图说明

图1是本发明的异构多控制器协同示意图；

具体实施方式

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

在SDN控制器标准不能统一的情况下，通过实现东西向接口标准，制定控制器之间的通信协议，成为了异构控制器之间的扩展最关键的途径，本发明参照OpenFlow协议并根据控制器通信的特色，提出了控制器通信协议，解决异构控制器之间的扩展、协作问题，实现不同的控制器之间无差别的通信。

一方面，本发明的实施方式提供了一种SDN异构多控制器协同方法，附图1为本发明的异构多控制器协同示意图，包括：

设计控制器之间的通信协议，将所述控制器通信类型分为两类：同步消息类型和异步消息类型；

在设计控制器之间的通信协议时，参照了OpenFlow v1.3规范并根据控制器自身通信特点进行了协议制定，将控制器通信类型分为两类：Symmetric和Asynchronous，即同步消息类型和异步消息类型。同步消息用于控制器之间进行角色问询、建立连接、心跳检测等，异步消息类型用于控制器之间的网络拓扑信息查询、更新、交换、角色选举以及其他控制器信息交换等。

表1协议消息列表

所述控制器间的每个通信数据包包含一个包头和一个指定信息类型的包体；

由于OpenFlow协议基于C语言风格指定，因此这里也将延续这个特点，使用C语言来描述协议消息类。

每一个控制器通信消息数据包都有一个包头，格式如下：

包头固定为18个字节。其中，type类型的可选值如下所示：

每个控制器间的通信数据包都包含一个包头和一个指定信息类型的包体。下面对几个主要信息类型进行说明。

1)ENQUIRY和ENQUIRY_REPLY消息

ENQUIRY是控制器用来查询其他角色的节点信息，根据查询类型不同，可分为从控制器查询主控制器和主控制器查询所有从控制器两种。ENQUIRY_MASTER类型用于控制器进入集群之后，询问主控制器的节点信息；ENQUIRY_SLAVE则是主控制器查询所有的从控制器节点信息。ENQUIRY_REPLY消息则是对查询消息的回应，告知所查询的节点信息。这两种消息是协议中唯一使用UDP广播通信方式的消息。

ENQUIRY消息格式如下：

其中，enquiry是查询信息的主要内容，包含查询事项类型、查询时间、重复查询次数等。目前查询事项只有一种，即查询主控制器节点信息。查询时间为当前的系统时间，在超时之后，最多可重复次数由重复查询次数规定，每查询一次重复查询次数自增1，直至上限值。该消息的具体定义如下：

上述的enquiry_type为查询事项类型，具体定义如下：

ENQUIRY_REPLY消息是对ENQUIRY的回应，其格式定义如下：

enquiry_reply为回应消息的包体，定义如下：

其中，sdn_controller_info表示的是节点自身信息，包含MAC地址、IP地址、当前角色、集群策略、系统时间、连接重试次数等，具体格式见下：

policy为集群控制策略，这里分为两种，一种是master/slave，即主从模式，一组主控制器负责和多个从控制器，主控制器进行任务调度工作，同时保留全局的具体拓扑信息，并不断监听其余控制器上报的网络事件，以此更新自己保存到额网络拓扑；从控制器负责路由计算、拓扑更新、流表下发等具体操作，并且要将交换机增加和移除等事件报告之主控制器。另一种是equal，即平等方式，每个控制器维护自己区域内的网络运行，彼此之间的角色平等，然后每个SDN域构成一个更大的SDN网络，OpenFlow交换机依据距离最近原则接入控制器。

本文的控制器集群策略是master/slave。policy的具体类型定义见下：

timeout为连接超时次数，即同一控制器向集群内其他控制器尝试连接的最大次数，尝试连接间隔为5s秒。

role为控制器的当前角色。作为新进入集群的控制器，在没有参加角色选举之前都默认为null。role的种类见下：

2)HELLO消息HELLO_REPLY消息

HELLO消息用于控制器之间建立连接，其方式是通过广播消息ENQUIRY获知主控制器的节点信息后使用TCP进行连接,其中，hid为该消息的标记。其消息格式如下：

HELLO_REPLY消息是对HELLO消息的确认，定义较为简单，只需要针对HELLO消息修改包头中的type消息类型,将包头中的xid值和hid值各加1，然后设置源MAC和源IP等信息即可。具体消息格式定义如下：

3)ROLE_SELECT消息

ROLE_SELECT用于控制器的角色选举。采用的选举算法比较简单，采用时间长者为主控制器，其余为从控制器。该协议消息定义如下：

而role_select具体定义如下：

4)TOPO_REQUEST和TOPO_REPLY消息

TOPO_REQUEST消息是控制器之间进行拓扑信息查询的消息类型。该协议消息定义也较为简单，直接修改sdn_controller_header中的type即可。

TOPO_REPLY消息是对TOPO_REQUEST消息的回应。该消息的定义格式如下：

其中topo_pair_node为网络中的拓扑结点信息,定义如下：

本发明提出了一种SDN异构多控制器协同方法，参照OpenFlow协议并根据控制器通信的特色，提出了控制器通信协议，实现不同的控制器之间无差别的通信，解决异构控制器之间的扩展、协作问题；本发明无需用户参与，控制器东西向扩展机制，实现异构控制器之间的扩展和同构控制器无缝互连，具有普适性，有效提升控制器的计算能力、网络运行稳定性。

另一方面，本发明的实施方式提供了一种SDN异构多控制器协同系统，图1为本发明的异构多控制器协同示意图，包括：

消息分类模块，用于设计控制器之间的通信协议，将所述控制器通信类型分为两类：同步消息类型和异步消息类型；

在设计控制器之间的通信协议时，参照了OpenFlow v1.3规范并根据控制器自身通信特点进行了协议制定，将控制器通信类型分为两类：Symmetric和Asynchronous，即同步消息类型和异步消息类型。同步消息用于控制器之间进行角色问询、建立连接、心跳检测等，异步消息类型用于控制器之间的网络拓扑信息查询、更新、交换、角色选举以及其他控制器信息交换等。

表1协议消息列表

协同模块，用于在所述控制器间的每个通信数据包添加一个包头和一个指定信息类型的包体；

由于OpenFlow协议基于C语言风格指定，因此这里也将延续这个特点，使用C语言来描述协议消息类。

每一个控制器通信消息数据包都有一个包头，格式如下：

包头固定为18个字节。其中，type类型的可选值如下所示：

每个控制器间的通信数据包都包含一个包头和一个指定信息类型的包体。下面对几个主要信息类型进行说明。

1)ENQUIRY和ENQUIRY_REPLY消息

ENQUIRY是控制器用来查询其他角色的节点信息，根据查询类型不同，可分为从控制器查询主控制器和主控制器查询所有从控制器两种。ENQUIRY_MASTER类型用于控制器进入集群之后，询问主控制器的节点信息；ENQUIRY_SLAVE则是主控制器查询所有的从控制器节点信息。ENQUIRY_REPLY消息则是对查询消息的回应，告知所查询的节点信息。这两种消息是协议中唯一使用UDP广播通信方式的消息。

ENQUIRY消息格式如下：

其中，enquiry是查询信息的主要内容，包含查询事项类型、查询时间、重复查询次数等。目前查询事项只有一种，即查询主控制器节点信息。查询时间为当前的系统时间，在超时之后，最多可重复次数由重复查询次数规定，每查询一次重复查询次数自增1，直至上限值。该消息的具体定义如下：

上述的enquiry_type为查询事项类型，具体定义如下：

ENQUIRY_REPLY消息是对ENQUIRY的回应，其格式定义如下：

enquiry_reply为回应消息的包体，定义如下：

其中，sdn_controller_info表示的是节点自身信息，包含MAC地址、IP地址、当前角色、集群策略、系统时间、连接重试次数等，具体格式见下：

policy为集群控制策略，这里分为两种，一种是master/slave，即主从模式，一组主控制器负责和多个从控制器，主控制器进行任务调度工作，同时保留全局的具体拓扑信息，并不断监听其余控制器上报的网络事件，以此更新自己保存到额网络拓扑；从控制器负责路由计算、拓扑更新、流表下发等具体操作，并且要将交换机增加和移除等事件报告之主控制器。另一种是equal，即平等方式，每个控制器维护自己区域内的网络运行，彼此之间的角色平等，然后每个SDN域构成一个更大的SDN网络，OpenFlow交换机依据距离最近原则接入控制器。

本文的控制器集群策略是master/slave。policy的具体类型定义见下：

timeout为连接超时次数，即同一控制器向集群内其他控制器尝试连接的最大次数，尝试连接间隔为5s秒。

role为控制器的当前角色。作为新进入集群的控制器，在没有参加角色选举之前都默认为null。role的种类见下：

2)HELLO消息HELLO_REPLY消息

HELLO消息用于控制器之间建立连接，其方式是通过广播消息ENQUIRY获知主控制器的节点信息后使用TCP进行连接,其中，hid为该消息的标记。其消息格式如下：

HELLO_REPLY消息是对HELLO消息的确认，定义较为简单，只需要针对HELLO消息修改包头中的type消息类型,将包头中的xid值和hid值各加1，然后设置源MAC和源IP等信息即可。具体消息格式定义如下：

3)ROLE_SELECT消息

ROLE_SELECT用于控制器的角色选举。采用的选举算法比较简单，采用时间长者为主控制器，其余为从控制器。该协议消息定义如下：

而role_select具体定义如下：

4)TOPO_REQUEST和TOPO_REPLY消息

TOPO_REQUEST消息是控制器之间进行拓扑信息查询的消息类型。该协议消息定义也较为简单，直接修改sdn_controller_header中的type即可。

TOPO_REPLY消息是对TOPO_REQUEST消息的回应。该消息的定义格式如下：

其中topo_pair_node为网络中的拓扑结点信息,定义如下：

本发明提出了一种SDN异构多控制器协同系统，参照OpenFlow协议并根据控制器通信的特色，提出了控制器通信协议，实现不同的控制器之间无差别的通信，解决异构控制器之间的扩展、协作问题；本发明无需用户参与，控制器东西向扩展机制，实现异构控制器之间的扩展和同构控制器无缝互连，具有普适性，有效提升控制器的计算能力、网络运行稳定性。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其他实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种SDN异构多控制器协同方法，其特征在于：

设计控制器之间的通信协议，将所述控制器通信类型分为两类：同步消息类型和异步消息类型；所述控制器间的每个通信数据包包含一个包头和一个指定信息类型的包体；

所述指定信息类型的包体包括查询消息和查询应答消息、建立连接消息和建立连接应答消息、角色选取消息、拓扑查询消息和拓扑查询应答消息；所述查询消息查询其他角色的节点信息，所述查询应答消息是对查询消息的回应，告知所查询的节点信息；所述建立连接消息建立控制器之间连接，所述建立连接应答消息对所述建立连接消息的确认；所述角色选取消息选取控制器的角色，时间长者为主控制器，其他为从控制器；所述拓扑查询消息查询控制器之间进行拓扑信息，所述拓扑查询应答消息对所述拓扑查询消息进行回应。

2.根据权利要求1所述的方法，其特征在于：所述同步消息用于控制器之间进行角色问询、建立连接、心跳检测，所述异步消息类型用于控制器之间的网络拓扑信息查询、更新、交换、角色选举以及其他控制器信息交换。

3.根据权利要求1所述的方法，其特征在于：所述查询应答消息包括集群控制策略，所述集群控制策略为主从模式，包括主控制器和多个从控制器，主控制器进行任务调度工作，同时保留全局的具体拓扑信息，并不断监听其他控制器上报的网络事件，更新所述主控制器保存到网络拓扑；所述从控制器负责具体操作，将交换机状态事件报告至所述主控制器。

4.根据权利要求1所述的方法，其特征在于：所述查询消息根据查询类型不同，分为从控制器查询主控制器和主控制器查询所有从控制器。

5.根据权利要求1所述的方法，其特征在于：所述建立连接应答消息是对所述建立连接消息的确认具体为：修改所述建立连接消息包头中的信息类型参数，将所述包头中的会话ID值和所述建立连接消息标记值各加1，设置源MAC地址和源IP地址。

6.一种SDN异构多控制器协同系统，其特征在于：所述系统包括：

消息分类模块，用于设计控制器之间的通信协议，将所述控制器通信类型分为两类：同步消息类型和异步消息类型；

协同模块，用于在所述控制器间的每个通信数据包添加一个包头和一个指定信息类型的包体；所述指定信息类型的包体包括查询消息和查询应答消息、建立连接消息和建立连接应答消息、角色选取消息、拓扑查询消息和拓扑查询应答消息；所述查询消息查询其他角色的节点信息，所述查询应答消息是对查询消息的回应，告知所查询的节点信息；所述建立连接消息建立控制器之间连接，所述建立连接应答消息对所述建立连接消息的确认；所述角色选取消息选取控制器的角色，时间长者为主控制器，其他为从控制器；所述拓扑查询消息查询控制器之间进行拓扑信息，所述拓扑查询应答消息对所述拓扑查询消息进行回应。

7.根据权利要求6所述的系统，其特征在于：所述同步消息用于控制器之间进行角色问询、建立连接、心跳检测，所述异步消息类型用于控制器之间的网络拓扑信息查询、更新、交换、角色选举以及其他控制器信息交换。

8.根据权利要求6所述的系统，其特征在于：所述查询应答消息包括集群控制策略，所述集群控制策略为主从模式，包括主控制器和多个从控制器，主控制器进行任务调度工作，同时保留全局的具体拓扑信息，并不断监听其他控制器上报的网络事件，更新所述主控制器保存到网络拓扑；所述从控制器负责具体操作，将交换机状态事件报告至所述主控制器。

9.根据权利要求6所述的系统，其特征在于：所述查询消息根据查询类型不同，分为从控制器查询主控制器和主控制器查询所有从控制器。

10.根据权利要求6所述的系统，其特征在于：所述建立连接应答消息是对所述建立连接消息的确认具体为：修改所述建立连接消息包头中的信息类型参数，将所述包头中的会话ID值和所述建立连接消息标记值各加1，设置源MAC地址和源IP地址。