CN1269321C

CN1269321C - 智能光网络中多节点重启后控制平面的恢复方法

Info

Publication number: CN1269321C
Application number: CNB021474400A
Authority: CN
Inventors: 蔡军州; 宋辉; 陈勇; 石兴华
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2002-10-25
Filing date: 2002-10-25
Publication date: 2006-08-09
Anticipated expiration: 2022-10-25
Also published as: CN1492601A

Abstract

本发明提供用于连续多个节点重启后控制平面恢复的方法，在恢复过程中，前一重启节点只有在完成与上游节点的同步恢复过程后才能发起对下游重启节点的同步；由上游未重启的节点或已与上游节点同步恢复完成的节点启动恢复定时器；在两个相邻节点没有同步恢复结束之前，它们之间交换的Hello消息中的Dst_instance的值始终设置为0；由上游节点在恢复定时器超时后通知下游节点同步恢复过程结束；通过将发往下游节点的Hello消息中的Dst_instance的值改为该节点从该下游节点收到的Hello消息中的Src_instance的值来实现。因此，本发明的方法可以克服现有技术的不足，解决连续多个节点重启后控制平面的正确恢复。

Description

智能光网络中多节点重启后控制平面的恢复方法

技术领域

本发明涉及光通信领域，特别涉及在智能光网络中多节点重启后控制平面的恢复方法。

背景技术

在智能光网络中，有一条基本的原则：控制平面的失败不能影响业务平面，导致对业务的损害。因此，当控制平面发生失败，如节点重启后，恢复原来的控制信息，重新对业务进行控制显得非常必要和重要。在智能光网络中，控制平面的失败可分为两种情况：一种是网元节点发生了失败，如节点重启，控制信息丢失，但底层的业务还保存下来了；另一种情况是控制通道失败，如两节点间的光纤断了，它们之间的控制通道通讯中断。本申请所涉及的只是节点重启后，用于恢复控制平面的方法。

在现有的IETF(Internet Engineering Task Force，因特网工程任务组)、OIF(Optical Internetworking Forum，光网络论坛)有关智能光网络的标准和草案中，对于由RSVP(Resource reSerVation Protocol，资源预留协议)或RSVP-TE(Resource reSerVation Protocol with TrafficEngineering Extension，具有流量工程扩展的资源预留协议)建立起来的连接，只给出了单节点发生重启后用于恢复控制平面的方法，对于有多个连续的节点发生重启后如何进行恢复处理，则没有给出解决方案。

上述关于单节点重启后恢复控制平面的技术解决方案记载在“用户网络接口信令协议1.0，光网络论坛，2000.125.7，2001年10月1日”(UserNetwork Interface(UNI)1.0Signaling Specification，OIF2000.125.7，October，1，2001)中。

在上述已知的技术解决方案中，由于同步恢复是由上游节点通过发送带Recovery_Label的Path消息来发起的，在重启的节点上启动了RecoveryTimer(恢复定时器)，这样，在多个连续的节点发生重启的情况下，采用上述的协议中提供的解决方案会存在以下问题。假设网络中的某条连接经过的两个连续的节点B和C发生了重启，而且节点C比节点B先完成重启，这样，节点C就有可能在Recovery Timer超时的时间内收不到节点B发过来的带Recovery_Label(恢复标签)的Path消息，因此，在Recovery Timer超时后，节点C会删除底层的交叉连接。在光网络中，控制层的失败不应影响业务层，即控制层的失败不能导致业务层的失败，而在上述情况下，控制层的失败导致删除了底层的交叉连接，影响了底层的业务，这种情况是不应该发生的。

发明内容

本发明正是针对上述现有的技术解决方案中的不足提出的，根据本发明的方法，可以实现连续多个节点重启后的控制平面的恢复。本发明的所述方法是基于这样一个基本原则来设计的，即只有上游节点同步恢复完毕了，才能发起对下游节点进行同步恢复。

为实现上述本发明目的，体现上述基本设计思想，本发明提供一种用于在智能光网络中多节点重启后恢复控制平面的方法，所述的智能光网络是根据RSVP或RSVP-TE建立、删除的连接，在该连接中至少有相邻的三个节点A，B和C，其中，一个节点A为非重启节点，位于其他节点B和C的上游，节点B和C为依次相邻的重启节点，所述方法包括以下步骤：

