CN1866909A - 一种转发引擎状态检测方法和路由设备 - Google Patents
一种转发引擎状态检测方法和路由设备 Download PDFInfo
- Publication number
- CN1866909A CN1866909A CNA2005100857203A CN200510085720A CN1866909A CN 1866909 A CN1866909 A CN 1866909A CN A2005100857203 A CNA2005100857203 A CN A2005100857203A CN 200510085720 A CN200510085720 A CN 200510085720A CN 1866909 A CN1866909 A CN 1866909A
- Authority
- CN
- China
- Prior art keywords
- forwarding engine
- forwarding
- frame
- predefine
- detecting method
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供一种转发引擎状态检测方法和路由设备,其核心均为:转发引擎根据其接收的其它各转发引擎广播发送的预定义帧确定其它各转发引擎的状态。本发明能够在不需要增加硬件走线、不增加硬件设计复杂度的前提下,使转发引擎能够直接、快速的检测到其它各转发引擎的状态,避免了路由处理/管理系统将某个转发引擎的异常状态消息通知其他各转发引擎的过程,有效减少了检测各转发引擎故障状态的时间;当本发明的技术方案应用于快速重路由技术中时,能够有效减少由于转发引擎的故障而导致的业务中断时间;从而实现了降低转发引擎状态检测成本,提高业务传输可靠性的目的。
Description
技术领域
本发明涉及网络通讯技术领域,具体涉及一种转发引擎状态检测方法和路由设备。
背景技术
路由器是网络互连的专用设备。它在Internet/Intranet、局域网互连、远处局域网访问、小型家庭办公室等领域,以及银行、交通、邮电等部门的专用网和商业网上都有着广泛的应用。
路由器工作在OSI(开发系统互连)参考模型的第三层,即网络层。路由器的基本功能是:为通过它的IP报文寻径,即路由,然后,将IP报文转发到下一站或目的地的主机。路由器在连接两个不同种类的网络时,必须在报文转发的同时完成各类协议的转换,将报文的上层统一为TCP/IP协议或其它协议。
目前,路由器的体系结构一般包括如下三种:
1、集中式转发路由器
集中式转发路由器的系统结构如附图1所示。图1中,路由器的接口卡与CPU(中央处理器)之间通过内部总线相连,CPU负责所有事务处理,如路由收集、转发处理、设备管理等。接口卡接收到报文后,通过内部总线传递给CPU,由CPU完成所有处理后从另一个网络接口卡传递出去。
2、共享总线式路由器
共享总线式路由器实现了转发和控制的分离,其体系结构如附图2所示。图2中,路由器的路由查找等转发动作通过接口板上的CPU来实现,控制CPU完成设备管理、路由计算等工作。控制CPU和接口板上负责转发的CPU之间通过共享总线的方式进行数据交互。通常使用的总线有PCI总线、CPCI总线等。
共享总线方式路由器中共享总线的带宽、接口板上CPU的处理能力是报文转发的瓶颈。
3、交换式路由器
交换式路由器也实现了转发平面和控制平面的分离,其体系结构如附图3所示。图3中,虚线是控制通道,实线是报文转发通道。交换式路由器和共享总线式路由器的不同之处在于:交换式路由器增加了交换网,且接口板上的转发引擎可以通过ASIC(专用集成电路)、FPGA(现场可编程门阵列)或者网络处理器来实现。
交换式路由器有效解决了共享总线式路由器中共享总线的带宽瓶颈问题,同时,通过取代了接口板上的通用CPU,使用专用的转发引擎进行路由查找等转发动作,有效解决了共享总线式路由器中报文转发性能瓶颈问题。
交换式路由器的软件系统结构如附图4所示。
图4中,交换式路由器的软件系统主要包括:控制CPU子系统和接口板子系统,控制CPU子系统即路由处理/管理系统,接口板子系统又可分为转发支撑部分和转发处理部分。
路由处理/管理系统的主要功能是:路由计算、路由维护、业务相关数据和设备相关数据的配置和维护、系统运行监控、统计数据的管理和维护以及例行测试、故障诊断/定位、报告等等。
转发支撑部分运行在接口板的控制CPU上,其主要功能是:为转发引擎服务,实现并处理链路层协议如PPP over SDH、IPoA(Internet Protocols over ATM,ATM承载IP协议)、EtherNet(以太网协议)、DPT协议等,统计数据收集,管理维护以及协同主控进行设备管理如接口管理、设备管理、调试支持等。
转发处理部分运行在接口板的转发引擎上,其主要功能是:数据转发如IP报文转发、MPLS报文转发,QOS,流分类/DIFFSERV(区别业务),为完成业务要素的实时统计数据而采集报文等。
由于交换式路由器容量比较大,使交换式路由器在网络中的地位比较高,对于电信级应用的路由器,一般都采用交换式的体系结构。
电信级应用对业务可靠性的要求非常高,对业务中断间隔要求比较严格,一般要求在50毫秒以内。当路由器的接口故障的时候,路由协议会重新计算一个出接口作为报文转发的出口,这种计算的时间等级应该是秒级的,业务中断的时间太长就无法满足电信级的要求。
为了在路由协议重新计算完成之前,使业务流量能够继续保持,目前已开发出了多种快速重路由技术。通常使用的快速重路由技术有如下三种:
1、基于负载分担的快速重路由
路由协议在转发表上生成若干个等价路由,IP或者MPLS等报文在进行报文转发时,在等价路由上进行负载分担。同时,路由协议需要检测各个等价路由的出接口的状态,如果对应的出接口down,则从其他等价路由中进行路由选择。在控制层面路由协议发现出接口down,并删除对应路由的时间比较长,在这段时间内,转发层面通过快速重路由将对应的业务流量从其他出接口转发。
2、预先设立低等级路由的快速重路由
该方法是在路由表中生成一个低等级的路由,正常的时候,这个路由不参与报文转发。如果高等级的若干等价路由中的某一个出接口down,则相应的业务流量转到低等级的路由上。在该方法中,低等级的路由只有在故障的时候才使用。路由协议在删除失效的等价路由、并重新计算路由后,将业务流量从低等级的路由切换到其他路由上。
3、MPLS TE(MultiProtocal Label Switching Traffic Engineering,多协议标签交换流量工程)的快速重路由
MPLS TE在网络中建立端到端的隧道,通过隧道来承载各种业务。MPLSTE对隧道中的节点或者链路有专门的保护机制,保护方法不同于前面两种基于路由的保护方法。MPLS TE使用建立专门的保护隧道对被保护隧道实施保护,用于保护的隧道是预先设置好的,当被保护的链路或者节点发生故障的时候,业务流量迅速的切换到保护隧道上,通过保护隧道使业务流量绕过故障节点或者故障链路,业务流量出保护隧道的时候,重新进入被保护的隧道。
上述三种快速重路由的前提都是对端口故障的快速检测,端口故障检测的快慢决定了业务中断的时间。目前,端口故障快速检测的方法主要有以下两种:
1、中断上报
路由器接口板上的物理层芯片检测到链路故障后,触发中断给转发支撑部分,由转发支撑部分向转发处理部分发送消息,在带内通过交换网广播包来通知所有的接口板。
2、定时查询
对于路由器接口板上的物理层芯片不支持中断的时候,转发支撑部分需要定时查询链路状态,查询的时间间隔决定了故障检测的快慢。
上述端口故障快速检测的前提是:接口板上的控制CPU能够正常工作,即运行转发支撑部分的CPU能够工作正常。在端口故障快速检测方法中,检测的对象是接口。
在转发引擎异常复位或者转发引擎故障使转发引擎状态异常时,同样需要进行快速重路由,但是,转发引擎状态异常时,接口板上的所有接口本身可能都是正常的,因此,利用上述端口故障快速检测方法不能够启动快速重路由过程。
随着通讯技术的发展,各种网络技术不断融合,GMPLS等新技术随之出现,在GMPLS技术下,控制平面可以是IP的路由协议或者流量工程的协议,在转发平面上则不仅仅是MPLS包,还可以是时分复用的时隙、ATM的VPI/VCI、波分复用的波段等等。对于这些应用,由于控制层面是IP的路由协议或者流量工程的协议,因此快速重路由技术是同样适用的。如果网络设备采用的同样是分布交换式的体系结构,转发引擎状态的快速检测同样需要。
目前,对转发引擎状态进行快速检测的方法主要有如下两种:
1、通过路由处理/管理系统完成。
路由处理/管理系统通过定时查询或者响应接口板主动上报中断的方式检测接口板故障,并在检测到接口板故障发生后,通知其他接口板。
该方法由于消息传递的路径过长,会导致故障检测的时间超过业务保护要求的时间。以转发引擎故障为例,转发支撑部分需要定时检测转发引擎的状态,在发现转发引擎故障后,发消息给路由处理/管理系统,路由处理/管理系统复位接口板,并采用最迅速的带内广播方式通知其他接口板,这个过程消耗的时间是无法忍受的。
2、各个转发引擎之间直接通过硬件连线通报状态信息。
该方法使转发引擎故障检测时间短,可靠性高,但是,该方法增加了硬件走线,占用了相应的硬件引脚,使硬件设计复杂。
发明内容
本发明的目的在于,提供一种转发引擎状态检测方法和路由设备,利用各转发引擎广播发送的预定义帧,使各转发引擎能够直接检测到其它转发引擎的状态,有效减少了检测各转发引擎故障状态的时间,实现了降低转发引擎状态检测成本,提高业务传输可靠性的目的。
为达到上述目的,本发明提供的一种转发引擎状态检测方法,包括:
转发引擎根据其接收的其它各转发引擎广播发送的预定义帧确定其它各转发引擎的状态。
所述方法具体包括:
a、各转发引擎均定时广播发送预定义帧;
b、转发引擎确定其对其它转发引擎发送的预定义帧连续未接收到的次数;
c、转发引擎根据其它各转发引擎对应的所述次数确定其它各转发引擎的正常状态/异常状态。
所述步骤a包括:
在各转发引擎中分别设置定时器;
各转发引擎根据其自身设置的定时器的定时间隔产生中断,并根据该中断广播发送预定义帧。
所述定时器的定时间隔动态可调。
所述方法在步骤a之前还包括:
在各转发引擎中均针对其它各转发引擎分别设置计数器和状态标识位;
且所述步骤b具体包括:
转发引擎在定时广播发送预定义帧时,将其自身中设置的各计数器的计数值增加预定步长;
转发引擎在接收到其它转发引擎广播发送来的预定义帧时,将其自身中设置的对应计数器复位,并将对应的状态标识位设置为正常。
所述步骤c具体包括:
转发引擎在定时广播发送预定义帧时,根据预定次数和其它各转发引擎对应的计数器的计数值判断其它各转发引擎的状态;
如果转发引擎对应的计数器的计数值小于预定次数,确定该转发引擎处于正常状态;
如果转发引擎对应的计数器的计数值不小于预定次数,确定该转发引擎处于故障状态,并将对应的状态标识位设置为异常。
所述方法还包括:
对处于正常状态的转发引擎进行端口状态检测。
所述预定义帧的优先级为最高。
所述转发引擎包括:交换式路由设备中的转发引擎。
本发明还提供一种路由设备,包括:多个转发引擎,各转发引擎中均设置有转发引擎状态检测模块,且所述转发引擎状态检测模块包括:
发送预定义帧子模块:发送广播预定义帧,并接收其它转发引擎的发送预定义帧子模块发送的预定义帧;
检测状态子模块:根据其所在的转发引擎的发送预定义帧子模块接收的预定义帧确定其它各转发引擎的状态。
通过上述技术方案的描述可知,本发明通过利用各转发引擎广播发送的预定义帧如控制帧等,在不需要增加硬件走线、不增加硬件设计复杂度的前提下,使转发引擎能够直接、快速的检测到其它各转发引擎的状态,避免了路由处理/管理系统将某个转发引擎的异常状态消息通知其他各转发引擎的过程,有效减少了检测各转发引擎故障状态的时间;通过调整转发引擎定时发送预定义帧的定时间隔,使检测转发引擎故障状态的时间可控制;当本发明的技术方案应用于快速重路由技术中时,能够有效减少由于转发引擎的故障而导致的业务中断时间;本发明中的转发引擎通过检测其未接收到的其他转发引擎发送的控制帧的次数,使本发明的转发引擎检测方法简单、易于实现;通过将预定义帧的优先级设置为最高,使预定义帧能够不受任何流控顺利的到达各转发引擎,保证了检测转发引擎异常状态的及时性;从而通过本发明提供的技术方案实现了降低转发引擎状态检测成本,提高业务传输可靠性的目的。
附图说明
图1是集中式转发路由器的系统结构示意图;
图2是共享总线式路由器的系统结构示意图;
图3是交换式路由器的系统结构示意图;
图4是交换式路由器的软件系统结构示意图;
图5是本发明的转发引擎状态检测的实现原理示意图;
图6是本发明的转发引擎状态检测流程图一;
图7是本发明的转发引擎状态检测流程图二。
具体实施方式
本发明的转发引擎状态检测方法和路由设备的核心均是:转发引擎根据其接收的其它各转发引擎广播发送的预定义帧确定其它各转发引擎的状态。
下面基于本发明的核心思想对本发明提供的方法和路由设备做进一步的描述。
本发明中的转发引擎需要根据其它转发引擎广播发送的预定义帧来检测其它各转发引擎的状态,预定义帧可以是根据检测需要新构造的帧,也可以是利用现有的转发引擎广播发送的帧。
在下述实施例的描述中,以本发明根据检测需要新构造的预定义帧--控制帧为例,对本发明的转发引擎状态检测方法和路由设备进行详细描述。
为保证转发引擎定时广播发送的控制帧在通过交换网时,不会受到任何流控,能够顺利通过交换网板到达其它各转发引擎,本发明可以将控制帧的优先级设置为最高。
由于本发明中的各转发引擎需要定时广播发送控制帧,所以,可以在各转发引擎中分别设置定时器,定时器的定时间隔可根据实际需要动态调整。转发引擎在其自身设置的定时器的计时值达到定时间隔时,产生定时中断,转发引擎广播发送控制帧。
转发引擎检测其它各转发引擎状态可以通过分别检测其未连续接收到的其它各转发引擎定时广播发送的控制帧的次数来实现。
为了方便的获得上述其它各转发引擎对应的次数,本发明可以在各转发引擎中设置一个记录其他各转发引擎状态信息的bitmap(位表)和记录对其它各转发引擎广播发送的控制帧的未连续接收到次数的计数器。如果一个转发引擎的状态信息使用一个比特位来表示,则bitmap中包含的比特位与所有转发引擎的个数相同。一个转发引擎中设置的计数器的个数同样与所有转发引擎的个数相同。计数器可以按照定时器的定时间隔进行计数处理。每个计数器都对应一个预定门限值,这个预定门限值就是判断其它转发引擎处于故障状态或处于正常状态的标准。各计数器对应的预定门限值可以相同。
在各转发引擎中设置的定时器、计数器、bitmap及转发引擎状态检测的方法如附图5所示。
图5中,路由设备中设置有n个转发引擎,每个转发引擎中都设置有一个定时器、n-1个计数器和n-1比特位长的bitmap。一个转发引擎中的n-1个计数器分别对应除该转发引擎之外的其它n-1个转发引擎,同样,n-1个比特位分别对应其它n-1个转发引擎。各转发引擎均根据定时器的定时间隔周期性广播发送控制帧,该控制帧通过交换网板传输至其它各转发引擎;各转发引擎均接收其它转发引擎通过交换网板传输来的控制帧,并在接收到控制帧后,相应复位对应计数器的计数值、同时将bitmap中对应的比特位设置为正常状态值;各转发引擎均根据定时器的定时间隔来将所有的计数器的计数值都增加预定步长,并则增加预定步长后,根据计数值来判断其它各转发引擎的正常状态/异常状态,在确定某个转发引擎为异常状态时,将该转发引擎对应的bitmap中的比特位设置为异常状态值,从而通过bitmap中各比特位的值可确定其它各转发引擎的状态。
转发引擎m在接收到其它转发引擎如转发引擎n广播发送的控制帧后的处理过程如附图6所示。
图6中,步骤600,转发引擎m接收到转发引擎n广播发送的控制帧。
到步骤610,转发引擎m将其自身中设置的bitmap中转发引擎n对应的比特位设置为正常状态值,如清除转发引擎n对应的比特位信息。
到步骤620,转发引擎m将其自身中设置的转发引擎n对应的计数器复位。
到步骤630,转发引擎m对转发引擎n广播发送的控制帧的处理过程结束。
转发引擎m广播发送控制帧及检测其它n-1个转发引擎状态的处理过程如附图7所示。
图7中,步骤700,转发引擎m中设置的定时器的计时达到定时间隔时,产生中断,转发引擎m需要广播控制帧、检测其它n-1个转发引擎状态。
到步骤710,转发引擎m构造控制帧,并广播发送。
到步骤720,转发引擎m开始检测其它n-1个转发引擎状态的过程。转发引擎将没有进行过下述步骤730处理的一个计数器的计数值增加预定步长,如增加1。
到步骤730,转发引擎m对刚刚增加了预定步长后的计数值进行判断,判断该计数值是否超过预定门限,如果超过预定门限到步骤731,将该计数器对应的bitmap中的比特位设置为故障状态值,如将bitmap中对应的bit置1。然后,到步骤740。
在步骤730,如果该计数器的计数值不超过预定门限,直接到步骤740。
在步骤740,转发引擎m判断是否对其自身中设置的所有计数器都进行了上述步骤720、730的处理,如果还存在没有经过上述处理的计数器,则到步骤741,从没有经过上述处理的计数器中选取一个计数器,到步骤720,将该计数器的计数值增加预定步长,如增加1,到步骤730。
在步骤740,如果转发引擎m自身中设置的所有计数器都进行了上述步骤720、730的处理,则到步骤750,本次检测其它转发引擎状态的过程结束。
这样,转发引擎m的bitmap中为1的比特位对应的转发引擎为处于故障状态的转发引擎。在检测到某个或某些转发引擎处于故障状态时,应启动快速重路由过程,以保证业务的可靠性。本发明可以在检测到转发引擎处于正常状态时,再检测该转发引擎中的端口的状态。
本发明通过调整转发引擎中定时器的中断时间,可控制转发引擎故障检测的时间,能够使转发引擎故障检测时间低于50ms。
下面对本发明提供的路由设备进行描述。
本发明的路由设备中设置有多个转发引擎,各转发引擎中均设置有转发引擎状态检测模块,各转发引擎状态检测模块包括:发送预定义帧子模块和检测状态子模块。
发送预定义帧子模块主要用于定时广播发送预定义帧如根据预定的定时间隔发送控制帧,同时,发送预定义帧子模块还接收其它转发引擎的发送预定义帧子模块定时广播发送的控制帧。发送预定义帧子模块定时广播发送的预定义帧如控制帧的优先级应设置为最高。发送预定义帧子模块发送预定义帧的预定的定时间隔可根据实际需要来调整。
检测状态子模块主要用于根据其所在的转发引擎的发送预定义帧子模块接收的预定义帧确定其它各转发引擎的状态。检测状态子模块检测其它各转发引擎状态可以通过分别检测其未连续接收到的其它各转发引擎定时广播发送的控制帧的次数来实现,具体过程如上述方法中的描述,在此不再详细描述。
通过上述实施例的描述可知,本发明不需要增加硬件走线,不需要更换硬件设备,且没有增加硬件设计复杂度,通过利用各转发引擎广播发送的预定义帧如控制帧等,使转发引擎能够直接、快速的检测到其它各转发引擎的状态,避免了路由处理/管理系统将某个转发引擎的异常状态消息通知其他各转发引擎的过程,有效减少了检测各转发引擎故障状态的时间;通过调整转发引擎定时发送预定义帧的定时间隔,使检测转发引擎故障状态的时间可控制;当本发明的技术方案应用于快速重路由技术中时,能够有效减少由于转发引擎的故障而导致的业务中断时间;从而实现了降低转发引擎状态检测成本,提高业务传输可靠性的目的。
虽然通过实施例描绘了本发明,本领域普通技术人员知道,本发明有许多变形和变化而不脱离本发明的精神,本发明的申请文件的权利要求包括这些变形和变化。
Claims (10)
1、一种转发引擎状态检测方法,其特征在于,包括:
转发引擎根据其接收的其它各转发引擎广播发送的预定义帧确定其它各转发引擎的状态。
2、如权利要求1所述的一种转发引擎状态检测方法,其特征在于,所述方法具体包括:
a、各转发引擎均定时广播发送预定义帧;
b、转发引擎确定其对其它转发引擎发送的预定义帧连续未接收到的次数;
c、转发引擎根据其它各转发引擎对应的所述次数确定其它各转发引擎的正常状态/异常状态。
3、如权利要求2所述的一种转发引擎状态检测方法,其特征在于,所述步骤a包括:
在各转发引擎中分别设置定时器;
各转发引擎根据其自身设置的定时器的定时间隔产生中断,并根据该中断广播发送预定义帧。
4、如权利要求3所述的一种转发引擎状态检测方法,其特征在于,所述定时器的定时间隔动态可调。
5、如权利要求2所述的一种转发引擎状态检测方法,其特征在于,所述方法在步骤a之前还包括:
在各转发引擎中均针对其它各转发引擎分别设置计数器和状态标识位;
且所述步骤b具体包括:
转发引擎在定时广播发送预定义帧时,将其自身中设置的各计数器的计数值增加预定步长;
转发引擎在接收到其它转发引擎广播发送来的预定义帧时,将其自身中设置的对应计数器复位,并将对应的状态标识位设置为正常。
6、如权利要求5所述的一种转发引擎状态检测方法,其特征在于,所述步骤c具体包括:
转发引擎在定时广播发送预定义帧时,根据预定次数和其它各转发引擎对应的计数器的计数值判断其它各转发引擎的状态;
如果转发引擎对应的计数器的计数值小于预定次数,确定该转发引擎处于正常状态;
如果转发引擎对应的计数器的计数值不小于预定次数,确定该转发引擎处于故障状态,并将对应的状态标识位设置为异常。
7、如权利要求2所述的一种转发引擎状态检测方法,其特征在于,所述方法还包括:
对处于正常状态的转发引擎进行端口状态检测。
8、如权利要求1至7中任一权利要求所述的一种转发引擎状态检测方法,其特征在于,所述预定义帧的优先级为最高。
9、如权利要求1至7中任一权利要求所述的一种转发引擎状态检测方法,其特征在于,所述转发引擎包括:交换式路由设备中的转发引擎。
10、一种路由设备,包括:多个转发引擎,其特征在于,所述各转发引擎中均设置有转发引擎状态检测模块,且所述转发引擎状态检测模块包括:
发送预定义帧子模块:发送广播预定义帧,并接收其它转发引擎的发送预定义帧子模块发送的预定义帧;
检测状态子模块:根据其所在的转发引擎的发送预定义帧子模块接收的预定义帧确定其它各转发引擎的状态。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005101169817A CN100466605C (zh) | 2005-07-30 | 2005-07-30 | 一种转发引擎状态检测方法和路由设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005101169817A CN100466605C (zh) | 2005-07-30 | 2005-07-30 | 一种转发引擎状态检测方法和路由设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1866909A true CN1866909A (zh) | 2006-11-22 |
CN100466605C CN100466605C (zh) | 2009-03-04 |
Family
ID=37425798
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2005101169817A Expired - Fee Related CN100466605C (zh) | 2005-07-30 | 2005-07-30 | 一种转发引擎状态检测方法和路由设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100466605C (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101299693B (zh) * | 2008-07-02 | 2011-02-09 | 华为技术有限公司 | 一种检测转发平面故障的方法和装置 |
CN102239669A (zh) * | 2011-01-14 | 2011-11-09 | 华为技术有限公司 | 一种数据转发方法和路由器 |
CN103999406A (zh) * | 2012-08-01 | 2014-08-20 | 华为技术有限公司 | 通信路径的处理方法与装置 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6480472B1 (en) * | 1999-07-21 | 2002-11-12 | Qualcomm Incorporated | Mobile station supervision of the forward dedicated control channel when in the discontinuous transmission mode |
US6885635B1 (en) * | 2000-11-21 | 2005-04-26 | Juniper Networks, Inc. | High capacity router having redundant components |
KR100474677B1 (ko) * | 2002-04-18 | 2005-03-08 | 삼성전자주식회사 | 분산 구조 라우터에서 라우팅 프로토콜 모듈의 결함 발생검사방법 |
US7139928B1 (en) * | 2002-10-17 | 2006-11-21 | Cisco Technology, Inc. | Method and system for providing redundancy within a network element |
CA2502711C (en) * | 2003-01-13 | 2011-03-15 | Cisco Technology, Inc. | Method and system for optimized switchover of redundant forwarding engines |
CN1333546C (zh) * | 2003-12-12 | 2007-08-22 | 华为技术有限公司 | 一种网络处理器转发故障的诊断方法 |
-
2005
- 2005-07-30 CN CNB2005101169817A patent/CN100466605C/zh not_active Expired - Fee Related
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101299693B (zh) * | 2008-07-02 | 2011-02-09 | 华为技术有限公司 | 一种检测转发平面故障的方法和装置 |
CN102239669A (zh) * | 2011-01-14 | 2011-11-09 | 华为技术有限公司 | 一种数据转发方法和路由器 |
WO2011143940A1 (zh) * | 2011-01-14 | 2011-11-24 | 华为技术有限公司 | 一种数据转发方法和路由器 |
CN102239669B (zh) * | 2011-01-14 | 2015-01-21 | 华为技术有限公司 | 一种数据转发方法和路由器 |
US9118546B2 (en) | 2011-01-14 | 2015-08-25 | Huawei Technologies Co., Ltd. | Data forwarding method and router |
CN103999406A (zh) * | 2012-08-01 | 2014-08-20 | 华为技术有限公司 | 通信路径的处理方法与装置 |
US9503317B2 (en) | 2012-08-01 | 2016-11-22 | Huawei Technologies Co., Ltd. | Method and device for processing communication path |
CN103999406B (zh) * | 2012-08-01 | 2017-09-29 | 华为技术有限公司 | 通信路径的处理方法与装置 |
US10243783B2 (en) | 2012-08-01 | 2019-03-26 | Huawei Technologies Co., Ltd. | Method and device for processing communication path |
US11233694B2 (en) | 2012-08-01 | 2022-01-25 | Huawei Technologies Co., Ltd. | Method and device for processing communication path |
Also Published As
Publication number | Publication date |
---|---|
CN100466605C (zh) | 2009-03-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Wang et al. | Scotch: Elastically scaling up sdn control-plane using vswitch based overlay | |
US9819590B2 (en) | Method and apparatus for notifying network abnormality | |
CN1606850A (zh) | 动态分配的环路保护和恢复技术中的带宽保留再使用 | |
US11533260B2 (en) | Network traffic appliance for triggering augmented data collection on a network based on traffic patterns | |
US9019817B2 (en) | Autonomic network management system | |
WO2014177952A2 (en) | A method and system to dynamically detect traffic anomalies in a network | |
CN1794715A (zh) | 多协议标记交换(mpls)网络的集中控制 | |
CN101051995A (zh) | 基于无连接网络的保护倒换方法 | |
CN1848844A (zh) | 在mpls网络中实现组保护的方法及装置 | |
CN101106518A (zh) | 为中央处理器提供负载保护的拒绝服务方法 | |
CN1866909A (zh) | 一种转发引擎状态检测方法和路由设备 | |
CN1929390A (zh) | 一种业务流保护方法 | |
Isyaku et al. | Software defined networking failure recovery with flow table aware and flows classification | |
US20090063679A1 (en) | Network relay apparatus | |
WO2010127524A1 (zh) | 基于深度报文检测设备的业务识别网络的管理方法与系统 | |
Cisco | show1 | |
Cisco | show1 | |
Cisco | show Commands | |
Cisco | show1 | |
Cisco | show bootvar | |
Wisdom | COMPREHENSIVE PERFORMANCE ANALYSIS AND DELAY AWARE POWER SAVING SCHEME (DAPSS) IN WIRELESS NETWORKS | |
Park et al. | Software-defined networking (SDN) control message classification, verification, and optimization system | |
Norden | ANMAC: A novel architectural framework for network management and control using active networks |
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 | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090304 Termination date: 20160730 |
|
CF01 | Termination of patent right due to non-payment of annual fee |