一种面向SDN网络操作系统的插件化多播框架的制作方法

本发明属于电子信息技术中网络通信领域，具体涉及一种面向sdn(softwaredefinednetwork，软件定义网络)网络操作系统的插件化多播框架。

背景技术：

多播是一种重要的网络通信手段，而且不同的应用场景对多播通信可能有不同的qos需求。然而，在经典网络架构下，负责向网络应用程序提供多播组管理和多播路由算法的多播框架是独占的和通用的。这给多播通信带来了两个缺陷：1)缺醒多播路由算法无法满足不同网络应用程序的不同qos需求；2)多播框架在一开始就被设计为封闭的而没有考虑到它的可扩展性和灵活性，因此定制的多播路由算法无法部署到网络内的多播框架上以满足不同应用程序的不同qos需求。

为了克服上述缺陷，且不干扰网络内现存多播框架和应用程序的运行，需要在网络内部署一个额外的多播框架，并将定制化的多播路由算法部署在这个额外加入的多播框架上。然而，当网络内存在两个多播框架时，这两个多播框架将会在两个方面产生冲突：1)同一个多播成员将会收到来自两个多播框架所发来的general-queryigmp消息，这会抑制多播组内其他成员正常发送membership-reportigmp消息，引起查询器无法准确地获得多播组内成员的拓扑关系。2)每个多播框架在收到多播成员的membership-reportigmp消息后都调用自身的多播路由算法为多播组更新多播树，导致同一个多播组具有两棵不同的多播树，引起数据包的重复传输。为了避免上述两类冲突，采用应用层协议实现多播功能的应用层多播框架是一种被广泛使用的方法。然而，应用层多播框架需要特殊协议及应用程序的支持，因此其又无法与网络内已经大量部署的经典多播应用程序兼容。

技术实现要素：

为了克服现有多播框架的独占性和通用性，为不同多播应用场景部署专用的多播路由算法且保持与经典多播程序的兼容，本发明提供一种面向sdn网络操作系统的插件化多播框架。

本发明采用的技术方案是：

一种面向sdn网络操作系统的插件化多播框架，其作为一种sdn应用程序运行于sdn控制器之上，通过调用sdn控制器的北向接口获取网络内sdn交换机的状态或向sdn交换机安装流表项，其特征在于：包括

多播组注册模块，用于记录用户向其注册的多播地址并将多播地址与多播路由算法模块内的某一个特定多播路由算法绑定；

多播成员加入、离开模块，用于从sdn控制器上查询在已经被注册的多播地址上是否有多播成员的加入和离开；

多播路由算法模块，用于以从sdn控制器所获得的网络拓扑信息及从多播成员加入模块、多播成员离开模块获得的多播成员位置信息作为参数调用与多播组绑定的多播路由算法，构建多播路由生成树，并将该生成树转换为生成树上sdn交换机的转发规则并发送至sdn交换机。本发明首次以“sdn网络操作系统插件”的形态实现对多播通信的支撑，在不对网络内缺省的多播框架和多播路由算法进行修改和造成干扰的前提下向网络内部署一个新的多播框架，并允许网络的使用者够通过该框架向网络内部署定制化的多播路由算法，并管理特定的多播组。

进一步，所述多播组注册模块注册的规则包括：

若向所述多播组注册模块注册的多播地址是第一次被注册，则所述多播组注册模块将从多播协议rfc5771所规定的“预留多播地址空间”中随机选择一个未使用的多播地址与之配对；若向所述多播组注册模块注册的多播地址已经被注册，但用户所选择的多播路由算法与上一次注册时所指定的算法不同，则为该多播地址绑定该新的多播路由算法。

进一步，所述多播路由算法模块转换得到的sdn交换机的转发规则是通过packet-out消息发送至sdn交换机。

进一步，所述多播路由算法模块通过软中断或轮训的方式从sdn控制器和多播成员加入、离开模块中获取相应信息。

