组播转发表项的下发方法及设备
技术领域
本申请涉及通信网络技术领域,特别涉及一种组播转发表项的下发方法及设备。
背景技术
随着服务器和交换机数量的不断增加,数据中心网络越来越倾向于扁平化的网络架构,以便于维护管理,这就要求构建一个大型的二层(Layer 2,L2)网络。传统的二层网络通过生成树协议(Spanning Tree Protocol,STP)来消除环路,但是,生成树协议本身所固有的一些缺陷使其不再适用于数据中心网络,例如:
(1)生成树协议通过阻塞冗余链路来消除环路,但是数据中心网络难以承受这种带宽浪费;
(2)生成树协议要求所有的数据必须经由根桥转发,这样会影响转发效率;
(3)生成树协议无法携带TTL(Time To Live,生存时间)参数,这样,一旦出现二层环路,会造成整网瘫痪;
(3)生成树协议收敛速度较慢,重新收敛对数据流有较大的影响。
为了解决生成树协议的上述问题,IETF(Internet Engineering Task Force,互联网工程任务组)通过制定TRILL(TRansparent Interconnection of Lots of Links,多链路透明互联)协议将三层路由技术IS-IS(Intermediate System-to-Intermediate System,中间***到中间***)的设计思路引入二层网络,并对其进行了必要的改造。从而将二层的简单、灵活性与三层的稳定、可扩展和高性能有机地融合起来。
图1和图2是典型的TRILL网络的架构示意图。TRILL网络是由RB(RoutingBridge,路由桥)构成的二层网络。运行TRILL协议的Bridge设备称为RB,也写作RBridge。根据在TRILL网络中的位置,RB又可分为Ingress RB、Transit RB和EgressRB三种,分别表示报文进入TRILL网络的入节点、在TRILL网络中经过的中间节点以及离开TRILL网络的出节点,如图1所示。RB在TRILL网络中的地址由NickName(昵称)表示,NickName是RB在TRILL网络中的唯一标识。Nickname由***自动分配,无需配置。
在TRILL网络中,存在两类转发表项:单播转发表项和组播转发表项。其中,单播转发表项用于指导目的MAC地址已知的单播报文的转发,组播转发表项用于指导多目的报文的转发,多目的报文包括:目的MAC地址未知的单播报文、广播报文和组播报文。TRILL网络中的每一个RB设备会根据LSDB(Link State Database,链路状态数据库)中的信息计算和选择组播树的树根。
为了提高数据流的转发效率,在每一个组播树上可以按照每一个VLAN(VirtualLocal Area Network,虚拟局域网)或每一个组播MAC(Media Access Control,媒体访问控制)地址建立组播转发表项,实现多目的报文按照根RB+VLAN或根RB+VLAN+MAC的剪枝转发。因此,根据key(关键词)的不同,组播转发表项分为:A类组播转发表项、B类组播转发表项和C类组播转发表项,其中,A类组播转发表项为基于根RB(即为组播树的树根)的组播转发表项,B类组播转发表项为基于根RB(即为组播树的树根)和VLAN的组播转发表项,C类组播转发表项为基于根RB(即为组播树的树根)、VLAN和MAC(组播MAC)的组播转发表项。这样,在报文转发过程中,RB接收到多目的报文后,会按照C->B->A的查表顺序查找匹配的组播转发表项,即,先在C类转发表中查找,若查找不到,则继续在B类转发表中查找,还查找不到,则在A类转发表中查找,在查找到匹配的组播转发表项后,根据匹配或命中的组播转发表项中的内容对接收到的多目的报文进行转发。
在一个大型的TRILL网络中,可能会存在多个组播树,每一个组播树上存在多个VLAN,每一个VLAN内存在多个组播MAC地址。这样,在RB设备中的包括A类、B类和C类组播转发表项在内的组播转发表项的个数就非常多。当TRILL网络的网络拓扑发生变化时,需要更新下发的组播转发表项的数量就可能很多,下发这些大量的组播转发表项所需要的时间就比较长,组播转发表项下发的效率较低,并且,将数据流切换到正确链路上的时间也会比较长。
发明内容
本申请提供了一种组播转发表项的下发方法及设备,以解决现有技术中存在的在网络拓扑发生变化时,下发组播转发表项所需要的时间较长,组播转发表项下发的效率较低,并且,将数据流切换到正确链路上的时间也较长的问题。
本申请的技术方案如下:
一方面,提供了一种组播转发表项的下发方法,应用于TRILL网络中的RB,该方法包括:计算出组播转发表项,其中,组播转发表项中包括:A类组播转发表项和B类组播转发表项;将计算出的A类组播转发表项下发到数据平面;对于计算出的每一个B类组播转发表项,仅在该B类组播转发表项的表项内容与第一A类组播转发表项的表项内容不同时,将该B类组播转发表项下发到数据平面,其中,第一A类组播转发表项为计算出的A类组播转发表项中与该B类组播转发表项的根RB相同的组播转发表项。
另一方面,还提供了一种TRILL网络中的RB,包括:计算模块,用于计算出组播转发表项,其中,组播转发表项中包括:A类组播转发表项和B类组播转发表项;比较模块,用于对于计算模块计算出的每一个B类组播转发表项,比较该B类组播转发表项的表项内容与第一A类组播转发表项的表项内容是否相同,其中,第一A类组播转发表项为计算出的A类组播转发表项中与该B类组播转发表项的根RB相同的组播转发表项;下发模块,用于将计算模块计算出的A类组播转发表项下发到数据平面;还用于对于计算模块计算出的每一个B类组播转发表项,仅在比较模块的比较结果为该B类组播转发表项的表项内容与第一A类组播转发表项的表项内容不同时,将该B类组播转发表项下发到数据平面。
在本申请的技术方案中,当基于相同的根RB的B类和A类组播转发表项的表项内容相同时,不再下发该B类组播转发表项,只有在不同时,才下发该B类组播转发表项,从而,通过B类组播转发表项和与其根RB相同的A类组播转发表项的复用,可以有效地减少下发的组播转发表项的个数,缩短下发组播转发表项所需要的时间,提高网络拓扑变化时组播转发表项的下发效率,并且,有效缩短将数据流切换到正确链路上的时间,同时也没有造成组播数据流的多发。
附图说明
图1是现有技术中一种典型的TRILL网络的架构示意图;
图2是现有技术中另一种典型的TRILL网络的架构示意图;
图3是本申请的实施例一的组播转发表项的下发方法的流程示意图;
图4是本申请的实施例二的组播转发表项的下发方法的流程示意图;
图5是本申请的实施例三的TRILL网络中的RB的结构示意图。
具体实施方式
为了解决现有技术中存在的在网络拓扑发生变化时,下发组播转发表项所需要的时间较长,组播转发表项下发的效率较低,并且,将数据流切换到正确链路上的时间也较长的问题,本申请的以下实施例提供了一种TRILL网络中的组播转发表项的下发方法以及可以应用该方法的RB。
对于A类组播转发表项、B类组播转发表项和C类组播转发表项这三类组播转发表项,其表项内容主要包括两部分:本地网络中是否存在组播接收者的标识,该标识用于判断是否需要将收到的TRILL数据报文解封装后进行本地转发,以及,一个用于TRILL数据报文转发的端口列表。其中,端口列表中可能包含有一个或多个端口(目前最多支持255个端口),每一个端口都有端口索引等信息。
接入层的RB接入TRILL网络中的端口数量相当有限,因此,大量组播转发表项的内容可能是完全相同的。所以,当基于相同的根RB的B类和A类组播转发表项的表项内容相同(本地网络中是否存在组播接收者的标识相同,且端口列表相同)时,不再需要下发该B类组播转发表项;同样,当基于相同的根RB和VLAN的C类和B类组播转发表项的表项内容相同(本地网络中是否存在组播接收者的标识相同,且端口列表相同)时,不再需要下发该C类组播转发表项。从而,通过组播转发表项的复用,即,B类组播转发表项和与其根RB相同的A类组播转发表项复用,C类组播转发表项和与其根RB、VLAN相同的B类组播转发表项复用,可以有效地减少下发的组播转发表项的个数,缩短了下发组播转发表项所需要的时间,提高了网络拓扑变化时组播转发表项的下发效率,并且,有效缩短了将数据流切换到正确链路上的时间,同时也没有造成组播数据流的多发。
实施例一
本申请的实施例一的组播转发表项的下发方法可以由TRILL网络中的任意一个RB来执行。如图3所示,该方法包括以下步骤:
步骤S301,计算出组播转发表项,其中,计算出的组播转发表项中包括:A类组播转发表项和B类组播转发表项;其中,A类组播转发表项的格式可以如表1所示,B类组播转发表项的格式可以如表2所示:
表1
根RB的NickName |
本地网络中是否存在组播接收者的标识 |
端口列表 |
表2
当网络拓扑发生变化时,RB中的CPU(即控制平面)会根据全网的变化后的链路状态信息计算出组播转发表项。
其中,A类组播转发表项为基于组播树的根RB的组播转发表项,B类组播转发表项为基于组播树的根RB和VLAN的组播转发表项。
步骤S302,将计算出的A类组播转发表项下发(下发即配置)到数据平面;
下发时,按照现有技术进行下发即可。在实际下发过程中,可以将计算出的A类组播转发表项均直接下发到数据平面,也可以仅下发表项内容发生了变化的A类组播转发表项。
步骤S303,对于计算出的每一个B类组播转发表项,仅在该B类组播转发表项的表项内容与第一A类组播转发表项的表项内容不同时,才将该B类组播转发表项下发到数据平面,其中,第一A类组播转发表项为计算出的A类组播转发表项中与该B类组播转发表项的根RB相同的组播转发表项。
即,在该B类组播转发表项的表项内容与第一A类组播转发表项的表项内容相同时,就不再将该B类组播转发表项下发到数据平面。
具体的,表项内容中包括:端口列表和本地网络中是否存在组播接收者的标识,因此,表项内容相同,即,端口列表相同,且本地网络中是否存在组播接收者的标识也相同;表项内容不同,即,端口列表和本地网络中是否存在组播接收者的标识中至少一个不同。
例如,计算出的一个B类组播转发表项如表3所示:
表3
此时,如果计算出的A类组播转发表项中与该B类组播转发表项的根RB相同的组播转发表项,即第一A类组播转发表项如表4所示,则,因为这两个转发表项中的本地网络中是否存在组播接收者的标识相同,均为0;并且,端口列表也相同,均为Port1,Port3和Port12,因此,如表3所示的B类组播转发表项不需要下发到数据平面。
表4
根RB的NickName |
本地网络中是否存在组播接收者的标识 |
端口列表 |
0x0100 |
0 |
Port1,Port3,Port12 |
然而,如果计算出的A类组播转发表项中与该B类组播转发表项的根RB相同的组播转发表项,即第一A类组播转发表项如表5-7中任一个所示,则,因为这两个转发表项中的本地网络中是否存在组播接收者的标识不相同,和/或,端口列表不相同,因此,如表3所示的B类组播转发表项需要下发到数据平面。
表5
根RB的NickName |
本地网络中是否存在组播接收者的标识 |
端口列表 |
0x0100 |
1(表示本地网络中存在组播接收者) |
Port1,Port3,Port12 |
表6
根RB的NickName |
本地网络中是否存在组播接收者的标识 |
端口列表 |
0x0100 |
0 |
Port5,Port8 |
表7
本实施例的技术方案中,当基于相同的根RB的B类和A类组播转发表项的表项内容相同(本地网络中是否存在组播接收者的标识相同,且端口列表相同)时,不再下发该B类组播转发表项,只有在不同时,才下发该B类组播转发表项,从而,通过B类组播转发表项和与其根RB相同的A类组播转发表项的复用,可以有效地减少下发的组播转发表项的个数,缩短了下发组播转发表项所需要的时间,提高了网络拓扑变化时组播转发表项的下发效率,并且,有效缩短了将数据流切换到正确链路上的时间,同时也没有造成组播数据流的多发。
实施例二
同样,也可以将C类组播转发表项和与其根RB、VLAN相同的B类组播转发表项进行复用,这样,本申请的实施例二的组播转发表项的下发方法,如图4所示,包括以下步骤:
步骤S401,计算出组播转发表项,其中,计算出的组播转发表项中包括:A类组播转发表项、B类组播转发表项和C类组播转发表项;其中,C类组播转发表项为基于组播树的根RB、VLAN和组播MAC地址的组播转发表项。
实现时,可以先计算A类组播转发表项,再计算B类组播转发表项,最后计算C类组播转发表项。
其中,A类组播转发表项的格式可以如表1所示,B类组播转发表项的格式可以如表2所示,C类组播转发表项的格式可以如表8所示:
表8
步骤S402,将计算出的A类组播转发表项下发到数据平面;
步骤S403,对于计算出的每一个B类组播转发表项,仅在该B类组播转发表项的表项内容与第一A类组播转发表项的表项内容不同时,才将该B类组播转发表项下发到数据平面,其中,第一A类组播转发表项为计算出的A类组播转发表项中与该B类组播转发表项的根RB相同的组播转发表项;
当一个B类组播转发表项需要下发时,检查其表项内容和与该B类转发组播表项的根RB相同的A类组播转发表项(将与该B类组播转发表项的根RB相同的A类组播转发表项称为第一A类组播转发表项)的表项内容是否相同,如果内容相同,则不再下发该B类组播转发表项,对应的多目的报文根据第一A类组播转发表项进行转发。如果表项内容不同,则下发该B类组播转发表项,对应的多目的报文根据该B类组播转发表项进行转发。
步骤S404,对于计算出的每一个C类组播转发表项,仅在该C类组播转发表项的表项内容与第一B类组播转发表项的表项内容不同时,才将该C类组播转发表项下发到数据平面,其中,第一B类组播转发表项为计算出的B类组播转发表项中与该C类组播转发表项的根RB和VLAN相同的组播转发表项。
即,在该C类组播转发表项的表项内容与第一B类组播转发表项的表项内容相同时,就不再将该C类组播转发表项下发到数据平面。
例如,计算出的一个C类组播转发表项如表9所示:
表9
此时,如果计算出的B类组播转发表项中与该C类组播转发表项的根RB和VLAN相同的组播转发表项,即第一B类组播转发表项如表10所示,则,因为这两个转发表项中的本地网络中是否存在组播接收者的标识相同,均为1;并且,端口列表也相同,均为Port2,Port10,Port14,Port17和Port29,因此,如表9所示的C类组播转发表项就不需要下发到数据平面。
表10
然而,如果计算出的B类组播转发表项中与该C类组播转发表项的根RB和VLAN相同的组播转发表项,即第一B类组播转发表项如表11-13中任一个所示,则,因为这两个转发表项中的本地网络中是否存在组播接收者的标识不相同,和/或,端口列表不相同,因此,如表9所示的C类组播转发表项需要下发到数据平面。
表11
表12
表13
由上,当一个C类组播转发表项需要下发时,检查其表项内容和与该C类组播转发表项的根RB、VLAN相同的B类组播转发表项(将与该C类组播转发表项的根RB和VLAN均相同的B类组播转发表项称为第一B类组播转发表项)的表项内容是否相同。如果表项内容相同,则不再下发该C类组播转发表项,对应的多目的报文根据第一B类组播转发表项进行转发。如果表项内容不同,则下发该C类组播转发表项,对应的多目的报文根据该C类组播转发表项进行转发。
当基于相同的根RB的B类和A类组播转发表项的表项内容相同时,不再下发该B类组播转发表项,只有在不同时,才下发该B类组播转发表项;同样,当基于相同的根RB和VLAN的C类和B类组播转发表项的表项内容相同时,不再下发该C类组播转发表项,只有在不同时,才下发该C类组播转发表项。从而,通过组播转发表项的复用,即,B类组播转发表项和与其根RB相同的A类组播转发表项复用,C类组播转发表项和与其根RB、VLAN相同的B类组播转发表项复用,可以有效地减少下发的组播转发表项的个数,缩短下发组播转发表项所需要的时间,提高网络拓扑变化时组播转发表项的下发效率,并且,有效缩短将数据流切换到正确链路上的时间,同时也没有造成组播数据流的多发。
上述实施例一和实施例二中的方法,在具体实施时,可以由RB中的CPU(即控制平面)来执行。由于CPU的处理速度是很快的,因此,CPU计算组播转发表项并进行比较的速度是非常快的,所需时间很短。而下发组播转发表项时,由于是CPU与转发处理芯片(即数据平面或转发引擎)之间进行通信的过程,下发速度是由CPU和转发处理芯片两者的处理速度来决定,而转发处理芯片的处理速度相对较慢,因此,本申请虽然增加了执行比较步骤所需的时间,但是,由于极大地减少了需要下发的组播转发表项的数量,并且,比较所需时间比下发所需时间要短得多,因此,本申请仍然有效地提高网络拓扑变化时组播转发表项的下发效率,并且,有效缩短将数据流切换到正确链路上的时间。
实施例三
针对上述实施例一和二中的方法,本申请的实施例三提供了一种TRILL网络中的RB,如图5所示,该RB包括以下模块:计算模块10、比较模块20和下发模块30,其中:
计算模块10,用于计算出组播转发表项,其中,组播转发表项中包括:A类组播转发表项和B类组播转发表项;
比较模块20,用于对于计算模块10计算出的每一个B类组播转发表项,比较该B类组播转发表项的表项内容与第一A类组播转发表项的表项内容是否相同,其中,第一A类组播转发表项为计算出的A类组播转发表项中与该B类组播转发表项的根RB相同的组播转发表项;
下发模块30,用于将计算模块10计算出的A类组播转发表项下发到数据平面;还用于对于计算模块10计算出的每一个B类组播转发表项,仅在比较模块20的比较结果为该B类组播转发表项的表项内容与第一A类组播转发表项的表项内容不同时,将该B类组播转发表项下发到数据平面。
另外,计算模块10计算出的组播转发表项中还包括:C类组播转发表项;则,比较模块20,还用于对于计算模块10计算出的每一个C类组播转发表项,比较该C类组播转发表项的表项内容与第一B类组播转发表项的表项内容是否相同,其中,第一B类组播转发表项为计算出的B类组播转发表项中与该C类组播转发表项的根RB和虚拟局域网VLAN相同的组播转发表项;下发模块30,还用于对于计算模块10计算出的每一个C类组播转发表项,仅在比较模块20的比较结果为该C类组播转发表项的表项内容与第一B类组播转发表项的表项内容不同时,将该C类组播转发表项下发到数据平面。
其中,A类组播转发表项为基于组播树的根RB的组播转发表项,B类组播转发表项为基于组播树的根RB和VLAN的组播转发表项,C类组播转发表项为基于组播树的根RB、VLAN和组播MAC地址的组播转发表项。表项内容中包括:端口列表和本地网络中是否存在组播接收者的标识。
综上,本申请以上实施例可以达到以下技术效果:
当基于相同的根RB的B类和A类组播转发表项的表项内容相同时,不再下发该B类组播转发表项,只有在不同时,才下发该B类组播转发表项;同样,当基于相同的根RB和VLAN的C类和B类组播转发表项的表项内容相同时,不再下发该C类组播转发表项,只有在不同时,才下发该C类组播转发表项。从而,通过组播转发表项的复用,即,B类组播转发表项和与其根RB相同的A类组播转发表项复用,C类组播转发表项和与其根RB、VLAN相同的B类组播转发表项复用,可以有效地减少下发的组播转发表项的个数,缩短下发组播转发表项所需要的时间,提高网络拓扑变化时组播转发表项的下发效率,并且,有效缩短将数据流切换到正确链路上的时间,同时也没有造成组播数据流的多发。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。