重启恢复时间的调整方法和装置与流程

本发明涉及数据网络通信领域，尤其涉及一种重启恢复时间的调整方法和装置。

背景技术：

rsvp-te(resourcereservationprotocol-trafficengineer基于流量工程的资源预留协议)是一种基于mpls多协议标签交换的流量工程技术。通过信息发布、路径计算、信令交互、流量转发四个部件实现业务流量在te隧道中的转发。

基于rsvp-te的gr(gracefulrestart,优雅重启)提供了一种业务流量的nsf(non-stopforwarding，不间断转发)机制，网络中设备的控制面发生故障时，可以通过该设备的邻居设备恢复控制面信息，转发信息在恢复控制面恢复的阶段能够保持住，以保证流量的转发。

gr技术需要基于hello检测，检测的目的之一就是需要感知邻居发生了重启。hello检测过程中会携带restarttime重启时间和recoverytime恢复时间两个参数，分别表示重启后恢复控制通道需要的时间以及控制通道恢复信令与转发需要的时间。在检测到邻居发生了重启之后，需要为重启方发送恢复报文，该节点我们称为辅助方。

restarttime重启时间，主要是用于辅助方，辅助方需要等待重启方等待多久，才给重启方发送恢复报文；recoverytime，主要用于重启方，需要多久才能完全恢复信令与转发。在hello的交互中双方都保存各个邻居的这两个参数，一旦邻居重启将通过这些重启前的参数进行恢复。

在实际工程部署优雅重启的过程中，主流厂商固定配置restarttime和recoverytime。实际上节点te隧道的数量对于恢复时间有直接的影响。节点间可能存在多条lsp隧道，lsp数目随着时间的变化是动态变化的。经过重启点的隧道越多，恢复时间就越长。工程部署的时候，往往静态配置这一恢复时间，随着开通业务的增加，承载的隧道数目也增多，需要重新配置，给运维也带来了较多的麻烦。若没有及时更新配置恢复时间参数，在节点重启 时，可能由于恢复时间不足，造成te隧道控制平面恢复失败，导致业务中断。

技术实现要素：

本发明的主要目的在于提供一种重启恢复时间的调整方法和装置，旨在解决网络设备在优雅重启时恢复时间不能根据lsp数目动态调整，可能由于恢复时间的不足造成te隧道恢复失败，从而导致业务中断的问题。

为实现上述目的，本发明提供一种重启恢复时间的调整方法，所述重启恢复时间的调整方法包括步骤：

第一节点获取与其相邻的第二节点之间的隧道数目；

所述第一节点根据所述隧道数目确定其重启恢复时间；

所述第一节点将所述重启恢复时间发送至第二节点，以供所述第二节点在第一节点重启时根据所述重启恢复时间向所述第一节点发送恢复报文。

可选地，所述第一节点根据所述隧道数目确定其重启恢复时间的步骤之前包括步骤：

所述第一节点判断所述隧道数目是否发生变化；

在所述隧道数目发生变化时，执行所述第一节点根据所述隧道数目确定其重启恢复时间的步骤。

可选地，所述第一节点将所述重启恢复时间发送至第二节点的步骤之前包括步骤：

所述第一节点判断所述重启恢复时间是否发生变化；

在所述重启恢复时间发生变化时，执行所述第一节点将所述重启恢复时间发送至第二节点的步骤。

可选地，所述重启恢复时间的调整方法还包括步骤：

所述第一节点接收与其相邻的所述第二节点发送的重启恢复时间；

所述第一节点根据所述重启恢复时间更新存储在本地的第二节点的重启恢复时间。

可选地，所述第一节点根据所述重启恢复时间更新存储在本地的第二节点的重启恢复时间的步骤之前还包括步骤：

所述第一节点判断接收到的所述重启恢复时间与本地存储的重启恢复时间是否一致；

在接收到的所述重启恢复时间与本地存储的重启恢复时间不一致时，执 行所述第一节点根据所述重启恢复时间更新存储在本地的第二节点的重启恢复时间的步骤。

