基于SDN的服务驱动组播的设计与实现

陈 红，刘宁春，郜 帅，周华春

(北京交通大学 电子信息工程学院，北京 100044)

0 引 言

传统IP组播由两个部分组成，组管理协议IGMP运行在接入路由器和组播接收者之间，主要功能是提供转发组播数据包到目的地的最后阶段所需的信息，实现主机与路由器之间的组播组信息交互；组播路由协议运行在组播路由器之间，用于在路由器之间共享组信息，为组播数据报的分发提供路由，确保每一个组播路由器都能收到数据包[1]。传统互联网中的路由计算和路由转发功能都由路由器来完成，组播的实现需要客户端、边缘路由器和经过的所有路由器的共同参与，组播的建立和维护需要复杂的组播路由算法和组播组管理机制[2]。

基于SDN[3-4]的组播路由借助SDN设计思想，将网络的路由计算与转发工作解耦，由控制器进行组播路由的计算和分发，交换机根据控制器分发的流表进行转发[5]。随着SDN的发展成熟，一些利用SDN提升组播性能的组播路由算法也相继出现[6-7]，由Marcondes等人提出的CastFlow组播路由算法[8]结合SDN网络架构，由控制器集中管控组播接收者变动和组播树的生成，节省组播响应时间；由Ananta等人提出的EDSPA(extended Dijkstra’s shortest path algorithm)[9]将节点处理信息的时延与链路状态结合，生成新的链路权重，用于计算从组播源到组播接收者间的最短路径树；由Lin等人提出的LAMA(locality-aware multicast approach)[10]通过将组播组集合成组播集群的方式，减少组播路由的计算时间和交换机上的路由条目，提高组播的可扩展性[11]。然而，上述基于SDN的组播路由机制均为被动地收集组播链路的状态信息，并基于此生成组播路由策略[12]并没有考虑特定组播服务的需求，如组播源希望其发送的组播数据包不经过某些特定的交换机；组播业务对链路带宽敏感等。

因此，该文提出了一种基于SDN的服务驱动组播机制，该机制可根据特定组播服务的需求(不经过特定交换机以及链路带宽敏感)动态调整网络中运行的组播策略，实现SDN组播的可管可控。

1 服务驱动组播路由

1.1 服务驱动组播路由算法

在组播实现的过程中，组播用户会有定制化服务的需求，例如绕过某个工作性能不是很好的交换机；选择一些高带宽低时延的链路等。该文所提出的组播路由实现了这样一种功能，为每个组播路由都加了一个条件限制参数，用来存储组播用户对于该组播组的服务需求。当组播建立完成后，用户可以在任何时间提出自己的要求，通过控制器的命令行输入具体指令，系统会将读取到的服务需求进行处理，重新规划组播的路径。具体的实现流程如图1所示。

服务驱动组播路由算法建立在特定源组播[13]的基础上，用户必须指定要添加服务需求的组播组的源地址和组播地址；目前可供选择的服务类型包括“障碍”需求和带宽需求，分别代表不允许经过某个交换机、限制链路带宽；条件参数则根据服务类型补充具体的条件。

组播应用接收到用户的服务请求后，判断该组播路由是否存在，若存在，将用户输入的过滤条件类型和条件参数加入到该组播路由中，根据服务驱动组播路由算法计算路径并下发到交换机。

图1 服务需求处理流程

服务驱动组播路由算法在计算路径时，首先需要指定起点s(即从顶点s开始计算)。此外，引进两个集合S和U。S记录已求出最短路径的顶点(以及相应的最短路径长度)，而U记录还未求出最短路径的顶点(以及该顶点到起点s的距离)。服务驱动组播路由算法求解组播路径的完整步骤为：(1)初始态，S只包含起点s；U包含除s外的其他顶点，且U中顶点的距离为“起点s到该顶点的距离”，不与s直接相连的点的距离记为无穷大。(2)从U中选出“与起点s距离最短的点k”，并将顶点k加入到S中；同时，从U中移除顶点k。(3)更新U中剩余点与s的距离，更新方法为在满足组播用户的服务需求条件下，比较当前该点记录的到s的距离和该点经过k到s的距离大小，取其中的较小值更新为该点与s的距离，如算法1所示。(4)重复步骤(2)和(3)，直到遍历完所有顶点。

