CN1269321C - 智能光网络中多节点重启后控制平面的恢复方法 - Google Patents
智能光网络中多节点重启后控制平面的恢复方法 Download PDFInfo
- Publication number
- CN1269321C CN1269321C CNB021474400A CN02147440A CN1269321C CN 1269321 C CN1269321 C CN 1269321C CN B021474400 A CNB021474400 A CN B021474400A CN 02147440 A CN02147440 A CN 02147440A CN 1269321 C CN1269321 C CN 1269321C
- Authority
- CN
- China
- Prior art keywords
- node
- instance
- value
- dst
- hello message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
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)协议进行建立、删除的光连接。所作的各种假设仅仅用于说明之目的,不应理解为对本发明的限定。本发明在现有方案的基础之上,提出了适用于连续多个节点重启后控制平面恢复的方法,所述方法应遵循的几个原则为:
(1)前一节点只有在完成与上游节点的同步恢复过程后才能发起对下游节点的同步;
(2)由上游未重启的节点或已与上游节点同步恢复完成的节点启动Recovery Timer定时器;
(3)在两个相邻节点没有同步恢复结束之前,它们之间交换的Hello消息中的Dst_instance的值始终设置为0;由上游节点在Recovery Timer定时器超时后通知下游节点同步恢复过程结束;
(4)通过将发往下游节点的Hello消息中的Dst_instance的值改为该节点从该下游节点收到的Hello消息中的Src_instance的值来实现。
本发明正是基于上述具有新颖性和创造性的几项原则,实现连续多个节点重启后控制平面恢复。本领域普通技术人员在本发明的上述教导下,根据本发明具体的应用情形,可以对本发明进行各种改型,然而,不偏离本发明上述思想的技术方案均应受到本发明所附权利要求的保护。
Claims (4)
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之值设置为零;
(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停止上述的自刷新,启动恢复定时器Recovery Timer,向节点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同步结束。
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同步的状态。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB021474400A CN1269321C (zh) | 2002-10-25 | 2002-10-25 | 智能光网络中多节点重启后控制平面的恢复方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB021474400A CN1269321C (zh) | 2002-10-25 | 2002-10-25 | 智能光网络中多节点重启后控制平面的恢复方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1492601A CN1492601A (zh) | 2004-04-28 |
CN1269321C true CN1269321C (zh) | 2006-08-09 |
Family
ID=34232979
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB021474400A Expired - Fee Related CN1269321C (zh) | 2002-10-25 | 2002-10-25 | 智能光网络中多节点重启后控制平面的恢复方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1269321C (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101283543B (zh) * | 2005-12-07 | 2011-07-06 | 中兴通讯股份有限公司 | 一种多个相邻节点同时重启时rsvp gr的处理方法 |
CN101087207B (zh) | 2006-06-09 | 2010-05-12 | 华为技术有限公司 | 一种多节点通信故障的处理方法 |
CN101212340B (zh) * | 2006-12-25 | 2010-05-19 | 中兴通讯股份有限公司 | 一种自动交换光网络控制节点的重启方法 |
WO2008086644A1 (fr) * | 2007-01-05 | 2008-07-24 | Zte Corporation | Procédé de réalisation de la synchronisation de l'état de connexion dans un réseau optique commuté automatique |
CN101141825B (zh) * | 2007-08-24 | 2010-09-29 | 中兴通讯股份有限公司 | 一种自动交换光网络中功能冻结/解冻方法 |
CN101616069B (zh) * | 2008-06-23 | 2012-04-04 | 华为技术有限公司 | 基于优雅重启的信息恢复方法和路由器 |
CN101646107A (zh) * | 2009-08-14 | 2010-02-10 | 中兴通讯股份有限公司 | 恢复业务连接的方法、装置、***以及节点设备 |
-
2002
- 2002-10-25 CN CNB021474400A patent/CN1269321C/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN1492601A (zh) | 2004-04-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100490390C (zh) | 业务故障恢复方法 | |
EP1953958B1 (en) | Management of protection path bandwidth and changing of path bandwidth | |
EP1986371A1 (en) | A failure processing method and a system and a device thereof | |
CN101047440A (zh) | 一种业务路径返回的方法 | |
EP1753182A1 (en) | A method for node restart recovery in the general multi-protocol label-switching path | |
CN1866806A (zh) | 共享格状网恢复的实现方法 | |
CN1269321C (zh) | 智能光网络中多节点重启后控制平面的恢复方法 | |
CN1812401A (zh) | 多协议标签交换***中建立返回标签交换路径的方法 | |
CN1505409A (zh) | 一种基于网络入口节点的重路由方法 | |
CN1780253A (zh) | 一种快速重路由的方法 | |
CN1933423A (zh) | 一种光网络lsp发生异常删除的恢复方法和装置 | |
CN1859157A (zh) | 业务保护方法 | |
CN1194507C (zh) | 自动光交换网中的双向通道恢复方法 | |
CN1812360A (zh) | 智能光网络的业务重路由触发方法 | |
CN1152313C (zh) | 一种基于随机早期检测的逐节拥塞控制方法 | |
CN1082299C (zh) | 用于分组方式数据连接的路由再选方法 | |
CN101047641A (zh) | 路由受限标记交换路由器的平稳重启方法 | |
CN1738213A (zh) | 防错连的方法 | |
CN1949724A (zh) | 一种以太端口保护的方法 | |
CN1805398A (zh) | 一种光传输网络的保护方法 | |
CN1874293A (zh) | 一种自动交换光网络信息传输方法 | |
CN1251447C (zh) | 一种实现网络网络接口连接的同步和恢复方法 | |
CN1863108A (zh) | 自动交换光网络中sc/spc连接控制的方法 | |
CN1744568A (zh) | 用于经由路径或迂回路径交换数据信息的网络节点 | |
CN1149761C (zh) | 在全光网中基于业务的保护方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C17 | Cessation of patent right | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20060809 Termination date: 20111025 |