本发明进一步提供一种重启恢复时间的调整装置，所述重启恢复时间调整的装置包括：

获取模块，用于获取与其所在的节点相邻的其它节点之间的隧道数目；

确定模块，用于根据所述隧道数目确定重启恢复时间；

发送模块，用于将所述重启恢复时间发送至所述与其所在的节点相邻的其它节点，以供所述其它节点在其所在节点重启时根据所述重启恢复时间向其所在节点发送恢复报文。

可选地，所述重启恢复时间的调整装置还包括：

第一判断模块，用于判断所述隧道数目是否发生变化；

所述确定模块还用于在所述隧道数目发生变化时，根据所述隧道数目计算确定其重启恢复时间。

可选地，所述重启恢复时间的调整装置还包括：

第二判断模块，用于判断所述重启恢复时间是否发生变化；

所述发送模块还用于在所述重启恢复时间发生变化时，将所述重启恢复时间发送至与其所在的节点相邻的其它节点，以供所述其它节点在其所在节点重启时根据所述重启恢复时间向其所在节点发送恢复报文。

可选地，所述重启恢复时间的调整装置还包括：

接收模块，用于接收与其所在节点相邻的所述其它节点发送的重启恢复回复时间；

存储模块，用于根据所述重启恢复时间更新存储在本地的所述其它节点的重启恢复时间。

可选地，所述重启恢复时间的调整装置还包括：

第三判断模块，用于判断接收到的所述重启恢复时间与本地存储的重启恢复时间是否一致；

所述存储模块还用于在所述接收到的重启恢复时间与本地存储的重启恢复时间不一致时，根据所述重启恢复时间更新存储在本地的所述其它节点的重启恢复时间。

本发明提出的重启恢复时间的调整方法和装置，第一节点获取其与第二节点之间的隧道数目；所述第一节点根据所述隧道数目计算确定其第一恢复时间；所述第一节点更新报文中的所述第一恢复时间并发送至第二节点。在第一节点发生重启时，第二节点可根据接收到的第一节点发送的报文中的根据二者之间隧道数目动态调整的恢复时间向第一节点发送恢复消息，保证第一节点充足的恢复时间，而不会由于recoverytime恢复时间不足，造成te隧道控制平面恢复失败，导致业务中断。

附图说明

图1为本发明重启恢复时间的调整方法第一实施例的流程示意图；

图2为本发明基于lsp隧道数目增减rsvphello调整recovery_time交互场景一；

图3为本发明一实施例判断隧道数目是否发生变化的流程示意图；

图4为本发明基于lsp隧道数目增减rsvphello调整recovery_time交互场景二；

图5为本发明一判断恢复时间是否发生变化的流程示意图；

图6为本发明重启恢复时间的调整方法第二实施例的流程示意图；

图7为本发明重启恢复时间的调整装置第二实施例的中判断恢复时间是否与本地一致的流程示意图；

图8为本发明重启恢复时间的调整装置第一实施例的模块示意图；

图9为本发明一实施例包括第一判断模块的的模块示意图；

图10为本发明一实施例中包括第二判断模块的模块示意图；

图11为本发明重启恢复时间的调整装置第二实施例的模块示意图；

图12为本发明重启恢复时间的调整装置第二实施例中包括第三判断模块的模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明提供一种重启恢复时间的调整方法。

参照图1，图1为本发明重启恢复时间的调整方法第一实施例的流程示意图。

本实施例提出一种重启恢复时间的调整方法，所述重启恢复时间的调整方法包括步骤：

步骤s10，第一节点获取与其相邻的第二节点之间的隧道数目；

在本实施例中，各个节点之间按照rsvp-te(resourcereservationprotocol-trafficengineer基于流量工程的资源预留协议)信令交互完成隧道的建立，其中建立隧道的路径可以是在本地进行的配置，也可以从网络获取。建立隧道连接的各个节点之间通过hello报文交互确认邻居节点的状态，其中所述hello报文携带了restarttime重启时间和recoverytime恢复时间两个参数。

