CN1801802B - 通用多协议标签交换路径上节点重启恢复的方法 - Google Patents

通用多协议标签交换路径上节点重启恢复的方法 Download PDF

Info

Publication number
CN1801802B
CN1801802B CN2004101031357A CN200410103135A CN1801802B CN 1801802 B CN1801802 B CN 1801802B CN 2004101031357 A CN2004101031357 A CN 2004101031357A CN 200410103135 A CN200410103135 A CN 200410103135A CN 1801802 B CN1801802 B CN 1801802B
Authority
CN
China
Prior art keywords
node
timer
message
recovery
overtime
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
Application number
CN2004101031357A
Other languages
English (en)
Other versions
CN1801802A (zh
Inventor
蔡军州
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN2004101031357A priority Critical patent/CN1801802B/zh
Priority to PCT/CN2005/002269 priority patent/WO2006069523A1/zh
Priority to EP05819664A priority patent/EP1753182A4/en
Publication of CN1801802A publication Critical patent/CN1801802A/zh
Application granted granted Critical
Publication of CN1801802B publication Critical patent/CN1801802B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/746—Reaction triggered by a failure

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

本发明公开了一种通用多协议标签交换路径上节点重启恢复的方法，该方法包括：正常邻居节点收到重启节点的HELLO应答消息后，停止本节点的自刷新定时器，并启动同步恢复定时器；当同步恢复定时器未超时时，所述正常邻居节点对其状态块进行自刷新；在自刷新过程中，向重启节点发送包含恢复信息的RSVP消息；重启节点根据RSVP消息恢复其状态块；当正常邻居和重启节点同步恢复完成后或者同步恢复定时器超时后，停止同步恢复定时器。利用本发明，可以保证在一条标签交换路径上有多个节点发生重启后该标签交换路径仍能正确恢复，提高了智能光网络控制平面的恢复能力。

Description

通用多协议标签交换路径上节点重启恢复的方法
技术领域
本发明涉及光网络技术领域，具体涉及一种通用多协议标签交换路径上节点重启恢复的方法。
背景技术
目前，受到IP(因特网协议)业务高速增长所产生的带宽需求以及波分复用技术所引入的新型带宽利用模式的双重驱动，IP业务的突发性和不确定性要求网络带宽动态分配，传统的静态光传输网难以满足需求，产生了智能光网络。智能光网络直接在光纤网络上引入了以IP为核心的智能控制技术，可以有效地支持连接的动态建立与拆除，基于流量工程按需合理分配网络资源，并能提供良好的网络保护/恢复性能。
智能光网络采用分层体系结构，包括三个平面：数据/传输面、管理面和控制面，由业务层提出带宽需求，通过标准的控制面来使传送面提供动态自动的路由，控制面可以通过信令UNI/NNI(用户网络接口/网络节点接口)接口的方式或通过管理***接口的方式来实现，而网络管理平面将仍然对全网进行管理。
在智能光网络中，引入了GMPLS(通用多协议标签交换)控制平面，使得网络在故障时具有强大的生存能力，实现了带宽的动态申请、释放和重新配置。简化了网络管理，提供了新的增值业务。与传统的MPLS(多协议标签交换)相比，GMPLS除支持包交换外，还支持低阶通道、高阶通道、波长交换、光纤交换等功能。基于IP网络的GMPLS在运用到电信级光传输网络时，所面临的最大挑战是稳定性和安全性问题，不论采用带内还是带外方式，控制平面的故障都不应该影响到传输平面已经建立的连接。在实际应用中，无论控制平面的UNI、NNI或CCI(控制连接接口)出现故障时，网络都必须具备良好的隔离和恢复能力，在一点或多点掉电恢复后业务和信令也必须能够恢复正常。
目前，大多数厂家选用RSVP-TE(基于资源预留协议的流量工程)协议作为实现控制平面的信令协议。
在UNI1.0标准和GMPLS RSVP-TE标准中给出了RSVP-TE协议在控制平面完全失败(如节点重启)，信令信息丢失后控制平面的恢复机制。如图1所示，具体过程如下：
(1)节点B发生掉电，不给节点A发HELLO(应答)响应。
(2)节点A在收不到节点B的HELLO响应且HELLO会话超时后，启动Restart_Timer定时器。在正常情况下，如果不从邻居节点收到周期性的刷新消息，PSB(路径状态块)、RSB(预留状态块)就会超时，导致连接被删除。在启动Restart_Timer定时器后，节点A进入自刷新过程：节点A虽然无法从邻居节点B收到周期性的刷新消息对那些经过节点B的连接的状态RSB进行刷新，但节点A仍然保存这些RSB，如同照常从邻居B收到了周期性的刷新消息一样。
(3)节点A一直给节点B发送HELLO消息，请求节点B应答。
(4)在节点B重启完成后，节点B会启动一个Recovery_timer定时器，节点B需要邻居节点在该定时器超时之前完成对本节点的所有LSP(标签交换路径)的恢复。在Recovery_timer定时器超时后，节点B会删除那些没有恢复的LSP。
(5)在节点B重启完成后，收到节点A发送过来的HELLO消息，节点B会给节点A发送一个HELLO消息，在节点A重新收到节点B的HELLO消息后，节点A会停止Restart_Timer定时器，从而停止自刷新。
(6)节点A发起对经过节点B的LSP进行恢复。对每条经过节点B的LSP，节点A给节点B发出Path(路径)消息，该消息中携带一个Recovery_label(恢复标签)对象；
(7)节点B在收到节点A发送过来的带Recovery_label的Path消息后，进行恢复处理。
上述方案只能解决一个节点重启的情况，在一条LSP(标签交换路径)上有多个节点发生重启后，会存在以下的缺陷：
1.连续两个节点重启时，上游节点先重启，下游节点长时间不重启。
如图2所示，假设一条LSP经过A-＞B-＞C-＞D，节点C和节点D发生掉电。假设节点C先重启，节点D长时间不重启，则在节点C重启完成后，节点B重新从节点C收到HELLO消息，会向节点C发出Path(带Recovery_label)消息进行恢复；节点C在收到该Path消息后，会做恢复的处理，在本地恢复起相应的控制块PSB。节点C在恢复了PSB后，会向节点D发出Path(带Recovery_label)消息进行恢复，但由于节点D没有完成重启，节点D不能恢复，所以节点C上的相应RSB不能恢复，所以节点C就不能对节点B上的RSB进行刷新。
由于在节点B重新收到节点C的HELLO响应后，节点B就会停止Restart_Timer定时器，从而停止自刷新，所以如果节点B上的RSB长时间不能从节点C收到相应的刷新消息，该RSB就会超时。在RSB超时后，节点B会向节点A发出ResvTear(预留删除)消息，同时删除本地的RSB。
在首节点A收到ResvTear后，会删除本地的RSB、PSB，同时会发出PathTear消息，去删除相应的PSB。
在节点B、节点C收到PathTear消息后，会删除本地的PSB。
这样，该条LSP的信令信息在节点A、B、C上都会被删除，这时即使节点D重启成功了，也无法恢复这条LSP，最后导致该条LSP恢复失败。
2.连续两个节点重启时，下游节点先重启，上游节点长时间不重启。
如图3所示，假设一条LSP经过A->B->C->D，节点B和节点C发生掉电。假设节点C先重启，节点B长时间不重启，则在节点C重启后，节点D重新收到节点C的HELLO消息，节点D会停止Restart_Timer定时器，从而停止自刷新过程。
由于节点C是上游节点，它重启后，信令信息丢失，节点B又长时间不能完成重启，所以节点C上的信令信息无法恢复，节点C不能对节点D上的PSB进行刷新；节点D上的PSB长时间得不到刷新，会超时，导致PSB、RSB的删除，从而恢复失败。
发明内容
本发明的目的是提供一种通用多协议标签交换路径上节点重启恢复的方法，以克服现有技术中在一条LSP(标签交换路径)上有多个节点发生重启时不能恢复该LSP的缺陷，保证LSP的正确恢复。
为此，本发明提供如下的技术方案：
一种通用多协议标签交换路径上节点重启恢复的方法，所述方法包括：
A、正常邻居节点收到重启节点的HELLO应答消息后，停止本节点的自刷新定时器，并启动同步恢复定时器；
B、当所述同步恢复定时器未超时时，所述正常邻居节点对其状态块进行自刷新；
C、在所述自刷新过程中，向所述重启节点发送包含恢复信息的资源预留协议RSVP消息，具体为：如果所述正常邻居节点是所述重启节点的上游节点，则向所述重启节点发送包含恢复信息的Path消息，如果所述正常邻居节点是所述重启节点的下游节点，并且收到所述重启节点发送的Path消息，则向所述重启节点发送包含恢复信息的Resv消息；
D、所述重启节点根据所述RSVP消息恢复其状态块，具体为：根据所述Path消息恢复其路径状态块，或者根据所述Resv消息恢复其预留状态块；
E、当所述正常邻居节点和所述重启节点同步恢复完成后或者所述同步恢复定时器超时后，停止所述同步恢复定时器。
所述启动同步恢复定时器包括：
A1、根据所述重启节点的HELLO消息获取所述重启节点的恢复定时器的定时时间；
A2、根据所述重启节点的恢复定时器的定时时间设定所述同步恢复定时器的定时时间；
A3、启动所述同步恢复定时器。
设定所述同步恢复定时器的定时时间与所述重启节点的恢复定时器的定时时间相同。
当所述正常邻居节点为所述重启节点的上游节点时，
所述步骤B具体包括：
当所述正常邻居节点上的预留状态块RSB刷新超时后，判断所述同步恢复定时器是否超时；
如果所述同步恢复定时器未超时，则对所述RSB进行自刷新；
否则，对所述RSB进行超时处理。
当所述正常邻居节点为所述重启节点的下游节点时，
所述步骤B具体包括：
当所述正常邻居节点上的路径状态块PSB刷新超时后，判断所述同步恢复定时器是否超时；
如果所述同步恢复定时器未超时，则对所述PSB进行自刷新；
否则，对所述PSB进行超时处理。
所述同步恢复完成为所述正常邻居节点和所述重启节点之间的所有LSP全部恢复完成。
由以上本发明提供的技术方案可以看出，本发明在一条LSP上有一个或多个节点发生重启时，好的邻居节点在收到重启节点发送过来的HELLO消息后，虽然停止了自刷新定时器(Restart_Timer)，但并未停止对状态块(PSB或RSB)进行自刷新，即通过启动一个同步恢复定时器(Restore_timer定时器)，相当于延长了其状态块的自刷新处理时间，通过设定该定时器的定时时间，等待重启节点的相邻节点重启完成，避免了因状态块刷新超时导致的恢复失败，提高了智能光网络控制平面的恢复能力。
附图说明
图1是现有技术中GMPLS路径上节点重启后的恢复过程示意图；
图2是现有技术中GMPLS路径上连续两个节点重启时恢复失败的一种示意图；
图3是现有技术中GMPLS路径上连续两个节点重启时恢复失败的另一种示意图；
图4是本发明方法的流程图；
图5是本发明方法中LSP上有单个节点重启时的处理流程图；
图6是本发明方法中连续两个节点且上游节点先重启时的处理流程图；
图7是本发明方法中连续两个节点且下游节点先重启时的处理流程图。
具体实施方式
本发明的核心在于在一条LSP(标签交换路径)上有节点发生重启时，好的邻居节点在收到重启节点发送过来的HELLO消息后，通过启动一个同步恢复定时器(Restore_timer)，并使其超时时间与重启节点上启动的恢复定时器(Recovery_Timer)的超时时间相同。这样，在Restore_timer定时器超时之前，如果依然没有从重启的邻居节点收到刷新消息对本地的状态块：PSB(路径状态块)或RSB(预留状态块)，进行刷新，则继续让状态块进行自刷新；只有在Restore_timer定时器超时之后，再按照正常的状态块(PSB或RSB)超时流程进行处理。以此保证在一条LSP上有多个节点发生重启，并且重启节点的相邻节点没有完成重启时，不会导致刷新超时从而恢复失败。
本技术领域人员知道，与MPLS(多协议标签交换)相同，GMPLS(通用多协议标签交换)网络也由两个主要元素组成：标签交换节点和标签交换路径。但GMPLS的LSR(标记交换路由器)包括所有类型的节点，这些LSR上的接口可以细分为若干等级：分组交换能力(PSC)接口、时分复用能力(TDM)接口、波长交换能力(LSC)接口和光纤交换能力(FSC)接口。而LSP则既可以是一条传递IP包的虚通路，也可以是一条TDM电路，或是一条DWDM(密集波分复用)的波道，甚至是一根光纤。GMPLS分别为电路交换和光交换设计了专用的标记格式，以满足不同业务的需求。
与MPLS不同的是，GMPLS将在信令协议中的标签数值从原来的32位扩展到了一个任意长度的阵列，并且修改了基于约束的标签分配协议CR-LDP和具有流量工程扩展的资源预留协议RSVP-TE，通过CR-LDP中的通用标签长度类型或者是RSVP-TE中的通用标签对象来传递它们自己的信息。
MPLS流量工程的信令协议用于将路由协议或者管理员指定的显式路由映射到实际的物理通路上，即通路上的每个LSR节点为该路由在各自节点处分配并绑定一个标签值，同时建立并维持相应的转发状态，从而建立起LSP。RSVP(资源预留协议)是一种可以扩展用于MPLS流量工程的信令协议。
RSVP有两个重要的消息：Path消息，从发送者到接收者；Resv消息，从接收者到始发者。
RSVP消息包含如下信息：
1)网络如何识别一个会话流(分类信息)；
2)描述会话流的定量参数(如数据率)；
3)要求网络为会话流提供的服务类型；
4)政策信息(如用户标识)。
RSVP的工作流程如下：
会话发送者首先发送Path消息，沿途的设备若支持RSVP则进行处理，否则继续发送；
设备若能满足资源要求，并且符合本地管理政策的话，则进行资源分配，Path消息继续发送，否则向发送者发送拒绝消息；
会话接收者若对发送者要求的会话流认同，则发送Resv消息，否则发送拒绝消息；
当发送者收到Resv消息时，表示可以进行会话，否则表示失败。
RSVP的Path及Resv消息必须在LSP上的LSR中周期地进行刷新。如果刷新消息未被传输，LSP状态将自动超时而最终被删除。
RSVP中的HELLO协议用于检测邻居节点的丢失或重新设置邻居的RSVP状态信息。HELLO协议扩展由HELLO消息、HELLORequest对象和HELLOAck对象组成。两个邻居间的HELLO处理指出对故障检测间隔的独立选择。每个邻居可以自动发出HELLORequest对象。每个HELLORequest对象通过HELLOAck对象来回答。
RSVP的HELLO扩展可以使RSVP节点发现邻居节点是否可达，这种机制提供了节点级的故障检测能力。邻居故障检测是通过收集和存储邻居节点的Instance(实例)值实现的，如果邻居节点的instant值发生变化或者没有按时发送HELLO信息，就可以判断该节点重启或者节点间连接发生故障。节点定期向邻居节点发送包含HELLO请求目标的HELLO消息，产生HELLO消息的时间间隔由HELLO interval(时间间隔)参数控制，默认值为5ms。
当节点收不到邻居节点的HELLO响应，使HELLO会话超时后，会启动自刷新定时器(Restart_Timer)，并通过该定时器对本节点的PSB或RSB进行自刷新；如果在该定时时间内不能收到邻居节点的刷新消息，当Restart_Timer定时器超时后，会删除本地的PSB或RSB。
在上述协议基础上，本发明为了避免现有技术中在一条LSP上有多个节点发生重启时导致的恢复失败，停止Restart_Timer定时器后，启动一个同步恢复定时器(Restore_timer)，在该定时时间内继续对本节点的PSB或RSB进行自刷新，等待重启节点的相邻节点重启完成，根据网络的实际需要，设定Restore_timer定时器的定时时间，保证该LSP能够恢复。
下面结合附图和实施方式对本发明作进一步的详细说明。
参照图4所示本发明方法的流程图，包括以下步骤：
步骤401：正常邻居节点接收重启节点的HELLO应答消息。
在重启节点重启完成后，重启节点会启动一个Recovery_timer定时器，该节点需要邻居节点在该定时器超时之前对本节点的所有LSP进行恢复。当重启节点收到正常邻居节点发送的HELLO消息后，会给该节点发送一个HELLO应答消息，在该消息中包含了Recovery_timer定时器的定时时间信息。
步骤402：停止本节点的Restart_Timer定时器，并启动Restore_timer定时器。
Restore_timer定时器的定时时间可以根据重启节点的HELLO消息所带的重启节点的Recovery_timer定时器的定时时间来确定，当然，也可以由用户根据实际需要自行设定。
比如，可以设定Restore_timer定时器的定时时间大于或等于重启节点的Recovery_timer定时器的定时时间。
步骤403：判断正常邻居节点上的状态块(PSB或RSB)刷新是否超时。
前面已经提到，RSVP通过Path及Resv消息在LSP上的节点中周期地进行刷新。如果刷新消息未被传输，也就是说收不到相应的Path及Resv消息，则LSP状态将自动超时而最终被删除，即该LSP上的所有PSB和RSB将被删除。通过下游节点发送的ResvTear(预留删除)消息删除本地的RSB，通过上游发送的PathTear(路径删除)消息删除本地的PSB和RSB。
如果正常邻居节点为重启节点的上游节点，重启节点重启完成后，该正常邻居节点向重启节点发送Path(Recovery_label)消息，然后等待重启节点回送Resv响应消息对本节点的RSB进行刷新。如果长时间接收不到重启节点的Resv响应消息，则RSB刷新会超时。
如果正常邻居节点为重启节点的下游节点，重启节点重启后，由于该节点为上游节点，重启后信令信息丢失，不能发起恢复，只有当收到其上游节点发送的Path(Recovery_label)消息后，重启节点才能恢复其PSB。同样，其下游的正常邻居节点会等待重启节点发送Path(刷新)消息，以便对本节点的PSB进行刷新，如果长时间接收不到重启节点的Path(刷新)消息，则PSB刷新会超时。
如果状态块刷新未超时，则返回步骤403等待本节点上的状态块刷新超时。
当状态块刷新超时后，进到步骤404：判断Restore_timer定时器是否超时。
如果该定时器已超时，则进到步骤405：对本节点上的状态块进行超时处理，即按照标准协议中正常的PSB或RSB超时流程进行处理。
如果该定时器未超时，则进到步骤406：对状态块进行自刷新。
然后，进到步骤407：在自刷新过程中，向重启节点发送包含恢复信息的RSVP(资源预留协议)消息，如果该正常邻居节点是重启节点的上游节点，则由该节点向重启节点发送包含恢复信息的Path消息，重启节点根据该Path消息恢复其PSB；
如果该正常邻居节点是重启节点的下游节点，则当重启节点的PSB恢复后，重启节点会向该下游的正常邻居节点发送Path(恢复)消息，该节点收到Path消息后，向上游的重启节点发送Resv(恢复)消息，重启节点根据该Resv消息恢复其RSB。在未从重启的上游邻居节点收到Path消息之前，禁止向重启的上游邻居节点发送相应的Resv消息。
即进到步骤408：重启节点根据收到的RSVP消息(Path和Resv)恢复其状态块。
重启节点的PSB或RSB恢复完成后，会向其下游或上游的正常邻居节点发送RSVP消息。这些正常邻居节点和重启节点同步恢复完成后，需要停止Restore_timer定时器，以便停止对其状态块进行自刷新。
因此，进到步骤409：在Restore_timer定时器超时前，正常邻居节点和重启节点同步恢复完成后，则停止Restore_timer定时器。所述同步恢复完成是指正常邻居节点和重启节点之间的所有LSP都恢复完成。当然，在Restore_timer定时器超时后，同样需要停止该定时器。
当重启节点的PSB和RSB恢复后，该条LSP也就重新恢复了。当正常的节点和重启节点间的所有LSP都恢复后，就停止Restore_timer定时器。
当一条LSP上只有单个节点发生重启时，其重启恢复过程如图5所示：
假设有一条LSP，路径是A->B->C。假设B节点掉电重启。
其恢复过程如下：
1)节点A重新收到节点B的Hello应答，停止Restart_Timer定时器，检测出节点B发生了重启，启动Restore_Timer定时器；同样，节点C重新收到节点B的Hello应答，也停止Restart_Timer定时器，检测出节点B发生了重启，启动Restore_Timer定时器；
2)A节点发出Path(带Recovery_label)消息对节点B进行恢复；
3)B节点在收到Path(带Recovery_label)消息后，恢复起相应的PSB，并向节点C发出Path(带Recovery_label)消息对节点C进行恢复；
4)由于节点C是正常的节点，没有发生重启，C节点将该Path消息作为刷新消息来处理。C节点向B节点发出Resv消息；
5)B节点在收到Resv消息后，恢复起相应的RSB，并向上游A节点发出Resv消息；
6)由于A节点是正常的节点，没有重启过，所以在收到Resv消息后作为刷新消息进行处理。
至此，一条LSP就恢复成功了，在所有的LSP恢复完成后，A节点和C节点上的Restore_Timer定时器应停掉。
如果一条LSP上有多个节点需要重启，按照本发明方法，可以提高节点的恢复能力。
下面将结合附图详细说明一条LSP上连续有两个节点发生重启时的节点恢复过程：
首先参照图6，图6示出了本发明方法中上游节点先重启时的处理流程：
假设有一条LSP，路径是A-＞B-＞C-＞D。假设C、D节点都掉电，然后节点C完成重启，而节点D长时间不重启。
1.好的邻居节点B重新收到重启节点C的HELLO消息后，停止Restart_timer定时器(表明邻居节点已重启完成)，并启动一个Restore_timer定时器，该定时器的超时时间与重启节点C上启动的Recovery_Timer定时器的超时时间相同，这一时间可从节点C发给节点B的HELLO消息中获得；
2.B节点发出Path(带Recovery_label)消息对节点C进行恢复，由于节点D没有重启，所以节点C不会从节点D收到相应的Resv消息，节点C也不会给节点B响应Resv消息；
3.节点B一直收不到节点C发过来的Resv消息，在RSB超时后，如果Restore_timer定时器还在工作(没有超时)，则让RSB自刷新；当Restore_timer定时器超时后，则按照标准协议中正常的RSB超时的流程进行处理，即向上游节点发出ResvTear消息发起删除，并删除本地的RSB；
4.在节点D完成重启后，节点C发出Path(带Recovery_label)消息对节点D进行恢复，节点D收到恢复的Path消息后，建立起相应的PSB和RSB，并构造相应的Resv消息发送给节点C；
5.节点C收到节点D的Resv响应消息后，同样建立起相应的RSB，并构造相应的Resv消息发给上游的节点B；
6.节点B从节点C收到了相应的Resv响应消息，因为节点B是正常的，所以进行刷新处理。至此该条LSP也就成功恢复起来了。
可见，通过上述方式，就可以避免因节点D长时间不重启，导致节点B上的RSB超时，致使发起删除LSP的问题。
参照图7，图7示出了本发明方法中下游节点先重启时的处理流程：
假设有一条LSP，路径是A-＞B-＞C-＞D。假设B、C节点都掉电，然后节点C完成重启，而节点B长时间不重启。
1.好的邻居节点D重新收到重启节点C的HELLO消息后，停止Restart_timer定时器(表明邻居节点已重启完成)，并启动一个Restore_timer定时器；该定时器的超时时间与相邻的重启节点C的Recovery_Timer定时器的超时时间相同，这一时间可从重启节点发给该节点的HELLO消息中得到；
2.由于C节点是D节点的上游节点，C节点重启后，信令信息就没有了，所以节点C不能发起恢复；
3.节点C不会对节点D上的PSB进行刷新，节点D上的PSB超时后，如果Restore_timer定时器还在工作(没有超时)，则让PSB自刷新；当Restore_timer定时器超时后，则按照标准协议中正常的PSB超时的流程进行处理，即向下游发出PathTear消息发起删除，并删除本地的PSB、RSB。如果PSB处于自刷新状态，还没有收到C节点发过来的Path消息，则当D节点上相应的RSB刷新超时时不向C节点发出Resv消息；
4.节点B完成重启后，节点A检测出节点B重启了，同样会停止Restart_timer定时器(表明邻居节点已重启完成)，并启动一个Restore_timer定时器，该定时器的超时时间与相邻的重启节点B的Recovery_Timer定时器的超时时间相同，这一时间可从重启节点B发给该节点的HELLO消息中得到；向节点B发出Path(带Recovery_label)消息，对节点B进行恢复；
5.节点B收到Path(带Recovery_label)消息后，做恢复的处理，然后向节点C发出Path(带Recovery_label)消息；
6.同样，节点C在收到Path(带Recovery_label)消息后，做恢复的处理，然后向节点D发出Path(带Recovery_label)消息；
7.节点D在收到Path(带Recovery_label)消息后，因为节点D没有重启，它保存的信息是完整的，节点D就将该Path消息当作刷新消息进行处理，节点D向节点C响应Resv消息；
8.节点C在收到Resv消息后，进行相应的恢复，然后向节点B发送Resv消息；
9.同样，节点C也做相应的处理；
10.节点A在收到节点B的Resv消息后，因为节点A没有重启过，所以将该Resv消息当作刷新消息进行处理。
至此，该条LSP就恢复起来了。
当一条LSP上有多个节点发生重启时，与上述处理过程类似，在此不再赘述。
根据***实际需要，合理设定各正常邻居节点的Restore_timer定时器的定时时间，比如，设定上游邻居节点的Restore_timer定时器的定时时间大于或等于下游邻居节点的Restore_timer定时器的定时时间，当然，Restore_timer定时器定时时间的设定与很多因素有关，比如，节点的启动速度、节点故障的修复时间等。只要合理设定各正常邻居节点的Restore_timer定时器的定时时间，即可提高节点的恢复能力，更好地满足智能光网络的需求。
虽然通过实施例描绘了本发明，本领域普通技术人员知道，本发明有许多变形和变化而不脱离本发明的精神，希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。