(1)所述非重启节点A发现与相邻节点B的通信中断，向该节点B发送的Hello消息中Src_instance之值保持不变，Dst_instance之值设置为零，并且所述的非重启节点A自刷新与该相邻节点B相关的状态；

(2)与非重启节点A相邻的重启节点B发生重启后，向相邻节点A和C发送Hello消息，该Hello消息中Src_instance之值相对于与该节点发生重启前的Src_instance之值发生变化，Dst_instance之值设置为零；

(3)与上述发生重启的节点B相邻的另一重启节点C根据从节点B接收到的Hello消息中的Dst_instance＝0判断出节点B尚未恢复同步，节点C向节点B发送响应的Hello消息中Dst_instance＝0；

(4)所述非重启节点A接受到从节点B发来的Hello消息，如果该消息中的Src_instance之值相对于该节点B发生重启前的Src_instance之值发生了变化，则判断出节点B发生了重启，节点A停止上述的自刷新，启动RecoveryTimer(恢复定时器)，向节点B发送的Hello消息中的Dst_instance之值保持为零，并且向节点B发送携带Recovery_Label的Path消息，用于节点B的同步恢复；

(5)所述非重启节点A在Recovery Timer超时后，发送到节点B的Hello消息中的Dst_instance之值设置成与节点B发送到节点A的Hello消息中的Src_instance之值相同，用于通知节点B同步结束；

(6)节点B与节点A同步后，节点B启动Recovery Timer，向节点C发送的Hello消息中的Dst_instance之值保持为零，并且向节点C发送携带Recovery_Label的Path消息，用于节点C的同步恢复；

(7)所述节点B在Recovery Timer超时后，发送到节点C的Hello消息中的Dst_instance之值设置成与节点C发送到节点B的Hello消息中的Src_instance之值相同，用于通知节点C同步结束。

从上述本发明所述的适用于连续多个节点重启后控制平面恢复的方法的技术方案中可以看出，本发明所述方法不同于现有协议，主要体现在以下几个方面：

(1)前一节点只有在完成与上游节点的同步恢复过程后才能发起对下游节点的同步；

(2)由上游未重启的节点或已与上游节点同步恢复完成的节点启动Recovery Timer定时器；

(3)在两个相邻节点没有同步恢复结束之前，它们之间交换的Hello消息中的Dst_instance的值始终设置为0；由上游节点在Recovery Timer定时器超时后通知下游节点同步恢复过程结束，

(4)通过将发往下游节点的Hello消息中的Dst_instance的值改为该节点从该下游节点收到的Hello消息中的Src_instance的值来实现。

因此，本发明的方法可以克服现有技术的不足，解决连续多个节点重启后控制平面的正确恢复，不影响底层的业务。

附图说明

图1示意性地说明了本发明提供的用于在连续多个节点重启后恢复控制平面的方法的流程。

具体实施方式

为了方便本领域普通技术人员理解本发明，在解释本发明的具体实施方式之前，先做如下假设：

(1)图1中的节点A、B、C为连续的三个节点，依次为上下游节点；

(2)在发生节点重启前，节点A发给邻居的Hello消息中的Src_instance＝11，节点B发给邻居的Hello消息中的Src_instance＝2，节点C发给邻居的Hello消息中的Src_instance＝3；

(3)节点A为非重启节点(Non Restart Node)，节点B和C为重启节点(Restart Node)。重启后，节点B发给邻居的Hello消息中的Src_instance＝22，节点C发给邻居的Hello消息中的Src_instance＝33。

接下来，参照图1，说明基于上述假设的本发明的用于在连续多个节点重启后恢复控制平面的方法。

1、节点B完成重启后，向邻居节点发送Hello消息

节点B完成重启后，分别向节点A和节点C发送Hello消息，Hello消息中的Src_instance＝22，Dst_instance＝0。

2、节点C在收到节点B发送所来得Hello消息后的处理

根据本发明，节点C应在节点B完成与节点A的同步恢复之后发生重启。节点C根据从节点B收到的上述Hello消息中的Dst_instance＝0，判定节点B还没有完成同步恢复。这时，节点C必须等待节点B完成同步恢复。在所述的等待过程中，节点C向节点B发送响应的Hello消息中的Src_instance＝33，Dst_instance＝0。

