CN104380671A - 在分级、冗余、多播路由选择中增加失效覆盖 - Google Patents
在分级、冗余、多播路由选择中增加失效覆盖 Download PDFInfo
- Publication number
- CN104380671A CN104380671A CN201380028766.4A CN201380028766A CN104380671A CN 104380671 A CN104380671 A CN 104380671A CN 201380028766 A CN201380028766 A CN 201380028766A CN 104380671 A CN104380671 A CN 104380671A
- Authority
- CN
- China
- Prior art keywords
- node
- downstream
- network node
- iif
- dfnp
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/16—Multipoint routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/22—Alternate routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
- H04L45/247—Multipath using M:N active or standby paths
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/48—Routing tree calculation
- H04L45/484—Routing tree calculation using multiple routing trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/18—Loop-free operations
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
一种增强快速重新路由机制向多播通信网络提供增大的失效覆盖。如果网络节点检测到失效,并且确定它不能重新路由多播数据,则网络节点在网络中发送下游快速通知分组(DFNP)。DFNP促使下游合并节点将多播数据的接收交换到其次要路径。网络节点随后接收来自合并节点的上游快速通知分组(UFNP)。网络节点在接收UFNP时修改其转发信息,使得网络节点将从接收UFNP经过的其下游接收多播数据。DFNP和UFNP促使多播数据在网络节点与合并节点之间反转其流向。
Description
相关申请交叉引用
本申请涉及题为“通过下游通知分组的PIM快速重新路由的增强”(ENHANCEMENTS TO PIM FAST RE-ROUTE WITH DOWNSTREAM NOTIFICATION PACKETS)(代理人案号4906P36947US1)的申请和题为“通过上游通知分组的PIM快速重新路由的增强”(ENHANCEMENTS TO PIM FAST RE-ROUTE WITH UPSTREAM ACTIVATION PACKETS)(代理人案号4906P37637US1)的申请,两个申请均在2012年6月1日提出。
技术领域
本发明的实施例涉及网络操作领域,并且更具体地说,涉及多播通信网络中的路由选择操作。
背景技术
协议独立多播稀疏模式(PIM-SM)(参阅2006年8月的IETF RFC4601)是用于在因特网协议(IP)多播通信网络中构建和保持多播树的熟知和普遍采用的协议。为将多播内容分发到多播通信网络的接收方节点(以下也称为“目的地”),PIM-SIM使用单个多播树。单个多播树缺乏在网络失效的情况下用于重新路由多播业务的冗余性。
PIM-SM现在通常用于为实时业务(例如,为因特网协议TV (IPTV))构建多播路径。然而,由于PIM-SM极其依赖单播路由选择,因此,在网络失效的情况下,多播恢复需要等待,直至单播路由选择已恢复。因此,对于PIM-SIM的失效反应相对慢,并且因此对实时应用是严重的缺陷。为克服此缺陷,2010年1月的IETF RFC5714提议为网络节点的进入多播流使用次要路径的因特网协议(IP)快速重新路由机制,由此在网络节点失去其与其主要上游邻居节点的连接的情况下,提供中间备选路径。然而,提议的方案未提供有效的失效检测技术,并且不能处理所有可能失效情形。
发明内容
一种增强快速重新路由机制向多播通信网络提供增大的失效覆盖。多播通信网络包括多播树以提供从共同来源节点到一个或更多个多播接收方节点的连接性。多播通信网络也包括一组次要路径以提供冗余性到多播树。
在一个实施例中,在网络节点检测到在引导到其上游邻居的进入接口的连接丢失时,它确定它是否能够重新路由多播数据业务。如果网络节点确定它不能执行重新路由,它便在网络中向下游发送下游快速通知分组(DFNP)。DFNP促使下游合并节点将多播数据业务的接收交换到引导到共同来源节点的其次要路径。网络节点随后接收来自合并节点的上游快速通知分组(UFNP)。网络节点在接收UFNP时修改其转发信息,使得网络节点将从接收UFNP经过的网络节点的下游邻居接收多播数据业务。
在另一实施例中,网络节点包括存储器和一个或更多个处理器,存储器配置成存储用于多播数据业务的转发信息,处理器配置成在到上游邻居的进入接口检测到连接的丢失,并且确定网络节点是否能够重新路由多播数据业务,使得多播数据业务能够到达多播接收方节点。网络节点也包括下游模块和传送器电路,下游模块配置成响应网络节点不能重新路由多播数据业务的确定,发起DFNP,并且传送器电路配置成往下游向多播接收方节点发送DFNP。DFNP促使下游合并节点将多播数据业务的接收交换到引导到共同来源节点的次要路径。网络节点也包括接收器电路和上游模块,接收器电路配置成接收来自下游合并节点的UFNP,并且上游模块配置成在接收UFNP时修改转发信息,使得网络节点将从接收UFNP经过的下游邻居接收多播数据业务。
在一个实施例中,UFNP和DFNP促使多播数据业务在网络节点与下游合并节点之间反转流向以便由此重新路由多播数据业务。
附图说明
本发明通过示例方式而不是限制的方式在附图的图形中示出,图中相似的标号表示类似的元素。应注意的是,在此公开内容中对“一”或“一个”实施例的不同引用不一定为相同的实施例,并且此类引用至少表示一个。此外,在结合实某个施例描述某个特定特征、结构或特性时,无论是否明确描述,认为结合其它实施例来实现此类特征、结构或特性是在本领域技术人员的认知之内。
图1A和1B示出多播通信网络的示例。
图2A和2B示出带有由MoFRR提供的冗余次要路径的多播树的示例。
图3A示出在多播通信网络中的简化网络段。
图3B示出根据MoFRR的转发表的示例。
图3C示出在一个实施例中根据增强MoFRR的转发表的示例。
图4是示出根据一个实施例,在准备阶段期间用于设置接口的方法的流程图。
图5是示出根据一个实施例,用于操作失效检测节点的方法的流程图。
图6是示出根据一个实施例,用于操作在失效检测节点与合并节点之间的中间节点的方法的流程图。
图7A和7B是根据本发明的一个实施例的网络节点的图形。
具体实施方式
在下面的描述中,陈述了许多特定细节。然而,要理解的是,实践本发明的实施例可无需这些特定细节。在其它情况下,公知的电路、结构和技术未详细显示以免混淆对此描述的理解。然而,本领域的技术人员将领会到,可无需此类特定细节而实践本发明。通过包括的描述,本领域技术人员将能够在不进行过度实验的情况下实现适当的功能性。
本发明的实施例通过允许多播业务在失效检测节点与合并节点之间反转其方向,增大MoFRR的失效覆盖。
在描述本发明的实施例之前,了解网络节点根据PIM-SIM如何加入多播群组是有益的。在PIM-SM中,网络节点使用单播转发消息以加入或离开多播群组。为加入多播群组,网络节点在多播树的上游方向将JOIN(加入)消息发送到共同来源节点(术语“共同来源节点”在下文指在共享树的情况下的多播来源节点或会合点)。沿由多播路由选择信息库(MRIB)表确定的多播树的路径路由JOIN消息。这些表中列出的路径通常直接从单播路由选择表推导,但它们也能够以不同方式推导。类似地,要离开多播群组的网络节点将PRUNE(剪除)分组沿多播树向上发送到共同来源网络节点。
MRIB表用于确定JOIN消息随后发送到的下一跳邻居。在逐跳的基础上路由和处理JOIN消息,直至到达已经接收多播内容的网络节点。沿此逐跳路径的所有网络节点处理JOIN消息,并且例如通过将接收JOIN消息经过的进入接口添加到多播的外出接口列表,安装或更新对应多播路由选择状态信息。例如,如果节点X经到节点Y的进入接口接收JOIN消息,则节点X将节点Y添加到用于多播的外出接口列表。在与收到JOIN消息的方向相反的方向上,将多播内容路由到网络节点。
仅多播快速重新路由(MoFRR)是IP快速重新路由机制,其中,网络节点经不止一个路径加入多播群组。加入多播群组涉及在主要路径上从节点向来源传送JOIN消息,并且在次要路径上从节点向来源传送另一JOIN消息。如果双加入节点失去其在主要路径上的连接,则节点具有它能够交换到的即时可用的次要路径。
根据MoFRR,每个双加入节点具有在主要路径上的主要上游多播跳(UMH)和在次要路径上的次要UMH。每个UMH是在朝向多播入口节点(MCI)的路径上在节点上游的节点的前一跳邻居。MCI是多播流从中进入当前传输技术(例如,PIM)域的节点,并且因此MCI能够被视为是用于当前域的多播来源。在本文中的描述中,术语“MCI”与多播来源节点同义使用。要理解的是,本发明的实施例适用于MCI与通常的多播来源节点不同的情形;例如MCI接收来自位于不同传输技术域中的多播来源节点的多播数据时。
根据MoFRR,能够从候选节点列表(即,前一跳上游节点)中选择双加入节点的(J)次要UMH,这些候选节点源自在朝向MCI的路径上节点J的等价多路径(ECMP)或无环路备选(LFA)邻居。如果从节点J能够以节点J到达主要UMH的成本相同的成本到达节点N,则节点N是节点J的ECMP邻居。如果满足在RFC 5289(2008年9月)指定的LFA准则或draft-karan-mofrr-02(2012年3月)中所述用于MoFRR的非ECMP模式条件之一,则节点N是节点J的LFA邻居。
MoFRR实现实时-实时多播保护技术,其中,双加入节点接收来自主要和次要两个路径的相同多播流。为防止重复分组转发到最终用户,双加入节点在实时-实时保护模式中操作的网络中一次只接收来自UMH之一的分组。优选哪个UMH是能够基于内部网关协议(IGP)可达性、链路状态、双向转发检测(BFD)、业务流等的本地判定。在网络中未检测到失效时,能够通过阻塞到较不优选UMH的进入接口来防止重复分组的接收;即,不在多播树上转发从此进入接口收到的分组。然而,如果优选UMH失效,则能够解除阻塞到更不优选UMH的进入接口以允许业务继续到下游。
在本文中的描述中,术语“上游”指沿路径朝向MCI的方向,并且术语“下游”指沿路径离开MCI的方向。此外,“邻居节点”是离当前节点一跳的节点。“前一节点”是当前节点的上游邻居节点,并且“下一跳”是当前节点的下游邻居节点。“分支节点”是耦合到往下游的不止一个路径的节点;“合并节点”是耦合到来自上游的不止一个路径的节点。
另外,术语“链路”、“接口”或“邻居”能够表示“物理”或“虚拟”链路、接口或邻居。“物理”链路指在两个节点之间的直接连接。物理接口或邻居指经物理链路耦合到另一接口/节点的接口/节点。“虚拟”链路能够是在两个节点之间的更低层隧道或复杂网络。虚拟接口/节点指经虚拟链路耦合到另一接口/节点的接口/节点。例如,经复杂以太网网络连接的两个IP路由器是在IP级别的“虚拟邻居”。
本文中描述了提供基于PIM-SIM的快速重新路由和增大的失效覆盖的增强MoFRR。通过在网络节点检测到失效时使用在网络节点的数据平面中生成和处理的下游快速通知分组(DFNP),改进了失效反应的速度。DFNP的使用改进了对非本地失效(即,远程失效,或等效地,在不止一跳外的节点或链路已发生的失效)反应的速度和可靠性。通过提供失效覆盖到不具有次要UMH的节点,增大了失效覆盖。下面将详细描述增强MoFRR。
图1A示出包括多个网络节点(“节点”)的多播通信网络12。多播通信网络12是运营商的网络。共同来源节点例如(节点S 11)经多播树拓扑将多播数据发送到其多播群组的成员。共同来源节点可以是MCI或多播群组的分支节点。也称为多播出口节点(MCE)的多播接收方节点(例如,节点R 14)是耦合到多播的订户的节点,或耦合到有多播的订户的相邻域的域出口节点。多播树的叶节点一般是MCE。在多播树的共同来源节点与叶节点之间是多个内部节点(例如,节点N 13)。多播数据从共同来源节点经内部节点向下游流到叶节点。在一个实施例中,一个或更多个内部节点也可以是MCE。
图1B是示出MoFRR提供的不足失效覆盖的问题的一段多播通信网络100的示例。假设节点S是共同来源节点,并且节点M是网络段中的合并节点。从节点S到节点M,有两个备选路径:一个是主要路径S→F→N1→N2→M,并且另一个是次要路径S→F→N3→N4→M。节点N1和N2可具有订户,节点M也可具有订户。根据MoFRR,如果节点F失效,则节点M能够将多播接收交换到次要路径。然而,节点N1和N2将在该失效的情况下不能接收多播,这是因为它们未连接到次要路径。
如上解释的一样,MoFRR网络不提供完全失效覆盖,这是因为网络中的一些节点可能未连接到次要路径。本发明的实施例通过使用在主要路径上失效处下游的节点提供冗余路径,增大了MoFRR的失效覆盖。在图1B的示例中,通过反转在节点N1(失效处的下一跳)与节点M(具有工作次要路径的节点)之间的多播数据业务,能够提供用于节点N1和N2的冗余路径(由虚线指示)。节点M将经节点N3和N4接收来自次要路径的多播。因此,所有节点M、N1和N2能够像在节点F的失效前一样继续接收多播。
图2A示出支持MoFRR的多播通信网络的示例。连接MCI→A→B→C→D→E和MCI→F→G的细线形成由PIM-SM定义的多播树。连接A→J→C, C→K→E和G→H→I→D的粗线表示通过MoFRR分别为节点C、E和D添加的次要路径。因此,节点C、D和E是双加入节点。从MCI开始的节点C的主要路径是MCI→A→B→C,并且其次要路径是MCI→A→J→C。因此,节点C的主要UMH是节点B,并且次要UMH是节点J。节点B具有作为其主要UMH的节点A,但没有次要UMH。
图2B示出与网络200具有相同配置但带有失效的节点A的多播通信网络210的示例。根据MoFRR的规则,每个节点B、C、J和K没有能够防止节点A的失效的工作次要路径。增强MoFRR的一实施例以快速预计算的方式重新建立到没有工作次要路径的多播流。在带有A的失效的上述示例中,节点D能够切换到次要UMH(即,节点I)。节点C能够交换到节点D,并且节点B和J能够交换到节点C。节点K将接收来自节点C的DFNP,并且将转发它到节点E(因为节点K没有次要路径)。然而,节点E将只接收来自节点K的DFNP,这是因为节点D(具有工作次要UMH)未将DFNP转发到节点E。因此,节点E将只接收来自其次要UMH的DFNP,并且将不对其做出反应。因此,多播数据业务流在节点B与节点D之间以及在节点J与节点D之间被反转,其中,节点B和J是失效处的下一跳,并且节点D是具有工作次要路径的节点。
在描述如图2B的示例中一样在失效情况下反转业务流的增强MoFRR前,先解释失效检测技术。失效检测使用下游快速通知分组(DFNP)通知失效处下游的节点失效的发生以及上游节点不能修复失效。
在一个实施例中,节点检测到本地失效(可由其UMH或连接到UMH的链路的失效造成)时,节点向连接到多播群组中下游节点的所有下游分支发起DFNP。在一个实施例中,下游分支包括在多播群组中在主要路径和次要路径上的所有链路。DFNP发起节点是失效检测节,它没有它能够回退到的无失效次要路径。如果失效检测节点具有可用次要路径,则它能够使用次要路径接收多播数据,并且DFNP不会生成。生成DFNP时,具有可用次要路径的下游节点能够由DFNP触发以进行到次要路径的切换。
DFNP能够仅使用在数据平面中可用的转发信息在数据平面中生成,而无需来自控制平面的输入。在收到DFNP时,也能够在数据平面中处理它们。在网络失效发生前,用于发送和接收DFNP所需的所有信息在数据平面中已可用。仅数据平面方案大幅降低了失效发生时的反应时间。在一个实施例中,DFNP的发起和处理能够在数据平面中的一个或更多个线路卡内执行;到控制平面的更新(例如,路由选择表)能够稍后执行而不影响实时失效恢复。
如果在非本地上游位置中发生失效,则双加入节点需要快速、可靠的机制检测上游失效。对于基于MoFRR的实施例,双加入节点也需要了解其它上游节点不能规避失效。基于业务监视的其它方法在范围方面受到限制,并且对稳态分组流工作效果最佳。例如,如果在网络中有持续的大量多播业务,则业务流的中断能够用作的失效的指示。相反,DFNP与分组流的状态无关。DFNP是非本地失效的指示符,并且能够触发次要备用路径的解除阻塞。
在下述内容中,提供了有关DFNP发起节点下游的每个节点遵守的规则(R1-R4)的描述。在一个实施例中,规则可存储在每个节点(如下面在图7A和7B中描述的网络节点)的数据平面电路中。
(R1)如果节点从其主要UMH接收DFNP,并且具有无失效次要路径(例如,未从其次要UMH接收DFNP,或者在到次要UMH的连接未检测到失效),则节点是修复节点。在接收DFNP时,此修复节点要解除阻塞到其次要UMH的次要路径。修复节点不进一步向下游转发DFNP。
(R2) 如果节点从其主要UMH接收DFNP,但没有次要UMH,则节点不是修复节点。在接收DFNP时,此节点要将DFNP转发到所有其下游节点。对于基于MoFRR的实施例,下游节点包括在主要和次要路径更远下游的分支上的所有节点。
(R3)如果节点接收两个DFNP - 一个来自其主要UMH,并且另一个来自其次要UMH,则此节点也不是修复节点。接收来自相应UMH的两个DFNP是其主要路径和次要路径均有故障的指示。在接收两个DFNP时,节点要将DFNP之一转发到所有下游节点(如在R2中一样)。另一DFNP能够被丢弃(等效于“不转发”)。在某种情形中,节点在接收来自其主要路径的DFNP时,能够等待预确定的时间量以了解它是否将接收来自其次要路径的另一DFNP。如果收到来自次要路径的另一DFNP,则节点无需解除阻塞次要路径,这是因为解除阻塞不能纠正失效。在另一情形中,节点在接收来自其主要路径的DFNP时能够立即解除阻塞其次要路径,并且丢弃收到的DFNP。如果节点随后未收到多播数据业务,而是接收来自次要UMH的另一DFNP,则节点将此另一DFNP转发到所有其下游节点。
(R4)仅从节点的次要UMH收到的DFNP将被丢弃。
是否转发DFNP的判定能够概括如下。如果节点只接收来自其次要路径的DFNP,或者如果节点接收来自其主要路径的DFNP,并且其次要路径可能在工作(例如,次要UMH的“停止运行状态”尚未通过本地检测或从次要UMH收到的DFNP得到确认),则节点不进一步向下游转发DFNP。如果节点接收来自其主要路径的DFNP,并且不存在用于节点的次要路径,或者如果节点接收来自其主要路径和次要路径之一的DFNP,并且以前从其主要路径和次要路径的另一路径收到另一DFNP,则节点进一步向下游转发DFNP。
图2A的示例能够用于示出上述规则的应用。如果节点A失效,则节点B和J将均在本地检测到失效(例如,在其相应进入接口),并且每个节点发起DFNP。两个DFNP均往下游向节点C发送。节点C由于将从其主要UMH(节点B)和其次要UMH(节点J)接收两个DFNP,因此,它不是修复节点。由于节点C不是修复节点,因此,它将向K和D转发DFNP这定(观察规则R3)。节点K没有用于多播树的次要UMH,因此,它将往下游向节点E发送DFNP(观察规则R2)。节点D具有工作次要UMH(节点I),因此,节点D是修复节点(应用规则R1)。节点E应用规则R4。因此,位于节点D和E或其下游的订户将继续接收多播业务。
DFNP允许失效处下游的节点明确识别受失效影响的多播树。在一个实施例中,DFNP包括识别多播群组或多播树的多播来源地址和多播群组地址(例如,在IP来源/目的地地址字段中)。
DFNP易于由接收方节点识别。在一个实施例中,特殊IP协议值(例如,在IP报头中)或特殊分配的用户数据报协议(UDP)端口号能够用于区分DFNP和多播流中的常规数据分组。如果使用特殊UDP端口号,则IP协议字段可设置成易于识别的值,如对应于PIM的“103”。在用于故障排除目的的一些实施例中,有效负载可包含发起DFNP的节点的ID,并且也可包含至其连接性丢失的节点的ID和/或在其上的连接性丢失的链路ID。在一些实施例中,DFNP也可包括指示其发起的时间的时间戳。
为允许如图1B和2B中所述的多播流的反转,每个网络节点配置成执行在三个阶段中的操作:准备阶段、第一失效反应阶段和第二失效反应阶段。在准备阶段中,每个网络节点准备其进入接口(IIF)和外出接口(OIF),使得它能够对失效快速反应。在一个实施例中,IIF和OIF安装在网络节点的数据平面卡(即,线路卡)中的转发信息库(FIB)或转发表中。
在第一失效反应阶段中,从检测到其UMH的失效的节点向下游发送DFNP。节点接收DFNP时,它解除阻塞在上游方向的其OIF。在第二失效反应阶段中,具有工作次要UMH的节点(即,如上述规则R1-R4定义的修复节点)在其主要路径上沿所有上游分支向MCI发送上游快速通知分组(UFNP)。节点接收UFNP时,它解除阻塞到下游节点的其进入接口。
下面进一步详细解释了三个阶段的操作。图3A-3C示出由图3A的网络段300中节点M执行的准备阶段的示例。节点M具有主要UMH U1和次要UMH U2。节点M也具有两个下游节点D1和D2。根据如图3B所示的MoFRR,节点M存储包括原IIF列表321:U1和(U2)和原OIF列表322:D1和D2,其中,包围接口的一对括号指示接口被阻塞。根据如图3C所示带有增大失效覆盖的增强MoFRR的一实施例,节点M存储转发表306,转发表306包含扩展IIF列表361:U1、(U2)、(D1)和(D2)和扩展OIF列表362:(U1)、(U2)、D1和D2。
参照图2A的节点C,节点C安装根据PIM引导到节点B的IIF和引导到节点D和K的两个OIF(在表2中示出)。根据MoFRR,节点C也安装引导到阻塞状态中的节点J的额外IIF,这是因为节点J是朝向用于节点C的MIC的次要UMH。节点C接收来自节点B和J的相同业务,但来自节点J的业务被丢弃。
根据增强MoFRR的一个实施例,节点C将朝向B的其接口安装为被阻塞OIF及IIF。节点C也将到节点D和K的其接口安装为被阻塞IIF及OIF。表1-3提供示出能够如何从MCI为多播树安装接口的示例。括号中的接口被阻塞。
节点B | PIM | MoFRR | 增强MoFRR |
进入接口 | A | - | A,(C) |
外出接口 | C | - | (A),C |
表1:失效前节点B的接口
节点C | PIM | MoFRR | 增强MoFRR |
进入接口 | B | (J) | B,(J),(D),(K) |
外出接口 | D,K | - | (B),(J),D,K |
表2:失效前节点C的接口
节点D | PIM | MoFRR | 增强MoFRR |
进入接口 | C | (I) | C,(I),(E) |
外出接口 | E | - | (C),(I),E |
表3:失效前节点D的接口
图4是示出用于在多播通信网络的每个节点中安装接口的方法400的流程图。方法400以每个网络节点扩展原IIF列表以形成包括网络节点的所有原IIF和所有原OIF的IIF的扩展列表(框410)开始。“原IIF”和“原OIF”表示根据MoFRR安装的接口。每个网络节点随后扩展在转发表中的原OIF列表以形成包括网络节点的所有原IIF和所有原OIF的OIF的扩展列表(框420)。随后,除引导到其主要UMH的原IIF外,每个网络节点将IIF的扩展列表中的所有IIF标记为阻塞(框430)。每个网络节点也将OIF的扩展列表中的所有原IIF标记为阻塞(框440)。
由于增强MoFRR的所有额外接口安装在阻塞状态中,因此,在网络中无失效时,多播数据业务同样流到与PIM建立的多播树。网络中发生失效时,网络的操作进入第一失效反应阶段,在该阶段期间,在多播树中激活备用路径。
节点检测到至其UMH的失效时,如果它没有可回退到的工作次要路径,则它发起DFNP。接收DFNP的下游节点根据上述规则R1-R4并通过如下所述另外的操作处理DNFP。
下游节点接收来自UMH的DFNP时,它是无上游节点能够修复失效的指示。因此,下游节点在其扩展OIF列表中发现UMH接口,并且解除阻塞该接口。
如果此下游节点具有无失效次要路径(即,它未接收来自次要UMH的DFNP,或者未检测到来自次要UMH的失效),则下游节点解除阻塞扩展IIF列表中的其次要UMH并且阻塞其主要UMH。解除阻塞次要UMH允许下游节点接收多播数据业务。在一个实施例中,此下游节点是合并节点。
DFNP到达其合并节点时,网络的操作进入第二失效反应阶段,在该阶段期间,修改多播树,从而将从此工作次要UMH收到的数据业务发送到收到DFNP的方向。
在第二失效反应阶段期间,合并节点发送上游快速通知分组(UFNP),UFNP是在数据平面中生成和处理的通知。沿在上游方向包括主要路径和次要路径的所有路径向MCI发送UFNP。类似于DFNP,UFNP明确识别受失效影响的多播树。在一个实施例中,UFNP包括识别多播群组或多播树的多播来源地址和多播群组地址(例如,在IP来源/目的地地址字段中)。通过包括特殊IP协议值(例如,在IP报头中)或者特殊分配的用户数据报协议(UDP)端口号,如对应于PIM的“103”,可轻松识别UFNP。在用于故障排除目的的一些实施例中,有效负载可包含发起UFNP的节点的ID,并且也可包含至其连接性丢失的节点的ID和/或在其上的连接性丢失的链路ID。在一些实施例中,UFNP也可包括指示其发起的时间的时间戳。
接收UFNP的任何节点解除阻塞在其扩展IIF列表中收到的UFNP来自的接口,并且阻塞扩展OIF列表中的相同接口。要注意的是,可从多个下游分支收到UFNP,但仅将扩展IIF列表中用于为该多播群组收到的第一UFNP的接口解除阻塞。其它UFNP被丢弃。将UFNP沿上游向上发送到发起DFNP的点。
参照节点A发生失效时的示例图2B,第一DFNP由节点B发起,并且沿下游发送到节点C;第二DFNP由节点J发起并且沿下游发送到节点C。
节点C接收DFNP时,它解除阻塞扩展OIF列表中引导到节点B的接口,并且将DFNP之一进一步向下游发送到节点D和K。不转发其它DFNP。节点D接收DFNP时,它解除阻塞在其扩展OIF列表中引导到节点C的接口。节点D具有工作次要UMH,因此,它解除阻塞到次要UMH的其进入接口,生成UFNP,并且将UFNP向上游发送到节点C。
节点C接收UFNP时,它解除阻塞在扩展IIF列表中引导到节点D的接口,阻塞在其扩展OIF列表中相同的接口,并且将UFNP向上游转发到节点B。节点B接收UFNP时,它解除阻塞在其扩展IIF列表中引导到节点C的接口,阻塞在其扩展OIF列表中相同的接口,并且由于节点B发起了DFNP,因此,它丢弃UFNP。
下面在表4-6中示出用于节点B、C和D的结果修改的多播转发条目。括号中的接口被阻塞。
节点B | 失效前 | 失效后 |
进入接口 | A,(C) | (A),C |
外出接口 | (A),C | (A),(C) |
表4:根据增强MoFRR在失效前和失效后的节点B
节点C | 失效前 | 失效后 |
进入接口 | B,(J),(D),(K) | (B),(J),D,(K) |
外出接口 | (B),(J),D,K | B,J,(D),K |
表5:根据增强MoFRR在失效前和失效后的节点C
节点D | 失效前 | 失效后 |
进入接口 | C,(I),(E) | (C),I,(E) |
外出接口 | (C),(I),E | C,(I),(E) |
表6:根据增强MoFRR在失效前和失效后的节点D
如从上述示例中能够看到的一样,通过增强MoFRR,节点B、C、J和K能够接收多播数据流,这在使用常规MoFRR时是不可能的。如果节点B、C、J和K具有在其下游更远的节点(图2B中未示出),则根据本发明的实施例,这些下游节点也能够继续接收多播数据业务。
图5是示出根据本发明的一个实施例,用于在多播通信网络中操作网络节点的方法500的流程图。在此实施例中的网络节点是失效检测节点。方法500以网络节点在其到UMH的进入接口检测连接的丢失开始(框510)。网络节点确定它是否能够重新路由多播数据业务以允许多播数据业务由多播接收方节点接收。如果确定网络节点不能执行重新路由(框520),则网络节点往下游向多播接收方节点发送DFNP(框530)。DFNP促使下游合并节点将多播数据分组的接收交换到引导到共同来源节点的其次要路径,并且将多播数据业务转发到收到的DFNP经过的其上游邻居。随后,网络节点接收来自合并节点的UFNP(框540)。在接收UFNP时,网络节点修改其转发信息(框550),使得网络节点能够从接收UFNP经过的其下游邻居接收多播数据业务。DFNP和UFNP促使多播数据业务在网络节点与下游合并节点之间反转流向以便由此重新路由多播数据业务。
图6是示出根据本发明的一个实施例,用于在多播通信网络中操作网络节点的方法600的流程图。在此实施例中的网络节点是在失效检测节点与合并节点之间的中间节点。方法600以中间节点接收DFNP开始(框610)。中间节点解除阻塞其扩展OIF列表中的一个或更多个OIF以允许多播数据业务流入中间节点的一个或更多个上游邻居(框620)。中间节点也阻塞其扩展OIF列表中当前通畅的OIF(框630)。中间节点接收UFNP(框640)时,它解除阻塞其扩展IIF列表中引导到从其接收UFNP的下游邻居的IIF(框650)。中间节点也阻塞其扩展IIF列表中当前通畅的IIF(框660)。
图7A示出可用于实现本发明的实施例的网络节点700的示例。如图7A所示,网络节点700包括数据平面,数据平面又包括交换结构730、多个线路卡750和多个I/O端口780。每个线路卡750包括线路卡处理器751以在通过I/O端口780收到的数据上执行功能。如图7B所示,线路卡处理器751的一实施例包括上游模块711和下游模块712。上游模块711配置成在接收UFNP时修改转发信息,使得网络节点能够从接收UFNP经过的下游邻居接收多播数据业务。下游模块712配置成响应网络节点不能重新路由多播数据业务的确定,发起DFNP。数据平面也包括线路卡存储器753,该存储器存储用于网络节点700是其成员的每个多播群组的转发表。转发表存储转发信息以便跟踪网络节点的上游邻居(例如,UMH)、下游邻居、这些邻居的IIF和OIF。交换结构730在线路卡750之间交换数据。
数据平面也包括接收器电路740和传送器电路760。接收器电路740和传送器电路760配置成分别接收和发送包括上述UFNP和DFNP的多播数据和控制分组。
网络节点700也包括控制平面。控制平面还包括一个或更多个节点处理器710,节点处理器包含配置成处理网络业务的路由选择和管理的控制逻辑。控制平面也包括存储器720,除其它之外,存储器还存储一个或更多个路由选择表721以保持网络的路由选择信息。要理解的是,网络节点700可包括与上述不同的另外组件和信息。
图4-6的操作已参照图7A和7B的示范实施例描述。然而,应理解,图4-6的操作能根据参照图7A和图7B讨论的实施例外的本发明的其它实施例执行,并且参照图7A和图7B讨论的实施例能执行与参照图4-6讨论的那些操作不同的操作。虽然图4-6示出本发明的某些实施例执行的操作的特定顺序,但应理解,此类顺序是示范(例如,备选实施例可以不同的顺序执行操作,组合某些操作,重叠某些操作等)。
本发明的不同实施例可使用软件、固件和/或硬件的不同组合实现。因此,所述图中所示技术可使用一个或更多个电子装置(例如,终端站、网络元件)上存储和执行的代码和/或数据来实现。此类电子装置使用计算机可读介质存储和传递(在内部和/或通过网络与其它电子装置)代码和数据,计算机可读介质如非短暂性计算机可读存储介质(例如,磁盘、光盘、随机存取存储器、只读存储器、闪存装置、相变存储器)和短暂性计算机可读传送介质(例如,电、光、声或其它形式传播信号 - 如载波、红外信号、数字信号)。另外,此类电子装置一般情况下包括耦合到诸如一个或更多个存储装置(非短暂性机器可读存储介质)、用户输入/输出装置(例如,键盘、触摸屏和/或显示器)和网络连接等一个或更多个其它组件的一个或更多个处理器的集合。处理器的集合与其它组件的耦合一般情况下是通过一个或更多个总线和桥接器(也称为总线控制器)。因此,给定电子装置的存储装置一般情况下存储代码和/或数据以便在该电子装置的一个或更多个处理器的集合上执行。
在本文中使用时,网络元件(例如,路由器、交换机、桥接器、控制器)是一件连网设备,包括硬件和软件,其在通信上与网络上的其它设备(例如,其它网络元件、终端站)互连。一些网络元件是“多服务网络元件”,其为多个连网功能(例如,路由选择、桥接、交换、第2层聚合、会话边界控制、服务质量和/或订户管理)提供支持和/或为多个应用服务(例如,数据、话音和视频)提供支持。订户终端站(例如,服务器、工作站、膝上型计算机、上网本、掌上型计算机、移动电话、智能电话、多媒体电话、因特网协议话音(VOIP)电话、用户设备、终端、便携式媒体播放器、GPS单元、游戏系统、机顶盒(STB))访问通过因特网提供的内容/服务和/或在因特网上重叠(例如,隧穿)的虚拟专用网(VPN)上提供的内容/服务。内容和/或服务一般由属于参与对等服务的服务或内容提供商或终端站的一个或更多个终端站(例如,服务器终端站)提供,并且可例如包括公共网页(例如,免费内容、店面、搜索服务)、私人网页(例如,提供电子邮件服务的用户名/密码访问网页)和/或通过VPN的企业网络等。一般情况下,订户终端站耦合(例如,通过(以有线或无线方式)耦合到接入网络的客户场所设备)到边缘网络元件,所述边缘网络元件(例如通过一个或更多个核心网络元件)耦合到其它边缘网络元件,所述其它边缘网络元件耦合到其它终端站(例如,服务器终端站)。
虽然本发明已根据几个实施例描述,但本领域的技术人员将认识到本发明不限于所述实施例,通过在随附权利要求书的精神和范围内的修改和变化,能够实践本发明。描述因此要视为是说明性的而不是限制。
Claims (20)
1. 一种由多播通信网络中的网络节点执行的方法,所述多播通信网络包括多播树以提供从共同来源节点到一个或更多个多播接收方节点的连接性,所述多播通信网络还包括一组次要路径以提供冗余性给所述多播树,所述方法包括以下步骤:
由所述网络节点在到上游邻居的进入接口检测连接的丢失;
确定所述网络节点不能重新路由所述多播数据业务以允许所述多播数据业务到达所述多播接收方节点;
从所述网络节点往下游向所述多播接收方节点发送下游快速通知分组(DFNP),其中所述DFNP促使下游合并节点将所述多播数据业务的接收交换到引导到所述共同来源节点的次要路径;
由所述网络节点接收来自下游合并节点的上游快速通知分组(UFNP);以及
在接收所述UFNP时修改所述网络节点的转发信息,使得所述网络节点将从接收所述UFNP经过的所述网络节点的下游邻居接收所述多播数据业务,其中所述DFNP和所述UFNP促使所述多播数据业务在所述网络节点与所述下游合并节点之间反转流向以便由此重新路由所述多播数据业务。
2. 如权利要求1所述的方法,其中所述下游合并节点耦合到在到所述共同来源节点的主要路径上的主要上游多播跳(UMH)和在到所述共同来源节点的所述次要路径上的次要UMH,所述方法还包括基于等价多路径(ECMP)或无环路备选(LFA)选择所述第二UMH的所述步骤。
3. 如权利要求1所述的方法,其中网络节点包括在存储器中记录所述网络节点的原外出接口(OIF)列表和原进入接口(IIF)列表的转发表,以及其中在检测的所述步骤之前,所述方法还包括以下步骤:
扩展所述转发表中所述原IIF列表以形成包括所有所述原IIF和所有所述原OIF的IIF的扩展列表;
扩展所述转发表中所述原OIF列表以形成包括所有所述原IIF和所有所述原OIF的OIF的扩展列表;
除引导到所述网络节点的所述主要上游邻居的原IIF外,将IIF的所述扩展列表中的所有所述IIF标记为阻塞;以及
将OIF的所述扩展列表中的所有所述原IIF标记为阻塞。
4. 如权利要求1所述的方法,其中一组中间节点位于所述网络节点与所述下游合并节点之间,以及其中所述DFNP促使每个中间节点解除阻塞引导到所述中间节点的一个或更多个上游邻居的一个或更多个OIF,并且阻塞当前通畅的OIF。
5. 如权利要求1所述的方法,其中所述DFNP促使所述下游合并节点解除阻塞引导到所述下游合并节点的主要上游邻居的OIF,解除阻塞引导到所述下游合并节点的次要上游邻居的IIF,以及阻塞当前通畅的IIF。
6. 如权利要求1所述的方法,其中一组中间节点位于所述网络节点与所述下游合并节点之间,其中所述UFNP促使每个中间节点解除阻塞到从其收到所述UFNP的所述中间节点的下游邻居的IIF,并且阻塞当前通畅的IIF。
7. 如权利要求1所述的方法,其中确定的所述步骤还包括确定一个或更多个以下操作:
确定所述网络节点没有将所述共同来源节点耦合到所述网络节点的次要路径,确定所述网络节点接收来自所述次要路径的失效的指示,或者确定所述网络节点检测在耦合到所述次要路径上的次要上游邻居的IIF的失效。
8. 如权利要求1所述的方法,其中所述DFNP和所述UFNP的处理是基于在数据平面中所述网络节点的一个或更多个线路卡上存储的所述转发信息。
9. 如权利要求1所述的方法,其中在所述DFNP到达所述下游合并节点时,不进一步向下游转发所述DFNP。
10. 如权利要求1所述的方法,其中在所述UFNP到达所述网络节点时,不进一步向上游转发所述UFNP。
11. 一种在多播通信网络中的网络节点,所述多播通信网络包括多播树以提供从共同来源节点到一个或更多个多播接收方节点的连接性,所述多播通信网络还包括一组次要路径以提供冗余性给所述多播树,所述网络节点包括:
存储器,配置成存储用于所述多播数据业务的转发信息;
耦合到所述存储器的一个或更多个处理器,所述一个或更多个处理器配置成在到上游邻居的进入接口检测连接的丢失,并且确定所述网络节点是否能够重新路由所述多播数据业务以允许所述多播数据业务到达所述多播接收方节点;
耦合到所述处理器的下游模块,所述下游模块配置成响应所述网络节点不能重新路由所述多播数据业务的确定,发起下游快速通知分组(DFNP);
耦合到所述处理器的传送器电路,所述传送器电路配置成往下游向所述多播接收方节点发送所述DFNP,其中所述DFNP促使下游合并节点将所述多播数据业务的接收交换到引导到所述共同来源节点的次要路径;以及
耦合到所述处理器的接收器电路,所述接收器电路配置成接收来自所述下游合并节点的上游快速通知分组(UFNP);以及
耦合到所述处理器的上游模块,所述上游模块配置成在接收所述UFNP时修改所述转发信息,使得所述网络节点将从接收所述UFNP经过的所述网络节点的下游邻居接收所述多播数据业务,以及其中所述UFNP和所述DFNP促使所述多播数据业务在所述网络节点与所述下游合并节点之间反转流向以便由此重新路由所述多播数据业务。
12. 如权利要求11所述的网络节点,其中所述下游合并节点耦合到在到所述共同来源节点的主要路径上的主要上游多播跳(UMH)和在到所述共同来源节点的所述次要路径上的次要UMH,以及其中基于等价多路径(ECMP)或无环路备选(LFA)选择所述第二UMH。
13. 如权利要求11所述的网络节点,其中所述网络节点包括记录所述网络节点的原外出接口(OIF)列表和原进入接口(IIF)列表的转发表,以及其中在检测到连接的所述丢失之前,所述网络节点配置成:
扩展所述转发表中所述原IIF列表以形成包括所有所述原IIF和所有所述原OIF的IIF的扩展列表;
扩展所述转发表中所述原OIF列表以形成包括所有所述原IIF和所有所述原OIF的OIF的扩展列表;
除引导到所述网络节点的所述主要上游邻居的原IIF外,将IIF的所述扩展列表中的所有所述IIF标记为阻塞;以及
将OIF的所述扩展列表中的所有所述原IIF标记为阻塞。
14. 如权利要求11所述的网络节点,其中一组中间节点位于所述网络节点与所述下游合并节点之间,以及其中所述DFNP促使每个中间节点解除阻塞引导到所述中间节点的一个或更多个上游邻居的一个或更多个OIF,并且阻塞当前通畅的OIF。
15. 如权利要求11所述的网络节点,其中所述DFNP促使所述下游合并节点解除阻塞引导到所述下游合并节点的主要上游邻居的OIF,解除阻塞引导到所述下游合并节点的次要上游邻居的IIF,以及阻塞当前通畅的IIF。
16. 如权利要求11所述的网络节点,其中一组中间节点位于所述网络节点与所述下游合并节点之间,其中所述UFNP促使每个中间节点解除阻塞到从其收到所述UFNP的所述中间节点的下游邻居的IIF,并且阻塞当前通畅的IIF。
17. 如权利要求11所述的网络节点,其中所述一个或更多个处理器配置成基于以下的一项或更多项,确定所述网络节点不能重新路由所述多播数据业务:所述网络节点没有将所述共同来源节点耦合到所述网络节点的次要路径,所述网络节点接收来自所述次要路径的失效的指示,或者所述网络节点检测在耦合到所述次要路径上的次要上游邻居的IIF的失效。
18. 如权利要求11所述的网络节点,其中所述网络节点还包括在所述数据平面中的一个或更多个线路卡,其中所述网络节点配置成基于在所述一个或更多个线路卡上存储的所述转发信息,处理所述DFNP和所述UFNP。
19. 如权利要求11所述的网络节点,其中在所述DFNP到达所述下游合并节点时,不进一步向下游转发所述DFNP。
20. 如权利要求11所述的网络节点,其中在所述UFNP到达所述网络节点时,不进一步向上游转发所述UFNP。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/486470 | 2012-06-01 | ||
US13/486,470 US8824276B2 (en) | 2012-06-01 | 2012-06-01 | Increasing failure coverage of MOFRR with dataplane notifications |
PCT/IB2013/053724 WO2013179163A1 (en) | 2012-06-01 | 2013-05-08 | Increasing failure coverage in hierarchical, redundant, multicast routing |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104380671A true CN104380671A (zh) | 2015-02-25 |
CN104380671B CN104380671B (zh) | 2018-04-27 |
Family
ID=48746598
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201380028766.4A Active CN104380671B (zh) | 2012-06-01 | 2013-05-08 | 在分级、冗余、多播路由选择中增加失效覆盖 |
Country Status (7)
Country | Link |
---|---|
US (2) | US8824276B2 (zh) |
EP (1) | EP2856714A1 (zh) |
JP (1) | JP2015521448A (zh) |
KR (1) | KR20150028260A (zh) |
CN (1) | CN104380671B (zh) |
IN (1) | IN2014DN10343A (zh) |
WO (1) | WO2013179163A1 (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110024438A (zh) * | 2016-12-21 | 2019-07-16 | 索尼公司 | 具有定向传输的无线网络中的鲁棒数据路由 |
CN111709623A (zh) * | 2020-06-04 | 2020-09-25 | 中国科学院计算机网络信息中心 | 高性能计算环境评价方法、装置、电子设备及存储介质 |
CN114157597B (zh) * | 2020-08-18 | 2024-01-02 | 瞻博网络公司 | 经加权的多播加入负载平衡 |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8913482B2 (en) | 2012-06-01 | 2014-12-16 | Telefonaktiebolaget L M Ericsson (Publ) | Enhancements to PIM fast re-route with upstream activation packets |
US9491091B2 (en) | 2012-06-08 | 2016-11-08 | Cisco Technology, Inc. | MLDP failover using fast notification packets |
US9614720B2 (en) * | 2013-04-09 | 2017-04-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Notification technique for network reconfiguration |
US9509520B2 (en) * | 2013-06-07 | 2016-11-29 | Cisco Technology, Inc. | Detection of repair nodes in networks |
US9699073B2 (en) * | 2013-09-24 | 2017-07-04 | Alcatel Lucent | System and method for reducing traffic loss while using loop free alternate routes for multicast only fast reroute (MoFRR) |
US9225629B2 (en) * | 2014-05-30 | 2015-12-29 | Telefonaktiebolaget L M Ericsson (Publ) | Efficient identification of node protection remote LFA target |
CN105704021B (zh) * | 2016-01-22 | 2019-04-12 | 中国人民解放军国防科学技术大学 | 一种基于弹性标签的重路由方法 |
US10110469B2 (en) * | 2016-07-21 | 2018-10-23 | Cisco Technology, Inc. | Detecting and preventing network loops |
US10785341B2 (en) | 2016-11-21 | 2020-09-22 | Intel Corporation | Processing and caching in an information-centric network |
US11855832B1 (en) * | 2022-06-21 | 2023-12-26 | Arista Networks, Inc. | Multicast flow restoration following network failure detection |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090268607A1 (en) * | 2007-03-31 | 2009-10-29 | Liyang Wang | Method and device for multicast traffic redundancy protection |
WO2011038750A1 (en) * | 2009-10-02 | 2011-04-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Technique for controlling data forwarding in computer networks |
JP2011166360A (ja) * | 2010-02-08 | 2011-08-25 | Nec Corp | マルチキャストツリー計算装置および計算方法、並びにネットワークシステム |
CN102316016A (zh) * | 2010-07-05 | 2012-01-11 | 华为技术有限公司 | 组播流量的转发方法及装置 |
Family Cites Families (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6771593B2 (en) | 2001-05-31 | 2004-08-03 | Motorola, Inc. | Method for improving packet delivery in an unreliable environment |
US7660235B2 (en) | 2003-03-20 | 2010-02-09 | Alcatel-Lucent Usa Inc. | Low latency shared data path allocation |
US7483374B2 (en) | 2003-08-05 | 2009-01-27 | Scalent Systems, Inc. | Method and apparatus for achieving dynamic capacity and high availability in multi-stage data networks using adaptive flow-based routing |
US7539131B2 (en) | 2003-11-26 | 2009-05-26 | Redback Networks Inc. | Nexthop fast rerouter for IP and MPLS |
KR100693052B1 (ko) | 2005-01-14 | 2007-03-12 | 삼성전자주식회사 | Mpls 멀티캐스트의 고속 재경로 설정 장치 및 방법 |
US8886831B2 (en) * | 2006-04-05 | 2014-11-11 | Cisco Technology, Inc. | System and methodology for fast link failover based on remote upstream failures |
US8570857B2 (en) | 2006-04-07 | 2013-10-29 | At&T Intellectual Property I, Lp | Resilient IP ring protocol and architecture |
US8004960B2 (en) | 2006-04-28 | 2011-08-23 | Cisco Technology, Inc. | Method and apparatus for forwarding label distribution protocol multicast traffic during fast reroute |
US7899049B2 (en) | 2006-08-01 | 2011-03-01 | Cisco Technology, Inc. | Methods and apparatus for minimizing duplicate traffic during point to multipoint tree switching in a network |
US8369212B2 (en) | 2006-08-29 | 2013-02-05 | Hewlett-Packard Development Company, L.P. | Network path validation based on user-specified criteria |
US8248921B2 (en) | 2006-11-03 | 2012-08-21 | At&T Intellectual Property I, L.P. | System and method of distributing digital content |
US8223660B2 (en) * | 2007-04-18 | 2012-07-17 | Rockstar Bidco Lp | Failure notification in a network having serially connected nodes |
US7684316B2 (en) | 2008-02-12 | 2010-03-23 | Cisco Technology, Inc. | Multicast fast reroute for network topologies |
US20090252033A1 (en) | 2008-04-08 | 2009-10-08 | At&T Knowledge Ventures, L.P. | System and method of distributing media content |
WO2009138133A1 (en) | 2008-05-12 | 2009-11-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Re-routing traffic in a communications network |
JP5039639B2 (ja) | 2008-06-09 | 2012-10-03 | 株式会社日立製作所 | パスプロテクション機能を有する通信装置及びその通信装置を使用するネットワークシステム |
IL192397A0 (en) | 2008-06-23 | 2012-06-28 | Eci Telecom Ltd | Technique for fast reroute protection of logical paths in communication networks |
US8619775B2 (en) | 2008-07-21 | 2013-12-31 | Ltn Global Communications, Inc. | Scalable flow transport and delivery network and associated methods and systems |
US8510551B1 (en) | 2008-11-10 | 2013-08-13 | Juniper Networks, Inc. | Policy handling for multicast transmissions |
EP2364539B1 (en) | 2008-11-17 | 2012-09-19 | Telefonaktiebolaget L M Ericsson (PUBL) | A system and method of implementing lightweight not-via ip fast reroutes in a telecommunications network |
US8102848B1 (en) | 2008-11-19 | 2012-01-24 | Force10 Networks, Inc. | Multicast high availability enhancements for faster convergence |
US8208377B2 (en) * | 2009-03-26 | 2012-06-26 | Force10 Networks, Inc. | MAC-address based virtual route aggregation |
US8462621B2 (en) | 2009-07-27 | 2013-06-11 | At&T Intellectual Property I, L.P. | Systems and methods of multicast reconfiguration using cross-layer information |
US8379516B2 (en) | 2009-12-24 | 2013-02-19 | Contextream Ltd. | Grid routing apparatus and method |
US8767735B2 (en) | 2010-08-04 | 2014-07-01 | Alcatel Lucent | System and method for multi-chassis link aggregation |
US8638659B2 (en) | 2012-06-01 | 2014-01-28 | Telefonaktiebolaget L M Ericsson (Publ) | Enhancements to PIM fast re-route with downstream notification packets |
US8913482B2 (en) | 2012-06-01 | 2014-12-16 | Telefonaktiebolaget L M Ericsson (Publ) | Enhancements to PIM fast re-route with upstream activation packets |
-
2012
- 2012-06-01 US US13/486,470 patent/US8824276B2/en active Active
-
2013
- 2013-05-08 KR KR20147036928A patent/KR20150028260A/ko not_active Application Discontinuation
- 2013-05-08 WO PCT/IB2013/053724 patent/WO2013179163A1/en active Application Filing
- 2013-05-08 CN CN201380028766.4A patent/CN104380671B/zh active Active
- 2013-05-08 EP EP13734173.1A patent/EP2856714A1/en not_active Withdrawn
- 2013-05-08 JP JP2015514622A patent/JP2015521448A/ja not_active Withdrawn
-
2014
- 2014-07-16 US US14/333,327 patent/US9197547B2/en active Active
- 2014-12-04 IN IN10343DEN2014 patent/IN2014DN10343A/en unknown
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090268607A1 (en) * | 2007-03-31 | 2009-10-29 | Liyang Wang | Method and device for multicast traffic redundancy protection |
WO2011038750A1 (en) * | 2009-10-02 | 2011-04-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Technique for controlling data forwarding in computer networks |
JP2011166360A (ja) * | 2010-02-08 | 2011-08-25 | Nec Corp | マルチキャストツリー計算装置および計算方法、並びにネットワークシステム |
CN102316016A (zh) * | 2010-07-05 | 2012-01-11 | 华为技术有限公司 | 组播流量的转发方法及装置 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110024438A (zh) * | 2016-12-21 | 2019-07-16 | 索尼公司 | 具有定向传输的无线网络中的鲁棒数据路由 |
CN110024438B (zh) * | 2016-12-21 | 2021-11-12 | 索尼公司 | 一种无线通信方法及装置 |
CN111709623A (zh) * | 2020-06-04 | 2020-09-25 | 中国科学院计算机网络信息中心 | 高性能计算环境评价方法、装置、电子设备及存储介质 |
CN114157597B (zh) * | 2020-08-18 | 2024-01-02 | 瞻博网络公司 | 经加权的多播加入负载平衡 |
Also Published As
Publication number | Publication date |
---|---|
US20130322233A1 (en) | 2013-12-05 |
WO2013179163A1 (en) | 2013-12-05 |
CN104380671B (zh) | 2018-04-27 |
US9197547B2 (en) | 2015-11-24 |
US8824276B2 (en) | 2014-09-02 |
IN2014DN10343A (zh) | 2015-08-07 |
EP2856714A1 (en) | 2015-04-08 |
KR20150028260A (ko) | 2015-03-13 |
US20140355422A1 (en) | 2014-12-04 |
JP2015521448A (ja) | 2015-07-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104380671A (zh) | 在分级、冗余、多播路由选择中增加失效覆盖 | |
CN104509044B (zh) | 用下游通知分组增强协议无关多播(pim)快速重新路由方法 | |
CN103380605B (zh) | 使用ldp的mpls快速重新路由ldp-frr的方法和网络单元 | |
CN104662851A (zh) | 用上游激活分组增强pim快速重新路由 | |
US7848224B2 (en) | Method and apparatus for constructing a repair path for multicast data | |
CN101953124B (zh) | 在数据通信网络中构造绕过多条不可用链路的修复路径 | |
CN102037685B (zh) | 通过链路状态协议控制的以太网的ip转发 | |
CN103891220B (zh) | 使用ldp的mpls快速重新路由(ldp-frr)的方法和网络单元 | |
CN100450039C (zh) | 快速收敛端到端业务的方法和装置 | |
CN102197625B (zh) | 提供商链路状态桥接(plsb)计算方法 | |
US20150312138A1 (en) | Bicasting using non-congruent paths in a loop-free routing topology having routing arcs | |
CN107070788B (zh) | 通过计算机网络的多播业务的分发的方法和设备 | |
US20150249597A1 (en) | Rapid Alternate Paths for Network Destinations | |
CN107040462A (zh) | 路由方法和中间路由器 | |
CN107040400A (zh) | 网络装置及方法 | |
US10164867B2 (en) | Generating non-congruent paths having minimal latency difference in a loop-free routing topology having routing arcs | |
CN102217238A (zh) | 应用于mpls网络的服务实例 | |
EP2761827A1 (en) | Incremental deployment of mrt based ipfrr | |
CN101485156A (zh) | 用于通过网络交换流量的系统和方法 | |
CN102150148A (zh) | 层2拓扑中针对单播帧和多播帧的差别化服务 | |
CN106165322A (zh) | 向冗余控制器路由协议的代理 | |
CN106559246A (zh) | 集群的实现方法和服务器 | |
CN101616093B (zh) | 一种用户接入多归属网络实现方法、装置及网络设备 | |
CN101529869A (zh) | 用于在路由网络中计算备选多播/广播路径的方法和设备 | |
CN105721322A (zh) | 在trill网络中传输组播数据的方法、装置和系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |