CN101222486A - 自动交换光网络中节点故障后路由重启恢复的控制方法 - Google Patents

Abstract

本发明涉及一种在自动交换光网络中实现节点故障后路由重启恢复的控制方法，特别是一种在故障节点和邻居节点之间实现路由重启恢复的控制方法。本发明不需要路由在重启过程中对全网两次泛洪；一定程度上避免了由于泛洪造成的网络拥塞；在实际应用中能够更加快速并且简单地完成对网络的路由恢复。

Description

自动交换光网络中节点故障后路由重启恢复的控制方法

技术领域

本发明涉及一种在自动交换光网络(Automatic Switched OpticalNetwork，ASON)中实现节点故障后路由重启恢复的控制方法，具体是一种基于改进的开放式最短路径优先(Open Shortest Path First，OSPF)协议技术实现节点故障后路由重启恢复的控制方法，特别是一种在故障节点和邻居节点之间实现路由重启恢复的控制方法。

背景技术

ASON是一种借助能够提供自动发现与自动连接配置功能的分布式(或者部分分布式)控制平面，在采用光同步数字传送网(SDH)或光传送网(OTN)等技术的传送平面基础上，实现面向动态交换的、基于信令和策略驱动控制的智能光网络解决方案。ASON网络由传送平面、控制平面、管理平面，以及支撑控制信令与管理信息传递的数据通信网构成，其中最重要的与控制平面相关的信令和路由功能，通常是利用通用多协议标记交换(GMPLS)技术来实现。

与传统的光网络相比，ASON主要用于格状拓扑结构的网络；建立在GMPLS协议基础上的控制平面支持多种粒度、多种类型和多层网络的快速、有效地故障保护与恢复能力；引入了更多的生存性约束条件(例如，共享风险链路组等概念)。因此，ASON生存性技术具有智能化、多样化的突出特点，高效、灵活、丰富、可靠的保护与恢复机制成为ASON网络的特色之一。由于智能控制平面的引入及其核心地位，如何确保控制平面自身的可靠运行成为整个ASON网络生存性研究的重要组成部分。控制平面主要是由各种软件功能模块和信令传送网络构成的，需要针对其特点采取相应的策略以保证控制平面的生存性。其中，节点故障后的重启恢复能力是保障ASON控制平面生存性的一种重要方法，对于ASON控制平面，其路由、信令和资源管理三个模块都应该支持节点重启。

目前基于OSPF实现的路由协议(例如，在IETF RFC 2328所公开的)，通过Hello消息来检测链路的连通性以及邻居的变化，但没有专门的重启机制。当节点故障后，其邻居节点将会发现Hello消息丢失，在InactivityTimer定时器超时后，路由模块将会通过LSA消息向其它相邻路由器通告这个消息，通过全网泛洪，整个网络都知道节点故障，将该节点从路由表中删除。在这之后，如果故障节点重启，该节点会重新给邻居节点发送协议报文，邻居节点将其添加到邻居列表中，并且向其他邻居节点通告该消息，全网泛洪后，整个网络将得知该节点重新恢复。

从上述原理可以看出，即使某一控制平面的节点在发生暂时性故障后很快地重新恢复控制功能，现有的OSPF协议也需要在节点实现重启前后的较短时间内连续进行两次全网泛洪过程。这不仅需要占用网络节点大量的工作时间，而且泛洪操作会产生突发的数据流量，有可能导致控制平面的拥塞或者不稳定。

实际中针对这类节点故障后马上重启的情况，网络拓扑在节点功能恢复前后一般不会发生变化。基于以上原因，我们提出一种新的解决方法，那就是邻居节点发现节点故障并且具有重启能力，则不对全网泛洪，而是等待其重启后帮助其恢复全网拓扑，这种重启策略不需要两次全网泛洪，从而能够更加快速并且简单地完成对整个网络的恢复。

发明内容

本发明的目的在于提供一种在自动交换光网络中节点故障后，基于改进的OSPF邻居状态机和Hello消息格式，实现路由重启恢复的控制方法，避免了路由信息短期内进行的两次全网泛洪，适用于节点具有快速重启能力的网络。

本发明的另一目的在于提供一种在自动交换光网络节点故障后路由重启恢复过程中，基于重路由或者等待重启恢复，处理建路请求的控制方法，降低了由于重启恢复过程中故障信息不泛洪造成全网不同步引起的建路失败率。

根据本发明的第一方面，提供一种基于改进的OSPF邻居状态机和Hello消息格式的路由重启恢复的控制方法。改进的OSPF邻居状态机主要增加了Help，Wait-Restart和Recovery三个状态及相应的事件触发；改进的Hello消息格式主要增加了RouterRestrartInterval和Flag字段。

根据本发明的第一方面，节点故障重启恢复的过程中，经由改进的Hello报文的交互，进行Wait-Restart、Recovery和Full的状态转移，从而完成数据库的更新。

根据本发明的第一方面，邻居节点在帮助故障节点重启恢复的过程中，经由改进的Hello报文的交互，进行Down、Help、Full的状态转移，从而帮助故障节点完成数据库的更新。

根据本发明的第二方面，提供一种基于重路由或者等待重启恢复处理建路请求的控制方法。对于故障节点作为建路显式路由中间节点的情况，采取重路由绕过故障节点的方法；对于故障节点作为建路显式路由的目的节点和无法重路由的中间节点的情况，采取等待路由重启恢复的方法。

附图说明

通过下面结合附图进行的对实施例的描述，本发明的上述和/或其他目的和优点将会变得更加清楚，其中：

图1：OSPF改进邻居状态机图

图2：OSPF改进Hello消息格式

图3：故障重启恢复过程状态交互图

图4：故障重启恢复过程邻居节点流程图

图5：故障重启恢复过程故障节点流程图

图6：故障重启恢复过程处理建路命令流程图

图7：中间节点故障，重路由成功

图8：重路由失败/目的节点故障，源节点不支持等待

图9：重路由失败/目的节点故障，源节点支持等待，节点重启失败

图10：重路由失败/目的节点故障，源节点支持等待，节点重启成功

具体实施方式

通过参照下面对示例性的非限定性的实施例和附图的详细描述，本发明的优点和特征以及实现本发明的方法可更易于理解。然而，本发明可以以多种不同的形式来实施，而不应被解释为受限于在此阐释的实施例。此外，提供这些实施例从而该公开将是彻底的和完全的，并将完整地将本发明的构思传达给本领域技术人员，本发明将仅由所附权利要求定义。在说明书中，相同的标号始终指示相同的部件。

以下结合附图对本发明所述方法的流程作进一步详细说明：

在本发明中，涉及了如下五种状态：

Down状态：即与邻居节点没有任何交流或者失去交流的状态。

Full状态：即与邻居节点建立完全的邻接关系的状态。

Help状态是邻居节点准备开始帮助故障节点恢复的状态。

Wait-Restart状态是故障节点发生故障，尚未重启，并且RouterRestartInterval定时器未超时时的状态。

Recovery状态是故障节点发生故障后及时重启，并且开始接受邻居节点帮助，开始恢复的状态。

在本发明中，这五种状态之间的转移是通过事件进行触发的，具体的事件与状态转移之间的对应关系为：

首先，Help状态是邻居节点准备开始帮助故障节点恢复的状态。

其次，Wait-Restart状态是故障节点发生故障，尚未重启，并且RouterRestartInterval定时器未超时时的状态。

另，Recovery状态是故障节点发生故障后及时重启，并且开始接受邻居节点帮助，开始恢复的状态。

其中，邻居节点由Down状态转化为Help状态是由事件Help-Hello触发的。

其次，邻居节点由Help状态转化为Full状态是由RecoveryDone事件触发的。

再次，故障节点由Full状态转化为Wait-Restart状态是由事件InactivityTimer-timeout触发的。

另外，故障节点由Wait-Restart状态转化为Down状态是由事件RouterRestartInterval-timeout触发的。

另外，故障节点由Wait-Restart状态转化为Recovery状态是由事件Req-Hello触发的。

另外，故障节点由Recovry状态转化为Full状态是由事件HelpDone触发的。

根据本发明的第一部分，图1示出了本发明所用到的各种事件示意图，具体描述如下：

Help-Hello事件：故障节点接收到邻居节点发送的Help-Hello报文。该事件只在邻居节点Down状态下有效，其他状态收到忽略。

RecoveryDone事件：故障节点成功从邻居节点处接收到所有LSU报文。该事件只在邻居节点Help状态下有效，其他状态收到忽略。

InactivityTimer-timeout事件：邻居节点的InactivityTimer定时器超时期间没有收到故障节点发送的Hello包。该事件说明故障节点发生故障。