在本实施例中，所述recoverytime恢复时间根据建立了邻居关系的节点间的lsp隧道数目确定。

步骤s20，所述第一节点根据所述隧道数目确定其重启恢复时间；

在本实施例中，在获取到建立邻居关系的节点间的隧道数目后，可根据一个随所述隧道数目单调的函数计算得到所述恢复时间，例如可根据公式恢复时间t＝(t1+lsp_count*t2)ms计算得到，其中t1是一个基础时间，t2是lsp数目变化的时间因子，也可以是其他的一个基于lsp数目的单调函数。

如图2所示，100条lsp从r1经过r2，目的地到r3。这样r1、r2、r3两两之间存在100条lsp，这个时候r1和r2，r2和r3分别建立有hello邻居关系。

r1和r2、r2和r3两两之间分别通告的recovery_time为t1+100*t2ms。保存与各自本地。

当r1和r3之间经过r2再增加一条lsp时，相当于r1和r2，以及r2和r3之间又新增一条lsp。这个时候r1和r2，以及r2和r3之间通告的recovery_time为t1+101*t2，同时也保存于各自本地。

步骤s30，所述第一节点将所述重启恢复时间发送至第二节点，以供所述第二节点在第一节点重启时根据所述重启恢复时间向所述第一节点发送恢复报文。

在本实施例中，所述邻居节点之间通过hello报文交互，所述hello报文携带了restarttime重启时间和recoverytime恢复时间两个参数。

进一步地，参照图3，所述步骤s20之前还包括步骤：

步骤s40，所述第一节点判断所述隧道数目是否发生变化；

在本实施例中，第一节点与第二节点之间的隧道数目可能随时间的变化产生变化，所述第一节点定时获取与所述第二节点之间的隧道数目，并将所述隧道数目保存在本地，在下次获取两节点之间的隧道数目后，将获取到的所述隧道数目与本地保存的隧道数目进行比对，确认两节点之间的隧道数目是否发生变化。

在所述隧道数目发生变化时，执行所述步骤s20。

在本实施例中，所述第一节点在确认与第二节点之间的隧道数目发生变化时，采用预设的随隧道数目单调的函数公式计算所述恢复时间并发送到第二节点。

可以理解的是，在检测到所述第一节点与第二节点之间的隧道数目没有发生变化时，则可不进行恢复时间的更新操作，只需向第二节点发送原来的恢复时间即可。

如图4所示，r4-r5-r6，r4-r5-r7分别具有100条lsp，这种情况下r4，r5之间存在200条lsp，r5，r6之间存在100条lsp，r5，r7之间也存在100条lsp。他们两两建立hello关系通告的recovery_time分别为：(r4，r5)为t1+200*t2；(r5，r6)为t1+100*t2；(r5，r7)为t1+100*t2。

如果在r5和r7之间增加一条lsp，那么r5和r7之间hello通告的recovery_time修改为：t1+101*t2。由于其他邻居间lsp数目没变，所以维持原来的recovery_time不变。

进一步地，参照图5，所述步骤s30之前包括步骤：

步骤s50，所述第一节点判断所述重启恢复时间是否发生变化；

在本实施例中，所述第一节点还可以在第一节点获取到与第二节点之间的隧道数目之后进行所述第一节点的重启恢复时间的计算，根据计算出的所 述第一节点的重启恢复时间判断是否发生了变化，根据所述判断结果确定是否在组建hello交互报文时的，将所述报文中第一节点的重启恢复时间参数更新。

在所述重启恢复时间发生变化时，执行所述步骤s30。

