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

文档序号:7647135阅读:112来源:国知局
专利名称:自动交换光网络中节点故障后路由重启恢复的控制方法
技术领域
本发明涉及一种在自动交换光网络(Automatic Switched Optical Network, 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消 息格式主要增加了 RouterRestrartlnterval和Flag字#爻。根据本发明的第一方面,节点故障重启恢复的过程中,经由改进的Hello报文的交互,进行Wait-Restart、 Recovery和Full的状态转移,从而完成数 据库的更新。根据本发明的第一方面,邻居节点在帮助故障节点重启恢复的过程中,经 由改进的Hello报文的交互,进行Down、 Help、 Full的状态转移,从而帮助 故障节点完成lt据库的更新。根据本发明的第二方面,提供一种基于重路由或者等待重启恢复处理建路 请求的控制方法。对于故障节点作为建路显式路由中间节点的情况,采取重 路由绕过故障节点的方法;对于故障节点作为建路显式路由的目的节点和无 法重路由的中间节点的情况,采取等待路由重启恢复的方法。


通过下面结合附图进行的对实施例的描述,本发明的上述和/或其他目的 和优点将会变得更加清楚,其中图1: OSPF改进邻居状态机2: 0SPF改进Hello消息格式图3:故障重启恢复过程状态交互4:故障重启恢复过程邻居节点流程5:故障重启恢复过程故障节点流程6:故障重启恢复过程处理建路命令流程7:中间节点故障,重路由成功图8:重路由失败/目的节点故障,源节点不支持等待图9:重路由失败/目的节点故障,源节点支持等待,节点重启失败图10:重路由失败/目的节点故障,源节点支持等待,节点重启成功具体实施方式
通过参照下面对示例性的非限定性的实施例和附图的详细描述,本发明 的优点和特征以及实现本发明的方法可更易于理解。然而,本发明可以以多 种不同的形式来实施,而不应被解释为受限于在此阐释的实施例。此外,提供这些实施例从而该公开将是彻底的和完全的,并将完整地将本发明的构思传达给本领域技术人员,本发明将仅由所附权利要求定义。在说明书中,相 同的标号始终指示相同的部件。以下结合附图对本发明所述方法的流程作进一步详细说明 在本发明中,涉及了如下五种状态Down状态即与邻居节点没有任何交流或者失去交流的状态。 Full状态即与邻居节点建立完全的邻接关系的状态。 He 1 p状态是邻居节点准备开始帮助故障节点恢复的状态。 Wait-Restart状态是故障节点发生故障,尚未重启,并且 RouterRestartlnterval定时器未超时时的^l犬态。Recovery状态是故障节点发生故障后及时重启,并且开始接受邻居节点 帮助,开始恢复的状态。在本发明中,这五种状态之间的转移是通过事件进行触发的,具体的事件 与状态转移之间的对应关系为首先,Help状态是邻居节点准备开始帮助故障节点恢复的状态。 其次,Wait-Restart状态是故障节点发生故障,尚未重启,并且 RouterRestartlnterval定时器未超时时的状态。另,Recovery状态是故障节点发生故障后及时重启,并且开始接受邻居 节点帮助,开始恢复的状态。其中,邻居节点由Down状态转化为Help状态是由事件Help-Hello触发的。其次,邻居节点由Help状态转化为Full状态是由RecoveryDone事件触 发的。再次,故障节点由Full状态转化为Wait-Restart状态是由事件 InactivityTimer-timeout触发的。另外,故障节点由Wait-Restart状态转化为Down状态是由事件 RouterRestartlnterval-timeout触发的。另外,故障节点由Wait-Restart状态转化为Recovery状态是由事件 Req-Hello触发的。另外,故障节点由Recovry状态转化为Full状态是由事件HelpDone触 发的。根据本发明的第一部分,图l示出了本发明所用到的各种事件示意图,具体4苗述々口下Help-Hello事件故障节点接收到邻居节点发送的Help-Hello报文。 该事件只在邻居节点Down状态下有效,其他状态收到忽略。RecoveryDone事件故障节点成功从邻居节点处接收到所有LSU报文。 该事件只在邻居节点Help状态下有效,其他状态收到忽略。InactivityTimer-timeout事件邻居节点的InactivityTimer定时器 超时期间没有收到故障节点发送的Hello包。该事件说明故障节点发生故障,RouterRestartlnterval-timeout事件RouterRestartlnterval定时器 超时。该事件说明故障节点发生故障后没有及时重启。该事件只在 Wait-Restart状态有效,其他状态收到忽略。Req-Hello事件:在RouterRestrartlnterval定时器没有超时之前,邻 居节点接收到故障节点发送的Req-Hello报文。HelpDone事件邻居节点发送完描述本地数据库中所有LSA的DD包。 该事件只在Help状态下有效,其他状态收到忽略。根据本发明的第一部分,图2示出了与本发明相关的 RouterRestrartlnterval定时器超时时间才艮文+各式示意图。 RouterRestrartlnterval定时器超时时间是由本发明提出的改进的Hello消 息格式中RouterRestrartlnterval字段表示的。正如图2所示出的,该字段 用来标记节点是否支持重启,以及如果支持重启时的重启超时时间。如果不 支持重启,本字段为0;如果支持重启,本字段设为非O的正数,当故障节 点出现故障,邻居节点在RouterDeadlnterval超时后,不会泛洪通知该故障 节点失效,而是等待故障节点重启,其等待时间就为RouterRestartlnterval 字段标识的秒数。其次,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报文中RouterRestartlnterval字段来进行判断,如果该字段为 0,则故障节点不支持重启,跳转到步骤S403,按照标准OSPF协议全网泛洪 告知节点故障;如果该字段大于O,则故障节点支持重启,跳转到步骤S404, 调用经过本发明修改的邻居状态机NSM进行处理,将故障节点状态转化为 Wait-Restart。步骤S405,向故障节点发送Help-Hello报文,该报文通过将经本发明 ^畛改的Hello消息才各式中的Flag字^爻置为1来标识。步骤S406,判断是否接收到故障节点发送来的Req-Hello报文,该报文通过将经本发明修改的Hello消息格式中的Flag字段置为2来标识,如果没 有接收到,跳转到步骤S407,检查RouterRestartlnterval定时器是否超时。 如果该定时器未超时,跳转到步骤S405,继续向故障节点发送Help-Hello 报文;如果超时,说明故障节点没有成功重启,跳转到步骤S408,按照标准 OSPF协i义全网泛洪告知节点故障。步骤S406中,如果接收到Req-Hello报文,说明故障节点已经重启,并 同意接受本节点的帮助进行数据库的恢复,则跳转到步骤S409,调用经本发 明修改的邻居状态机NSM将故障节点状态转化为Recovery。之后,正式开始故障节点重启后的帮助恢复过程。步骤S410,向故障节点发送并接收其返回的DD报文,将本节点置为 Master,故障节点置为Slave。步骤S411为共享数据库阶段,向Slave即故 障节点发送DD报文,共享LSA数据库信息,并设置超时定时器,在此定时器 超时期间未收到Slave回送的DD报文,则重发DD报文。步骤S412为数据库 更新阶段,接收Slave即故障节点发送的LSR报文,根据其中的LSA头(LSA Header)从本地的LSA数据库中找出相应的LSA,并打包成LSU报文,但此LSU 报文并不产生全网泛洪,而是只发送给Slave。完成数据库更新后继续到步骤S413,调用经本发明修改的邻居状态机将 故障节点的状态转化为Full,完成了整个重启后帮助恢复过程。根据本发明的第一方面,如图5所示的故障节点流程图,其具体工作步 骤描述如下步骤S501,当所述节点发生故障重启后,接收到邻居节点发送的 Help-Hello报文,跳转到步骤S502,调用经本发明修改的邻居状态机将邻居 节点的状态转化为Help。步骤S503,作为对Help-Hello报文的应答,向邻居节点发送Req-Hel lo 才艮文,同意对方帮助恢复。以下从步骤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,正向拆路,结束建鴻4青求,具体参 见图8;如果是,跳转到步骤S610,该情况下源节点仅发送ACK消息,接收该消息,等待故障节点重启。步骤S611,判断故障节点是否成功重启,即在RouterRestartlnterval 超时之前,是否接收到故障节点发送的Hello消息。如果否,跳转到步骤S612, 反向拆路,结束建路请求,参见图9;如果接收到Hello消息,说明故障节 点成功重启,可以支持建立业务,则跳转到步骤S613,下发建路命令,成功 完成建路请求,参见图10。本发明不限于上述实施例,在不脱离本发明范围的情况下,可以进行各种变形和修改。
权利要求
1. 一种基于自动交换光网络实现节点故障后路由重启恢复的控制方法,包括实现对路由重启恢复功能的支持;处理重启过程中的建路请求。其特征在于所述方法中,采用了改进的OSPF协议技术,采用了重路由或者等待重启恢复的方法,具体包括以下处理部分当有节点发生故障时,邻居节点不全网泛洪通知该故障,而是试图等待其重启,帮助其恢复,其特征在于使用了本发明提出的改进的邻居状态机和Hello报文格式。通过与信令模块交互,采用重路由的方法处理中间节点发生故障的建路请求,采取等待重启恢复的方法处理无法重路由的中间节点发生故障的建路请求和目的节点发生故障的建路请求。
2、 如权力要求1所述的基于自动发现光网络实现节点故障后路 由重启恢复的控制方法,其特征在于所述采用改进的0SPF协议技术 实现对路由重启恢复功能的支持的过程发生在当有节点发生故障;并且节点具有支持快速重启恢复的能力; 并且该故障节点快速重启成功。如权力要求1所述的基于自动发现光网络实现节点故障后路由 重启恢复的控制方法,其特征在于所述采用重路由的方法处理重启过 程中的建路请求的过程发生在节点具有支持快速重启恢复的能力;并且新业务的显式路由经过该故障节点;并且该故障节点为显式路由的中间节点。
3、 如权力要求1所述基于自动发现光网络实现节点故障后路由 重启恢复的控制方法,其特征在于所述采用等待重启恢复的方法处理 重启过程中的建路请求的过程发生在'节点具有支持快速重启恢复的能力; 并且新业务的显式路由经过该故障节点;并且该故障节点为显式路由的目的节点或者该故障节点为显式 路由的中间节点但对其重路由不成功。
4、 如权力要求1所述基于自动发现光网络实现节点故障后路由 重启恢复的控制方法,其特征在于第一部分中所述实现对路由重启恢 复功能支持过程中使用到的邻居状态机包含了新增的He 1 p,Wait-Restart和Recovery三个状态和Help-Hello、 RecoveryDone、 InactivityTimer—timeout、 RouterRestartInterval—timeout、 Req-Hello、 HelpDone六个事件。
5、 如权力要求4所述邻居状态机,其特征在于Help状态是邻居节点准备开始帮助故障节点恢复的状态; Wait-Restart状态是故障节点发生故障,尚未重启,并且RouterRes tart Interval定时器未超时时的4犬态;Recovery状态是故障节点发生故障后及时重启,并且开始接受邻居节点帮助,开始恢复的状态。
6、 如权力要求4所述邻居状态机,其特征在于He 1 p-He 11 o事件代表故障节点接收到邻居节点发送的 Help-Hello报文;RecoveryDone事件^表故障节点成功/人邻居节点处4妾收到所有 LSU报文;Inact ivi tyTimer-t imeout事件代表邻居节点的 InactivityTimer定时器超时期间没有收到故障节点发送的Hello 包;RouterRestartlnterval-timeout事件代表 RouterRestartlnterval定时器超时;Req-Hello事件代表在RouterRestrartlnterval定时器没有超 时之前,邻居节点接收到故障节点发送的Req-Hello报文;HelpDone事件代表邻居节点发送完描述本地数据库中所有LSA 的DD包。
7、 如权力要求1所述基于自动发现光网络实现节点故障后路由 重启恢复的控制方法,其特征在于第 一部分中所述实现对路由重启恢复功能支持过程中使用到的Hello消息格式包含了新增的 RouterRestrartlnterval字段和Flag字段。
8、 如权力要求7所述Hello消息格式中RouterRestrartlnterval 字段,其特征在于如果不支持重启,本字段为0;如果支持重启,本字段设为非O的正数,当故障节点出现故障, 邻居节点在RouterDeadlnterval超时后,不会泛洪通知该故障节点 失效,而是等待故障节点重启,其等待时间就为本字段标识的秒数。如权力要求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消息接受邻居节点帮助其恢复。
全文摘要
本发明涉及一种在自动交换光网络中实现节点故障后路由重启恢复的控制方法,特别是一种在故障节点和邻居节点之间实现路由重启恢复的控制方法。本发明不需要路由在重启过程中对全网两次泛洪;一定程度上避免了由于泛洪造成的网络拥塞;在实际应用中能够更加快速并且简单地完成对网络的路由恢复。
文档编号H04L29/06GK101222486SQ200710062660
公开日2008年7月16日 申请日期2007年1月12日 优先权日2007年1月12日
发明者杰 张, 沛 张, 磊 石, 怡 程, 顾畹仪 申请人:北京邮电大学
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1