进一步，所述多播成员加入、离开模块通过软中断或者轮训的方式从sdn控制器上查询在已经被注册的多播地址上是否有多播成员的加入和离开。

进一步，所述多播成员加入、离开模块在sdn交换机收到一个新的多播成员的加入请求时，从sdn控制器上探测已经注册的多播地址列表内是否包括该多播地址，若有则记录该多播成员在网络内的位置信息。

进一步，所述sdn交换机通过packet-in消息向sdn控制器报告本交换机收到了一个新的多播成员的加入请求。

进一步，所述多播组注册模块首次在sdn网络操作系统中探测到有多播主机试图加入到一个已经在多播组注册模块注册过的多播地址时从rfc5771协议所规定的“预留多播地址空间”中选择一个未被使用过的多播地址并将已注册多播地址与该预留多播地址进行映射，所述多播成员加入、离开模块在与多播主机相连的sdn交换机上安装一条流表项，命令sdn交换机将所有从多播主机发向已注册多播地址的多播数据在将目的地址更改为预留多播地址后沿与已注册多播地址相绑定的多播路由算法所规划的多播树转发出去。

本发明与现有技术相比较，具有如下特点：

1)本发明首次提出了“sdn网络操作系统的插件的概念”，并在此理念的指导下实现了多播框架。如同电脑软件的插件能够在不干扰现有软件运行的情况下为软件扩展新的功能一样，本发明能够灵活地部署于sdn网络内而不与现有多播框架发生冲突。

2)与广泛使用的应用层多播框架相比，本发明严格遵循标准igmp协议实现而非通过应用层协议实现，因此完整地保持了与经典多播应用程序兼容性。

3)本发明能够将用户指定的多播组从现存的多播框架内接管，并为不同多播组部署定制化的多播路由算法。

附图说明

图1是本发明的示意图。

具体实施方式

下面结合具体实施例来对本发明进行进一步说明，但并不将本发明局限于这些具体实施方式。本领域技术人员应该认识到，本发明涵盖了权利要求书范围内所可能包括的所有备选方案、改进方案和等效方案。

参见图1，本实施例提供了一种面向sdn网络操作系统的插件化多播框架，包括多播组注册模块、多播成员加入、离开模块及多播路由算法模块，协同完成对指定多播组的多播通信支持。

本实施例的所述面向sdn网络操作系统的插件化多播框架，作为一种sdn应用程序运行于sdn控制器之上，通过调用sdn控制器的北向接口获取网络内sdn交换机的状态或向sdn交换机安装流表项。

本实施例所述多播组注册模块记录用户输入的多播地址并将多播地址与用户所选择的多播路由算法模块内的某一个特定多播路由算法绑定。若该多播地址是第一次被注册，则所述多播组注册模块将从rfc5771协议所规定的“预留多播地址空间”中随机选择一个未使用的多播地址与之配对，为后续多播成员加入、离开模块对“预留多播地址”与“被注册多播地址”之间的多播地址替换做准备。若该多播地址已经被注册，但用户所选择的多播路由算法与上一次注册时所指定的算法不同，则为该多播地址绑定该新的多播路由算法。

本实施例所述的多播路由算法模块通过软中断或轮训的方式从sdn控制上读取全网sdn交换机的拓扑结构、位置信息以及发起多播通信的多播主机的位置信息。当多播成员加入模块、多播成员离开模块发现特定多播组成员改变时，多播路由算法模块将以网络拓扑信息及多播成员位置信息作为参数调用与多播组绑定的多播路由算法构建多播路由生成树，并将该生成树转换为生成树上sdn交换机的转发规则，通过packet-out消息发送至sdn交换机。