本实施例提出的重启恢复时间的调整方法，第一节点获取与其相邻的第二节点之间的隧道数目；所述第一节点根据所述隧道数目确定其重启恢复时间；所述第一节点将所述重启恢复时间发送至第二节点，以供所述第二节点在第一节点重启时根据所述重启恢复时间向所述第一节点发送恢复报文。在每一次发送hello报文进行交互时，都将获取到的所述恢复时间更新在报文中，并将所述hello报文发送至邻居节点。在第一节点发生重启时，第二节点可根据接收到的第一节点发送的报文中的根据二者之间隧道数目动态调整的重启恢复时间向第一节点发送恢复消息，保证第一节点充足的恢复时间，而不会由于recoverytime恢复时间不足，造成te隧道控制平面恢复失败，导致业务中断。

进一步地，基于本发明第一实施例提出本发明重启恢复时间的调整方法的第二实施例，参照图6，所述重启恢复时间的调整方法还包括步骤：

步骤s60，所述第一节点接收与其相邻的所述第二节点发送的重启恢复时间；

在本实施例中，所述第一节点与第二节点之间建立了连接隧道，第一节点与第二节点互为邻居节点，在第二节点进行优雅重启时，所述第一节点即为所述第二节点的辅助方，向第二节点发送恢复报文，在进行hello报文交互时，两节点互相发送并接收所述hello报文，故第一节点也可接收第二节点发送的hello报文。

步骤s70，所述第一节点根据所述重启恢复时间更新存储在本地的第二节点的重启恢复时间。

在本实施例中，所述第一节点接收到第二节点发送的所述报文后，提取所述报文中的重启恢复时间，并将所述重启恢复时间保存在本地，在所述第二节点进行重启时，所述第一节点作为第二节点的辅助方，根据所述重启恢复时间向所述第二节点发送恢复报文。

在本实施例中，所述第一节点在接收到所述第二节点发送的报文后，提取所述报文中的重启恢复时间，即所述第二节点进行优雅重启时的恢复时间，在所述第一节点提取出所述重启恢复时间后，将所述重启恢复时间更新保存在本地，作为新的重启恢复时间，即所述第二节点发生优雅重启时，向所述第二节点发送恢复报文的时间。

进一步地，参照图7，所述步骤s70之前还包括步骤：

步骤s80，所述第一节点判断接收到的所述重启恢复时间与本地存储的重启恢复时间是否一致；

在本实施例中，所述第一节点在提取到所述重启恢复时间之后，可将所述重启恢复时间与保存在本地的重启恢复时间进行对比，根据所述对比结果判断是否需要对保存在本地的重启恢复时间，即所述所述第二节点发生优雅重启时，第一节点向所述第二节点发送恢复报文的时间，进行更新。

在所述报文中的第二恢复时间与本地存储的第三存储时间不一致时，执行所述步骤s70。

在本实施例中，在第一节点判断所述报文中的重启恢复时间与所述保存在本地的重启恢复时间不一致时，将所述报文中的所述重启恢复时间作为新的重启恢复时间保存在本地，作为所述第二节点发生优雅重启时，第一节点向所述第二节点发送恢复报文的时间。

本实施例提出的重启恢复时间的调整方法，在节点接收到邻居节点发送的报文后，根据从所述报文中提取出的所述恢复时间与本地保存的恢复时间进行对比，确定所述恢复时间是否发生变化，在所述恢复时间发生变化时，将所述变化的恢复时间更新保存在本地作为邻居节点的优雅重启恢复时间，在所述恢复时间没有发生变化时，不更新所述保存在本地的恢复时间，更加节省资源。

本发明进一步提供一种重启恢复时间的调整装置。

如图8所示，图8为本发明重启恢复时间的调整装置第一实施例的功能模块示意图。需要强调的是，对本领域的技术人员来说，图8所示功能模块图仅仅是一个较佳实施例的示例图，本领域的技术人员围绕图8所示的重启恢复时间的调整装置的功能模块，可轻易进行新的功能模块的补充；各功能 模块的名称是自定义名称，仅用于辅助理解该重启恢复时间的调整装置的各个程序功能块，不用于限定本发明的技术方案，本发明技术方案的核心是，各自定义名称的功能模块所要达成的功能。