RouterRestartInterval-timeout事件：RouterRestartInterval定时器超时。该事件说明故障节点发生故障后没有及时重启。该事件只在Wait-Restart状态有效，其他状态收到忽略。

Req-Hello事件：在RouterRestrartInterval定时器没有超时之前，邻居节点接收到故障节点发送的Req-Hello报文。

HelpDone事件：邻居节点发送完描述本地数据库中所有LSA的DD包。该事件只在Help状态下有效，其他状态收到忽略。

根据本发明的第一部分，图2示出了与本发明相关的RouterRestrartInterval定时器超时时间报文格式示意图。

RouterRest rartInterval定时器超时时间是由本发明提出的改进的Hello消息格式中RouterRestrartInterval字段表示的。正如图2所示出的，该字段用来标记节点是否支持重启，以及如果支持重启时的重启超时时间。如果不支持重启，本字段为0；如果支持重启，本字段设为非0的正数，当故障节点出现故障，邻居节点在RouterDeadInterval超时后，不会泛洪通知该故障节点失效，而是等待故障节点重启，其等待时间就为RouterRestartInterval字段标识的秒数。

其次，Help-Hello包和Req-Hello包由本发明提出的改进的Hello消息格式中的Flag字段表示。正如图2所示出的，该字段和它随后的Neighbor字段共同标识了一个邻居的状态信息。对于未发生故障情况下的Hello消息，Flag全部填0；当有节点发生故障时，发现该故障的邻居节点如果支持重启，将向该故障节点发送携带Flag为1的Hello消息去通知故障节点可以帮助其重启，该Hello消息即本发明中所说的Help-Hello消息。故障节点重启后，收到Help-Hello消息进入Recovery状态，并且回送Flag为2的Hello消息接受邻居节点帮助其恢复，该Hello消息即本发明中所说的Req-Hello消息。

根据本发明的第一部分，即邻居节点帮助故障节点进行重启恢复进行描述，如图3所示的状态转移交互图。对于有重启能力的节点，当它发生故障时，邻居节点不向全网泛洪告知该故障，而是试图等待其重启，帮助其恢复。

如图3所示的状态转移交互图，包含了如下几种状态：

根据本发明的第一部分以及图3所示的状态转移交互图，恢复的步骤可以描述为：

首先，故障节点重启成功，此时它认为所述邻居节点状态是Down S301；所述邻居节点没有收到所述故障节点消息，认为所述故障节点仍在重启中，状态是Wait-Restart S302。

其次，故障节点接收到邻居节点发送的Help-Hello报文，将所述邻居节点状态转化为Help S303，向所述邻居节点发送Req-Hello报文，接受所述邻居节点的帮助，此时故障节点的状态转化为Recovery S304。

之后，邻居节点与故障节点交互DD报文，确定Master/Slave。

随后，邻居节点与故障节点继续交互DD包，进行数据库信息的共享。

继而，故障节点通过LSR包向邻居节点请求数据库具体内容，邻居节点通过LSU包发送数据库具体内容，进行数据库的更新。

最后，当数据库更新完毕，两者都到达Full状态，故障节点的重启恢复结束。

根据本发明的第一方面，图4示出了邻居节点流程示意图，具体实施过程可以描述为以下几个步骤：

步骤S401，邻居节点为故障节点设置的InactivityTimer定时器超时，标志着在这段时间里没有收到故障节点的Hello报文，认为其发生故障。

步骤S402，检查故障节点是否支持重启。通过查看之前从故障节点接收到的Hello报文中RouterRestartInterval字段来进行判断，如果该字段为0，则故障节点不支持重启，跳转到步骤S403，按照标准OSPF协议全网泛洪告知节点故障；如果该字段大于0，则故障节点支持重启，跳转到步骤S404，调用经过本发明修改的邻居状态机NSM进行处理，将故障节点状态转化为Wait-Restart。

步骤S405，向故障节点发送Help-Hello报文，该报文通过将经本发明修改的Hello消息格式中的Flag字段置为1来标识。

步骤S406，判断是否接收到故障节点发送来的Req-Hello报文，该报文通过将经本发明修改的Hello消息格式中的Flag字段置为2来标识，如果没有接收到，跳转到步骤S407，检查RouterRestartInterval定时器是否超时。如果该定时器未超时，跳转到步骤S405，继续向故障节点发送Help-Hello报文；如果超时，说明故障节点没有成功重启，跳转到步骤S408，按照标准OSPF协议全网泛洪告知节点故障。