本实施例所述多播成员加入、离开模块通过软中断或者轮训的方式从sdn控制器上查询在已经被注册的多播地址上是否有多播成员的加入和离开。当与主机相连的sdn交换机在收到主机发送的member-reportigmp消息后检查流表内是否有与之匹配的转发规则，如果没有则通过packet-in消息向sdn控制器报告本交换机收到了一个新的多播成员的加入请求。此时，多播成员加入、离开模块从sdn控制器上获得包含已经注册的多播地址的packet-in消息以及与要加入多播组的主机相连的sdn交换机的网络位置信息。多播成员加入模块通过sdn控制器首次在网络内探测到有多播主机试图加入一个已经在多播组注册模块注册过的多播地址时从rfc5771协议所规定的“预留多播地址空间”中选择一个未被使用过的多播地址并将已注册多播地址与该预留多播地址进行映射，在这种条件下，多播成员加入、离开模块在与多播主机相连的sdn交换机上安装流表项，命令sdn交换机将所有从多播主机发向已注册多播地址的数据包的目的地址更改为预留多播地址，然后沿与已注册多播地址相绑定的多播路由算法所规划的多播树转发出去。

具体的，根据rfc5771协议的规定，多播程序一般工作在局域网多播地址空间224.0.0.0～224.0.0.255和互联网多播地址空间224.0.1.0～224.0.1.255，而234.0.0.0～238.255.255.255这段地址空间则被预留下来没有使用。假设在图1所示的一个由sdn交换机a、b、e、d构成的sdn网络内需要在224.0.0.32的地址上以特定多播路由算法进行多播通信。那么首先需要将二元组<224.0.0.32，特定多播路由算法>通过多播组注册模块配置到本多播框架上。

若host_1,host_2,host_3和host_4试图加入该多播组。以host_2为例，它首先要通过接入交换机switchb的2号端口向该交换机发送类型为member-report的igmp消息以向多播框架通报其正尝试加入多播地址为224.0.0.32的多播组。然而，在一开始，交换机b上并没有与该igmp消息相匹配的流表项。交换机b不知道如何处理该igmp数据报，因此根据openflow协议的规定它将发送一条packet-in消息到sdn控制器以报告本交换机收到了异常数据报。由于本多播框架作为一个sdn应用程序被安装在sdn控制器上，因此多播成员加入、离开模块能够通过sdn北向接口获知host_2试图加入地址为224.0.0.32的多播组。显然，在同一时间同样作为sdn应用程序的现存多播框架也将会通过同样的手段获知host_2试图加入地址为224.0.0.32的多播组，并且调用自身的多播路由算法将host_2加入到一个我们并不需要的多播树t＝<{a,b,c,d,e},{(a,b),(a,c),(c,e),(a,d)}>。但是由于之前多播地址224.0.0.32已经显式的配置进本多播框架内，因此这时本多播框架将在接入交换机b上执行一个“映射”操作，指示交换机b将从host_2所发来的多播数据报的多播地址从原来的224.0.0.32转换为234.0.0.32然后再从端口1和端口4发送到由本多播框架的多播路由算法模块所建立的多播树t'＝<{a,b,d,e},{(a,b),(b,e),(e,d)}>上。反映这个“映射”操作的流表项如图1内“映射流表”所示。

相应的，一个“反映射”操作也会被在交换机b上执行，以指示交换机b将发往host_2的多播数据报的地址从234.0.0.32改为224.0.0.32。这样，host_2得以在原来约定的多播地址224.0.0.32上收到多播数据报。反映这个“反映射”操作的流表项如图1内“映射回流表”所示。

通过上述“映射-反映射”操作，现存多播框架的多播查询器将无法收到由host_2所发出的类型为member-report的igmp消息。因此现存多播框架将依照igmp协议的规定，在为多播地址为234.0.0.32的多播组所设定的定时器超时后从本框架所建立的多播树t上自动的删除host_2所在的分支。同样的“映射-反映射”操作将在网络内的接入交换机a、b、d上执行。这样，我们需要的多播树t'被建立起来而我们不需要的多播树t则被完全地从网络内删除。最终，现存多播框架将依照igmp协议放弃对多播地址为234.0.0.32的多播组的管理，本多播框架则完全地从现存多播框架上接管该多播组。