减少软状态刷新的资源预留协议实现方法 【技术领域】
本发明涉及支持IP业务服务质量的资源预留协议技术，特别涉及一种减少软状态刷新的资源预留协议实现方法。
背景技术
资源预留协议(以下简称RSVP)最初设计为支持IP业务服务质量(QoS)的集成服务模型的资源预留协议。RSVP通过扩展可以支持多协议标签交换(简称MPLS)，通过协议操作建立标签交换路径(简称LSP)。RSVP扩展的基本工作原理是发送方向接收方发送路径(简称PATH)消息，其中包含资源请求和标签分配请求等。接收方接收到PATH消息后，向上游发送预留消息(RESV)，用于资源的预留以及标签的分配。当RESV消息到达发送方后，则LSP建立成功。
现有技术一的技术方案：
RSVP需要为RESV状态(由RSB保存)维护一个刷新定时器和一个超时定时器。每次刷新定时器超时后，它会向前一跳发送RESV刷新消息，前一跳节点接收到RESV消息后，重启清除定时器。如果清除定时器超时后，前一跳节点仍然没有接收到RESV刷新消息，那么就会向它的上游节点发送预留拆除(简称RESVTEAR)消息，删除沿路的RESV状态。如图1所示，当节点R3的预留状态块(简称RSB)超时后，它向节点R2发送RESVTEAR消息，直到入口节点R1。
RSVP在维护RESV状态时，如果出现失败的情况，向上游发送的RESVTEAR消息只会删除沿路地RESV状态，但是不会删除PATH状态。如果RESV状态始终无法恢复，那么保留的PATH状态也会持续进行刷新。虽然保留PATH状态在一定条件下通过刷新可以重新建立限制路由标签交换路径(CRLSP)，但在实际中，保留PATH状态的意义并不大，相反可能会为维护PATH状态造成资源的浪费。
现有技术二的技术方案：
RSVP使用软状态刷新的方法来进行状态的维护。在每一跳，RSVP为PATH状态(由PSB保存)维护一个刷新定时器和一个超时定时器，每次刷新定时器超时后，它会向下一跳发送PATH刷新消息，下一跳节点接收到PATH消息后，重启清除定时器。如果清除定时器超时后，下一跳节点仍然没有接收到PATH刷新消息，那么就会向它的下游节点发送路径拆除消息(以下简称PATHTEAR消息)，删除沿路的PATH状态。如图2所示，节点R3的路径状态块(简称PSB)超时后，会向节点R4发送RESVTEAR消息。
RSVP采用软状态刷新方式进行PATH状态维护，在出现失败的情况时，失败节点只会向下游发送PATHTEAR消息。但失败节点的上游节点的状态会保留，因为失败节点的RSB已经删除，所以可能会导致上游节点的RSB超时。此时处理与RSB超时处理一致。
现有技术三的技术方案：
RSVP在LSP建立过程中可能会遇到路径错误，此时发生错误的节点会向上游节点发送路径错误消息(PATHERR)。在入口节点，RSVP会通知上层应用PATHERR的信息。如图3所示，节点R3出现路径错误后，会向上游节点R2发送PATHERR消息，直到入口节点R1。在节点R1，RSVP通知上层应用PATHERR消息。
现有技术三的缺点
RSVP使用PATHERR通知路径错误，但是没有明确指出入口节点如何处理PATHERR。这样做的结果可能是路径中的状态得到保留，这些保留的状态刷新时会造成资源浪费。另一方面，入口节点通知上层节点，这要求上层应用必须理解PATHERR的意义，这样的协议相关性必然会造成模块的耦合度高，不利于开发。
现有技术四的技术方案
RSVP在LSP建立过程中可能会遇到预留错误，此时发生错误的节点会向下游节点发送预留错误消息(RESVERR)。在出口节点，RSVP会通知上层应用RESVERR的信息。如图4所示，节点R2出现预留错误后，会向下游节点R3发送RESVERR消息，直到出口节点R4。在节点R4，RSVP通知上层应用RESVERR消息。
RSVP使用RESVERR通知预留错误，它的缺陷与PATHERR的处理类似。首先RSVP没有明确指出出口节点如何处理RESVERR。这样做的结果可能是路径中的状态得到保留，这些保留的状态刷新时会造成资源浪费。另一方面，出口节点通知上层节点，这要求上层应用必须理解RESVERR的意义，这样的协议相关性必然会造成模块的耦合度高，不利于开发。
【发明内容】
本发明的目的在于提供一种减少软状态刷新的资源预留协议实现方法，以提高网络资源的利用率。
本发明的方法包括步骤：
采用资源预留协议在承载网内的节点间建立标签交换路径或维护已建立的标签交换路径发生错误时，发生错误的节点向上游或下游节点发起相应的错误消息；以及
根据该错误消息的类型，节点间通过路径拆除消息完全拆除所述标签交换路径和/或通过预留拆除消息拆除标签交换路径沿路的预留状态。
根据上述方法：
当发生的错误为路径错误(PATHERR)时包括步骤：
A1、发生错误的节点向上游节点发送路径错误消息并到达入口接点；
A2、资源预留协议判定该错误是否应导致标签交换路径删除；
A3、如果判断结果为“是”，则从该入口节点向下游节点发起路径拆除消息，以完全拆除标签交换路径否则，对该错误消息不处理或通知上层应用进行处理。
当发生的错误为预留错误时包括步骤：
B1、发生错误的节点向下游节点发送预留错误消息并到出口接点；
B2、资源预留协议判断该错误是否应导致标签交换路径删除；如果判断结果为“是”，则进行步骤B3，否则不处理该错误；
B3、从该出口节点向上游节点发起预留拆除消息并到达入口节点，并且上游节点接收到该消息时删除本节点的预留块；
B4、入口节点向下游节点发起路径拆除消息，以完全拆除标签交换路径。
当发生的错误为节点的预留状态块超时时包括步骤：
C1、发生错误的节点删除预留状态块后向上游节点发起预留拆除消息并到达入口节点，并且上游节点接收到该消息时删除本节点的预留块；
C2、入口节点向下游节点发起路径拆除消息以完全拆除标签交换路径。
当发生的错误为节点的路径状态块超时时包括步骤：
D1发生错误的节点直接向下游节点发起路径拆除消息，以删除下游节点的路径状态块和预留状态块；
D2、发生错误的节点向上游节点发起预留拆除消息并到达入口节点，并且上游节点接收到该消息时删除预留块；
D3、入口节点向下游节点发起路径拆除消息，以完全拆除标签交换路径。
本发明具有以下有益效果：
1、预留拆除消息(RESVTEAR)到达入口节点后发起路径拆除消息(PATHTEAR)，可以完全删除出现错误的LSP，减少资源预留协议(RSVP)的软状态刷新。
2、路径状态块(PSB)超时处理流程利用改进的预留拆除消息(RESVTEAR)处理流程，也可以完全删除出现错误的LSP，减少资源预留协议(RSVP)的软状态刷新。
3、明确定义了路径错误消息(PATHERR)的处理流程，由资源预留协议(RSVP)自主决定对路径错误的处理，减少协议相关性，同时可以根据路径错误消息删除标签交换路径(LSP)，减少资源预留协议的软状态刷新。
4、明确定义了预留错误消息(RESVERR)的处理流程，由资源预留协议自主决定对预留错误的处理，减少协议相关性，同时可以根据预留错误消息删除标签交换路径(LSP)，减少资源预留协议的软状态刷新。
【附图说明】
图1为预留状态块(RSB)超时的处理示意图；
图2为路径状态块(PSB)超时的处理示意图；
图3为路径错误(PATHERR)的处理示意图；
图4为预留错误(RESVERR)的处理示意图；
图5为预留状态块(RSB)超时发起的标签交换路径删除流程图；
图6为路径状态块(PSB)超时发起的标签交换路径删除流程图；
图7为路径错误(PATHERR)发起的标签交换路径删除流程图；
图8为预留错误(RESVERR)发起的标签交换路径删除流程图。
【具体实施方式】
本发明的方法主要是在标签交换路径(简称LSP)建立过程出现错误时，完全删除该LSP，达到减少软状态刷新的目的。
参阅图5，预留状态块(简称RSB)超时发起LSP删除：
RSB超时操作的主要修改是入口节点接收到预留拆除消息(简称RESVTEAR消息)的处理。为了完全删除LSP，入口节点接收到RESVTEAR消息后，不仅删除RSB，还会删除路径状态块(以下简称PSB)，并向下游发送路径拆除消息(简称PATHTEAR消息)。该PATHTEAR消息会删除沿路的PSB和RSB。
假设节点R3的RSB因为某种原因超时，此时的删除过程如下：
(1)节点R3删除RSB，并向节点R2发送RESVTEAR消息；
(2)节点R2删除RSB，并向节点R1发送RESVTEAR消息；
(3)节点R1删除RSB，同时删除PSB，然后向节点R2发送PATHTEAR消息；
(4)节点R2删除PSB，然后向节点R3发送PATHTEAR消息；
(5)节点R3删除PSB，然后向节点R4发送PATHTEAR消息。
在RSB超时，节点R3向上游发送RESVTEAR的过程中，可能会出现节点R4发送的RESV消息到达节点R3，这样节点R3会重新建立RSB。这种异常不会影响协议正常工作，因为从入口节点R1发起的PATHTEAR消息会删除沿路所有节点的PSB和RSB。
参阅图6，路径状态块(PSB)超时发起标签交换路径(LSP)删除：
假设节点R1至节点R4的LSP已经建立。如果节点R3的PSB因为某种原因超时，此时的删除过程如下：
(1)节点R3删除PSB与RSB，并向节点R4发送PATHTEAR消息。节点R4接收到PATHTEAR消息，会删除PSB和RSB；
(2)节点R3向上游节点R2节点发送RESVTEAR消息；
(3)节点R2删除RSB，并向节点R1发送RESVTEAR消息；
(4)节点R1删除PSB和RSB，向节点R2发送PATHTEAR消息；
(5)节点R2删除PSB，并向节点R3发送PATHTEAR消息。节点R3即使接收到该消息，因为PSB和RSB已经删除，所以也不会做进一步的处理。
在PSB超时后，节点R3会删除PSB和RSB。对于节点R3上游的节点R2节点，即使节点R3不向节点R2发送RESVTEAR消息，节点R2也会因为接收不到来自节点R3的RESV刷新消息最终会引起RSB超时。节点R3主动向上游发送RESVTEAR消息只是为了能尽快删除LSP。
需要注意的是节点R3向上游发送RESVTEAR时，由于节点R2收到RESVTEAR后只删除RSB，所以保留的PSB会向下游节点R3发起PATH刷新消息，导致下游节点重新建立PSB，甚至节点R4会重新发起预留。这种异常不会影响协议正常工作，因为从入口节点节点R1发起的PATHTEAR消息会删除沿路所有节点的PSB和RSB。
从经过改进的PSB和RSB的超时处理流程来看，由于入口节点接收到RESVTEAR消息后会主动发起PATHTEAR消息删除LSP，这样保证出现错误状态的LSP可以被完全删除，从而达到了减少软状态刷新消息数量的目的。
参阅图7，路径错误(PATHERR)消息的处理过程：
为了减少前述的协议相关性的问题，当PATHERR消息到达入口节点后，RSVP应当独立决定如何处理PATHERR消息，而不是通知上层应用来决定。因为路径错误的情况是多种多样的，所以在入口节点在接收到PATHERR消息后，需要区分这些错误情况。目前协议中规定的路径错误有如下几种情况：
(1)错误应导致LSP的删除：如对象错误等；
(2)错误不应导致LSP的删除：如RRO过大等；
(3)在支持备份和快速重路由时，通知的路径错误会触发建立备份路径或者是将流量切换到备份路径上。
对于这几种情况，入口节点的处理分别如下：
对于情况(1)，RSVP删除PSB和/或RSB，向下游节点发送PATHTEAR消息，删除LSP；
对于情况(2)，RSVP不处理该错误；
对于情况(3)，RSVP通知上层应用实现路径备份及流量切换。
如图7，假设LSP已经建立，在刷新过程中，节点R3检测到路径错误，处理流程如下：
(1)节点R3向节点R2发送PATHERR消息；
(2)节点R2向节点R1发送PATHERR消息；
(3)假设RSVP判定该错误应导致LSP删除，那么节点R1会删除PSB和RSB，向节点R2发送PATHTEAR消息；
(4)节点R2删除PSB和RSB，并向节点R3发送PATHTEAR消息；
(5)节点R3删除PSB和RSB，并向节点R4发送PATHTEAR消息。节点R4接收到该消息后，也会删除PSB和RSB。
参阅图8，预留错误消息(RESVERR)的处理：
为了减少前述的协议相关性的问题，当RESVERR消息到达出口节点后，RSVP应当独立决定如何处理RESVERR消息，而不是通知上层应用来决定。目前协议中规定的预留错误有如下几种情况：
(1)错误应导致LSP的删除：如对象错误等；
(2)错误不应导致LSP的删除：如RRO过大等；
上述两种情况，出口节点的处理分别如下：
对于情况(1)，RSVP删除RSB，向上游节点发送RESVTEAR消息，删除LSP。
对于情况(2)，RSVP不处理该错误。
如图8所示，假设LSP已经建立，在刷新过程中，节点R2检测到预留错误，处理流程如下：
(1)节点R2向节点R3发送RESVERR消息；
(2)节点R3向节点R4发送RESVERR消息；
(3)假设RSVP判定该预留错误应导致LSP删除，节点R4会删除RSB，并向节点R3发送RESVTEAR消息；
(4)节点R3删除RSB，并向节点R2发送RESVTEAR消息；
(5)节点R2删除RSB，并向节点R1发送RESVTEAR消息。
当RESVTEAR消息到达入口节点后，入口节点会发起PATHTEAR消息删除沿路的PATH状态信息。
从路径错误消息(PATHERR)和预留错误消息(RESVERR)的处理流程来看，由于资源预留协议(RSVP)独立判断如何处理错误消息，减少了通知上层应用处理的协议相关性。另一方面，RSVP根据错误消息可以删除出现错误的LSP，从而减少了软状态刷新消息的数量。