本实施例提出一种重启恢复时间的调整装置，所述重启回复时间的调整装置包括：

获取模块10，用于获取与其所在的节点相邻的其它节点之间的隧道数目；

在本实施例中，各个节点之间按照rsvp-te(resourcereservationprotocol-trafficengineer基于流量工程的资源预留协议)信令交互完成隧道的建立，其中建立隧道的路径可以是在本地进行的配置，也可以从网络获取。建立隧道连接的各个节点之间通过hello报文交互确认邻居节点的状态，其中所述hello报文携带了restarttime重启时间和recoverytime恢复时间两个参数。

在本实施例中，所述recoverytime恢复时间根据建立了邻居关系的节点间的lsp隧道数目确定。

确定模块20，用于根据所述隧道数目确定重启恢复时间；

在本实施例中，在获取到建立邻居关系的节点间的隧道数目后，可根据一个随所述隧道数目单调的函数计算得到所述恢复时间，例如可根据公式恢复时间t＝(t1+lsp_count*t2)ms计算得到，其中t1是一个基础时间，t2是lsp数目变化的时间因子，也可以是其他的一个基于lsp数目的单调函数。

如图2所示，100条lsp从r1经过r2，目的地到r3。这样r1、r2、r3两两之间存在100条lsp，这个时候r1和r2，r2和r3分别建立有hello邻居关系。

r1和r2、r2和r3两两之间分别通告的recovery_time为t1+100*t2ms。保存与各自本地。

当r1和r3之间经过r2再增加一条lsp时，相当于r1和r2，以及r2和r3之间又新增一条lsp。这个时候r1和r2，以及r2和r3之间通告的recovery_time为t1+101*t2，同时也保存于各自本地。

发送模块30，用于将所述重启恢复时间发送至所述与其所在的节点相邻的其它节点，以供所述其它节点在其所在节点重启时根据所述重启恢复时间 向其所在节点发送恢复报文。

在本实施例中，邻居节点之间通过hello报文交互，所述hello报文携带了restarttime重启时间和recoverytime恢复时间两个参数。所述其它节点作为辅助方时在主节点重启时根据所述重启恢复时间向主节点发送恢复报文。

进一步地，参照图9，所述rsvp-te优雅重启的恢复时间调整装置还包括：

第一判断模块40，用于判断所述隧道数目是否发生变化；

在本实施例中，一节点与其邻居节点之间的隧道数目可能随时间的变化产生变化，所述一节点定时获取与其邻居二节点之间的隧道数目，并将所述隧道数目保存在本地，在下次获取两节点之间的隧道数目后，将获取到的所述隧道数目与本地保存的隧道数目进行比对，确认两节点之间的隧道数目是否发生变化。

所述确定模块20还用于在所述隧道数目发生变化时，根据所述隧道数目计算确定其重启恢复时间。

可以理解的是，在检测到所述一节点与其邻居节点之间的隧道数目没有发生变化时，则可不进行恢复时间的更新操作，只需向其邻居节点发送原来的恢复时间即可。

如图4所示，r4-r5-r6，r4-r5-r7分别具有100条lsp，这种情况下r4，r5之间存在200条lsp，r5，r6之间存在100条lsp，r5，r7之间也存在100条lsp。他们两两建立hello关系通告的recovery_time分别为：(r4，r5)为t1+200*t2；(r5，r6)为t1+100*t2；(r5，r7)为t1+100*t2。

如果在r5和r7之间增加一条lsp，那么r5和r7之间hello通告的recovery_time修改为：t1+101*t2。由于其他邻居间lsp数目没变，所以维持原来的recovery_time不变。

进一步地，参照图10，所述重启恢复时间的调整装置还包括：

第二判断模块50，用于判断所述重启恢复时间是否发生变化；