Claims (6)

1.一种通用多协议标签交换路径上节点重启恢复的方法，其特征在于，所述方法包括：
A、正常邻居节点收到重启节点的HELLO应答消息后，停止本节点的自刷新定时器，并启动同步恢复定时器；
B、当所述同步恢复定时器未超时时，所述正常邻居节点对其状态块进行自刷新；
C、在所述自刷新过程中，向所述重启节点发送包含恢复信息的资源预留协议RSVP消息，具体为：如果所述正常邻居节点是所述重启节点的上游节点，则向所述重启节点发送包含恢复信息的Path消息，如果所述正常邻居节点是所述重启节点的下游节点，并且收到所述重启节点发送的Path消息，则向所述重启节点发送包含恢复信息的Resv消息；
D、所述重启节点根据所述RSVP消息恢复其状态块，具体为：根据所述Path消息恢复其路径状态块，或者根据所述Resv消息恢复其预留状态块；
E、当所述正常邻居节点和所述重启节点同步恢复完成后或者所述同步恢复定时器超时后，停止所述同步恢复定时器。
2.根据权利要求1所述的方法，其特征在于，所述启动同步恢复定时器包括：
A1、根据所述重启节点的HELLO消息获取所述重启节点的恢复定时器的定时时间；
A2、根据所述重启节点的恢复定时器的定时时间设定所述同步恢复定时器的定时时间；
A3、启动所述同步恢复定时器。
3.根据权利要求2所述的方法，其特征在于，所述步骤A2具体为：设定所述同步恢复定时器的定时时间与所述重启节点的恢复定时器的定时时间相同。
4.根据权利要求1所述的方法，其特征在于，所述正常邻居节点为所述重启节点的上游节点，所述步骤B具体包括：
当所述正常邻居节点上的预留状态块RSB刷新超时后，判断所述同步恢复定时器是否超时；
如果所述同步恢复定时器未超时，则对所述RSB进行自刷新；
否则，对所述RSB进行超时处理。
5.根据权利要求1所述的方法，其特征在于，所述正常邻居节点为所述重启节点的下游节点，所述步骤B具体包括：
当所述正常邻居节点上的路径状态块PSB刷新超时后，判断所述同步恢复定时器是否超时；
如果所述同步恢复定时器未超时，则对所述PSB进行自刷新；
否则，对所述PSB进行超时处理。
6.根据权利要求1所述的方法，其特征在于，所述同步恢复完成为所述正常邻居节点和所述重启节点之间的所有LSP全部恢复完成。
CN2004101031357A 2004-12-31 2004-12-31 通用多协议标签交换路径上节点重启恢复的方法 Expired - Fee Related CN1801802B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN2004101031357A CN1801802B (zh) 2004-12-31 2004-12-31 通用多协议标签交换路径上节点重启恢复的方法
PCT/CN2005/002269 WO2006069523A1 (fr) 2004-12-31 2005-12-21 Procede de recuperation de redemarrage de noeud dans un trajet de commutation multiprotocole par etiquette
EP05819664A EP1753182A4 (en) 2004-12-31 2005-12-21 METHOD FOR RECOVERING NODE RESTART IN A MULTIPROTOCOL LABEL SWITCHING PATH

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2004101031357A CN1801802B (zh) 2004-12-31 2004-12-31 通用多协议标签交换路径上节点重启恢复的方法