步骤S406中，如果接收到Req-Hello报文，说明故障节点已经重启，并同意接受本节点的帮助进行数据库的恢复，则跳转到步骤S409，调用经本发明修改的邻居状态机NSM将故障节点状态转化为Recovery。

之后，正式开始故障节点重启后的帮助恢复过程。

步骤S410，向故障节点发送并接收其返回的DD报文，将本节点置为Master，故障节点置为Slave。步骤S411为共享数据库阶段，向Slave即故障节点发送DD报文，共享LSA数据库信息，并设置超时定时器，在此定时器超时期间未收到Slave回送的DD报文，则重发DD报文。步骤S412为数据库更新阶段，接收Slave即故障节点发送的LSR报文，根据其中的LSA头(LSAHeader)从本地的LSA数据库中找出相应的LSA，并打包成LSU报文，但此LSU报文并不产生全网泛洪，而是只发送给Slave。

完成数据库更新后继续到步骤S413，调用经本发明修改的邻居状态机将故障节点的状态转化为Full，完成了整个重启后帮助恢复过程。

根据本发明的第一方面，如图5所示的故障节点流程图，其具体工作步骤描述如下：

步骤S501，当所述节点发生故障重启后，接收到邻居节点发送的Help-Hello报文，跳转到步骤S502，调用经本发明修改的邻居状态机将邻居节点的状态转化为Help。

步骤S503，作为对Help-Hello报文的应答，向邻居节点发送Req-Hello报文，同意对方帮助恢复。

以下从步骤S504开始，正式进入重启后的数据恢复阶段。

步骤S504，接收并向邻居节点发送DD报文，将本节点置为Slave，邻居节点为Master。步骤S505为共享数据库阶段，接收邻居节点即Master发送的DD报文，并回送DD报文作为应答。步骤S506，调用经本发明修改的邻居状态机将邻居节点的状态转化为Full。

步骤S507为数据库更新阶段，根据步骤S505共享到的数据库中LSA头(LSA Header)信息，打包生成LSR报文发送至邻居节点请求LSA资源，并接收Master返回的LSU报文获取到具体LSA资源。在收到Master返回的LSU报文的时候不产生泛洪，当在规定的时间内没有收到LSU报文时，重发LSR报文。从而在接收完全部的LSU报文后，完成故障重启后的恢复过程。

根据本发明的第二方面，即通过与信令模块的交互，如图6所示，处理由于故障节点重启恢复期间邻居节点不泛洪造成的网络不同步时的业务请求。

在图6中，当网络中有节点发生故障时，上游节点作为故障节点的邻居节点，了解该故障信息。当有建立业务的信令传递到该节点时，它将按以下步骤进行处理：

步骤S601，检查该业务的显式路由中是否包含该故障节点，如果未包含，跳转到步骤S602，按照正常建路请求的流程继续。如果包含，跳转到步骤S603，判断故障节点是显式路由的中间节点还是目的节点，如果是中间节点，跳转到步骤S604，向路由模块申请重路由。

步骤S605，判断重路由是否成功，如果是，跳转到步骤S606，按照步骤S604中申请到的重路由，将建路命令传递到目的节点，完成建路命令，参见图7；如果否，跳转到步骤S607。步骤S603中，如果故障节点是显式路由的目的节点，也跳转到步骤S607，因为对于上游节点而言，目的节点和无法重路由的中间节点都是不可绕过的，必须等待重启才可以建路。

步骤S607，保存建路命令，并向源节点直接发送Notify消息，告知源节点有节点故障，需要等待节点重启。

步骤S608，判断源节点是否支持等待，如果否，跳转到步骤S609，接收源节点发送的ACK和拆路消息PathTear，正向拆路，结束建路请求，具体参见图8；如果是，跳转到步骤S610，该情况下源节点仅发送ACK消息，接收该消息，等待故障节点重启。

步骤S611，判断故障节点是否成功重启，即在RouterRestartInterval超时之前，是否接收到故障节点发送的Hello消息。如果否，跳转到步骤S612，反向拆路，结束建路请求，参见图9；如果接收到Hello消息，说明故障节点成功重启，可以支持建立业务，则跳转到步骤S613，下发建路命令，成功完成建路请求，参见图10。

本发明不限于上述实施例，在不脱离本发明范围的情况下，可以进行各种变形和修改。

Claims (10)

1.一种基于自动交换光网络实现节点故障后路由重启恢复的控制方法，包括：

实现对路由重启恢复功能的支持；

