专利名称：一种多节点通信故障的处理方法
技术领域：
本发明涉及通用多协议标签交换(GMPLS)技术，尤其涉及GMPLS中多节点通信故障的处理方法。
背景技术：
目前，在互联网协议(IP)业务高速增长所产生的带宽需求以及波分复用技术所引入的新型带宽利用模式的双重驱动下，IP业务的突发性和不确定性要求能够实现网络带宽的动态分配，而传统的静态光传输网难以满足动态分配的需求，因此智能光网络应运而生。智能光网络直接在光纤网络上引入了以IP为核心的智能控制技术，从而有效支持连接的动态建立与拆除，并且基于流量工程对网络资源进行合理的按需分配，能够提供良好的网络保护/恢复性能。
智能光网络中引入了GMPLS控制平面，使得网络在发生故障时具有强大的生存能力，实现带宽的动态申请、释放和重新配置。简化了网络管理，提供了新的增值业务。基于IP的GMPLS信令协议在被运用到电信级光传输网络时，所面临的最大挑战是稳定性和安全性问题。为了最大程度地保证业务不被中断，任何控制平面的故障都不应该影响到传输平面已经建立的业务并导致业务中断。在实际应用中，无论控制平面中一个还是连续多个控制节点出现故障时，网络都必须对控制平面故障具备良好的隔离和恢复能力。在一点或连续多个控制节点失效并恢复后，失效前所建立的业务在控制节点相关的信令状态必须能够恢复正常。
针对节点通信故障的处理，互联网工程任务组请求注解(IETF RFC)3473中定义了带流量工程的资源预留协议(RSVP-TE)，对控制平面中节点的重启进行恢复处理。
图1示出了现有的节点重启处理方法的流程图。参见图1，该方法包括在步骤101中，节点B掉电，节点A接收不到来自于节点B的HELLO消息。
节点A和节点B为GMPLS控制平面上的两个节点，在节点A与节点B均处于正常状态时，通过互发HELLO消息来相互通告控制平面软件的运行状态，并且通过周期性地发送刷新消息，来对两节点中的控制状态信息进行刷新。在节点B发生掉电后，无法向节点A发送HELLO消息。
在步骤102中，节点A启动恢复等待定时器(Restart_Timer)，进行自刷新。
当存在同时经过节点A和节点B的标签交换路径(LSP)时，节点A确定接收不到来自于节点B的HELLO消息后，启动自身的恢复等待定时器。此后，节点A不会再周期性地向节点B发送对应于该LSP的刷新消息，而是通过维持与该LSP相关的控制状态信息来实现自刷新。换言之，节点A在接收不到来自于邻居节点B的周期性刷新消息时，在恢复等待定时器计时期间仍然保持该LSP对应的控制状态信息。如果在恢复等待定时器超时后仍然未接收到邻居节点的刷新消息，则将未被刷新的LSP删除。
更具体地说，对于正常运行的LSP而言，其上的每个节点均会接收到来自于上游节点的Path消息以及来自于下游节点的预留(RESV)消息，节点中会建立针对该LSP的路径状态块(PSB)和预留状态块(RSB)，分别用于保存Path消息和RESV消息中携带的控制状态信息，例如标签值、带宽值、LSP经过的路由信息等。节点根据自身PSB中的信息，向其下游邻居节点发送Path消息，根据RSB中的信息，向其上游邻居节点发送RESV消息。由于节点发生掉电后无法向其上游邻居节点发送RESV消息、并且也无法向其下游邻居节点发送Path消息，因此上游邻居节点中的RSB无法被周期刷新，即节点A对自身中与节点B相关的RSB进行自刷新。
在步骤103中，节点A不断向节点B发送HELLO消息，请求节点B应答。
在步骤104～105中，节点B上电重启，启动恢复重启定时器(RecoveryTimer)，并向节点A发送HELLO消息，指明节点B已重启。
节点B中恢复重启定时器的作用在于节点B要求其邻居节点在该恢复重启定时器超时之前，完成所有经过节点B与节点A的LSP的控制状态信息的恢复。在恢复重启定时器超时后，节点B删除未被恢复的LSP。
HELLO消息中通常包含源实例(src-instance)和目的实例(dst-instance)等信元。其中src-instance中填写有发送HELLO消息的节点在正常运行时统一的常数值，该数值可以被掉电保存，节点重启后在掉电保存值的基础上加1；dst-instance中填写有最近一次收到对端节点发来的HELLO消息中包含的src-instance值，如果一直接收不到对端的HELLO消息，或者重启后第一次发送HELLO消息，该信元中的数值为0。
当节点发生掉电重启后，在该节点所发送的HELLO消息中的src-instance值填写的是通信链路中断前的值+1，dst-instance值为0；当节点本身正常运行、但节点间通信链路中断时，节点所发送的HELLO消息中的src-instance值等于通信链路中断前的值，并且dst-instance值为0。接收到HELLO消息的节点根据该消息中所携带的src-instance和dst-instance值的变化组合来确定邻居节点是发生了重启还是仅仅发生了通讯链路中断。
在步骤106～107中，节点A停止恢复等待定时器，停止对与经过节点A和节点B的LSP相关的控制状态信息的自刷新，并且向节点B发送携带有恢复标签(Recovery_label)的路径(Path)消息。
当节点A通过来自于节点B的HELLO消息确定节点B重启之后，根据自身的PSB中的控制状态信息，通过Path消息对经过节点A和B的LSP发起恢复操作，并且每一条LSP对应一条Path消息。
在步骤108～109中，节点B向节点A返回针对Path消息的响应(ACK)消息，指明节点B接收到了来自于节点A的Path消息，并且该节点B根据接收到的Path消息对相关的LSP的控制状态信息进行恢复处理。
由于节点B在掉电时PSB中的控制状态信息已丢失，因此节点B接收到节点A发送过来的Path消息后，创建对应的PSB，并在该PSB中记录Path消息中包含的上游方向的控制状态信息。另外，如果经过节点B的LSP还存在下游节点，则节点B会向该下游节点发送Path消息，下游节点也会向节点B发送RESV消息，并且当节点B接收到该RESV消息后，创建对应的RSB，记录RESV消息中的控制状态信息。节点B中PSB和RSB的建立完成，代表着完成对应LSP的恢复。
在步骤110中，重启恢复定时器超时，节点B删除未被恢复的LSP。
在节点B中的重启恢复定时器停止计时后，如果节点B中仍然存在未被恢复控制状态信息的LSP，则这些LSP被删除。
至此，完成现有的节点重启处理流程。
上述流程针对的是单节点重启的情况，当一条LSP路径上存在连续多个节点发生重启的情况时，依据上述流程进行处理，会导致该条LSP被删除。
具体而言，假设存在一条依次经过节点A、B、C和D的LSP，节点B和C掉电，并且上游节点B先重启，下游节点C需要较长时间才能够重启。当节点B重启后，节点A根据来自于节点B的HELLO消息确定节点B重启，则向节点B发送Path消息，节点B根据来自于节点A的Path消息恢复相应的PSB。但是，由于节点C尚未重启，则节点B无法接收到来自于节点C的RESV消息，无法对RSB进行恢复，从而无法向节点A发送RESV消息对节点A中的RSB进行刷新。这样，节点A自重新接收到来自于节点B的HELLO消息后，就停止了自刷新，如果节点A长时间得不到来自于节点B的RESV刷新消息，就会导致节点A中对应的RSB被节点A删除。然后节点A向节点B发出路径删除(Path_Tear)消息，通知节点B删除本地的PSB，进而导致对应的LSP被删除。
如果依次经过节点A、B、C和D的LSP路径上节点B和C掉电，并且下游节点C先重启，上游节点B需要较长时间才能够重启，那么节点C在重启后无法收到来自于节点B的Path消息。因此节点C上的PSB无法被恢复，而节点D收到节点C重启后发来的HELLO消息后，会停止对PSB的自刷新处理，从而节点D上的PSB会因为长时间收不到C节点发来的Path消息而超时被删除，并且节点D在自身的RSB对应的定时器超时后，会向节点C发送预留删除(Resv_Tear)消息，通知节点D删除本地的RSB，进而导致对应的LSP被删除。
可见，应用现有的节点重启处理方法，在LSP路径上多个节点发生通信故障时，无法可靠地恢复该LSP，从而使得控制平面的故障影响到传送平面的业务。
发明内容
有鉴于此，本发明的目的在于提供一种多节点通信故障的处理方法，能够在LSP路径上多个节点出现通信故障时，可靠地恢复该LSP。
依据本发明思想的方法包括以下步骤A.标签交换路径LSP上至少一个节点发生重启，重启节点确定与邻居节点处于控制通道通信中断状态；B.LSP路径上的节点在恢复等待时间内维持所述节点内该LSP对应的控制状态信息，并且当所述重启节点与邻居节点在所述恢复等待时间内恢复通信时，LSP路径上的节点对该LSP对应的控制状态信息执行恢复处理。
较佳地，步骤A所述至少一个节点发生重启之后，该方法进一步包括LSP路径上距离重启节点最近的正常节点向所述重启节点发送恢复消息，所述重启节点根据接收到的恢复消息，对所述LSP对应的控制状态信息进行恢复。
较佳地，所述步骤B之前，该方法进一步包括所述重启节点发出通信中断故障信息，所述LSP路径上距离重启节点最近的正常节点接收到所述通信故障信息后，按照所述恢复等待时间计时；步骤B所述重启节点与所述邻居节点恢复通信之后，该方法进一步包括所述LSP路径上距离重启节点最近的正常节点停止计时。
较佳地，所述步骤B之前，该方法进一步包括所述重启节点向所述LSP路径上距离重启节点最近的正常节点发出通信故障信息，并按照所述恢复等待时间计时；步骤B所述重启节点与所述邻居节点恢复通信的之后，该方法进一步包括所述重启节点停止计时。
较佳地，所述邻居节点为所述重启节点的下游节点，则所述步骤B包括B11.LSP路径上距离重启节点最近的上游方向的正常节点通过自刷新处理来维持该LSP对应的预留状态块RSB控制状态信息；B12.在所述恢复等待时间内所述重启节点确定与所述邻居节点恢复通信，并且所述重启节点向所述邻居节点发送恢复消息，所述邻居节点判断自身是否为LSP路径的目的节点，如果是，则执行步骤B13，否则，执行步骤B14；B13.所述邻居节点根据接收到的恢复消息，恢复自身中LSP对应的PSB和RSB控制状态信息，并向所述重启节点发送恢复应答消息，所述重启节点根据接收到的恢复应答消息，恢复自身中LSP对应的RSB控制状态信息，并且所述邻居节点沿上游方向将恢复应答消息逐跳发送至该LSP路径上的距离重启节点最近的上游方向的正常节点或者源节点，结束本处理流程；B14.所述邻居节点根据接收到的恢复消息，恢复自身中该LSP对应的PSB控制状态信息，并沿下游方向将恢复消息逐跳发送至所述LSP路径上距离重启节点最近的正常节点，接收到恢复消息的下游节点对自身中LSP对应的PSB控制状态信息进行恢复或者同步，进入正常刷新处理，然后LSP路径上距离重启节点最近的下游方向的正常节点沿上游方向将恢复应答消息逐跳发送至所述LSP路径上的距离重启节点最近的上游方向的正常节点或者源节点。
较佳地，步骤B11所述LSP路径上距离重启节点最近的上游方向的正常节点维持RSB控制状态信息的同时，该方法进一步包括该LSP路径上所述邻居节点的下游邻居节点在自身的重启定时时间内通过自刷新处理来维持该LSP对应的路径状态块PSB控制状态信息。
较佳地，所述邻居节点为所述重启节点的上游节点，则所述步骤B包括B21.所述LSP路径上距离重启节点最近的下游方向的正常节点通过自刷新处理来维持该LSP对应的PSB控制状态信息；
B22.在所述恢复等待时间内所述重启节点确定与所述邻居节点恢复通信，并且所述重启节点向所述邻居节点发送恢复消息，所述邻居节点判断自身是否为所述LSP路径上的源节点，如果是，则执行步骤B23，否则，执行步骤B24；B23.所述邻居节点根据接收到的恢复消息，恢复自身中LSP对应的PSB控制状态信息，并且所述邻居节点沿下游方向将恢复消息逐跳发送至所述LSP路径上距离重启节点最近的下游方向的正常节点，所述LSP路径上距离重启节点最近的下游方向的正常节点沿上游方向逐跳将恢复应答消息发送给所述源节点，接收到所述恢复应答消息的节点对自身中LSP对应的RSB控制状态信息进行恢复或同步，进入正常刷新处理，并结束本处理流程；B24.所述邻居节点根据接收到的恢复消息，恢复自身中LSP对应的PSB控制状态信息，并沿下游方向将恢复消息逐跳发送至所述LSP路径上距离重启节点最近的下游方向的正常节点，所述LSP路径上距离重启节点最近的下游方向的正常节点沿上游方向将恢复应答消息逐跳发送至所述LSP路径上距离重启节点最近的上游方向的正常节点，接收到恢复应答消息的上游节点对自身中LSP对应的RSB控制状态信息进行恢复或同步，进入正常刷新处理。
较佳地，步骤B21所述LSP路径上距离重启节点最近的下游方向的正常节点维持PSB控制状态信息的同时，该方法进一步包括该LSP路径上所述邻居节点的上游邻居节点在自身的重启定时时间内通过自刷新处理来维持该LSP对应的路径状态块RSB控制状态信息。
较佳地，所述步骤B之前，该方法进一步包括所述重启节点收到恢复消息后构造正常的恢复应答消息，发送给所述LSP路径上距离所述重启节点最近的正常节点，并且按照所述恢复等待时间计时；步骤B所述重启节点确定与所述邻居节点恢复通信之后，该方法进一步包括所述重启节点停止计时。
较佳地，所述邻居节点为所述重启节点的下游节点，则所述步骤B包括B31.所述重启节点根据上游方向节点发来的恢复消息以及自身保存的传送平面信息，在自身创建LSP对应的RSB，通过自刷新处理来维持该RSB中的控制状态信息，并且所述重启节点构造恢复应答消息，发送给所述LSP路径上距离重启节点最近的上游方向的正常节点；B32.所述LSP路径上距离重启节点最近的上游方向的正常节点根据接收到的恢复应答消息，对自身中LSP对应的控制状态信息进行刷新；B33.在所述恢复等待时间内所述重启节点确定与所述邻居节点恢复通信后，所述重启节点向所述邻居节点发送恢复消息，所述邻居节点判断自身是否为LSP路径的目的节点，如果是，则执行步骤B34，否则，执行步骤B35；B34.所述邻居节点恢复自身中LSP对应的PSB和RSB控制状态信息，并向所述重启节点发送恢复应答消息，接收到恢复应答消息的所述重启节点恢复自身中LSP对应的RSB控制状态信息，所述重启节点与所述邻居节点进入正常刷新处理，并结束本处理流程；B35.所述邻居节点根据接收到的恢复消息，恢复自身中LSP对应的PSB控制状态信息，并沿下游方向将恢复消息逐跳发送至所述LSP路径上离重启节点最近的下游方向的正常节点，接收到恢复消息的下游节点对自身中LSP对应的PSB控制状态信息进行恢复，进入正常刷新处理，并且所述LSP路径上距离重启节点最近的下游方向的正常节点沿上游方向将恢复应答消息逐跳发送至所述LSP路径上距离重启节点最近的上游方向的正常节点或源节点，接收到所述恢复应答消息的节点对自身中LSP对应的RSB控制状态信息进行恢复或同步，并进入正常的刷新处理。
较佳地，所述邻居节点为所述重启节点的上游节点，则所述步骤B包括B41.所述重启节点根据下游方向节点发来的恢复消息以及自身保存的传送平面信息，在自身创建LSP对应的PSB，通过自刷新处理来维持该PSB中的控制状态信息，并且所述重启节点构造恢复消息，发送给所述LSP路径上距离重启节点最近的下游方向的正常节点；B42.所述LSP路径上距离重启节点最近的下游方向的正常节点根据接收到的恢复消息，对自身中LSP对应的控制状态信息进行同步并向所述重启节点方向逐跳发送恢复应答消息，收到恢复应答消息的节点恢复自身中LSP对应的RSB控制状态信息，进入正常刷新处理；B43.在所述恢复等待时间内所述重启节点确定与所述邻居节点恢复通信，所述重启节点向所述邻居节点发送恢复消息，所述邻居节点判断自身是否为LSP路径的源节点，如果是，则执行步骤B44，否则，执行步骤B45；B44.所述邻居节点根据接收到的恢复消息，恢复或同步自身中LSP对应的PSB控制状态信息，并向所述重启节点发送恢复消息，接收到恢复消息的所述重启节点恢复自身中LSP对应的PSB控制状态信息，并向所述邻居节点发送恢复应答消息，收到恢复应答消息的所述邻居节点恢复自身中LSP对应的RSB控制状态信息，进入正常刷新处理，并结束本处理流程；B45.所述邻居节点根据接收到的恢复消息，恢复自身中该LSP对应的PSB控制状态信息，并向所述重启节点发送恢复消息，接收到恢复消息的所述重启节点恢复自身中LSP对应的PSB控制状态信息，并向所述邻居节点发送恢复应答消息，收到恢复应答消息的所述邻居节点恢复或同步自身中LSP对应的RSB控制状态信息，进入正常刷新处理。
较佳地，预先设置将所述恢复等待时间作为计时时间的恢复等待定时器，则所述按照恢复等待时间计时为启动恢复等待定时器；所述停止计时为停止所述恢复等待定时器。
较佳地，所述按照恢复等待时间计时之前，该方法进一步包括设置将所述恢复等待时间作为计时时间的恢复等待定时器；所述按照恢复等待时间计时为启动所述恢复等待定时器；所述停止计时为停止所述恢复等待定时器。
较佳地，所述重启节点与邻所述居节点处于控制通道通信中断状态为所述邻居节点尚未重启或者所述重启节点与所述邻居节点间的通信链路中断。
较佳地，步骤B所述维持该LSP对应的控制状态信息之后，该方法进一步包括在所述恢复等待时间超时后，所述重启节点与所述邻居节点仍处于控制通道中断状态，则所述LSP路径上的节点删除该LSP对应的控制状态信息，并结束本处理流程。
由上述的技术方案可见，依据本发明思想的方法能够在LSP路径上多个节点出现通信故障时，可靠地恢复该LSP。具体而言，本发明具有如下有益效果当LSP路径上由于节点长时间掉电不重启或者节点间链路中断等原因而造成连续多个节点之间发生通信故障，并且各个节点间恢复正常通信的时间不一致时，LSP路径上的节点在恢复等待时间内，维持上述节点内LSP对应的控制状态信息进行自刷新；并且，如果发生通信故障的所有节点在该恢复等待时间之内均恢复正常，则对该LSP路径上节点内未被恢复的控制状态信息进行恢复，有效地防止LSP的异常删除，提高LSP恢复的可靠性。
另外，本发明在由于非通信中断故障而导致LSP无法恢复的情况下，能够实现LSP的快速删除，从而能够快速准确地拆除故障连接，有利于快速释放该LSP占用的网络资源，提高网络资源的利用率。
下面将通过参照附图详细描述本发明的示例性实施例，使本领域的普通技术人员更清楚本发明的上述及其它特征和优点，附图中图1为现有的节点重启处理方法的流程图；图2为本发明多节点通信故障处理方法的示例性流程图；图3为本发明实施例1、2和3中LSP路径上节点运行状况的示意图；图4为本发明实施例1中多节点通信故障处理方法的流程图；图5为本发明实施例2中多节点通信故障处理方法的流程图；图6为本发明实施例3中多节点通信故障处理方法的流程图；图7为本发明实施例4和5中LSP路径上节点运行状况的示意图；图8为本发明实施例4中多节点通信故障处理方法的流程图；图9为本发明实施例5中多节点通信故障处理方法的流程图。
具体实施例方式
为使本发明的目的、技术方案更加清楚明白，以下参照附图并举实施例，对本发明做进一步的详细说明。
本发明为一种多节点通信故障的处理方法，其基本思想是LSP路径上距离重启节点最近的正常节点在恢复等待时间内对该LSP对应的控制状态信息进行自刷新。
图2示出了本发明中多节点通信故障处理方法的示例性流程图。如图2所示，该方法包括在步骤201中，LSP路径上至少一个节点发生重启，重启节点确定与邻居节点处于控制通道通信中断状态；在步骤202中，LSP路径上的节点在恢复等待时间内维持所述节点内该LSP对应的控制状态信息，并且当重启节点与邻居节点在所述恢复等待时间内恢复通信时，LSP路径上的节点执行对该LSP对应的控制状态信息的恢复处理。
在本发明的方法中，如果在所述恢复等待时间超时后，重启节点与邻居节点之间仍然处于控制通道通信中断状态，则所述LSP路径上的节点删除该LSP对应的控制状态信息。
依据本发明思想的方法包括如下三种处理方式1.在确定重启节点与其邻居节点间通信中断后，重启节点发出通信中断故障信息，LSP路径上距离重启节点最近的正常节点接收到该通信中断故障信息后，按照恢复等待时间进行计时，LSP路径上的节点在该恢复等待时间内通过维持LSP对应的控制状态信息来执行恢复等待处理，并且在重启节点与邻居节点恢复正常通信时，停止恢复等待处理且恢复该LSP的控制状态信息；2.在确定重启节点与其邻居节点间通信中断后，重启节点发出通信中断故障信息，并且该重启节点按照恢复等待时间进行计时，LSP路径上的节点在该恢复等待时间内通过维持LSP对应的控制状态信息来执行恢复等待处理，并且在重启节点与邻居节点恢复正常通信时，停止恢复等待处理且恢复该LSP的控制状态信息；3.在确定重启节点与其邻居节点间通信中断后，重启节点构造正常的恢复应答消息，向LSP路径上的正常节点发送，并且该重启节点按照恢复等待时间进行计时，LSP路径上的节点在该恢复等待时间内通过维持LSP对应的控制状态信息来执行恢复等待处理，当重启节点与邻居节点恢复正常通信时，停止恢复等待处理且恢复该LSP的控制状态信息。
重启节点与邻居节点处于控制通道通信中断状态的原因包括邻居节点掉电后尚未重启或者重启节点与邻居节点间的通信链路中断而邻居节点正常运行。上述任意一种原因导致重启节点与邻居节点处于控制通道中断状态时，依据本发明思想的多节点故障处理方法所执行的操作都相同。
下面以重启节点的邻居节点长时间不重启为例，通过五个实施例，对本发明中的多节点通信故障处理方法进行说明。
实施例1本实施例中以依次经过节点A、B、C和D的LSP为例进行说明。图3示出了本实施例中LSP路径上节点运行状况的示意图。如图3所示，节点B和节点C掉电，并且节点B发生重启、节点C长时间无法重启。节点B为重启节点，节点C为节点B的邻居节点，节点A为距离重启节点B最近的上游方向的正常节点，节点D为距离重启节点B最近的下游方向的正常节点。这里依据方式1，在LSP路径上距离重启节点最近的正常节点，即节点A上设置恢复等待时间。
图4示出了本实施例中多节点通信故障处理方法的流程图。参见图4，该方法包括在步骤401～402中，节点B上电重启，向节点A和节点C发送HELLO消息，并且节点B通过HELLO消息机制获知节点B与节点C处于通信故障状态。
这里节点B所发出的HELLO消息中，src-instance值是掉电前的值+1，dst-instance值为0，以便节点A和节点C知晓节点B的重启。
节点B在向节点C发出HELLO消息之后，接收不到节点C对该HELLO消息的响应，因此判定节点B与节点C之间处于通信中断状态。造成两节点通信中断的原因不仅可以是节点C仍然掉电尚未重启，还可以是节点B和节点C之间的通信链路出现故障。
在步骤403～404中，节点A向节点B发送恢复消息，通知节点B恢复LSP对应的控制状态信息，节点B根据接收到的恢复消息执行恢复操作，并且将节点B和节点C之间通信中断故障信息通知给节点A。
这里，节点A向节点B发送诸如携带有恢复标签的Path消息之类的恢复消息，以便节点B根据接收到的恢复消息，建立PSB并将恢复消息中携带的状态控制信息保存在该PSB中，以实现本地控制状态信息的恢复。
在正常情况下，节点B在完成恢复PSB之后，向节点C发送恢复消息。但是，由于节点C尚未重启，使得节点B中的RSB无法按照RFC3473中描述的正常协议流程被恢复，所以节点B沿接收到的恢复消息相反的方向，向节点A通知节点B和节点C通信中断。
在步骤405中，节点A启动按照恢复等待时间进行计时的恢复等待定时器，通过自刷新处理来维持LSP对应的RSB控制状态信息。
节点A通过来自于节点B的通信中断故障信息，确定LSP暂时无法恢复，则启动按照恢复等待时间进行计时的恢复等待定时器，并在该定时器计时期间对节点A中该LSP对应的RSB中的控制状态信息进行自刷新，以防止该RSB对应的定时器超时而删除该RSB。这里的恢复等待定时器可以预先设置并在本步骤中启动，也可以在本步骤中设置并启动。
此外，节点C的下游邻居节点D由于与节点C也处于通信中断状态，因此在节点D中的恢复等待定时器超时之前对该LSP对应的控制状态信息进行自刷新，例如对节点D中该LSP对应的PSB进行自刷新。
在步骤406～407中，节点C在节点A中的恢复等待定时器超时之前重启，向节点B和节点D发送HELLO消息，指明节点C上电重启。
在步骤408～412中，节点B向节点C发送恢复消息，节点C完成对控制状态信息的恢复后，向节点D发送恢复消息，节点D进入正常的刷新处理；节点D通过节点C、节点B向节点A发送恢复应答消息，节点A停止恢复等待定时器，进入正常的刷新处理。
节点C接收到恢复消息后，判断自身是否为LSP的目的节点。在节点C是目的节点的情况下，对节点C中该LSP对应的PSB和RSB中的控制状态信息进行恢复，并向节点B发送诸如RESV消息之类的恢复应答消息；节点B根据接收到的恢复应答消息，恢复该节点中LSP对应的RSB，并向节点A发送恢复应答消息；节点A接收到恢复应答消息后，停止自身的恢复等待定时器并开始正常的控制状态信息刷新处理。在节点C不是目的节点的情况下，对节点C中LSP对应的PSB中的控制状态信息进行恢复，并向下游方向的正常节点D转发恢复消息；节点D接收到恢复消息后，对LSP对应的PSB进行同步，并开始正常的控制状态信息刷新处理；然后节点D沿上游方向逐跳发送恢复应答消息，接收到恢复应答消息的节点C和节点B对LSP对应的RSB中的控制状态信息进行恢复，节点A在接收到恢复应答消息后，停止自身的恢复等待定时器并开始正常的控制状态信息刷新处理。
如果由于节点间链路中断而导致节点B与节点C通信故障，则在节点C为目的节点的情况下，节点C接收到恢复消息后，恢复自身的控制状态信息并开始正常的刷新处理。
至此，完成本实施例中多节点通信故障处理流程。
以上为节点C在节点A中的恢复等待定时器超时之前重启的情况，当恢复等待定时器的计时时间到达预先设置的恢复等待时间，即该定时器停止计时后，节点C仍未重启，则节点A发起删除未被恢复的LSP的处理，节点B收到关于删除LSP的消息后删除该节点中该LSP对应的控制状态信息。节点D由于本地的重启定时时间超时而删除该节点内LSP对应的控制状态信息，或者，即使在A节点所设置的恢复等待定时器超时后的某个时间节点C重启，节点D也会因为一直接收不到上游节点C发来的恢复消息而将该节点D上LSP对应的控制状态信息删除。
使用上述流程，当LSP路径上连续多个节点发生通信故障，并且各个节点实现正常通信的时间不一致时，距离由故障恢复正常的节点最近的正常节点在所设置的恢复等待时间内，维持该节点内LSP对应的控制状态信息，进行自刷新；并且，如果发生通信故障的所有节点在该恢复等待时间之内均恢复正常，则对该LSP路径上节点内未被恢复的控制状态信息进行恢复，有效地防止LSP的异常删除，提高LSP恢复的可靠性。如果LSP路径上发生其它的非通讯故障，例如上游节点中已经删除了该LSP的控制状态信息，下游节点会快速删除该节点中的LSP控制状态信息，则本实施例可以按照RFC3473协议中描述的方法将该LSP删除，从而能够快速准确地拆除故障连接，有利于快速释放该LSP占用的网络资源，提高网络资源的利用率。
实施例2本实施例中仍以图3所示的LSP为例，节点B发生重启、节点C长时间无法重启。这里依据方式2在重启节点上，即节点B上设置恢复等待时间，并且向节点A发送通信中断的故障信息。
图5示出了本实施例中多节点通信故障处理方法的流程图。参见图5，该方法包括在步骤501～502中，节点B上电重启，向节点A和节点C发送HELLO消息，并且节点B通过HELLO消息机制获知节点B和节点C处于通信故障状态。
这里节点B所发出的HELLO消息中，src-instance值是掉电前的值+1，dst-instance值为0，以便节点A和节点C知晓节点B的重启。
节点B在向节点C发出HELLO消息之后，接收不到节点C对该HELLO消息的响应，因此判定节点B与节点C之间处于通信中断状态。造成两节点通信中断的原因不仅可以是节点C仍然掉电尚未重启，还可以是节点B和节点C之间的通信链路出现故障。
在步骤503～505中，节点A向节点B发送恢复消息，通知节点B恢复LSP对应的控制状态信息，节点B根据接收到的恢复消息执行恢复操作，然后节点B启动恢复等待定时器，并且节点B将自身与节点C之间的通信中断故障信息通知给节点A，节点A对LSP对应的RSB控制状态信息进行自刷新处理。
这里，节点A向节点B发送诸如携带有恢复标签的Path消息之类的恢复消息，以便节点B根据接收到的恢复消息，建立PSB并将恢复消息中携带的状态控制信息保存在该PSB中，以实现本地控制状态信息的恢复。
由于节点C未重启，节点B中的RSB无法按照RFC3473中描述的正常协议流程被恢复，因此节点B在完成PSB的恢复之后，启动按照恢复等待时间进行计时的恢复等待定时器，并将节点B与节点C之间出现通信故障的情况通知给节点A。节点A接收到来自于节点B的通信中断故障信息后，对该节点中LSP对应的RSB控制状态信息进行自刷新。这里的恢复等待定时器可以预先设置并在本步骤中启动，也可以在本步骤中设置并启动。
另外，节点C的下游邻居节点D由于与节点C也处于通信中断状态，因此在节点D中的恢复等待定时器超时之前对该LSP对应的控制状态信息进行自刷新，例如对节点D该LSP对应的PSB进行自刷新。
在步骤506～507中，节点C在节点A中的恢复等待定时器超时之前重启，向节点B和节点D发送HELLO消息，指明节点C上电重启。
在步骤508～512中，节点B停止恢复等待定时器，进入正常的刷新处理，并向节点C发送恢复消息，节点C完成对控制状态信息的恢复后，向节点D发送恢复消息，节点D进入正常的刷新处理；节点D通过节点C、节点B向节点A发送恢复应答消息，。
节点B在通过HELLO机制获知节点C重启后，停止自身的恢复等待定时器。节点C接收到恢复消息后，判断自身是否为LSP的目的节点。在节点C是目的节点的情况下，对节点C中该LSP对应的PSB和RSB中的控制状态信息进行恢复，并向节点B发送诸如RESV消息之类的恢复应答消息；节点B根据接收到的恢复应答消息，恢复该节点中LSP对应的RSB，并向节点A发送恢复应答消息；节点A接收到恢复应答消息后同步自身RSB中的控制状态信息并开始执行正常的控制状态信息刷新处理。在节点C不是目的节点的情况下，对节点C中LSP对应的PSB中的控制状态信息进行恢复，并向下游方向的正常节点D转发恢复消息；节点D接收到恢复消息后，对LSP对应的PSB进行同步，并开始正常的控制状态信息刷新处理；然后节点D沿上游方向逐跳发送恢复应答消息，接收到恢复应答消息的节点C和节点B对LSP对应的RSB中的控制状态信息进行恢复，节点A在接收到恢复应答消息后同步自身RSB中的控制状态信息并开始正常的控制状态信息刷新处理。
至此，完成本实施例中多节点通信故障处理流程。
以上为节点C在节点B中的恢复等待定时器超时之前重启的情况，当恢复等待定时器的计时时间到达预先设置的恢复等待时间，即该定时器停止计时后，节点C仍未重启，则节点B向节点A方向发起删除未被恢复的LSP的处理。节点A收到节点B关于删除LSP的消息后，删除该节点中LSP对应的控制状态信息。节点D由于本地的重启定时时间超时而删除该节点内LSP对应的控制状态信息，或者，即使在节点A所设置的恢复等待定时器超时后的某个时间节点C重启，节点D也会因为一直接收不到上游节点C发来的恢复消息而将该节点D上LSP对应的控制状态信息删除。
使用上述流程，当LSP路径上连续多个节点发生通信故障，并且各个节点实现正常通信的时间不一致时，重启节点在恢复等待时间内，维持该节点内LSP对应的控制状态信息；并且，如果发生通信故障的所有节点在该恢复等待时间之内均恢复正常，则对该LSP路径上的节点内未被恢复的控制状态信息进行恢复，有效地防止LSP的异常删除，提高LSP恢复的可靠性。如果LSP路径上发生其它非通讯故障，则本实施例可以按照RFC3473协议中描述的方法将该LSP快速删除，从而能够快速准确地拆除故障连接，有利于快速释放该LSP占用的网络资源，提高网络资源的利用率。
实施例3本实施例中仍以图3所示的LSP为例，节点B发生重启、节点C长时间无法重启。这里依据方式3在重启节点上，即节点B上设置恢复等待时间并构造正常的恢复应答消息向节点A发送。
图6示出了本实施例中多节点通信故障处理方法的流程图。参见图6，该方法包括在步骤601～602中，节点B上电重启，向节点A和节点C发送HELLO消息，并且节点B通过HELLO消息机制获知节点B和节点C之间处于通信故障状态。
节点B在向节点C发出HELLO消息之后，接收不到节点C对该HELLO消息的响应，因此判定节点B与节点C之间处于通信中断状态。造成两节点通信中断的原因不仅可以是节点C仍然掉电尚未重启，还可以是节点B和节点C之间的通信链路出现故障。
在步骤603～605中，节点A向节点B发送恢复消息，通知节点B恢复LSP对应的控制状态信息，节点B根据接收到的恢复消息执行恢复操作，然后节点B启动恢复等待定时器，并且根据A节点发来的恢复消息以及节点B中保存的传送平面信息在该节点内创建RSB，并构造正常的恢复应答消息后向A节点发送，节点A收到恢复应答消息后对LSP对应的RSB控制状态信息进行同步并开始正常的刷新处理。
这里，节点A向节点B发送诸如携带有恢复标签的Path消息之类的恢复消息，以便节点B根据接收到的恢复消息，建立PSB并将恢复消息中携带的状态控制信息保存在该PSB中，以实现本地控制状态信息的恢复。
由于节点C尚未重启，节点B中的RSB虽然能够向上游节点A方向正常发送诸如RESV消息之类的刷新消息，但由于节点B接收不到节点C发来的诸如RESV消息之类的刷新消息，所以该节点中只保存了部分的RSB控制状态信息。因此，节点B在完成PSB的恢复并完成部分RSB的恢复后，启动按照恢复等待时间进行计时的恢复等待定时器，并对节点B中LSP对应的RSB控制状态信息进行自刷新处理。同时，节点B构造正常的恢复应答消息发送给节点A。此种操作的目的在于，只有重启节点B处知晓与节点C处于通信中断状态，而LSP路径上的其他正常节点按照正常的方式对LSP进行刷新。
另外，节点C的下游邻居节点D由于与节点C也处于通信中断状态，因此在节点D中的恢复等待定时器超时之前对该LSP对应的控制状态信息进行自刷新，例如对节点D该LSP对应的PSB进行自刷新。
在步骤606～607中，节点C在节点B中的恢复等待定时器超时之前重启，向节点B和节点D发送HELLO消息，指明节点C上电重启。
在步骤608～611中，节点B停止恢复等待定时器，进入正常的刷新处理，并向节点C发送恢复消息，节点C完成对控制状态信息的恢复后，向节点D发送恢复消息，节点D进入正常的刷新处理；节点D通过节点C向节点B发送恢复应答消息。
节点B在通过HELLO机制获知节点C重启后，停止自身的恢复等待定时器。节点C接收到来自节点B的恢复消息后，判断自身是否为LSP的目的节点。在节点C是目的节点的情况下，对节点C中该LSP对应的PSB和RSB中的控制状态信息进行恢复，并向节点B发送诸如RESV消息之类的恢复应答消息；节点B根据接收到的恢复应答消息，恢复该节点中LSP对应的RSB中的所有状态数据，并和节点C开始进行正常的控制状态信息刷新处理；在节点C不是目的节点的情况下，对节点C中LSP对应的PSB中的控制状态信息进行恢复，并向下游方向的正常节点D转发恢复消息；节点D接收到恢复消息后，对LSP对应的PSB进行恢复，并开始正常的控制状态信息刷新处理；然后节点D沿上游方向逐跳发送正常的恢复应答消息，接收到恢复应答消息的节点C对LSP对应的RSB中的控制状态信息进行恢复，节点B在接收到恢复应答消息后，恢复所有的控制状态信息并在节点B和节点C之间开始正常的控制状态信息刷新处理。
至此，完成本实施例中多节点通信故障处理流程。
以上为节点C在节点B中的恢复等待定时器超时之前重启的情况，当恢复等待定时器的计时时间到达设置的恢复等待时间，即该定时器停止计时后，节点C仍未重启，则节点B向节点A方向发起删除未被恢复的LSP的处理。节点A收到关于删除LSP的消息后，删除该节点中与该LSP对应的控制状态信息。节点D由于本地的重启定时时间超时而删除本地与该LSP对应的控制状态信息，或者，即使在节点B所设置的恢复等待定时器超时后的某个时间节点C重启，节点D也会因为一直收不到上游节点C发来的恢复消息而导致节点D与该LSP对应的控制状态信息被删除。
使用上述流程，当LSP路径上连续多个节点发生通信故障，并且各个节点实现正常通信的时间不一致时，重启节点在恢复等待时间内，维持该节点内LSP对应的控制状态信息；并且，如果发生通信故障的所有节点在该恢复等待时间之内均恢复正常，则对该LSP路径上的节点内未被恢复的控制状态信息进行恢复，有效地防止LSP的异常删除，提高LSP恢复的可靠性。如果LSP路径上发生其它非通讯故障，则本实施例可以按照RFC3473协议中描述的方法将该LSP快速删除，从而能够快速准确地拆除故障连接，有利于快速释放该LSP占用的网络资源，提高网络资源的利用率。
实施例4本实施例中以依次经过节点A、B、C和D的LSP为例进行说明。图7示出了本实施例中节点运行状况示意图。如图7所示，节点B和节点C掉电，并且节点C发生重启、节点B长时间无法重启。节点C为重启节点，节点B为节点C的邻居节点，节点A为距离重启节点C最近的上游方向的正常节点，节点D为距离重启节点C最近的下游方向的正常节点。这里依据方式1，在LSP路径上距离重启节点最近的正常节点，即节点D上预先设置恢复等待时间。
图8示出了本实施例中多节点通信故障处理方法的流程图。参见图8，该方法包括在步骤801～802中，节点C上电重启，向节点B和节点D发送HELLO消息，并且节点C通过HELLO消息机制获知节点C和节点B处于通信故障状态。
节点C在向节点B发出HELLO消息之后，接收不到节点B对该HELLO消息的响应，因此判定节点B与节点C之间处于通信中断状态。造成两节点通信中断的原因不仅可以是节点B仍然掉电尚未重启，还可以是节点B和节点C之间的通信链路出现故障。
在步骤803～804中，节点D向节点C发送恢复消息，通知节点C恢复LSP对应的控制状态信息，节点C根据接收到的恢复消息执行恢复操作，并且将节点B和节点C之间的通信中断故障信息通知给节点D。
这里，节点D发出的恢复消息可以是Recovery Path消息。节点C根据接收到的恢复消息对自身LSP对应的PSB中的控制状态信息进行恢复。由于节点B尚未重启，因此节点C将与节点B之间发生通信中断的情况通知给节点D。
在步骤805中，节点D启动恢复等待定时器，对LSP对应的PSB控制状态信息进行自刷新处理。
节点D通过来自于节点C的通信中断故障信息，确定LSP暂时无法恢复，则启动按照预先设置的恢复等待时间进行计时的恢复等待定时器，并对节点D中该LSP对应的PSB中的控制状态信息进行自刷新，以防止该PSB对应的定时器超时而删除该PSB。并且，节点B的上游邻居节点A由于与节点B也处于通信中断状态，因此在节点A中的恢复等待定时器超时之前对该LSP对应的控制状态信息进行自刷新，例如对节点A该LSP对应的RSB进行自刷新。
在步骤806～807中，节点B在节点D中的恢复等待定时器超时之前重启，向节点A和节点C发送HELLO消息，指明节点B上电重启。
在步骤808～813中，节点A和节点C都向节点B发送恢复消息，节点B完成对控制状态信息的恢复后，向节点C发送恢复消息，节点C完成对控制状态信息的同步后，向节点D发送恢复消息；节点D收到恢复消息后停止恢复等待定时器并同步自身的控制状态信息，进入正常的刷新处理；节点D通过节点C、节点B向上游方向的正常节点A发送恢复应答消息。
节点B接收到下游方向的节点C发来的恢复消息后，判断自身是否为LSP的源节点。
在节点B是源节点的情况下，对节点B中该LSP对应的PSB和RSB中的控制状态信息进行恢复，并向节点C发送诸如携带有恢复标签的Path消息之类的恢复消息；节点C根据接收到的恢复消息，同步该节点中LSP对应的PSB，并向节点D发送恢复消息；节点D接收到恢复消息后，同步自身的控制状态信息并停止自身的恢复等待定时器，开始正常的控制状态信息刷新处理；节点D通过节点C、节点B向上游方向的正常节点A逐跳发送诸如RESV消息的恢复应答消息，节点C和节点B收到恢复应答消息后恢复本地的RSB控制状态信息，节点A收到恢复应答消息后同步本地的RSB控制状态信息。进入正常的刷新处理。
在节点B不是LSP的源节点的情况下，节点B维持自身已经存在的部分PSB控制状态信息并对下游方向执行正常的刷新处理。直到节点B收到上游方向节点A发来的恢复消息后才向节点C发送诸如携带有恢复标签的Path消息之类的恢复消息；节点C根据接收到的恢复消息，同步该节点中LSP对应的PSB，并向节点D发送恢复消息；节点D接收到恢复消息后，同步自身的控制状态信息并停止自身的恢复等待定时器，开始正常的控制状态信息刷新处理；节点D通过节点C、节点B向上游方向的正常节点A逐跳发送诸如RESV消息的恢复应答消息，节点C和节点B收到恢复应答消息后恢复本地的RSB控制状态信息，节点A收到恢复应答消息后同步本地的RSB控制状态信息。进入正常的刷新处理。
至此，完成本实施例中多节点通信故障处理流程。
以上为节点B在节点D中的恢复等待定时器超时之前重启的情况，当恢复等待定时器的计时时间到达预先设置的恢复等待时间，即该定时器停止计时后，节点B仍未重启，则节点D发起删除未被恢复的LSP的处理。
本实施例与实施例1相似，当LSP路径上连续多个节点发生通信故障，并且各个节点实现正常通信的时间不一致时，能够有效地防止LSP的异常删除，提高LSP恢复的可靠性；并且当LSP路径上发生其它非通信故障时，本实施例能够结合RFC3437中描述的方法将该LSP删除，从而能够快速准确地拆除故障连接，有利于快速释放该LSP占用的网络资源，提高网络资源的利用率。
实施例5本实施例中仍以图7所示的LSP为例，节点C重启、节点B长时间无法重启。这里依据方式2，在重启节点上，即节点C上预先设置恢复等待定时间。
图9示出了本实施例中多节点通信故障处理方法的流程图。参见图9，该方法包括在步骤901～902中，节点C上电重启，向节点B和节点D发送HELLO消息，并且节点C通过HELLO消息机制获知节点C和节点B处于通信故障状态。
在步骤903～905中，节点D向节点C发送恢复消息，通知节点C恢复LSP对应的控制状态信息，节点C根据接收到的恢复消息执行恢复操作，然后节点C启动恢复等待定时器，并且将节点B和节点C之间的通信中断故障信息通知给节点D，节点D对LSP对应的PSB控制状态信息进行自刷新处理。
在步骤906～907中，节点B在节点D中的恢复等待定时器超时之前重启，向节点A和节点C发送HELLO消息，指明节点B上电重启。
在步骤908～913中，节点A和C都向节点B发送恢复消息，节点B完成对控制状态信息的恢复后，向节点C发送恢复消息，节点C完成对控制状态信息的同步后停止恢复等待定时器并向节点D发送恢复消息止；节点D收到恢复消息后并同步自身的控制状态信息，进入正常的刷新处理；节点D通过节点C、节点B向上游方向的正常节点A发送恢复应答消息。
节点B接收到下游方向的节点C发来的恢复消息后，判断自身是否为LSP的源节点。
在节点B是源节点的情况下，对节点B中该LSP对应的PSB和RSB中的控制状态信息进行恢复，并向节点C发送诸如携带有恢复标签的Path消息之类的恢复消息；节点C根据接收到的恢复消息后同步该节点中LSP对应的PSB并停止自身的恢复等待定时器，向节点D发送恢复消息；节点D接收到恢复消息后，同步自身的控制状态信息，开始正常的控制状态信息刷新处理；节点D通过节点C、节点B向上游方向的正常节点A逐跳发送诸如RESV消息的恢复应答消息，节点C和节点B收到恢复应答消息后恢复本地的RSB控制状态信息，节点A收到恢复应答消息后同步本地的RSB控制状态信息。进入正常的刷新处理。
在节点B不是LSP的源节点的情况下，节点B维持自身已经存在的部分PSB控制状态信息并对下游方向执行正常的刷新处理。直到节点B收到上游方向A节点发来的恢复消息后才向节点C发送诸如携带有恢复标签的Path消息之类的恢复消息；节点C根据接收到的恢复消息，同步该节点中LSP对应的PSB并停止自身的恢复等待定时器，向节点D发送恢复消息；节点D接收到恢复消息后，同步自身的控制状态信息，开始正常的控制状态信息刷新处理；节点D通过节点C、节点B向上游方向的正常节点A逐跳发送诸如RESV消息的恢复应答消息，节点C和节点B收到恢复应答消息后恢复本地的RSB控制状态信息，节点A收到恢复应答消息后同步本地的RSB控制状态信息。进入正常的刷新处理。
至此，完成本实施例中多节点通信故障处理流程。
以上为节点B在节点C中的恢复等待定时器超时之前重启的情况，当恢复等待定时器的计时时间到达预先设置的恢复等待时间，即该定时器停止计时后，节点B仍未重启，则节点D删除未被恢复的LSP。
本实施例与实施例2相似，当LSP路径上连续多个节点发生通信故障，并且各个节点实现正常通信的时间不一致时，能够有效地防止LSP的异常删除，提高LSP恢复的可靠性；并且当LSP路径上发生其它非通信故障时，本实施例能够结合RFC3437中描述的方法将该LSP删除，从而能够快速准确地拆除故障连接，有利于快速释放该LSP占用的网络资源，提高网络资源的利用率。
另外，如果采用方式3来处理图7所示的LSP，则由节点C中的恢复等待定时器进行计时，并且节点C确定与节点B之间处于通信中断状态时，构造正常的恢复消息，发送给节点D。并且在节点B与节点C恢复通信后按照与实施例3相似的方式进行恢复处理。具体而言，节点C根据下游方向节点发来的恢复消息以及自身保存的传送平面信息，在自身创建LSP对应的PSB，通过自刷新处理来维持该PSB中的控制状态信息，并且节点C构造恢复消息，发送给LSP路径上距离该重启节点最近的下游方向的正常节点D。节点D根据接收到的恢复消息，对该节点中LSP对应的控制状态信息进行刷新并向该重启节点方向发送恢复应答消息，收到恢复应答消息的节点恢复该节点中LSP对应的RSB控制状态信息进入正常刷新处理。在恢复等待时间内节点C确定与节点B恢复通信，则节点C向节点B发送恢复消息，节点B判断自身是否为LSP路径的源节点。
在节点B是源节点的情况下，节点B恢复或同步自身中LSP对应的PSB控制状态信息，并向节点C发送恢复消息，节点C根据接收到的恢复消息同步该节点中LSP对应的PSB控制状态信息，停止自身的恢复定时器，并向节点B发送恢复应答消息，收到恢复应答消息的节点B恢复该节点中LSP对应的RSB控制状态信息进入正常刷新处理，并结束本处理流程。
在节点B不是源节点的情况下，节点B维持自身已经存在的部分PSB控制状态信息并对下游方向执行正常的刷新处理。节点B直到接收到上游方向节点A发来的恢复消息后，才向节点C发送诸如携带有恢复标签的Path消息之类的恢复消息；节点C根据接收到的恢复消息后，停止自身的恢复定时器，同步该节点中LSP对应的PSB控制状态信息，并经过节点B向上游方向的正常节点A发送恢复应答消息；收到恢复应答消息的节点B恢复该节点中LSP对应的RSB控制状态信息，并且节点A收到恢复应答消息后同步该节点中LSP对应的RSB控制状态信息，进入正常刷新处理，并结束本处理流程。
在上述的实施例1、2、4和5中，重启节点接收到来自于上游或者下游邻居节点的恢复消息之后，向正常的节点发送通信中断故障信息。重启节点也可以在未收到恢复消息时，在检测到与邻居节点间通信中断后，根据本节点预先记录的LSP路由信息，将通信中断故障信息发送给正常节点。
另外，上述五个实施例均为LSP中的节点因长时间不重启而发生通信故障的情况，依据本发明思想的方法还可以应用于重启节点与邻居节点运行正常，但是节点间通信链路中断而出现通信故障的情况。此时，发生重启的节点在重启后通过HELLO消息机制检测出自身与邻居节点之间的通信链路中断，此后可以按照上述任意一种实施例的方法进行操作。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种多节点通信故障的处理方法，其特征在于，该方法包括A.标签交换路径LSP上至少一个节点发生重启，重启节点确定与邻居节点处于控制通道通信中断状态；B.LSP路径上的节点在恢复等待时间内维持所述节点内该LSP对应的控制状态信息，并且当所述重启节点与邻居节点在所述恢复等待时间内恢复通信时，LSP路径上的节点对该LSP对应的控制状态信息执行恢复处理。
2.如权利要求1所述的方法，其特征在于，步骤A所述至少一个节点发生重启之后，该方法进一步包括LSP路径上距离重启节点最近的正常节点向所述重启节点发送恢复消息，所述重启节点根据接收到的恢复消息，对所述LSP对应的控制状态信息进行恢复。
3.如权利要求1所述的方法，其特征在于，所述步骤B之前，该方法进一步包括所述重启节点发出通信中断故障信息，所述LSP路径上距离重启节点最近的正常节点接收到所述通信故障信息后，按照所述恢复等待时间计时；步骤B所述重启节点与所述邻居节点恢复通信之后，该方法进一步包括所述LSP路径上距离重启节点最近的正常节点停止计时。
4.如权利要求1所述的方法，其特征在于，所述步骤B之前，该方法进一步包括所述重启节点向所述LSP路径上距离重启节点最近的正常节点发出通信故障信息，并按照所述恢复等待时间计时；步骤B所述重启节点与所述邻居节点恢复通信的之后，该方法进一步包括所述重启节点停止计时。
5.如权利要求3或4所述的方法，其特征在于，所述邻居节点为所述重启节点的下游节点，则所述步骤B包括B11.LSP路径上距离重启节点最近的上游方向的正常节点通过自刷新处理来维持该LSP对应的预留状态块RSB控制状态信息；B12.在所述恢复等待时间内所述重启节点确定与所述邻居节点恢复通信，并且所述重启节点向所述邻居节点发送恢复消息，所述邻居节点判断自身是否为LSP路径的目的节点，如果是，则执行步骤B13，否则，执行步骤B14；B13.所述邻居节点根据接收到的恢复消息，恢复自身中LSP对应的PSB和RSB控制状态信息，并向所述重启节点发送恢复应答消息，所述重启节点根据接收到的恢复应答消息，恢复自身中LSP对应的RSB控制状态信息，并且所述邻居节点沿上游方向将恢复应答消息逐跳发送至该LSP路径上的距离重启节点最近的上游方向的正常节点或者源节点，结束本处理流程；B14.所述邻居节点根据接收到的恢复消息，恢复自身中该LSP对应的PSB控制状态信息，并沿下游方向将恢复消息逐跳发送至所述LSP路径上距离重启节点最近的正常节点，接收到恢复消息的下游节点对自身中LSP对应的PSB控制状态信息进行恢复或者同步，进入正常刷新处理，然后LSP路径上距离重启节点最近的下游方向的正常节点沿上游方向将恢复应答消息逐跳发送至所述LSP路径上的距离重启节点最近的上游方向的正常节点或者源节点。
6.如权利要求5所述的方法，其特征在于，步骤B11所述LSP路径上距离重启节点最近的上游方向的正常节点维持RSB控制状态信息的同时，该方法进一步包括该LSP路径上所述邻居节点的下游邻居节点在自身的重启定时时间内通过自刷新处理来维持该LSP对应的路径状态块PSB控制状态信息。
7.如权利要求3或4所述的方法，其特征在于，所述邻居节点为所述重启节点的上游节点，则所述步骤B包括B21.所述LSP路径上距离重启节点最近的下游方向的正常节点通过自刷新处理来维持该LSP对应的PSB控制状态信息；B22.在所述恢复等待时间内所述重启节点确定与所述邻居节点恢复通信，并且所述重启节点向所述邻居节点发送恢复消息，所述邻居节点判断自身是否为所述LSP路径上的源节点，如果是，则执行步骤B23，否则，执行步骤B24；B23.所述邻居节点根据接收到的恢复消息，恢复自身中LSP对应的PSB控制状态信息，并且所述邻居节点沿下游方向将恢复消息逐跳发送至所述LSP路径上距离重启节点最近的下游方向的正常节点，所述LSP路径上距离重启节点最近的下游方向的正常节点沿上游方向逐跳将恢复应答消息发送给所述源节点，接收到所述恢复应答消息的节点对自身中LSP对应的RSB控制状态信息进行恢复或同步，进入正常刷新处理，并结束本处理流程；B24.所述邻居节点根据接收到的恢复消息，恢复自身中LSP对应的PSB控制状态信息，并沿下游方向将恢复消息逐跳发送至所述LSP路径上距离重启节点最近的下游方向的正常节点，所述LSP路径上距离重启节点最近的下游方向的正常节点沿上游方向将恢复应答消息逐跳发送至所述LSP路径上距离重启节点最近的上游方向的正常节点，接收到恢复应答消息的上游节点对自身中LSP对应的RSB控制状态信息进行恢复或同步，进入正常刷新处理。
8.如权利要求7所述的方法，其特征在于，步骤B21所述LSP路径上距离重启节点最近的下游方向的正常节点维持PSB控制状态信息的同时，该方法进一步包括该LSP路径上所述邻居节点的上游邻居节点在自身的重启定时时间内通过自刷新处理来维持该LSP对应的路径状态块RSB控制状态信息。
9.如权利要求2所述的方法，其特征在于，所述步骤B之前，该方法进一步包括所述重启节点收到恢复消息后构造正常的恢复应答消息，发送给所述LSP路径上距离所述重启节点最近的正常节点，并且按照所述恢复等待时间计时；步骤B所述重启节点确定与所述邻居节点恢复通信之后，该方法进一步包括所述重启节点停止计时。
10.如权利要求9所述的方法，其特征在于，所述邻居节点为所述重启节点的下游节点，则所述步骤B包括B31.所述重启节点根据上游方向节点发来的恢复消息以及自身保存的传送平面信息，在自身创建LSP对应的RSB，通过自刷新处理来维持该RSB中的控制状态信息，并且所述重启节点构造恢复应答消息，发送给所述LSP路径上距离重启节点最近的上游方向的正常节点；B32.所述LSP路径上距离重启节点最近的上游方向的正常节点根据接收到的恢复应答消息，对自身中LSP对应的控制状态信息进行刷新；B33.在所述恢复等待时间内所述重启节点确定与所述邻居节点恢复通信后，所述重启节点向所述邻居节点发送恢复消息，所述邻居节点判断自身是否为LSP路径的目的节点，如果是，则执行步骤B34，否则，执行步骤B35；B34.所述邻居节点恢复自身中LSP对应的PSB和RSB控制状态信息，并向所述重启节点发送恢复应答消息，接收到恢复应答消息的所述重启节点恢复自身中LSP对应的RSB控制状态信息，所述重启节点与所述邻居节点进入正常刷新处理，并结束本处理流程；B35.所述邻居节点根据接收到的恢复消息，恢复自身中LSP对应的PSB控制状态信息，并沿下游方向将恢复消息逐跳发送至所述LSP路径上离重启节点最近的下游方向的正常节点，接收到恢复消息的下游节点对自身中LSP对应的PSB控制状态信息进行恢复，进入正常刷新处理，并且所述LSP路径上距离重启节点最近的下游方向的正常节点沿上游方向将恢复应答消息逐跳发送至所述LSP路径上距离重启节点最近的上游方向的正常节点或源节点，接收到所述恢复应答消息的节点对自身中LSP对应的RSB控制状态信息进行恢复或同步，并进入正常的刷新处理。
11.如权利要求9所述的方法，其特征在于，所述邻居节点为所述重启节点的上游节点，则所述步骤B包括B41.所述重启节点根据下游方向节点发来的恢复消息以及自身保存的传送平面信息，在自身创建LSP对应的PSB，通过自刷新处理来维持该PSB中的控制状态信息，并且所述重启节点构造恢复消息，发送给所述LSP路径上距离重启节点最近的下游方向的正常节点；B42.所述LSP路径上距离重启节点最近的下游方向的正常节点根据接收到的恢复消息，对自身中LSP对应的控制状态信息进行同步并向所述重启节点方向逐跳发送恢复应答消息，收到恢复应答消息的节点恢复自身中LSP对应的RSB控制状态信息，进入正常刷新处理；B43.在所述恢复等待时间内所述重启节点确定与所述邻居节点恢复通信，所述重启节点向所述邻居节点发送恢复消息，所述邻居节点判断自身是否为LSP路径的源节点，如果是，则执行步骤B44，否则，执行步骤B45；B44.所述邻居节点根据接收到的恢复消息，恢复或同步自身中LSP对应的PSB控制状态信息，并向所述重启节点发送恢复消息，接收到恢复消息的所述重启节点恢复自身中LSP对应的PSB控制状态信息，并向所述邻居节点发送恢复应答消息，收到恢复应答消息的所述邻居节点恢复自身中LSP对应的RSB控制状态信息，进入正常刷新处理，并结束本处理流程；B45.所述邻居节点根据接收到的恢复消息，恢复自身中该LSP对应的PSB控制状态信息，并向所述重启节点发送恢复消息，接收到恢复消息的所述重启节点恢复自身中LSP对应的PSB控制状态信息，并向所述邻居节点发送恢复应答消息，收到恢复应答消息的所述邻居节点恢复或同步自身中LSP对应的RSB控制状态信息，进入正常刷新处理。
12.如权利要求3、4或9所述的方法，其特征在于，预先设置将所述恢复等待时间作为计时时间的恢复等待定时器，则所述按照恢复等待时间计时为启动恢复等待定时器；所述停止计时为停止所述恢复等待定时器。
13.如权利要求3、4或9所述的方法，其特征在于，所述按照恢复等待时间计时之前，该方法进一步包括设置将所述恢复等待时间作为计时时间的恢复等待定时器；所述按照恢复等待时间计时为启动所述恢复等待定时器；所述停止计时为停止所述恢复等待定时器。
14.如权利要求1所述的方法，其特征在于，所述重启节点与邻所述居节点处于控制通道通信中断状态为所述邻居节点尚未重启或者所述重启节点与所述邻居节点间的通信链路中断。
15.如权利要求1所述的方法，其特征在于，步骤B所述维持该LSP对应的控制状态信息之后，该方法进一步包括在所述恢复等待时间超时后，所述重启节点与所述邻居节点仍处于控制通道中断状态，则所述LSP路径上的节点删除该LSP对应的控制状态信息，并结束本处理流程。
全文摘要
本发明公开了一种多节点通信故障的处理方法，该方法包括A.标签交换路径LSP上至少一个节点发生重启，重启节点确定与邻居节点处于控制通道通信中断状态；B.LSP路径上的节点在恢复等待时间内维持所述节点内该LSP对应的控制状态信息，并且当所述重启节点与邻居节点在所述恢复等待时间内恢复通信时，LSP路径上的节点对该LSP对应的控制状态信息执行恢复处理。应用本发明，能够在LSP路径上多个节点出现通信故障时，可靠地恢复该LSP。
文档编号H04L12/54GK101087207SQ20061009291
公开日2007年12月12日 申请日期2006年6月9日 优先权日2006年6月9日
发明者高建华, 李丹 申请人:华为技术有限公司