节点B在收到来自节点C的响应的Hello消息后，由于本节点还没有完成同步恢复，所以发给节点A和节点C的Hello消息中的Src_instance＝22，Dst_instance＝0。

也就是说，根据本发明，如果上游节点没有完成同步恢复，该节点与其下游的邻居节点之间交换的Hello消息中的Dst_instance＝0应始终保持。本发明正是通过这种机制保证在上游节点例如节点B没有完成同步恢复前，其下游节点例如节点C就不会启动恢复过程。

3、节点A收到节点B发送过来的Hello消息后的处理

如图1所示，节点A为非重启节点。如现有技术中已知的那样，节点A一旦发现与邻居的通信中断，该节点向发生通信中断的邻居节点B的Hello消息中的Src_instance＝11，Dst_instance＝0。这时，节点A与节点B相关的状态进入自刷新状态。

根据前面的假设，在发生节点重启前，节点B发给邻居的Hello消息中的Src_instance＝2。然而，如前文所述，此时发生了节点B重启，如上所述，节点A从节点B接收到的HELLO消息是Src_instance＝22，Dst_instance＝0。

节点A通过将其保存的节点B的Src_instance之值(Src_instance＝2)与刚收到的来自节点B的Hello消息中的Src_instance(Src_instance＝22)值相比较，二者发生了变化，据此，节点A可以判断节点B发生了重启。于是，节点A停止自刷新，启动Recovery Timer，向节点B发送Hello消息，该Hello消息中Src_instance＝11，Dst_instance＝0。值得注意的是，在未能与节点B完成同步恢复之前，节点A发给节点B的Hello消息中的Dst_instance应始终为0。

同时，节点A根据所有与节点B有关的状态生成Path消息，并携带Recovery_Label对象发送到节点B，以对节点B进行同步恢复。

4、如果节点A启动的Recovery Timer超时，节点A会删除没有和节点B同步的状态，节点A发给节点B的Hello消息中的Dst_instance被设置为22，而不再为0，这样做是用于通知节点B同步结束。

5、节点B收到节点A发送过来的带Recovery_Label的Path消息之后的处理与现有技术完全一致。简而言之，节点B首先检查它是否有与所接受的Path消息相对应的RSVP状态。如果有与该Path消息相对应的状态，则按照正常的处理流程对该Path消息进行处理。

如果没有与该Path消息相对应的状态，并且该消息中没有携带Recovery_Label对象，则该Path消息是用于建立一条新的LSP(标签交换路径)的，做创建新的连接的处理；

如果没有与该Path消息相对应的状态，该消息中携带了Recovery_Label对象，就在交叉连接表中查找incoming interface(入接口)与Path消息中携带的incoming interface相同且incoming_label(入标记)与Recovery_Label对象中携带的标记相同的交叉连接。如果这样的交叉连接没有找到，就认为该Path消息是用于建立一条新的连接的。

如果这样的交叉连接找到了，则创建相应的RVSP状态。然后，向下游节点发送Path消息时，包含一个Suggested_Label(建议标签)对象，其值与该交叉连接的Outgoing_label(出标记)的值相同，Outgoing Interface(出接口)与该交叉连接的Outgoing Interface的值相同。如果该节点的下一个节点也重启了，则还要在Path消息中携带一个Recovery_label对象。

对于双向LSP，就要在交叉连接表中查找incoming interface与Path消息中携带的incoming interface相同，incoming_label与Recovery_label对象中携带的标记相同，outgoing_label与Upstream_lable(上行标签)中携带的标记相同的交叉连接。如果这样的交叉连接没有找到，就认为该Path消息是用于建立一条新的连接的。

如果这样的交叉连接找到了，则创建相应的RSVP状态。该交叉连接就认为被同步了。如果该节点不是LSP的末节点，则相应的发送出去的Path消息中携带的Upstream_lable的值为该交叉连接的incoming_label的值。

6、节点B收到节点A发送过来的Hello消息后，若发现收到的Hello消息中的Dst_instance＝0，则说明和节点A还没有完成同步，节点B发给节点A的Hello消息中的Dst_instance仍设置为0；如果收到的Hello消息中的Dst_instance＝22，即与节点B发送给节点A的Hello消息中的Src_instance相同，则由此可以判断节点A与节点B的同步恢复过程已完成。只有在节点B完成了与其上游节点例如节点A的同步恢复后，节点B才能发起与节点C的同步恢复过程。