处理重启过程中的建路请求。

其特征在于所述方法中，采用了改进的OSPF协议技术，采用了重路由或者等待重启恢复的方法，具体包括以下处理部分：

当有节点发生故障时，邻居节点不全网泛洪通知该故障，而是试图等待其重启，帮助其恢复，其特征在于使用了本发明提出的改进的邻居状态机和Hello报文格式。

通过与信令模块交互，采用重路由的方法处理中间节点发生故障的建路请求，采取等待重启恢复的方法处理无法重路由的中间节点发生故障的建路请求和目的节点发生故障的建路请求。

2.如权力要求1所述的基于自动发现光网络实现节点故障后路由重启恢复的控制方法，其特征在于所述采用改进的OSPF协议技术实现对路由重启恢复功能的支持的过程发生在：

当有节点发生故障；

并且节点具有支持快速重启恢复的能力；

并且该故障节点快速重启成功。

如权力要求1所述的基于自动发现光网络实现节点故障后路由重启恢复的控制方法，其特征在于所述采用重路由的方法处理重启过程中的建路请求的过程发生在：

节点具有支持快速重启恢复的能力；

并且新业务的显式路由经过该故障节点；

并且该故障节点为显式路由的中间节点。

3.如权力要求1所述基于自动发现光网络实现节点故障后路由重启恢复的控制方法，其特征在于所述采用等待重启恢复的方法处理重启过程中的建路请求的过程发生在：

节点具有支持快速重启恢复的能力；

并且新业务的显式路由经过该故障节点；

并且该故障节点为显式路由的目的节点或者该故障节点为显式路由的中间节点但对其重路由不成功。

4.如权力要求1所述基于自动发现光网络实现节点故障后路由重启恢复的控制方法，其特征在于第一部分中所述实现对路由重启恢复功能支持过程中使用到的邻居状态机包含了新增的Help，Wait-Restart和Recovery三个状态和Help-Hello、RecoveryDone、InactivityTimer-timeout、RouterRestartInterval-timeout、Req-Hello、HelpDone六个事件。

5.如权力要求4所述邻居状态机，其特征在于：

Help状态是邻居节点准备开始帮助故障节点恢复的状态；

Wait-Restart状态是故障节点发生故障，尚未重启，并且RouterRestartInterval定时器未超时时的状态；

Recovery状态是故障节点发生故障后及时重启，并且开始接受邻居节点帮助，开始恢复的状态。

6.如权力要求4所述邻居状态机，其特征在于：

Help-Hello事件代表故障节点接收到邻居节点发送的Help-Hello报文；

RecoveryDone事件代表故障节点成功从邻居节点处接收到所有LSU报文；

InactivityTimer-timeout事件代表邻居节点的InactivityTimer定时器超时期间没有收到故障节点发送的Hello包；

RouterRestartInterval-timeout事件代表RouterRestartInterval定时器超时；

Req-Hello事件代表在RouterRestrartInterval定时器没有超时之前，邻居节点接收到故障节点发送的Req-Hello报文；

HelpDone事件代表邻居节点发送完描述本地数据库中所有LSA的DD包。

7.如权力要求1所述基于自动发现光网络实现节点故障后路由重启恢复的控制方法，其特征在于第一部分中所述实现对路由重启恢复功能支持过程中使用到的Hello消息格式包含了新增的RouterRestrartInterval字段和Flag字段。

8.如权力要求7所述Hello消息格式中RouterRestrartInterval字段，其特征在于：

如果不支持重启，本字段为0；

如果支持重启，本字段设为非0的正数，当故障节点出现故障，邻居节点在RouterDeadInterval超时后，不会泛洪通知该故障节点失效，而是等待故障节点重启，其等待时间就为本字段标识的秒数。

如权力要求7所述的Hello消息格式中Flag字段的特征在于：

对于未发生故障情况下的Hello消息，Flag全部填0；

对于Help-Hello消息，Flag填1。

对于Req-Hello消息，Flag填2。

9.如权力要求8所述的Help-Hello消息，其特征在于：

当有节点发生故障时，发现该故障的邻居节点如果支持重启，将向该故障节点发送携带Flag为1的Help-Hello消息去通知故障节点可以帮助其重启。

10.如权力要求8所述的Req-Hello消息，其特征在于：

故障节点重启后，收到Help-Hello消息进入Recovery状态，并且回送Flag为2的Req-Hello消息接受邻居节点帮助其恢复。

Images