CN1819543A - 一种降低组播业务延迟的方法 - Google Patents
一种降低组播业务延迟的方法 Download PDFInfo
- Publication number
- CN1819543A CN1819543A CNA2006100650895A CN200610065089A CN1819543A CN 1819543 A CN1819543 A CN 1819543A CN A2006100650895 A CNA2006100650895 A CN A2006100650895A CN 200610065089 A CN200610065089 A CN 200610065089A CN 1819543 A CN1819543 A CN 1819543A
- Authority
- CN
- China
- Prior art keywords
- multicast
- multicast group
- current execution
- query messages
- candidate
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
本发明公开了一种降低组播业务延迟的方法,通过在组播路由器向自身当前执行RP发送组播业务请求时,同时发送携带组播组地址的查询消息,若未在预定时间内收到来自当前执行RP的组播业务响应或携带组播组地址的确认消息,则重新选择新的执行RP。本发明提供的方法既适用于连接客户机的组播路由器也适用于连接组播源的路由器。由于本发明在请求组播业务的同时,查询了当前执行RP的状态,因此使得在当前执行RP失效时,组播路由器可以及时得知并重新选择新的执行RP,降低了组播业务的延迟。
Description
技术领域
本发明涉及组播业务技术领域,具体涉及一种降低组播业务延迟的方法。
背景技术
目前,协议无关组播稀疏模式(PIM SM)是应用最广泛的一个组播路由协议,而汇合点(RP)是该PIM SM运行机制中的重要角色。在PIM SM下组播源发布组播流,首先要向RP进行单播方式的注册;客户机想接收某个组播组的组播流,也要先向RP发送加入信息。所以RP的可用与否,决定着PIM SM下组播流传送的成功与失败。
为了保证RP的可靠性,PIM SM设计了RP的冗余与负荷分担机制。在PIM SM中可以配置多个组播路由器扮演侯选RP的角色,这些被配置了侯选RP角色的路由器周期性地向PIM SM域中的自举路由器(BSR)发送信息,该信息中描述了自身扮演RP角色的有效期以及自身愿意服务的组播组;BSR收集所有扮演侯选RP角色的路由器信息后,将所述扮演侯选RP角色的路由器信息发布给PIM SM域中的所有组播路由器,则组播路由器就得知了对某个特定的组播组共有哪些侯选RP可供自身选择。
由于扮演侯选RP角色的路由器信息在整个PIM SM域中的所有组播路由器中进行了共享,所以每个组播路由器都会根据相同的哈希算法为某个特定组播组计算出应该选择哪一个侯选RP作为该组播组的执行RP。计算过程为:路由器根据该特定组播组的地址和一个哈希掩码,对各愿意为该特定组播组服务的侯选RP分别运行哈希算法,最后将所得结果最小的侯选RP作为执行RP,若最小结果对应多个侯选RP,则取IP地址最大的侯选RP作为执行RP。当前网络管理员在部署PIM SM组播网络方案时,绝大多数情况下,会让连接客户机的组播路由器进行最短路径树(SPT)切换即:连接客户机的组播路由器先向执行RP申请接收组播流,执行RP再向组播源申请接收组播流;当连接客户机的组播路由器收到来自执行RP的组播流的第一个业务包时,就直接向组播源申请接收组播流,并同时拒绝接收来自执行RP的组播流,这样可使得组播业务传输的效率最高,此时执行RP只履行注册功能。当作为执行RP的路由器由于某些原因无法扮演RP角色时,该路由器会通知其它路由器,以便及时为组播组选出新的执行RP。但是,通知信息需要经历一段时间后才能让PIM SM域内的其它路由器收到,这样就会导致在发送通知信息至收到通知信息的这段时间内,原执行RP服务的组播组对应的组播业务不能进行,增加了组播业务延迟。
发明内容
有鉴于此,本发明的主要目的在于提供一种降低组播业务延迟的方法,以在当前执行RP失效时,快速选择出新的执行RP,降低组播业务的延迟。
为达到上述目的,本发明的技术方案是这样实现的:
一种降低组播业务延迟的方法,该方法包括:
组播路由器向自身当前执行RP发送组播业务请求,同时发送携带组播组地址的查询消息,若未在预定时间内收到来自当前执行RP的组播业务响应或携带组播组地址的确认消息,则重新选择新的执行RP。
所述组播路由器为连接客户机的组播路由器,所述组播业务请求为PIM加入请求,所述组播业务响应为请求的组播流。
所述组播路由器为连接组播源的组播路由器,所述组播业务请求为PIM源注册消息,所述组播业务响应为停止注册消息或加入消息。
所述查询消息的条数至少为1条。
所述查询消息携带的组播组地址的个数至少为1个。
所述确认消息携带的组播组地址的个数至少为1个。
所述组播路由器向当前执行RP发送查询消息之后进一步包括:当前执行RP收到查询消息后,判断自身是否要为该查询消息携带的组播组地址对应的组播组服务,若要,向组播路由器返回携带组播组地址的确认消息。
所述当前执行RP收到查询消息之后、判断自身是否要为组播组服务之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则判断自身是否要为该组播组服务。
所述当前执行RP判定自身要为该组播组服务之后、向组播路由器返回确认消息之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则向组播路由器返回确认消息。
所述方法进一步包括:当前执行RP收到所述更合适的候选RP返回的确认消息,向组播路由器返回拒绝消息。
所述组播路由器向当前执行RP发送查询消息之后进一步包括:当前执行RP收到查询消息后,检测到自身不要为该查询消息携带的组播组地址对应的组播组服务,向组播路由器返回携带组播组地址的拒绝消息。
一种降低组播业务延迟的方法,该方法包括:
当连接客户机的组播路由器要接收组播流时,向自身当前执行RP发送PIM加入请求,同时发送携带组播组地址的查询消息,若未在预定时间内收到来自当前执行RP的组播流或携带组播组地址的确认消息,则重新选择新的执行RP;
当连接组播源的组播路由器要发布组播流时,向自身当前执行RP发送PIM源注册消息,同时发送携带组播组地址的查询消息,若未在预定时间内收到来自当前执行RP的停止注册消息或加入消息或携带组播组地址的确认消息,则重新选择新的执行RP。
所述连接客户机的组播路由器向当前执行RP发送查询消息之后进一步包括:当前执行RP收到查询消息后,判断自身是否要为该查询消息携带的组播组地址对应的组播组服务,若要,向连接客户机的组播路由器返回携带组播组地址的确认消息;
所述连接组播源的组播路由器向当前执行RP发送查询消息之后进一步包括:当前执行RP收到查询消息后,判断自身是否要为该查询消息携带的组播组地址对应的组播组服务,若要,向连接组播源的组播路由器返回携带组播组地址的确认消息。
所述连接客户机的组播路由器向当前执行RP发送查询消息之后、判断自身是否要为组播组服务之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则判断自身是否要为该组播组服务;
所述连接组播源的组播路由器向当前执行RP发送查询消息之后、判断自身是否要为组播组服务之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则判断自身是否要为该组播组服务。
所述当前执行RP判定自身要为该组播组服务之后、向连接客户机的组播路由器返回确认消息之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则向连接客户机的组播路由器返回确认消息;
所述当前执行RP判定自身要为该组播组服务之后、向连接组播源的组播路由器返回确认消息之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则向连接组播源的组播路由器返回确认消息。
与现有技术相比,本发明所提供的方法通过在组播路由器向自身当前执行RP发送组播业务请求时,同时发送携带组播组地址的查询消息,若未在预定时间内收到来自当前执行RP的组播业务响应或携带组播组地址的确认消息,则重新选择新的执行RP。本发明提供的方法既适用于连接客户机的组播路由器也适用于连接组播源的路由器。由于本发明在请求组播业务的同时,查询了当前执行RP的状态,因此使得在当前执行RP失效时,组播路由器可以及时得知并重新选择新的执行RP,降低了组播业务的延迟。
附图说明
图1为本发明提供的降低组播业务延迟的具体实施例一的流程图;
图2为本发明提供的降低组播业务延迟的具体实施例二的流程图;
图3为本发明提供的降低组播业务延迟的具体实施例三的流程图;
图4为本发明提供的降低组播业务延迟的具体实施例四的流程图;
图5为本发明提供的降低组播业务延迟的具体实施例五的流程图;
图6为本发明提供的降低组播业务延迟的具体实施例六的流程图。
具体实施方式
下面结合附图及具体实施例对本发明再作进一步详细的说明。
图1为本发明提供的降低组播业务延迟的具体实施例一的流程图,如图1所示,其具体步骤如下:
步骤101:连接客户机的组播路由器向当前执行RP发送PIM加入请求消息,以申请接收组播流时,同时向当前执行RP发送携带组播组地址的查询消息。
这里,连接客户机的组播路由器可向当前执行RP发送1条查询消息,也可根据网络实际状况,同时发送多于1条查询消息。
查询消息的具体格式如表1所示,主要包括:消息头、RP地址和组播组地址,其中,消息头包括:PIM版本号、类型字段、保留字段、校验和字段。类型字段可取固定值:9,RP地址为连接客户机的组播路由器的当前执行RP地址,组播组地址为客户机申请接收的组播流对应的组播组的地址,其它字段的取值遵循PIM协议的标准定义。
PIM版本号 | 类型 | 保留 | 校验和 |
RP地址 | |||
组播组地址 |
表1 RP查询消息格式
需要指出的是,若连接客户机的组播路由器要同时向当前执行RP申请接收多个组播组的组播流,则在一个查询消息的组播组地址字段可同时携带所述多个组播组的地址。
步骤102:当前执行RP收到查询消息后,判断自身是否要为该查询消息携带的组播组地址对应的组播组服务,若是,执行步骤103;否则,转至步骤104。
这里,网络管理员预先会将每个RP要服务的组播组地址配置在对应RP上,当前执行RP根据自身配置的要服务的组播组地址,可得知自身是否要为查询消息携带的组播组地址对应的组播组服务。
进一步地,当前执行RP在判定自身不要为该组播组服务之后包括:向连接客户机的组播路由器返回携带组播组地址的拒绝消息。
拒绝消息的具体格式如表2所示,主要包括:消息头、RP地址和组播组地址,其中,消息头包括:PIM版本号、类型字段、保留字段、校验和字段。类型字段可取固定值:11,其它字段的取值与步骤101中的查询消息的对应字段取值相同。
PIM版本号 | 类型 | 保留 | 校验和 |
RP地址 | |||
组播组地址 |
表2 RP拒绝消息格式
步骤103:当前执行RP向连接客户机的组播路由器返回携带组播组地址的确认消息,以表示要为该组播组服务。
步骤104:连接客户机的组播路由器判断是否在预定时间内收到来自当前执行RP的组播流或确认消息,若是,判定当前执行RP有效,本流程结束;否则,执行步骤105。
这里,预定时间可根据实际需要设定,如设为2秒。
确认消息的具体格式如表3所示,主要包括:消息头、RP地址和组播组地址,其中,消息头包括:PIM版本号、类型字段、保留字段、校验和字段。类型字段可取固定值:10,其它字段的取值与步骤101中的查询消息的对应字段取值相同。
PIM版本号 | 类型 | 保留 | 校验和 |
RP地址 | |||
组播组地址 |
表3 RP确认消息格式
需要指出的是,若当前执行RP要向某个连接客户机的组播路由器同时返回针对多个组播组的确认信息,则在一个确认消息的组播组地址字段可同时携带所述多个组播组的地址。
步骤105:连接客户机的组播路由器判定当前执行RP失效,重新选择新的执行RP,将该新执行RP作为当前执行RP。
图2为本发明提供的降低组播业务延迟的具体实施例二的流程图,如图2所示,其具体步骤如下:
步骤201:连接客户机的组播路由器向当前执行RP发送PIM加入请求消息,以申请接收组播流时,同时向当前执行RP发送携带组播组地址的查询消息。
步骤202:当前执行RP收到查询消息后,立即根据该查询消息携带的组播组地址、对所有要为该组播组服务的候选RP分别运行哈希算法。
步骤203:当前执行RP根据哈希算法结果,判断是否有比自己更合适的侯选RP,若是,执行步骤204;否则,执行步骤206。
具体地,比当前执行RP更合适的候选RP指:哈希算法结果比当前执行RP的哈希算法结果小的候选RP,或者指:哈希算法结果与当前执行RP的哈希算法结果相同、但IP地址比当前执行RP的IP地址大的候选RP。
步骤204:当前执行RP向所述比自身更合适的候选RP发送携带组播组地址的查询消息。
步骤205:当前执行RP判断是否在预定时间内收到来自所述比自身更合适的候选RP的确认消息,若是,转至步骤208;否则,执行步骤206。
进一步地,当前执行RP在预定时间内收到来自所述比自身更合适的候选RP的确认消息之后包括:向连接客户机的组播路由器返回拒绝消息。
步骤206:当前执行RP判断自身是否要为该组播组服务,若是,执行步骤207;否则,转至步骤208。
进一步地,当前执行RP判断自身不要为该组播组服务之后包括:向连接客户机的组播路由器返回拒绝消息。
步骤207:当前执行RP向连接客户机的组播路由器返回携带组播组地址的确认消息,以表示要为该组播组服务。
步骤208:连接客户机的组播路由器判断是否在预定时间内收到来自当前执行RP的组播流或确认消息,若是,判定当前执行RP有效,本流程结束;否则,执行步骤209。
步骤209:连接客户机的组播路由器判定当前执行RP失效,重新选择新的执行RP,将该新执行RP作为当前执行RP。
图3为本发明提供的降低组播业务延迟的具体实施例三的流程图,如图3所示,其具体步骤如下:
步骤301:连接客户机的组播路由器向当前执行RP发送PIM加入请求消息,以申请接收组播流时,同时向当前执行RP发送携带组播组地址的查询消息。
步骤302:当前执行RP收到查询消息后,判断自身是否要为该组播组服务,若是,执行步骤303;否则,转至步骤308。
进一步地,当前执行RP判断自身不要为该组播组服务之后包括:向连接客户机的组播路由器返回拒绝消息。
步骤303:当前执行RP根据该查询消息携带的组播组地址、对所有要为该组播组服务的候选RP运行哈希算法。
步骤304:当前执行RP根据哈希算法结果,判断是否有比自己更合适的侯选RP,若是,执行步骤305;否则,执行步骤307。
步骤305:当前执行RP向所述比自身更合适的候选RP发送携带组播组地址的查询消息。
步骤306:当前执行RP判断是否在预定时间内收到来自所述比自身更合适的候选RP的确认消息,若是,转至步骤308;否则,执行步骤307。
进一步地,当前执行RP在预定时间内收到来自所述比自身更合适的候选RP的确认消息之后包括:向连接客户机的组播路由器返回拒绝消息。
步骤307:当前执行RP向连接客户机的组播路由器返回携带组播组地址的确认消息,以表示要为该组播组服务。
步骤308:连接客户机的组播路由器判断是否在预定时间内收到来自当前执行RP的组播流或确认消息,若是,判定当前执行RP有效,本流程结束;否则,执行步骤309。
步骤309:连接客户机的组播路由器判定当前执行RP失效,重新选择新的执行RP,将该新执行RP作为当前执行RP。
可以看出,图2和图3所示实施例的区别在于,图2所示实施例中,当前执行RP先查找比自己更合适的候选RP,若未找到或未收到来自所述比自己更合适的候选RP的确认消息,则继续判断自身是否要为组播组服务;图3所示实施例中,当前执行RP先判断自身是否要为组播组服务,若要,则继续查找比自己更合适的候选RP。
图1~3所示实施例,可以解决连接客户机的组播路由器的执行RP失效带来的组播业务延迟问题,以下图4~6给出解决连接组播源的组播路由器的执行RP失效带来的组播业务延迟的具体实施例。
图4为本发明提供的降低组播业务延迟的具体实施例四的流程图,如图4所示,其具体步骤如下:
步骤401:连接组播源的组播路由器向当前执行RP发送PIM源注册消息,同时向当前执行RP发送查询消息。
这里,连接组播源的组播路由器可向当前执行RP发送1条查询消息,也可根据网络实际状况,同时发送多于1条查询消息。
查询消息的格式与表1相同,其中,RP地址为连接组播源的组播路由器的当前执行RP地址,组播组地址为组播源要发布的组播流对应的组播组的地址,其它字段的取值与表1所示查询消息的对应字段取值相同。
需要指出的是,若连接组播源的组播路由器要同时向当前执行RP申请发布多个组播组的组播流,则在一个查询消息的组播组地址字段可同时携带所述多个组播组的地址。
步骤402:当前执行RP收到查询消息后,判断自身是否要为该查询消息携带的组播组地址对应的组播组服务,若是,执行步骤403;否则,转至步骤404。
进一步地,当前执行RP在判定自身不要为该组播组服务之后包括:向连接组播源的组播路由器返回携带组播组地址的拒绝消息。
步骤403:当前执行RP向连接组播源的组播路由器返回携带组播组地址的确认消息,以表示要为该组播组服务。
步骤404:连接组播源的组播路由器判断是否在预定时间内收到来自当前执行RP的注册停止消息或加入消息或确认消息,若是,判定当前执行RP有效,本流程结束;否则,执行步骤405。
这里,预定时间可根据实际需要设定,如设为2秒。
确认消息的格式与表2相同,其中,各字段的取值与步骤401中查询消息的对应字段的取值相同。
需要指出的是,若当前执行RP要向某个连接组播源的组播路由器同时返回针对多个组播组的确认信息,则在一个确认消息的组播组地址字段可同时携带所述多个组播组的地址。
步骤405:连接组播源的组播路由器判定当前执行RP失效,重新选择新的执行RP,将该新执行RP作为当前执行RP。
图5为本发明提供的降低组播业务延迟的具体实施例五的流程图,如图5所示,其具体步骤如下:
步骤501:连接组播源的组播路由器向当前执行RP发送PIM源注册消息,同时向当前执行RP发送查询消息。
步骤502:当前执行RP收到查询消息后,立即根据该查询消息携带的组播组地址、对所有要为该组播组服务的候选RP运行哈希算法。
步骤503:当前执行RP根据哈希算法结果,判断是否有比自己更合适的侯选RP,若是,执行步骤504;否则,执行步骤506。
步骤504:当前执行RP向所述比自身更合适的候选RP发送携带组播组地址的查询消息。
步骤505:当前执行RP判断是否在预定时间内收到来自所述比自身更合适的候选RP的确认消息,若是,转至步骤508;否则,执行步骤506。
进一步地,当前执行RP在预定时间内收到来自所述比自身更合适的候选RP的确认消息之后包括:向连接组播源的组播路由器返回拒绝消息。
步骤506:当前执行RP判断自身是否要为该组播组服务,若是,执行步骤507;否则,转至步骤508。
进一步地,当前执行RP判定自身不要为该组播组服务之后包括:向连接组播源的组播路由器返回拒绝消息。
步骤507:当前执行RP向连接组播源的组播路由器返回携带组播组地址的确认消息,以表示要为该组播组服务。
步骤508:连接组播源的组播路由器判断是否在预定时间内收到来自当前执行RP的注册停止消息或加入消息或确认消息,若是,判定当前执行RP有效,本流程结束;否则,执行步骤509。
步骤509:连接组播源的组播路由器判定当前执行RP失效,重新选择新的执行RP,将该新执行RP作为当前执行RP。
图6为本发明提供的降低组播业务延迟的具体实施例六的流程图,如图6所示,其具体步骤如下:
步骤601:连接组播源的组播路由器向当前执行RP发送PIM源注册消息,同时向当前执行RP发送查询消息。
步骤602:当前执行RP收到查询消息后,判断自身是否要为该组播组服务,若是,执行步骤603;否则,转至步骤608。
进一步地,当前执行RP判定自身不要为该组播组服务之后包括:向连接组播源的组播路由器返回拒绝消息。
步骤603:当前执行RP根据该查询消息携带的组播组地址、对所有要为该组播组服务的候选RP运行哈希算法。
步骤604:当前执行RP根据哈希算法结果,判断是否有比自己更合适的侯选RP,若是,执行步骤605;否则,执行步骤607。
步骤605:当前执行RP向所述比自身更合适的候选RP发送携带组播组地址的查询消息。
步骤606:当前执行RP判断是否在预定时间内收到来自所述比自身更合适的候选RP的确认消息,若是,转至步骤608;否则,执行步骤607。
进一步地,当前执行RP在预定时间内收到来自所述比自身更合适的候选RP的确认消息之后包括:向连接组播源的组播路由器返回拒绝消息。
步骤607:当前执行RP向连接组播源的组播路由器返回携带组播组地址的确认消息,以表示要为该组播组服务。
步骤608:连接组播源的组播路由器判断是否在预定时间内收到来自当前执行RP的注册停止消息或加入消息或确认消息,若是,判定当前执行RP有效,本流程结束;否则,执行步骤609。
步骤609:连接组播源的组播路由器判定当前执行RP失效,重新选择新的执行RP,将该新执行RP作为当前执行RP。
可以看出,图5和图6所示实施例的区别在于,图5所示实施例中,当前执行RP先查找比自己更合适的候选RP,若未找到或未收到来自所述比自己更合适的候选RP的确认消息,则继续判断自身是否要为组播组服务;图6所示实施例中,当前执行RP先判断自身是否要为组播组服务,若要,则继续查找比自己更合适的候选RP。
必须指出的是,在实际应用中,在同一组播网络中,通过图1、2、3中任意一个所示实施例来解决连接客户机的组播路由器的执行RP失效带来的组播业务延迟,与通过图4、5、6中任意一个所示实施例来解决连接组播源的组播路由器的执行RP带来的组播业务延迟,可以同时进行,以最大限度地降低组播业务延迟。
以上所述仅为本发明的过程及方法实施例,并不用以限制本发明,凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (15)
1、一种降低组播业务延迟的方法,其特征在于,该方法包括:
组播路由器向自身当前执行汇合点RP发送组播业务请求,同时发送携带组播组地址的查询消息,若未在预定时间内收到来自当前执行RP的组播业务响应或携带组播组地址的确认消息,则重新选择新的执行RP。
2、如权利要求1所述的方法,其特征在于,所述组播路由器为连接客户机的组播路由器,所述组播业务请求为协议无关组播PIM加入请求,所述组播业务响应为请求的组播流。
3、如权利要求1所述的方法,其特征在于,所述组播路由器为连接组播源的组播路由器,所述组播业务请求为PIM源注册消息,所述组播业务响应为停止注册消息或加入消息。
4、如权利要求1所述的方法,其特征在于,所述查询消息的条数至少为1条。
5、如权利要求1所述的方法,其特征在于,所述查询消息携带的组播组地址的个数至少为1个。
6、如权利要求1所述的方法,其特征在于,所述确认消息携带的组播组地址的个数至少为1个。
7、如权利要求1所述的方法,其特征在于,所述组播路由器向当前执行RP发送查询消息之后进一步包括:当前执行RP收到查询消息后,判断自身是否要为该查询消息携带的组播组地址对应的组播组服务,若要,向组播路由器返回携带组播组地址的确认消息。
8、如权利要求7所述的方法,其特征在于,所述当前执行RP收到查询消息之后、判断自身是否要为组播组服务之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则判断自身是否要为该组播组服务。
9、如权利要求7所述的方法,其特征在于,所述当前执行RP判定自身要为该组播组服务之后、向组播路由器返回确认消息之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则向组播路由器返回确认消息。
10、如权利要求8或9所述的方法,其特征在于,所述方法进一步包括:当前执行RP收到所述更合适的候选RP返回的确认消息,向组播路由器返回拒绝消息。
11、如权利要求1所述的方法,其特征在于,所述组播路由器向当前执行RP发送查询消息之后进一步包括:当前执行RP收到查询消息后,检测到自身不要为该查询消息携带的组播组地址对应的组播组服务,向组播路由器返回携带组播组地址的拒绝消息。
12、一种降低组播业务延迟的方法,其特征在于,该方法包括:
当连接客户机的组播路由器要接收组播流时,向自身当前执行RP发送PIM加入请求,同时发送携带组播组地址的查询消息,若未在预定时间内收到来自当前执行RP的组播流或携带组播组地址的确认消息,则重新选择新的执行RP;
当连接组播源的组播路由器要发布组播流时,向自身当前执行RP发送PIM源注册消息,同时发送携带组播组地址的查询消息,若未在预定时间内收到来自当前执行RP的停止注册消息或加入消息或携带组播组地址的确认消息,则重新选择新的执行RP。
13、如权利要求12所述的方法,其特征在于,所述连接客户机的组播路由器向当前执行RP发送查询消息之后进一步包括:当前执行RP收到查询消息后,判断自身是否要为该查询消息携带的组播组地址对应的组播组服务,若要,向连接客户机的组播路由器返回携带组播组地址的确认消息;
所述连接组播源的组播路由器向当前执行RP发送查询消息之后进一步包括:当前执行RP收到查询消息后,判断自身是否要为该查询消息携带的组播组地址对应的组播组服务,若要,向连接组播源的组播路由器返回携带组播组地址的确认消息。
14、如权利要求13所述的方法,其特征在于,所述连接客户机的组播路由器向当前执行RP发送查询消息之后、判断自身是否要为组播组服务之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则判断自身是否要为该组播组服务;
所述连接组播源的组播路由器向当前执行RP发送查询消息之后、判断自身是否要为组播组服务之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则判断自身是否要为该组播组服务。
15、如权利要求13所述的方法,其特征在于,所述当前执行RP判定自身要为该组播组服务之后、向连接客户机的组播路由器返回确认消息之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则向连接客户机的组播路由器返回确认消息;
所述当前执行RP判定自身要为该组播组服务之后、向连接组播源的组播路由器返回确认消息之前,进一步包括:当前执行RP为所述组播组查找比自己更合适的候选RP,若查找到,向所述更合适的候选RP发送携带组播组地址的查询消息,若未查找到更合适的候选RP或未收到所述更合适的候选RP返回的确认消息,则向连接组播源的组播路由器返回确认消息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100650895A CN100421415C (zh) | 2006-03-16 | 2006-03-16 | 一种降低组播业务延迟的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100650895A CN100421415C (zh) | 2006-03-16 | 2006-03-16 | 一种降低组播业务延迟的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1819543A true CN1819543A (zh) | 2006-08-16 |
CN100421415C CN100421415C (zh) | 2008-09-24 |
Family
ID=36919242
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006100650895A Active CN100421415C (zh) | 2006-03-16 | 2006-03-16 | 一种降低组播业务延迟的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100421415C (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009065359A1 (fr) * | 2007-11-23 | 2009-05-28 | Huawei Technologies Co., Ltd. | Routeur d'amorçage, et procédé et système de gestion d'expiration |
CN101873658A (zh) * | 2009-04-21 | 2010-10-27 | 华为技术有限公司 | 移动组播切换的方法和设备 |
CN101232392B (zh) * | 2008-02-22 | 2011-07-13 | 中兴通讯股份有限公司 | 一种msdp和pim间通告组播源的方法 |
CN102724048A (zh) * | 2012-04-27 | 2012-10-10 | 杭州华三通信技术有限公司 | 稀疏模式协议无关组播通知汇聚点的方法和装置 |
CN113259252A (zh) * | 2020-02-13 | 2021-08-13 | 瞻博网络公司 | 使用协议无关多播加入/修剪响应控制协议无关多播加入/修剪消息 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030193958A1 (en) * | 2002-04-11 | 2003-10-16 | Vidya Narayanan | Methods for providing rendezvous point router redundancy in sparse mode multicast networks |
JP3936311B2 (ja) * | 2003-06-16 | 2007-06-27 | アンリツ株式会社 | マルチキャストネットワークの配信経路設定方法及びルータ |
CN100499635C (zh) * | 2003-08-04 | 2009-06-10 | 华为技术有限公司 | 一种提高组播pim-sm协议网络的健壮性的方法 |
-
2006
- 2006-03-16 CN CNB2006100650895A patent/CN100421415C/zh active Active
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009065359A1 (fr) * | 2007-11-23 | 2009-05-28 | Huawei Technologies Co., Ltd. | Routeur d'amorçage, et procédé et système de gestion d'expiration |
CN101232392B (zh) * | 2008-02-22 | 2011-07-13 | 中兴通讯股份有限公司 | 一种msdp和pim间通告组播源的方法 |
CN101873658A (zh) * | 2009-04-21 | 2010-10-27 | 华为技术有限公司 | 移动组播切换的方法和设备 |
CN102724048A (zh) * | 2012-04-27 | 2012-10-10 | 杭州华三通信技术有限公司 | 稀疏模式协议无关组播通知汇聚点的方法和装置 |
CN102724048B (zh) * | 2012-04-27 | 2015-02-11 | 杭州华三通信技术有限公司 | 稀疏模式协议无关组播通知汇聚点的方法和装置 |
CN113259252A (zh) * | 2020-02-13 | 2021-08-13 | 瞻博网络公司 | 使用协议无关多播加入/修剪响应控制协议无关多播加入/修剪消息 |
CN113259252B (zh) * | 2020-02-13 | 2022-05-27 | 瞻博网络公司 | 使用协议无关多播加入/修剪响应控制协议无关多播加入/修剪消息的方法、系统和计算机可读非瞬态存储设备 |
Also Published As
Publication number | Publication date |
---|---|
CN100421415C (zh) | 2008-09-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1878118A (zh) | 一种实现数据通讯的系统及其方法 | |
CN1638353A (zh) | 网络拓扑构成方法及节点 | |
CN1921457A (zh) | 一种网络设备和基于多核处理器的报文转发方法 | |
CN1816011A (zh) | 数据传输装置、多播系统和程序 | |
CN1777149A (zh) | 在三层交换机上实现组播转发的方法 | |
CN101030943A (zh) | 一种发送报文的方法和路由器 | |
CN101030869A (zh) | 网络资源下载方法和装置 | |
CN1794707A (zh) | 即时消息系统间的搜索方法和互连服务器 | |
CN1925493A (zh) | 一种arp报文处理方法及装置 | |
CN101030896A (zh) | 网络系统及通信量信息汇集装置 | |
CN1929472A (zh) | 数据网络中管理数据传输的方法、系统、信号及介质 | |
CN1694379A (zh) | 移动通信系统和mbms服务相关信息传送方法 | |
CN1433197A (zh) | 单址通信到多址通信转换装置、方法和程序以及监视系统 | |
CN1756429A (zh) | 多媒体广播/组播业务中小区信息变化的通知方法 | |
CN1866863A (zh) | 一种网络设备的邻居发现方法及系统 | |
CN1819543A (zh) | 一种降低组播业务延迟的方法 | |
CN1845527A (zh) | 在微波接入全球互通系统中提供组播业务的方法及系统 | |
CN101075879A (zh) | 一种数据下载方法 | |
CN1946064A (zh) | 报文转发方法及设备 | |
CN101051920A (zh) | 一种组播业务的实现方法和网络设备 | |
CN1588927A (zh) | 一种大规模多媒体接入网关的方法 | |
CN101047649A (zh) | 一种转发数据流的方法和设备 | |
CN101043464A (zh) | 解决标签冲突的方法和系统 | |
CN1889477A (zh) | 一种提高组播点播成功率的方法及协议无关组播路由器 | |
CN1794721A (zh) | 一种在指定时间下载媒体对象的方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CP03 | Change of name, title or address | ||
CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: Huasan Communication Technology Co., Ltd. |