7、节点B发起与节点C的同步恢复过程

节点B发起与节点C的同步恢复过程的处理情况与节点A发起与节点B的同步恢复的处理过程类似。具体来说，节点B启动Recovery Timer，向节点C发送Hello消息(Src_instance＝22，Dst_instance＝0)。同样，在节点B未能与节点C完成同步恢复之前，节点B向节点C发送的HELLO消息中的Dst_instance始终为零。

类似于节点A对节点B发起的同步恢复，节点B也要根据所有与节点C有关的状态生成PATH消息，并携带Recovery_Label对象发送到节点C，以完成对节点C的同步恢复。节点C收到节点B发送过来的Hello消息后，若发现收到的Hello消息中的Dst_instance＝0，则说明和节点B还没有完成同步，节点C发给节点B的Hello消息中的Dst_instance仍设置为0；如果收到的Hello消息中的Dst_instance＝33，即与节点C发送给节点B的Hello消息中的Src_instance相同，则由此可以判断节点B与节点C的同步恢复过程已完成。

当此连接中的连续节点A，B和C恢复同步后，控制平面的恢复即告完成。

需要说明的是，在前述对本发明具体实施方式的描述中，所说的连接均指在智能光网络中使用RSVP(RSVP-TE)协议进行建立、删除的光连接。所作的各种假设仅仅用于说明之目的，不应理解为对本发明的限定。本发明在现有方案的基础之上，提出了适用于连续多个节点重启后控制平面恢复的方法，所述方法应遵循的几个原则为：

(3)在两个相邻节点没有同步恢复结束之前，它们之间交换的Hello消息中的Dst_instance的值始终设置为0；由上游节点在Recovery Timer定时器超时后通知下游节点同步恢复过程结束；

本发明正是基于上述具有新颖性和创造性的几项原则，实现连续多个节点重启后控制平面恢复。本领域普通技术人员在本发明的上述教导下，根据本发明具体的应用情形，可以对本发明进行各种改型，然而，不偏离本发明上述思想的技术方案均应受到本发明所附权利要求的保护。

Claims

1、用于智能光网络中多节点重启后恢复控制平面的方法，所述的智能光网络是根据资源预留协议RSVP或具有流量工程扩展的资源预留协议RSVP-TE建立、删除的连接，在该连接中至少有相邻的三个节点A，B和C，其中，一个节点A为非重启节点，位于其他节点B和C的上游，节点B和C为依次相邻的重启节点，所述方法包括以下步骤：

(1)所述非重启节点A发现与相邻节点B的通信中断，向该节点B发送的Hello消息中源实例Src_instance之值保持不变，目的实例Dst_instance之值设置为零，并且所述的非重启节点A自刷新与该相邻节点B相关的状态；

(2)与非重启节点A相邻的重启节点B发生重启后，向相邻节点A和C发送Hello消息，该HeUo消息中Src_instance之值相对于与该节点发生重启前的Src_instance之值发生变化，Dst_instance之值设置为零；

(4)所述非重启节点A接受到从节点B发来的Hello消息，如果该消息中的Src_instance之值相对于该节点B发生重启前的Src_instance之值发生了变化，则判断出节点B发生了重启，节点A停止上述的自刷新，启动恢复定时器Recovery Timer，向节点B发送的Hello消息中的Dst_instance之值保持为零，并且向节点B发送携带Recovery_Label的Path消息，用于节点B的同步恢复；

2、根据权利要求1所述的用于智能光网络中多节点重启后恢复控制平面的方法，其中在步骤(4)中，节点A停止自刷新后，启动Recovery Timer，向节点B发送的Hello消息中的Dst_instance之值应保持为零，直到节点A与节点B恢复同步。

3、根据权利要求1所述的用于智能光网络中多节点重启后恢复控制平面的方法，其中在上述步骤(3)中，节点C等待上游重启节点B与节点A完成同步恢复，在等待期间，节点C发送到节点B的Dst_instance之值应保持为零。

4、根据权利要求1所述的用于智能光网络中多节点重启后恢复控制平面的方法，其中在步骤(5)中，非重启节点A在Recovery Timer超时后，删除未与节点B同步的状态。