算法1：更新节点s与节点x之间的最短距离。

s/*源节点s*/

k/*中间节点k*/

x/*待更新节点x*/

D(s,k) /*s与k之间的最短距离*/

D(k,x) /*k与x之间的最短距离*/

D(s,x) /*s与x之间的最短距离*/

path /*从某个点到另一个点的路径，以数组表示，如：a经过b到c的路径记为[a,b,c]*/

F(path) /*判断某条路径是否符合预设条件，若符合预设条件，结果为true*/

/*s与x经过中间节点k的距离小于原本记录的距离，并且路径[s,k,x]符合预设条件，则更新s与x之间的最短距离，否则不更新*/

if ((D(s,k)+D(k,x)

thenD(s,x)←D(s,k)+D(k,x)

算法1中利用F函数来判断当前路径是否符合服务需求，不同的服务需求对应不同的F函数。根据用户提出的服务需求不同，可以大致分为指定服务方式的需求和指定服务质量的需求两类。下面分别以具体场景举例说明这两种需求的服务场景和对应的F函数的设计。

1.2 指定服务方式的需求举例

1.2.1 服务场景

使用最短路径算法生成的组播路径只会考虑组播源到组播接收者之间的距离最短的路径，然而在一些情况下，网络中的SDN交换机并不是完全可信的，组播用户希望组播算法生成的组播路径可以绕开不可信的SDN交换机，保证组播消息在可靠的SDN交换机之间传输，这也就是该文所提出的“障碍”需求服务场景，用户以控制器命令行的方式指明特定组播路由不允许经过的交换机，服务驱动组播路由算法根据用户需求重新生成组播路由并下发流表。

1.2.2 判断函数

该需求服务场景的判断函数的入参为待判断路径[s,k,x]，其中s为组播源，x为其中一个接收者，要判断的是，如果组播源s到接收者x之间的路径经过k，是否符合用户提出的需求。

判断方法：读取用户提出的关于“障碍”需求的参数，若参数中包含交换机节点k，则返回false；否则返回true。

1.3 指定服务质量的需求举例

1.3.1 服务场景

由最短路径算法生成的组播路径不会对带宽有明确的规定，也无法预测用户将要传送的组播消息占用带宽的大小。当用户明确要传送的组播消息占用带宽很大(如视频文件)，在低带宽的链路中容易造成较大的丢包和较长的时延，这时用户可以在控制器命令行中明确提出使用的组播路径的最小带宽，服务驱动组播路由算法根据用户的需求筛选合适的路径，重新下发流表。

1.3.2 判断函数

该需求服务场景的判断函数的入参为待判断路径[s,k,x]，其中s为组播源，x为其中一个接收者，要判断的是，如果组播源s到接收者x之间的路径经过k，是否符合用户提出的需求。

判断方法：读取用户提出的带宽需求；从控制器中取出节点s到节点k之间的链路的带宽，以及节点k到节点x之间的链路带宽；当s与k之间的带宽以及k与x之间的带宽均大于用户的带宽需求时认为这是一条满足用户需求的路径，返回true；否则返回false。

2 仿真测试

2.1 仿真环境

仿真是在由Mininet[14]搭建的SDN网络上[15]进行的。Mininet是一个轻量级软件定义网络和测试平台；它采用轻量级的虚拟化技术使一个单一的系统看起来像一个完整的网络运行相关的内核系统和用户代码，也可简单理解为SDN网络系统中的一种基于进程虚拟化平台，它支持OpenFlow等协议。在仿真环境中，使用一个控制器来控制网络内的交换机和主机，网络的基本配置信息如表1所示。

表1 仿真环境配置

2.2 基于SDN的服务驱动组播机制构建

2.2.1 组播流程

基于SDN的服务驱动组播将组播接收者管理工作集中在SDN控制器内，支持多个组播同时独立进行组播业务，支持组播接收者在任意时间的加入或退出，同时支持用户在组播运行过程中，随时根据服务需要，为组播组添加路由过滤条件，控制器根据用户添加的条件及时更新组播路由。

组播的工作流程如下：

(1)接收到需要处理的组播数据包(符合目的IP地址为组播地址的IPv4数据包)。

(2)对组播数据包进行筛选，避免浪费应用资源进行不必要的处理工作。在这一过程中，去除掉一些不符合条件的数据包，如已经被别的应用处理过的、内容为空的以及IPv6数据包等。

(3)解析数据包，得到数据包的源地址、目的地址(组播地址)、使用的网络层协议(用来判断该数据包是组播源发出的组播数据包还是由组播接收者发出的加入/离开组播请求)。

(4)如果解析到的数据包协议为IGMP协议，则执行组播接收者加入/退出流程；否则认为该数据包是由组播源发送的，执行组播建立过程。

2.2.2 组播建立

组播应用接收到来自组播源的数据包，首先解析数据包得到该数据包的源地址与目的地址，数据包的源地址即为组播源的IP地址，数据包的目的地址即为该组播组地址，根据源地址与组播地址，查找是否含有相同组播地址和源地址的组播组存在，如果有，则认为该组播组已经注册过，不再对该数据包进行后续处理；如果没有，则将新的组播路由添加到组播管理应用中，并且根据数据包的源地址信息将该条组播路由条目的与组播源相连的交换机端口信息补充完整，然后将组播地址和源地址的对应关系添加到源和组播地址对应表中。

至此，一条新的组播路由建立完成，它包含组播地址、源地址和组播源相连的交换机端口，由于当前组播还没有成员加入，控制器不会生成组播路由并下发路径到交换机。当有组播接收者加入的时候，控制器才能获得该组播组的接受者所连的交换机端口集合信息，并将组播路由转化为相应的组播路径下发到交换机，在没有组播用户提出的特殊服务需求时，组播路由采用Dijkstra算法[16]；在有服务需求时，采用服务驱动组播路由算法。成员加入的流程具体见2.2.3。

2.2.3 组播接收者加入/离开

组播应用接收到来自组播接收者的数据包(IGMP数据包)，首先解析数据包得到该数据包的有效载荷，根据有效载荷中提供的信息判断该数据包是加入组播组请求还是离开组播组请求，分别对应着不同的处理。

以加入组播组的请求为例，根据成员想要加入的组播组地址，查询组播源与组播地址对应表中是否有对应的组播源地址，如果没有，则表示该成员想要加入的组播组尚且没有在组播应用中建立，无需处理入组请求。如果有，则表明该组播组已经在组播应用中注册，此时要根据要加入的组播组地址和查找出的对应的组播源地址，获取该组播的成员列表，如果成员列表中不包含该成员，那么就将该成员加入，更新组播路由。

对离开组播组请求的处理与加入组播组请求处理过程大致相似，不同的是一个是将该成员加入到组播的成员列表中，另一个是从成员列表中移出该成员。

2.3 服务驱动路由功能测试

在组播用户没有提出特定服务需求的情况下，组播应用会按照Dijkstra算法生成从组播源到各个组播接收者之间的最短路径。当用户提出特定的服务需求时，组播路由会根据用户的需求决定是否需要更新。如图2所示的测试拓扑，由11个交换机和16个主机构成。组播源为h1，四个组播接收者分别为h5，h7，h8，h9。

图2 服务驱动路由功能测试

2.3.1 特定交换机需求测试

测试当用户添加不允许任何组播路径经过s3交换机的服务需求时，从h1到h7的路径是否会发生变化。

其中h1到h7有两条路径可以选择，分别是[s1,s3,s8]和[s1,s2,s5,s8]。组播用户没有对组播路径提出具体需求，组播应用按照Dijkstra算法生成从组播源到各个组播接收者间的最短路径，可以看到此时h1到h7之间的路径选择的是[s1,s3,s8]，如图3所示。

图3 没有用户指定服务需求时的组播路由

之后，组播用户为该条组播添加特定的服务需求，需求为：所有组播路径不允许经过s3，此时的组播路由变化如图4所示，可以看到此时从h1到h7的路径选择了[s1,s2,s5,s8]。

图4 添加用户服务需求的路由

2.3.2 带宽需求测试

根据链路带宽设置，重新开启一个组播地址为224.1.1.5的组播路由，建立由h1到h7和h8的组播路由，由于s3与s8之间的链路带宽设置为100 M，测试当加上所选路径带宽必须大于300 M的时候，h1到h7之间的路径是否会发生变化。

在该组播路由没有带宽需求的时候，h1到h7之间的路径如图3所示，为根据最短路径算法得到的最短路径。之后，组播用户为该条组播添加特定的服务需求，需求为：要求所有组播路径的带宽必须大于300 M，添加带宽服务需求后的组播路径如图5所示。

图5 添加带宽需求后的组播路径

在添加需求后，h1到h7之间选择了[s1,s2,s5,s8],绕开了[s3,s8]这个不符合服务需求的路径。

2.4 服务驱动组播性能测试

2.4.1 端到端时延测试

消息从组播源发出到组播接收者成功接收的时间记为端到端时延，是组播用户非常敏感的一个参数，测试该文所提出的服务驱动组播在没有服务需求和有服务需求两种情况下，端到端时延的变化。端到端时延的测量方法为：在组播源发出的数据包中打上时间戳，接收者接收到数据包解析时间戳，并用接收时间减去时间戳时间，得到该组播源到该接收者之间的端到端时延。时延测试结果如图6所示。

图6 平均端到端时延的测量结果

根据时延测量结果，当添加了服务需求后，由于服务需求对流表的影响，使端到端时延产生了一定的增加，但是增加的范围很小，不会对时延性能造成太大影响。

2.4.2 路由收敛速度测试

组播接收者的加入/退出、链路状态改变、用户添加服务需求等都会对组播策略产生影响，造成组播路径的重新规划和流表的重新下发等行为。该文测试了由于组播接收者加入/退出造成的路由重新规划，从成员发送IGMP包开始到新的策略下发到交换机的整个过程的时间。策略下发时间包含成员发送IGMP包到控制器时间T1，控制器处理IGMP包并生成新的组播路由时间T2，控制器将组播路由下发到交换机的时间T3。由于控制器与交换机之间直接相连，T3相比T1和T2来说很小，策略下发时间T≈T1+T2。策略下发时间的测试结果如图7所示。

图7 策略下发时间测量结果

根据测量结果显示，基于SDN的服务驱动组播的策略下发时间在几百毫秒之间，随着组播规模的增加，策略下发时间也会增加；添加服务需求后的组播路由的策略下发时间要比没有添加服务需求的下发时间长，会比没有服务需求的组播路由增加约1%。

2.5 测试结论

经过本章的功能测试和性能测试，得出以下结论：(1)所提出的基于SDN服务驱动组播可以在SDN网络条件下，服务于有基础组播需求的用户和有特殊服务需求的组播用户；(2)没有服务需求时，组播路由默认采用最短路径算法，为组播路由添加服务需求后，根据需求对最终生成的组播路径的影响程度，会轻微牺牲组播的性能表现，但是不会对性能产生严重影响。

3 结束语

从组播用户的角度提出了基于SDN的服务驱动组播的概念，设计并实现可以根据用户需求动态更改组播路由的组播算法，一方面可以实现用户对于组播的不同的定制化需求，另一方面依靠SDN路由与转发分离的特性，将传统互联网中的组播路由计算和根据路由转发两个功能解耦出来，极大地减少了交换机负担，提高组播的服务质量。

目前的用户需求仅支持用户手动选择或者添加相应的服务特定需求。但是，组播用户对于组播路由的需求和业务场景是有密切联系的，是有规律可循的。可以利用组播用户大数据，探索用户需求与业务场景之间的关系，找出其中的联系规律，将部分需求封装在组播路由内部，由组播系统自动帮助用户选择。例如，用户传送视频等需要大带宽的文件时，自动为用户选择链路占用率小的链路，保证组播文件的有效传送。

在大数据与人工智能发展如此快速的今天，基于SDN的组播路由可以借助其力量，为组播用户提供更加便捷优质的服务。