Publications (2)

Publication Number Publication Date
CN1801802A CN1801802A (zh) 2006-07-12
CN1801802B true CN1801802B (zh) 2010-06-02

Family

ID=36614490

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2004101031357A Expired - Fee Related CN1801802B (zh) 2004-12-31 2004-12-31 通用多协议标签交换路径上节点重启恢复的方法

Country Status (3)

Country Link
EP (1) EP1753182A4 (zh)
CN (1) CN1801802B (zh)
WO (1) WO2006069523A1 (zh)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047700B (zh) 2006-05-01 2010-05-12 华为技术有限公司 一种提高lmp控制通道可靠性的方法与装置
CN101087207B (zh) 2006-06-09 2010-05-12 华为技术有限公司 一种多节点通信故障的处理方法
CN101123563B (zh) * 2006-08-07 2010-09-08 中兴通讯股份有限公司 一种用于多跳伪线下平稳重启的方法、装置及网络
CN100438447C (zh) * 2006-09-08 2008-11-26 华为技术有限公司 一种光网络lsp发生异常删除的恢复方法和装置
CN101174974B (zh) * 2006-11-01 2010-05-12 中兴通讯股份有限公司 用于o-uni***的节点维护的消息处理方法
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 中兴通讯股份有限公司 一种自动交换光网络中功能冻结/解冻方法
CN101296239B (zh) * 2008-06-18 2011-10-26 杭州华三通信技术有限公司 刷新标签交换路径的方法及标签交换路由器
CN101616069B (zh) * 2008-06-23 2012-04-04 华为技术有限公司 基于优雅重启的信息恢复方法和路由器
CN101964925B (zh) * 2009-07-21 2014-04-30 中兴通讯股份有限公司 自动交换光网络中控制平面节点重启后的恢复方法及***
CN102480653A (zh) * 2010-11-30 2012-05-30 中兴通讯股份有限公司 一种自动交换光网络节点重启后业务激活的方法及***
US9001672B2 (en) * 2012-07-27 2015-04-07 Alcatel Lucent System, method and apparatus conforming path cost criteria across multiple ABRs
US9535794B2 (en) 2013-07-26 2017-01-03 Globalfoundries Inc. Monitoring hierarchical container-based software systems
CN104980295A (zh) * 2014-04-09 2015-10-14 中兴通讯股份有限公司 防止网络节点老化的方法、装置及***
CN105530117A (zh) * 2014-10-24 2016-04-27 中兴通讯股份有限公司 控制通道协议状态的更新方法、装置及***
CN105763436B (zh) * 2014-12-16 2019-08-30 南京中兴软件有限责任公司 删除链路状态通告的方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003318983A (ja) * 2002-04-26 2003-11-07 Hitachi Ltd 光クロスコネクト網の障害回復方法
CN1556637A (zh) * 2003-12-30 2004-12-22 ���ͨ�ſƼ��ɷ����޹�˾ 一种在格状网中利用共享备用通道进行故障恢复的方法
CN1558621A (zh) * 2003-10-30 2004-12-29 ����� Լ������� 通用多协议标签交换网络中恢复路由的方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7317731B2 (en) * 2002-05-13 2008-01-08 Tropic Networks Inc. System and method for distributed resource reservation protocol-traffic engineering (RSVP-TE) hitless restart in multi-protocol label switching (MPLS) network
US7272310B2 (en) * 2003-06-24 2007-09-18 Intel Corporation Generic multi-protocol label switching (GMPLS)-based label space architecture for optical switched networks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003318983A (ja) * 2002-04-26 2003-11-07 Hitachi Ltd 光クロスコネクト網の障害回復方法
CN1558621A (zh) * 2003-10-30 2004-12-29 ����� Լ������� 通用多协议标签交换网络中恢复路由的方法
CN1556637A (zh) * 2003-12-30 2004-12-22 ���ͨ�ſƼ��ɷ����޹�˾ 一种在格状网中利用共享备用通道进行故障恢复的方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
L. Berger, et al.RFC3474: Generalized Multi-Protocol Label Switching(GMPLS) Signaling.IETF STANDARD, INTERNET ENGINEERING TASK FORCE.2003,1-42. *
L.Berger et al.RFC3474: Generalized Multi-Protocol Label Switching(GMPLS) Signaling.IETF STANDARD