在本实施例中，所述一节点在确认与其邻居二节点之间的隧道数目发生变化时，采用预设的随隧道数目单调的函数公式计算所述恢复时间并发送到其邻居节点。

在本实施例中，所述一节点还可以在其获取到与其邻居节点之间的隧道数目之后进行所述重启恢复时间的计算，根据计算出的所述重启恢复时间判断是否发生了变化，根据所述判断结果确定是否在组建新报文时，将所述报文中的的所述重启恢复时间更新。

所述发送模块30还用于在所述重启恢复时间发生变化时，将所述重启恢复时间发送至与其所在的节点相邻的其它节点，以供所述其它节点在其所在节点重启时根据所述重启恢复时间向其所在节点发送恢复报文。

本实施例提出的重启恢复时间的调整装置，获取与其所在的节点相邻的其它节点之间的隧道数目；根据所述隧道数目确定重启恢复时间；将所述重启恢复时间发送至所述与其所在的节点相邻的其它节点，以供所述其它节点在其所在节点重启时根据所述重启恢复时间向其所在节点发送恢复报文。在每一次发送hello报文进行交互时，都将获取到的所述恢复时间更新在报文中，并将所述hello报文发送至邻居节点。在一节点发生重启时，其邻居节点可根据接收到的报文中的根据二者之间隧道数目动态调整的恢复时间向所述节点发送恢复消息，保证其充足的恢复时间，而不会由于recoverytime恢复时间不足，造成te隧道控制平面恢复失败，导致业务中断。

进一步地，基于本发明第一实施例提出本发明重启恢复时间的调整装置的第二实施例，参照图11，所述重启恢复时间的调整装置还包括：

接收模块60，，用于接收与其所在节点相邻的所述其它节点发送的重启恢复回复时间；

在本实施例中，所述一节点与其邻居二节点之间建立了连接隧道，在第二节点进行优雅重启时，第一节点即为所述第二节点的辅助方，向第二节点发送恢复报文，在进行hello报文交互时，两节点互相发送并接收所述hello报文，故第一节点也可接收第二节点发送的hello报文。

存储模块70，用于根据所述重启恢复时间更新存储在本地的所述其它节点的重启恢复时间。

在本实施例中，第一节点接收到第二节点发送的所述报文后，提取所述报文中的重启恢复时间，并将所述重启恢复时间保存在本地，在所述第二节点进行重启时，所述第一节点作为第二节点的辅助方，根据所述重启恢复时 间向所述第二节点发送恢复报文。

进一步地，参照图12，所述所述重启恢复时间的调整装置还包括：

第三判断模块80，用于判断接收到的所述重启恢复时间与本地存储的重启恢复时间是否一致；

在本实施例中，第一节点在提取到所述重启恢复时间之后，可将所述重启恢复时间与保存在本地的重启恢复时间进行对比，根据所述对比结果判断是否需要对保存在本地的重启恢复时间，即所述所述第二节点发生优雅重启时，第一节点向所述第二节点发送恢复报文的时间，进行更新。

所述存储模块70还用于在所述接收到的重启恢复时间与本地存储的重启恢复时间不一致时，根据所述重启恢复时间更新存储在本地的所述其它节点的重启恢复时间。

在本实施例中，在第一节点判断所述报文中的重启恢复时间与所述保存在本地的重启恢复时间不一致时，将所述报文中的所述重启恢复时间作为新的重启恢复时间保存在本地，作为所述第二节点发生优雅重启时，第一节点向所述第二节点发送恢复报文的时间。

本实施例提出的重启恢复时间的调整装置，在节点接收到邻居节点发送的报文后，根据从所述报文中提取出的所述恢复时间与本地保存的恢复时间进行对比，确定所述恢复时间是否发生变化，在所述恢复时间发生变化时，将所述变化的恢复时间更新保存在本地作为邻居节点的优雅重启恢复时间，在所述恢复时间没有发生变化时，不更新所述保存在本地的恢复时间，更加节省资源。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述 实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。