CN1859277A - 基于资源预留协议的路径消息的确认方法 - Google Patents

Abstract

本发明涉及一种基于资源预留协议的路径消息的确认方法。该方法包括：发送方向接收方发送基于资源预留协议RSVP的路径Path消息，然后，当发送方收到接收方返回所述Path消息对应的资源预留Resv消息时，确认接收方已经收到所述的Path消息。本发明由于采用了将收到的Resv消息作为Path消息的确认消息，在ACK消息延迟或丢失的情况下，有效缩短了确认Path消息所需要的时间，提高了网络通信系统的性能；同时，本发明还可以减少网络中传送的消息的数量，有效节约了网络资源和系统资源。

Description

基于资源预留协议的路径消息的确认方法

技术领域

本发明涉及网络通信技术领域，尤其涉及一种基于资源预留协议的路径消息的确认方法。

背景技术

RSVP(资源预留协议)是MPLS(多协议标签交换)控制协议的一种，RSVP包括一组消息、对象及相关处理的集合，而且所述的RSVP与其它协议协同工作实现相应的功能。RSVP主要消息有：路径消息Path，预留消息Resv，路径出错消息PathErr，预留出错消息ResvErr，路径清除PathTear，预留清除消息ResvTear，预留确认消息ResvConf，一般确认消息ACK，邻居回话消息Hello，概要刷新消息SRefresh，通知消息Notify。

所述的ACK消息是RSVP中用于应答需要确认的消息，所述的ACK消息是通过携带在消息中的MESSAGE_ID(消息标识)对象来指定被确认的消息，ACK消息接收方通过收到的MESSAGE_ID对象匹配发送的消息，实现消息接收的确认。如果消息发送方发送的消息没有被确认，则在预定的时间内，消息发送方将重新发送携带有相同MESSAGE_ID对象的相同消息，即进行消息的重传，直至被消息接收方确认应答或重传超时。

所述的MESSAGE_ID对象包含在每个需要确认的RSVP消息，对每个节点的需要确认的初始RSVP消息，都分配一个唯一的MESSAGE_ID，用于在本节点唯一标识相应的消息。

所述的RSVP协议通过Path消息和Resv消息建立LSP(标签交换路径)和预留状态，即软状态，并通过定时发送的刷新消息对下游和上游的软状态进行维护和保持。

初始的软状态刷新是由路径请求方向即LSP上游Path消息对预留发起方向即LSP下游匹配的路径状态信息进行刷新，由LSP下游Resv消息对匹配的上游预留状态信息进行刷新；但是由于需要刷新的LSP很多，而且刷新仅仅是为了保证软状态不被超时删除，因此，如果采用Path/Resv消息频繁进行刷新，占用大量的带宽和部分处理能力，则显得有些浪费。

为此，提出了隐式ACK策略。隐式ACK即对于某些需要回ACK的RSVP消息，如果在收到ACK之前收到了另一种可以表明接收方已经收到了发送的该消息的回应消息，则确认所述消息已经被接收。

在Rfc2961的4.5节“MESSAGE_ID对象的使用”中建议：PathErr和ResvErr应该被作为隐式ACK处理，即PathErr可以作为触发者Path的隐式ACK，ResvErr可以作为触发者Resv的隐式ACK。以PathErr为例，如图1所示：节点Node B向节点Node C发送Path消息，并持续重发，直到收到NodeC返回的PathErr消息时确认接收方已经收到所述的Path消息。

在上述隐式ACK处理策略之外还存在一种情况：当消息接收方以Resv消息迅速回应消息发送方发送的Path消息时，消息发送方由于各种原因尚未收到相应的ACK消息，此时，尽管收到的Resv消息已经能够表明Path被下游收到并处理，但是根据现有的隐式ACK处理策略可知，该Resv消息不会作为Path消息的隐式ACK消息，因此，上游也会继续重传Path消息，直到收到Path消息的ACK消息为止。

如图2所示，节点Node A向节点Node B发送的Path(MESSAGE_ID＝21)、Path(MESSAGE_ID＝22)和Path(MESSAGE_ID＝23)消息，均需要等到收到接收方Node B返回对应的ACK消息，才结束Path消息的重传。由于在消息发送过程中，没有考虑收到的Resv消息，因此，使得整个Path消息的确认所需时间加长，还使得节点间传送的消息数量增多。

发明内容

鉴于上述现有技术所存在的问题，本发明的目的是提供一种基于资源预留协议的路径消息的确认方法，从而缩短确认该消息所需要的时间，并可以减少网络中传送的消息的数量。

本发明的目的是通过以下技术方案实现的：

本发明涉及一种基于资源预留协议的路径消息的确认方法，包括：

A、发送方向接收方发送基于资源预留协议RSVP的路径Path消息；

B、当发送方收到接收方返回所述Path消息对应的资源预留Resv消息时，确认接收方已经收到所述的Path消息。

所述的步骤A包括：

发送方向接收方发送用于创建或刷新路径状态的Path消息。

所述的步骤A还包括：

启动Path消息重传定时器，当定时器超时时重新传送所述的Path消息。

所述的步骤B还包括：

当发送方收到接收方返回所述Path消息对应的确认ACK消息或路径出错PathErr消息时，确认接收方已经收到所述的Path消息。

所述的步骤B包括：

当收到接收方返回的ACK消息时，根据ACK消息中承载消息标识确定其是否为所述Path消息对应的ACK消息，如果是，则结束Path消息的重传处理过程。

所述的步骤B包括：

当收到接收方返回的Resv消息时，根据Resv消息中承载的过滤说明确定其是否为所述Path消息对应的Resv消息，如果是，则结束Path消息的重传处理过程。

所述的步骤B包括：