Also Published As

Publication number Publication date
EP1753182A1 (en) 2007-02-14
WO2006069523A1 (fr) 2006-07-06
EP1753182A4 (en) 2007-08-22
CN1801802A (zh) 2006-07-12

Similar Documents

Publication Publication Date Title
CN1801802B (zh) 通用多协议标签交换路径上节点重启恢复的方法
CN101087207B (zh) 一种多节点通信故障的处理方法
CN1866806B (zh) 共享格状网恢复的实现方法
US7974183B2 (en) Method for restoration and normalization in a mesh network
Li et al. Control plane design for reliable optical networks
CN100521593C (zh) 在基于波分复用的光交换网络内恢复资源的方法和***
CN100563354C (zh) 一种自动交换光网络中实现业务保护的方法
Ye et al. A simple dynamic integrated provisioning/protection scheme in IP over WDM networks
KR100228943B1 (ko) 네트워크에서 접속 확립 방법 및 장치와 각 노드의 스위치 표 갱신방법
US7468944B2 (en) Path fault recovery method, switching-back method after recovery from fault, and node using the same
EP1953958B1 (en) Management of protection path bandwidth and changing of path bandwidth
WO2006039865A1 (fr) Procede permettant de mettre en oeuvre une decouverte automatique de structure de topologie dans le reseau boucle mpls
JP2002247038A (ja) ネットワークにおけるリング形成方法及び障害回復方法並びにリング形成時のノードアドレス付与方法
CN102098596B (zh) 光网络中路由建立方法及装置
CN101163030A (zh) 一种建立区分器映射表的方法
CN101222486B (zh) 自动交换光网络中节点故障后路由重启恢复的控制方法
Xin et al. On an IP-centric optical control plane
CN100372305C (zh) 自动交换光网络业务的保护方法
CN101505277B (zh) 一种退出优雅重启的方法、设备及***
CN101420378B (zh) 资源预留协议流量工程下优雅重启的实现装置及方法
CN100550840C (zh) 路由受限标记交换路由器的平稳重启方法
CN101360348B (zh) 一种业务首尾节点之间的虚拟控制通道建立方法
CN101771488B (zh) 提高多业务传送网可靠性的方法、***及设备
CN1710993B (zh) 智能光网络中的业务路径优化方法
Dong et al. Differentiated-resilience provisioning for the wavelength-routed optical network

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
TR01 Transfer of patent right

Effective date of registration: 20170920

Address after: 065200, No. 1, row 5, 2 street, East Hospital, Sanhe South District, Hebei, Langfang

Patentee after: Chen Liping

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: Huawei Technologies Co., Ltd.

TR01 Transfer of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20100602

Termination date: 20171231

CF01 Termination of patent right due to non-payment of annual fee