[发明专利]一种多节点通信故障的处理方法

说明书

技术领域

本发明涉及通用多协议标签交换(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上电重启，启动恢复重启定时器(Recovery_Timer)，并向节点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。