当收到接收方返回的PathErr消息时，根据PathErr消息中承载的过滤说明确定其是否为所述Path消息对应的PathErr消息，如果是，则结束Path消息的重传处理过程。

由上述本发明提供的技术方案可以看出，本发明由于采用了将收到的Resv消息作为Path消息的确认消息，在ACK消息延迟或丢失的情况下，有效缩短了确认Path消息所需要的时间，提高了网络通信系统的性能；同时，本发明还可以减少网络中传送的消息的数量，进一步提高了网络的传输性能和处理性能。总之，本发明的实现可以有效减少系统中RSVP消息的发送数量，以节约宝贵的网络资源和系统资源。

附图说明

图1为隐式ACK处理策略的处理流程图；

图2为现有技术的RSVP消息的确认处理流程图；

图3为本发明所述的方法的流程图；

图4为与图2对应的本发明中RSVP消息的确认处理流程图。

具体实施方式

根据RSVP可知，完成LSP的创建需要在LSP两端节点间传送Path/Resv消息。下游节点(即Path消息接收方)只有收到Path消息，才可能向上游节点(即Path消息发送方)发Resv消息。同时，上游节点收到下游节点的Resv消息时，才能够唯一的匹配一个发送过的Path消息建立的软状态。因此，如果下游节点在给上游节点返回Path消息的ACK之前，如果发回了相应的Resv消息，则根据该Resv消息可以证明下游节点已经收到相关的Path消息。

也就是说，上游节点发送Path消息后，下游节点如果迅速回应Resv消息，则该Resv消息不必携带所述Path消息的ACK(普通RSVP消息允许携带ACK消息)，也不必有迟发的Path消息对应的ACK消息；只要根据收到的Resv消息可以找到匹配的Path消息备份，并据此结束Path消息的重传过程。

本发明正是基于上述Path消息与Resv消息间的关联关系进行Path消息的确认，从而快速实现Path消息的确认。

本发明所述的方法的具体实现方式如图3所示，具体包括以下步骤：

步骤31：当需要创建或刷新路径状态时，发送方向接收方发送基于资源预留协议RSVP的路径Path消息；

步骤32：启动Path消息重传定时器，当定时器超时时，重新传送所述的Path消息，以确保接收方收到所述的Path消息；

步骤33：当发送方收到接收方返回所述Path消息对应的Resv消息、ACK消息或PathErr消息时，确认接收方已经收到所述的Path消息；

具体为：当收到接收方返回的所述Path消息对应的Resv消息、ACK消息或PathErr消息时，根据返回的消息中承载的FILTERSPEC(过滤说明)确定其是否为所述Path消息对应的Resv消息、ACK消息或PathErr消息，如果是，则确认接收方已经收到所述的Path消息；

步骤34：结束Path消息的重传处理过程；

也就是说，当接收方返回的Resv消息、ACK消息或PathErr中任一种消息与发送的Path消息对应，则可以确认Path消息已经被对方准确接收。

可以看出，本发明增加了当收到所述的Resv消息时的确认处理过程，从而将所述的Resv消息作为Path消息的隐式ACK的确认消息，而无需仅等待ACK消息的到来，从而有效节约了网络资源和系统资源。

下面再以具体的应用实例对本发明所述的方法进行说明。

如图4所示，仍以图2所示的各情况为例，如果采用本发明，则节点NodeA向节点Node B发送的Path(MESSAGE_ID＝21)、Path(MESSAGE_ID＝22)和Path(MESSAGE_ID＝23)消息，则只要收到接收方Node B返回对应的Resv消息、ACK消息或PathErr消息，便确认接收方已经接收到所述的Path消息，并结束所述Path消息的重传过程。由于在消息发送过程中，考虑到了收到的Resv消息的情况，因此，使得整个Path消息的确认所需时间缩短，并可以减少节点间传送的消息数量。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (7)

1、一种基于资源预留协议的路径消息的确认方法，其特征在于，包括：

A、发送方向接收方发送基于资源预留协议RSVP的路径Path消息；

B、当发送方收到接收方返回所述Path消息对应的资源预留Resv消息时，确认接收方已经收到所述的Path消息。

2、根据权利要求1所述的基于资源预留协议的路径消息的确认方法，其特征在于，所述的步骤A包括：

发送方向接收方发送用于创建或刷新路径状态的Path消息。

3、根据权利要求1或2所述的基于资源预留协议的路径消息的确认方法，其特征在于，所述的步骤A还包括：

启动Path消息重传定时器，当定时器超时时重新传送所述的Path消息。

4、根据权利要求1或2所述的基于资源预留协议的路径消息的确认方法，其特征在于，所述的步骤B还包括：

当发送方收到接收方返回所述Path消息对应的确认ACK消息或路径出错PathErr消息时，确认接收方已经收到所述的Path消息。

5、根据权利要求4所述的基于资源预留协议的路径消息的确认方法，其特征在于，所述的步骤B包括：

当收到接收方返回的ACK消息时，根据ACK消息中承载消息标识确定其是否为所述Path消息对应的ACK消息，如果是，则结束Path消息的重传处理过程。

6、根据权利要求4所述的基于资源预留协议的路径消息的确认方法，其特征在于，所述的步骤B包括：

当收到接收方返回的Resv消息时，根据Resv消息中承载的过滤说明确定其是否为所述Path消息对应的Resv消息，如果是，则结束Path消息的重传处理过程。

7、根据权利要求4所述的基于资源预留协议的路径消息的确认方法，其特征在于，所述的步骤B包括：

当收到接收方返回的PathErr消息时，根据PathErr消息中承载的过滤说明确定其是否为所述Path消息对应的PathErr消息，如果是，则结束Path消息的重传处理过程。

Images