[发明专利]在代理装置上管理主机预订状态的有效方式

说明书

技术领域

本发明的实施例涉及用于改进在下游代理装置的多播订户管理的效率和可扩展性的方法和系统。具体而言，本发明的实施例涉及使用接口跟踪表管理关于多播订户节点的聚合要求的多播源，在下游代理装置与上游多播路由器之间接口的聚合状态。

背景技术

代理装置在多播网络中用于管理在多播订户节点集与上游多播路由器之间多播源的转发和阻塞。上游多播路由器与多播源直接连接，或者中间装置间接连接到提供内容到多播订户节点集的多播源。代理装置是为多播群组管理成员数据库的二级(L2)装置。成员数据库的管理在RFC 4605中描述。代理装置使用成员数据请求上游多播路由器转发或阻塞用于每个多播源的业务。RFC 4605建议在维护成员数据库中，代理装置使用在RFC 3376的第3.2部分（用于IPv4）或RFC 3810的第4.2部分（用于IPv6）中描述的合并规则。这些参考的部分描述了能够维护在使用因特网群组管理协议版本3 (IGMPv3)或多播侦听器发现版本2 (MLDv2)的上游多播路由器与代理装置之间的接口上用于多播群组的成员的聚合状态的方式。在接口的不同侧上用于相同多播群组的成员状态不同时，此聚合状态能够用于管理接口。

对于IGMPv3和MLDv2，多播群组中的成员状态能够是在包含或排除模式中。聚合状态能够基于在来自多播订户节点的多播成员报告中收到的信息推导。多播订户节点在其报告中识别它们要求来自其的业务的多播源（即，被转发的那些源）和它们不要求来自其的业务的那些多播源（即，被阻塞的那些源）。在包含模式中，将只为多播群组转发来自多播订户节点请求的源的业务。在排除模式中，将为多播群组转发来自除多播订户节点明确请求的那些源外所有源的业务。然而，如果在接口上存在是包含和排除模式的混合的多个应用或套接字，则接口需要聚合此状态以便能够正确服务于所有订户节点。

RFC 3376的第3.2部分描述了一种用于计算聚合状态的方法。然而，此过程要求检查被排除的所有多播群组以便为排除确定共同源，并且随后从共同排除源的列表减去明确包括的所有源。在代理装置上管理成员数据库的此过程效率低，并且不能扩展。接口的数量（例如，在智能边缘装置的多结(mutli-bond)接口上的订户电路）能够是大约数千个接口。单个电路上多播群组成员状态的任何更改要求重新处理所有电路的群组成员状态以便得出多结接口的新聚合状态。此方法对于代理装置是处理器密集型，并且延迟接口的新聚合状态的计算。此外，虽然基于所有电路的聚合状态在被重新处理，但已经处理的电路的状态的任何更改将还要求重新处理。由于来自多播订户节点的成员报告能够经常更改状态，因此，这能够经常发生。例如，在某些实施例中，多播订户节点是管理生成经常信道更改的因特网协议电视(IPTV)的机顶盒，其中，每个信道对应于一个多播源。

发明内容

一种在广域网的网络单元中实现的方法，网络单元充当用于上游多播路由器的代理，上游多播路由器使用因特网群组管理协议(IGMP)或多播侦听器发现(MLD)提供多个多播源到多个多播订户节点，多个多播订户节点与网络单元进行通信，方法通过跟踪多个多播订户节点的聚合状态要求的多个多播源中多播源的子集，以有效和可扩展的方式管理在上游多播路由器与代理之间的接口，跟踪使用接口跟踪表来确定接口的聚合状态，而不是跟踪详细描述每个多播订户节点要求的每个多播源的更特定数据的转发信息库(FIB)和成员数据库，方法包括以下步骤：由网络单元接收来自多个多播订户节点的第一节点的IGMP或MLD成员报告，IGMP或MLD成员报告指示在网络单元与上游多播路由器之间的接口上第一多播订户节点要接收的多播源集中的至少一个更改；更新接口跟踪表以在多播源的子集中反映至少一个更改，接口跟踪表对应于在网络单元与上游多播路由器之间的接口，并且维护多个多播订户节点的聚合状态，聚合状态定义要转发到多个多播订户节点或为多个多播订户节点阻塞的多播源的子集；以及基于接口跟踪表的更新，将要转发到网络单元或为网络单元阻塞的多播源的子集中的至少一个更改通知上游多播路由器，接口跟踪表的更新独立于为每个多播订户节点维护要转发和阻塞的多播源的FIB和成员数据库的更新。