CN102143038A

CN102143038A - 一种建立业务的方法和节点

Info

Publication number: CN102143038A
Application number: CN2010102138639A
Authority: CN
Inventors: 饶国义; 赖晓; 吕鑫; 贺志国; 祝广东
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2010-06-23
Filing date: 2010-06-23
Publication date: 2011-08-03
Anticipated expiration: 2030-06-23
Also published as: CN102143038B

Abstract

本发明实施例公开了一种建立业务的方法和节点。本发明技术方案由于节点中，可以为不同业务分别建立LSP，在节点中可以包括有多个入接口，从不同的入接口接收到的Path消息归属于不同的LSP，每个接口可以和一个或者多个RSVP实例相连，节点可以根据接收到的Path消息的入接口不同，将Path消息分配到不同的RSVP实例中处理。这里的节点中包括多于一个的RSVP实例，每个RSVP实例可以是由一个单板实现，一个节点中的RSVP实例的数量是可变的，通常一个RSVP实例中处理的LSP数量是固定的，可以通过扩展RSVP的数量可以扩大单个节点中处理LSP的数量，从而提高了中间节点的容量，同时，不会降低中间节点的性能。

Description

一种建立业务的方法和节点

技术领域

本发明涉及通信技术领域，具体涉及一种建立业务的方法和节点。

背景技术

随着人们对通信需求在不断增长，导致网络规模越来越大，边缘接入节点(PE)越来越多。而且，网络扁平化的趋势也使得每一层的网络规模在变大。在大规模网络下，如何规划流量，使得网络整体利用效率提高，是关系到运营商投资收益的重要问题。另外，差异化服务是运营商营销的重要策略，如何在同一张网络中提供差异化服务，直接关系到运营商市场的成功与否。同时，随着市场竞争激烈化，用户要求也越来越高，其中高可靠性的通信质量是至关重要的，这种要求反映到到网络技术上，就是PE之间通信如何保证服务质量(QoS，Quality of Service)和可靠性。

流量工程(TE，Traffic Engineering)技术能很好的满足上述要求。TE能指定显式路径，满足用户网络规划的需求；TE通过区分服务流量工程(DS-TE，Diffserv Traffic Engineering)，可以提供差异化服务；TE支持快速重路由(FRR，Fast Reroute)、端到端保护，能满足不同层次的可靠性需求。但是随着网络的规模变大，TE扩展性不足的情况开始呈现：由于TE是软状态刷新协议，每条标签交换路径(LSP，Label Switch Path)的状态块需要定期刷新，限制了单个资源预留协议(Resource Reservation Protocol，简称RSVP)实例能够支持的LSP数量，并且，每条LSP都需要占用状态块，耗用内存资源，也限制了单个RSVP实例能够支持的LSP数量。需要说明的是，现有技术中单个网络节点中包括一个RSVP实例，由于单个RSVP实例能够支持的LSP数量有限，影响了节点的性能和容量，从而也成为网络发展的瓶颈，尤其是核心节点网络，核心节点之间采用全互联，随着接入节点数量的增大，核心节点能够支撑LSP的数量受限导致了核心节点网络的性能大大降低。

发明人在实现本发明的过程中，发现现有技术至少存在的缺陷是：网络单个节点支持的LSP数量非常有限，严重影响网络侧对数据的传输速度，需要增加网络设备，造成网络布局复杂，成为扩大网络规模的瓶颈。

发明内容

本发明实施例提供一种建立业务的方法和节点，克服了现有技术中网络单个节点支持的LSP数量非常有限的缺点。

本发明实施例提供了一种建立业务的方法，包括：

根据从上游节点接收到Path消息的入接口，将所述Path消息发送给第一资源预留协议RSVP实例，所述第一RSVP实例建立Path消息状态块；

所述第一RSVP实例根据所述Path消息为所述Path消息对应的标签交换路径LSP预留带宽并申请标签；

所述第一RSVP实例生成发送给下游节点的Path消息，将所述发送给下游节点的Path消息发送给第二RSVP实例，所述第二RSVP实例为所述Path消息出接口对应的RSVP实例；

所述第二RSVP实例根据接收的所述发送给下游节点的Path消息，记录所述LSP与第一RSVP的绑定关系，将所述发送给下游节点的Path消息发送给下游节点；

所述第二RSVP实例接收所述下游节点发送的Resv消息，其中，所述Resv消息与所述Path消息对应于相同的LSP；所述第二RSVP实例根据所述LSP与第一RSVP实例的绑定关系，将所述Resv消息发送给所述第一RSVP实例；

所述第一RSVP实例根据所述Resv消息，建立所述LSP；

所述第一RSVP实例生成发送给上游节点的Resv消息，并发送给所述上游节点。

本发明实施例还提供了一种建立业务的节点，包括：第一RSVP实例和第二RSVP实例；

所述第一RSVP实例，用于根据从上游节点接收到Path消息的入接口，接收所述Path消息，建立Path消息状态块；根据所述Path消息为所述Path消息对应的标签交换路径LSP预留带宽并申请标签；生成发送给下游节点的Path消息，将所述发送给下游节点的Path消息发送给第二RSVP实例，所述第二RSVP实例为所述Path消息出接口对应的RSVP实例；接收所述第二RSVP实例发送的Resv消息，根据所述Resv消息，建立所述LSP；生成发送给上游节点的Resv消息，并发送给所述上游节点；

所述第二RSVP实例，用于接收所述第一RSVP实例发送的所述发送给下游节点的Path消息，根据接收的所述发送给下游节点的Path消息，记录所述LSP与第一RSVP的绑定关系，将所述发送给下游节点的Path消息发送给下游节点；接收所述下游节点发送的Resv消息，其中，所述Resv消息与所述Path消息对应于相同的LSP；根据所述LSP与第一RSVP实例的绑定关系，将所述Resv消息发送给所述第一RSVP实例。

本发明实施例采用中间节点中接收Path消息的入接口所在的RSVP实例(即RSVPl)，结合资源管理模块和转发代理模块，完成了建立LSP的主要处理，而中间节点中发送Path消息的出接口所在的RSVP实例(即RSVP2)只是协助RSVP2进行Path消息的发送，和Resv消息的接收。因此，当中间节点中要建立大量LSP时，可以根据接收到Path消息的不同入接口将需要建立的LSP所归属的业务分布到不同的RSVP实例中，由于RSVP实例的数量可扩展，从而提高了中间节点的容量，同时，不会降低中间节点的性能。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为基于接口的RSVP分布式的通信系统示意简图；

图2本发明实施例提供的一种建立业务的方法流程简图；

图3为本发明实施例提供的在首节点建立业务的方法示意图；

图4为本发明实施例提供的在中间节点建立业务的方法示意图；

图5为PLR节点进行Bypass隧道绑定处理的示意图；

图6为PLR节点进行Auto FRR处理的示意图；

图7为PLR节点将流量切换到备份隧道的方法示意图；

图8是对FRR MP将流量切换到备份隧道的方法示意图；

图9是从发送端说明该摘要刷新的方法流程示意简；

图10是从接收端说明该摘要刷新的方法流程示意简图；

图11为本发明实施例还提供了一种建立业务的节点示意图。

具体实施方式

本发明实施例提供一种建立业务的方法，该方法中采用多个RSVP实例，根据接收到Path消息的入接口不同，将多个LSP的处理分别分配给多个RSVP实例处理，减轻了单个RSVP实例的负担，其中，节点中包括多于一个的RSVP实例，每个RSVP实例由一个单板实现，一个节点中的RSVP实例的数量是可变的，优选的，一个单板实现一个RSVP实例，通常一个RSVP实例中处理的LSP数量是固定的，通过扩展RSVP的数量可以引入更多单板对LSP进行支持，可以扩大单个节点中处理LSP的数量，从而提高了单个节点的业务处理速度，提高了单个节点的容量和性能。需要理解的是，本发明实施例提供的技术方案也可以根据Path消息的出接口不同，将多个LSP的处理分别分配给多个RSVP实例处理，与上述提出的根据接收到Path消息的入接口不同进行处理方法的实质是相同的，根据在后续的文字中重点说明的根据接收到Path消息的入接口不同进行处理的方法可以容易得出。发明实施例还提供相应的节点及通信系统。以下分别进行详细说明。

为了便于对本发明实施例的理解，参见图1所示，为基于接口的RSVP分布式的通信系统示意简图，图中包括一条LSP所路由的三个节点，包括：入接口节点(ingress，或者称为“首节点”)，传输节点(transit，或者称为“中间节点”，其中，中间节点可以有多个)，和出接口节点(egress，或者称为“末节点”)。

在中间节点中LSP处理由Path消息入接口所对应的RSVP实例执行；中间节点中Path消息的出接口(通常就是Resv消息的入接口)所对应的RSVP实例缓存相应的RSVP消息用于刷新以及邻居处理(即Hello处理)，即业务处理主要由入接口对应的RSVP实例处理。其中，由于首节点不会接收到上游节点发送的Path消息，而是由业务管理模块建立业务请求，因此，为了方便，可以将业务的首节点处理全部由一个RSVP实例(本实施例中将该实例举例为RSVP0实例，后续实施例中会更详细说明)处理。

在单个节点中RSVP实例的个数不限于图1中所示的两个，可以是更多，一个RSVP实例对应一个或者多于一个的接口；RSVP实例可以部署在主控板上，管理人员可也配置RSVP实例与接口之间的对应关系；每个RSVP实例都可以获知配置的RSVP实例与接口之间的对应关系。由于不同的业务的入接口通常分散在各个单板上，与入接口对应的进行主要业务处理的RSVP实例通常也分散在各个单板上，可以实现分布式处理。

如图2所示，为本发明实施例提供的一种建立业务的方法流程简图，该方法的说明包括：

步骤S1：根据从上游节点接收到Path消息的入接口，将Path消息发送给第一资源预留协议RSVP实例，第一RSVP实例建立Path消息状态块；

步骤S2：第一RSVP实例根据Path消息为Path消息对应的标签交换路径LSP预留带宽并申请标签；

步骤S3：第一RSVP实例生成发送给下游节点的Path消息，将发送给下游节点的Path消息发送给第二RSVP实例，第二RSVP实例为Path消息出接口对应的RSVP实例；

步骤S4：第二RSVP实例根据接收的发送给下游节点的Path消息，记录LSP与第一RSVP的绑定关系，将发送给下游节点的Path消息发送给下游节点；

步骤S5：第二RSVP实例接收下游节点发送的Resv消息，其中，Resv消息与Path消息对应于相同的LSP；第二RSVP实例根据LSP与第一RSVP实例的绑定关系，将Resv消息发送给第一RSVP实例；

步骤S6：第一RSVP实例根据Resv消息，建立LSP；

步骤S7：第一RSVP实例生成发送给上游节点的Resv消息，并发送给上游节点。

本发明实施例提供的一种建立业务的方法中，节点中接收Path消息的入接口所对应的RSVP实例(即第一RSVP实例)，结合资源管理模块和转发代理模块，完成了建立LSP的主要处理，而节点中发送Path消息的出接口所在的RSVP实例(即第二RSVP实例)只是协助第一RSVP实例进行Path消息的发送，和Resv消息的接收。由于在该节点中可以为不同业务分别建立LSP，在节点中可以包括有多个入接口，从不同的入接口接收到的Path消息归属于不同的LSP，每个接口可以和一个或者多个RSVP实例相连，节点可以根据接收到的Path消息的入接口不同，将Path消息分配到不同的RSVP实例中处理。这里的节点中包括多于一个的RSVP实例，每个RSVP实例可以是由一个单板实现，一个节点中的RSVP实例的数量是可变的，通常一个RSVP实例中处理的LSP数量是固定的，可以通过扩展RSVP的数量可以扩大单个节点中处理LSP的数量。

因此，当节点中要建立大量LSP时，可以根据接收到Path消息的不同入接口将需要建立的LSP所归属的业务分布到不同的RSVP实例中，由于RSVP实例的数量可扩展，从而提高了中间节点的容量，同时，不会降低中间节点的性能。

图3为本发明实施例提供的在首节点建立业务的方法示意图，在首节点中可以包括：RSVP0，RSVP3，业务管理模块，资源管理模块，转发代理模块和路径计算模块。其中，业务管理模块，资源管理模块，转发代理模块和路径计算模块可以集中在RSVP0中实现。首节点中的RSVP3中只有Path消息的出接口，如图中路径计算模块计算出的首节点的出接口为IF3，其中，IF3与RSVP3相连。

由于首节点中没有Path消息的入接口，则由业务管理模块触发RSVP0进行LSP的业务处理。下面对该方法详细说明，包括：

步骤301：业务管理模块接收到配置隧道的命令；

步骤302：业务管理模块根据接收到的配置隧道的命令，向路径计算模块请求计算隧道路径，业务管理模块将计算结果返回给业务管理模块；

其中，路径计算模块为了方便计算路径，可以将TE链路信息统一在一起，例如采用约束最短路径优先(CSPF，Constraint Shortest Path First)算法。也可以将路径计算分布部署，但此时TE链路信息不能集中到一个路径计算模块，计算路径会比较复杂。

步骤303：业务管理模块指示RSVP0建立LSP；

步骤304：RSVP0根据接收到的建立LSP指示，为所述新的LSP预留带宽并申请标签，具体包括：RSVP0向转发代理模块请求进行检查，转发代理模块记录需要建立的LSP和RSVP0的绑定关系，转发代理模块向资源管理模块请求资源检查，资源管理模块返回检查结果给转发代理模块，转发代理模块返回检查结果给RSVP0；

其中，转发代理模块，还可以作为转发层面与控制层面的接口，将控制层面的内容下发给转发层面。资源管理模块中会检查是否有足够的带宽给要建立的LSP使用，如果带宽充足，则检查结果中包括节点中有足够的资源建立LSP的信息。

步骤305：RSVP0根据上述检查结果中的用于建立LSP的资源信息，生成发送给下游的Path消息，根据预置的出接口与RSVP实例对应关系，将发送给下游的Path消息发送给下游RSVP3，RSVP3记录LSP和RSVP0的绑定关系，由RSVP3将发送给下游的Path消息发送给下一跳；RSVP3为Path消息出接口对应的RSVP实例；

还需要说明的是，RSVP0不仅参与执行预留带宽、下发转发层面的操作，还进行申请标签等主要的建立LSP的操作。

其中，在建立了LSP后，RSVP3会定时的发送Path消息给下一跳进行刷新。

步骤306：RSVP3接收到下游回复的Resv消息；

步骤307：RSVP3根据在步骤305中记录的LSP和RSVP0的绑定关系，将Resv消息发送给RSVP 0；

步骤308：RSVP0接收Resv消息后，向转发代理模块发送资源预留请求，转发代理模块转发资源预留请求给资源管理模块，资源管理模块预留资源成功后，返回资源预留成功响应通过转发代理发送到RSVP0；

步骤309：RSVP0向下游RSVP3回复Resv消息处理结果响应(如Ack消息)；

其中，RSVP3根据接收到的RSVP0发送的Ack消息，当后续收到的Resv消息发生变化或者超时才向RSVP0报告Resv消息情况，由RSVP3接收下游定时发送的Resv消息刷新。

步骤310：RSVP0向业务管理模块回复LSP建立成功响应。

其中，建立LSP是节点的本地行为，当接收到Resv消息后，LSP才是激活的。

通过上述对本发明实施例提供的首节点中建立业务的方法的说明，由于首节点中包括多个RSVP，每个RSVP实例可以是由一个单板实现，一个节点中的RSVP实例的数量是可变的，通常一个RSVP实例中处理的LSP数量是固定的，可以通过扩展RSVP的数量可以扩大单个节点中处理LSP的数量。该首节点中的业务管理模块选择建立LSP的RSVP实例，将大量的LSP分布在多个RSVP实例中，与现有技术中将所有LSP部署在一个RSVP实例相比，本发明实施例提供的方法可以通过增加RSVP实例的数量，从而扩大首节点的容量和性能，可以提高首节点处理业务的速度。

图4为本发明实施例提供的在中间节点建立业务的方法示意图，在中间节点可以包括与首节点相同的模块，由于中间节点中具有接收Path消息的入接口，因此，可以不包括业务管理模块和路径计算模块。该方法具体包括：

步骤401：RSVPl接收到上游发送的Path消息，建立Path状态块(PSB，PathState Block)；

其中，RSVP1是接收到上游发送的Path消息的入接口所连接的RSVP实例。该入接口与RSVP1的连接的可以是预先配置的。一个RSVP实例可以配置多个与之相连的接口。

步骤402：RSVP1根据接收到的Path消息，发送资源检查请求给转发代理模块，转发代理模块记录该Path消息所要建立的LSP与RSVP1的绑定关系，将资源检查请求发送给资源管理模块，资源管理模块返回检查结果通过转发代理模块发送给RSVP 1；

其中，资源管理模块中可以检查是否有足够的带宽分配给该LSP所归属的业务，资源管理模块不限于上述说明的检查带宽等资源，还可以是其它，此处不应该理解为对本发明实施例的限制。其中，步骤402中的操作也可以理解为第一RSVP实例根据所述Path消息为所述Path消息对应的标签交换路径LSP预留带宽并申请标签。

步骤403：RSVP1生成发送给下游的Path消息，将该发送给下游的Path消息发送给出接口所归属的RSVP实例(即图4中RSVP2)，RSVP2记录该发送给下游的Path消息所归属的LSP与RSVP1的绑定关系，启动定时器定时向下游发送Path消息；

步骤403中具体可以通过与RSVP2相连的接口IF2将Path消息发送给下游节点。

步骤404：RSVP2接收到下游回复的与上述Path消息对应的Resv消息；

步骤405：RSVP2根据该Resv消息归属的LSP与RSVP1的绑定关系，将接收到的Resv消息转发给RSVP1；

步骤406：RSVP1接收Resv消息，建立所述LSP；

其中，步骤406中建立所述LSP的具体操作可以包括：RSVP1向转发代理模块发送预留资源请求；转发代理模块将该预留资源请求发送给资源管理模块，资源管理模块预留资源成功后，通过转发代理模块将预留成功响应发送给RSVP1；

步骤407：RSVP1向RSVP2回复Resv消息的处理结果响应(如Ack消息)；RSVP2根据接收到的Ack消息，启动超时定时器，接收定时发送的Resv消息刷新。当后一次接收的Resv消息与前一次接收的Resv消息中内容有不同，或者规定时间内未接收到Resv消息时，RSVP2向RSVP1报告超时未接收的Resv消息。否则，若RSVP2接收到下游节点定时发送的Resv消息，并且该Resv消息的内容与前一次接收的相同，则不向RSVP1报告，RSVP1维持LSP的状态。

步骤408：RSVP1发送给上游节点的Resv消息。

步骤408中具体可以通过与RSVP1相连的接口IF1将Resv消息发送给上游节点。

通过上述对图4的说明，由于中间节点中接收Path消息的入接口所在的RSVP实例(即RSVP1)，结合资源管理模块和转发代理模块，完成了建立LSP的主要处理，而中间节点中发送Path消息的出接口所在的RSVP实例(即RSVP2)只是协助RSVP2进行Path消息的发送，和Resv消息的接收。当中间节点中要建立大量LSP时，可以根据接收到Path消息的不同入接口将需要建立的LSP所归属的业务分布到不同的RSVP实例中，且多个RSVP实例是由多个单板实现，每个RSVP实例可以是由一个单板实现，一个节点中的RSVP实例的数量是可变的，通常一个RSVP实例中处理的LSP数量是固定的，可以通过扩展RSVP的数量可以扩大单个节点中处理LSP的数量，从而提高了中间节点的容量，同时，不会降低中间节点的性能。

需要理解的是，一个节点既可以作为一条LSP的首节点，也可以作为另一条LSP的中间节点，当然也可以作为其它LSP的末节点。

由于末节点只有入接口，没有出接口，处理上就不需要涉及到多个RSVP实例，对末节点的处理可以参考现有技术。

由于RSVP的快速重路由(FRR，Fast Reroute)是RSVP协议的一种重要功能，在主LSP发生故障时，可以将路径切换到保护LSP(该保护LSP具体可以是旁路(Bypass)隧道，也称为Bypass LSP，该Bypass隧道与主LSP绑定)上。下面结合附图对已经建立主LSP的本地修复节点(PLR，Point ofLocal Repair)建立保护LSP的方法进行说明。

图5为PLR节点进行Bypass隧道绑定处理的示意图。其中PLR通常为BypassLSP的头节点，PLR位于主LSP上。图中节点RT1-节点RT2-节点RT3的路径为主LSP，节点RT1-节点RT4-节点RT3的路径为Bypass LSP，在节点RT1-节点RT4-节点RT3的路径Bypass LSP上可以保护多于一条LSP，建立BypassLSP的方法与图3、图4中说明的建立LSP的方法相同。在业务管理模块中记录有Bypass LSP可以保护的多个LSP所需要的总的带宽。例如：在节点RT1-节点RT2-节点RT3的路径上有LSP1、LSP2、LSP3、LSP4四条LSP，建立BypassLSP总的带宽为40M，那么，Bypass LSP可以为每条LSP分配一定的带宽，保护主LSP，四条LSP的Bypass LSP的带宽总和不能超出40M。其中，节点RT1为PLR，在节点RT1中由RSVP实例管理Bypass隧道，对有带宽需要的Bypass隧道，集中到业务管理模块申请扣减带宽。

需要说明的是，RSVP1获知到Path消息的出接口所在的RSVP接收到下游发送的Resv消息(即LSP在该节点中建立成功)，且RSVP1根据用户的配置记录信息，发现LSP需要FRR保护执行该Bypass隧道绑定处理的方法；其中，该RSVP1是接收Path消息的入接口所在的实例。该方法包括：

步骤501：RSVP1将保护该主LSP出接口的Bypass隧道以及主LSP发送给路径计算模块，路径计算模块检验Bypass隧道是否能够保护该主LSP，路径计算模块返回检查结果给RSVP1；

其中，如果路径计算模块判断出Bypass隧道能够保护该主LSP，则返回的检查结果中包括：Bypass隧道与出接口之间绑定的信息。还需要理解的是，Bypass隧道的建立有二种方式：一种是自动方式建立的(auto方式)；另一种是手工建立的；其中，手工的Bypass隧道是预先建立好的；auto Bypass是在配置快速重路由(FRR)时建立的，即非手工配置的情况下，隧道是在配置FRR时自动触发创建的。

Bypass隧道的建立与上述首节点，中间阶段和末节点中建立LSP的方法可以是一样，只是首节点为PLR节点。

步骤502：RSVP1判断出该LSP需要带宽保护，向业务管理模块申请Bypass隧道的保护带宽，业务管理模块扣减Bypass隧道的保护带宽，将处理结果返回给RSVP1；

其中，RSVP1可以根据配置信息以及主LSP是否有带宽要求，判断该LSP是否需要带宽保护，具体过程可以参考现有技术。业务管理模块能够获知Bypass隧道的带宽，扣减的带宽是对主LSP保护需要的带宽值，每保护一条，就需要扣减相应能够保护的带宽。

步骤503：如果RSVP1根据业务管理模块返回的处理结果，判断Bypass隧道与主LSP上的出接口的绑定成功时，RSVP1向转发代理模块发送FRR出接口，转发代理模块向转发平面发送FRR出接口；

其中，转发代理模块向转发平面发送FRR出接口的作用是：通知转发层面进行FRR保护，当主LSP故障就切换到Bypass路径上。FRR出接口是一个特殊的出接口，需要与被保护的出接口一起下发给转发层面。

步骤504：如果RSVP1根据业务管理模块返回的处理结果，判断Bypass隧道与主LSP上的接口的绑定失败时，定期触发重新绑定。

其中，RSVP1可以在绑定失败时启动定时器，在预定的时刻触发有带宽保护绑定的尝试。

还需要说明的是，业务管理模块根据LSP是否携带了带宽参数可以判断出Bypass隧道是否需要带宽保护，当LSP中有带宽参数，则Bypass隧道需要带宽保护。对于有带宽保护要求的FRR，为了使得RSVP实例能够在Bypass隧道选择前期排除一些带宽不满足要求的Bypass隧道，该Bypass隧道绑定处理的方法，还可以包括：

步骤505：业务管理模块将Bypass隧道能够保护的带宽信息周期性发布给节点中的每个RSVP实例；

其中，业务管理模块将Bypass隧道能够保护的带宽信息发送给各RSVP实例的触发条件可以是：当RSVP实例要求Bypass隧道提供带宽保护，但是，业务管理模块中保存的带宽信息表明已经不能提供带宽保护时，业务管理模块将该条备份隧道的带宽向所有的RSVP实例周期性发布Bypass隧道能够保护的带宽信息。

需要说明的是，步骤505中业务管理模块将能够保护的带宽信息周期性发布给节点中的每个RSVP实例，使得每个RSVP实例中获知到业务管理模块中的能够保护的带宽信息，从而在每个RSVP实例中根据自身需要的保护带宽和业务管理模块中的能够保护的带宽信息，判断出业务管理模块中的带宽是否够用，够用的情况才去业务管理模块中申请带宽，不够用的情况下，就不申请带宽保护。因此，步骤505了减少RSVP实例通知业务管理模块申请扣减带宽时失败的概率。

上述是对PLR进行FRR的说明，RSVP协议的另一种重要功能是自动快速重路由(Auto FRR)。Auto FRR可以在整体LSP上自动创建对链路或者对接口的Bypass隧道。

图6所示为PLR节点进行Auto FRR处理的示意图。在该PLR节点中每个RSVP实例都可以获取Auto FRR的配置，并且每个RSVP实例可以决定是否触发建立Auto FRR隧道。执行该方法的目的是：在节点已经成功建立LSP的基础上，实现对该LSP上的节点或者该LSP所属的链路的保护。其中，LSP建立成功的标志可以是：接收到下游发送的Resv消息，并且向上游发送了Resv消息。

下面对Auto FRR处理进行说明，该方法包括：

步骤601：RSVP1通知业务管理模块创建自动旁路(Auto Bypass)隧道；

其中，步骤601可以具体是在RSVP1通过本地数据查找，检查到LSP需要FRR保护，并且本地不能查找到合适的备份隧道时，才触发执行的。

还需要说明的是，步骤601是在本节点LSP建立成功后才执行的，PLR节点中RSVP1相当于上述说明的首节点中RSVP0实例，即RSVP1参与执行预留带宽、申请标签、下发转发层面的操作成功。

其中，RSVP1是接收Path消息的入接口所属的RSVP，如果Path消息的出接口所归属的RSVP定期的接收到Resv消息，即表示该LSP是定期刷新的，该LSP处于保活状态，如果该Resv消息与上一次接收到的Resv消息的内容相同，则Path消息的出接口所归属的RSVP不会发送的报告消息给RSVP1。

步骤602：业务管理模块触发建立Auto Bypass隧道；

其中，业务管理模块触发建立Auto Bypass隧道的具体操作与图3中说明的首节点建立业务的方法可以相类似，Auto Bypass隧道也是一条隧道，在业务管理模块上当作Bypass使用，不需要用户配置建立。当前的RSVP1相当于上述RSVP0，在与业务管理模块等结合，建立新的LSP，该新的LSP即为Auto Bypass隧道。

步骤603：业务管理模块向RSVP1返回Auto Bypass隧道标识(Tunnel-ID)用于建立FRR出接口；

其中，步骤603操作的用途是将该Auto Bypass隧道用作主LSP的一个FRR出接口，用来保护主LSP的原来的出接口。

步骤604：RSVP1根据Auto Bypass隧道ID，建立FRR出接口，将FRR出接口下发给转发代理模块；由转发代理模块向转发平面发送FRR出接口；

进一步，该方法还包括：

步骤605：当Auto Bypass隧道不需要带宽保护，业务管理模块将AutoBypass隧道的信息下发给每个RSVP实例；如果Auto Bypass隧道是绕道(Detour)保护，每条Bypass隧道只是保护一条主LSP上的一段路径，每个节点中对一条LSP的处理主要由一个RSVP实例执行，因此，在节点中业务管理模块不需要将Auto Bypass的信息下发给每个RSVP实例。

其中，Auto Bypass信息具体可以包括：隧道ID、隧道的目的地址，或者带宽信息参数。

通过上述对Auto FRR方法的说明，节点中接收Path消息的不同入接口所归属的不同RSVP实例可以与业务管理模块等结合，实现自动快速重路由。

当PLR节点检测到接口或者节点故障后，RSVP实例将Path消息通过备份隧道(例如：Bypass隧道)进行发送，转发平面检测到链路故障，将流量切换到备份隧道。

图7为PLR节点将流量切换到备份隧道的方法示意图，在该PLR节点中举例有三个RSVP实例，包括：RSVP1，RSVP2和RSVP4。其中，当发现发送Path消息的出接口(即第三接口，该第三接口归属于RSVP2)出现故障时，即判断出主LSP出现故障，则将发送Path消息的出接口对应的RSVP2中流量切换到备份隧道对应的RSVP4中处理。该方法具体包括：

步骤701：RSVP1接收到接口管理模块通知的第三接口(简称“IF3”)故障的消息；

其中，RSVP1是主LSP所属的RSVP实例，也就是接收Path消息的入接口所归属的RSVP实例，IF3出现故障时，将RSVP1中的业务转移到Bypass隧道上。

步骤702：RSVP 1向转发代理模块发送FRR切换请求，转发代理模块收到该FRR切换请求，转发代理模块将切换消息下发到转发平面，用于转发层面消息的流量切换；

其中，通知执行步骤702使得流量会从原来的主LSP出接口转移到FRR的Bypass隧道的出接口。

步骤703：RSVP1根据Bypass隧道信息，将Path消息发送到Bypass隧道的出接口所在的RSVP4，由RSVP4定时发送Path消息执行刷新；

其中，RSVP1中预置的Bypass隧道信息，可以是当节点执行FRR后，通知给各RSVP实例的，也可以是RSVP1从业务管理模块中主动获取的。

步骤704：RSVP1发送一个释放消息给RSVP2，使RSVP2删除其主LSP出接口所在的RSVP2的缓存的与LSP有关的信息；

其中，RSVP2为主LSP上发送Path消息的出接口所属的RSVP实例；上述所说的与LSP有关的信息，具体包括：Path缓存消息和接收的Resv缓存消息。

步骤705：RSVP4接收到合并节点(MP，Merge Point)发送的Resv消息；

其中，MP与PLR对应，PLR是Bypass隧道的首节点，MP是Bypass隧道的末节点。

步骤706：RSVP4将Resv报文缓存，并启动超时定时器，当MP节点继续往PLR节点发送Resv消息时，如果没有变化，可以在RSVP4更新超时定时器，使其不超时，并结束Resv消息处理，不需要向RSVP1上送。

通过上述对图7对PLR将流量切换到备份隧道的方法进行了说明，使得当PLR检测到节点或者接口故障时，将流量切换到备份隧道，从而提高网络的可靠性。

图8是对FRR MP将流量切换到备份隧道的方法示意图。由于MP节点上原来的入接口故障，导致FRR LSP的MP节点上的入接口与原来主LSP的入接口不一样，因此，需要去转发代理模块中查找处理该Path消息的RSVP实例，再进行处理。为了描述方便，假设该MP中主LSP原来在RSVP6中进行处理，FRR切换后Path消息从通过第二接口(简称“IF2”)被RSVP5接收。

该方法包括：

步骤801：RSVP5接收到PLR发送的Path消息；

步骤802：RSVP5向转发代理模块查询该Path消息所归属的LSP是否已经有RSVP实例进行处理；

步骤803：转发代理模块返回该LSP已经在RSVP6中进行处理的消息给RSVP5；

步骤804：RSVP5将Path消息发送到RSVP6进行处理，并将Path消息缓存，如果上游继续发送的Path消息到RSVP5，并且Path消息没有变化，则直接更新超时定时器，不需要再往RSVP6发送Path消息；

步骤805：RSVP6接收到Path消息，RSVP6具体根据Path消息中参数SendTemper发生变化来判断是否发生FRR，如果是，RSVP6将流量进行FRR切换，向备份隧道在MP节点的入接口对应的RSVP实例发送Resv消息(如图8中备份隧道入接口对应的RSVP实例为RSVP5)；RSVP6删除FRR切换前缓存的Path消息和Resv消息；

其中，FRR切换前RSVP6中缓存的Path消息和Resv消息是从归属于RSVP6的接口IF6中获取的。FRR切换后的Path消息和Resv消息是从归属于RSVP5的接口IF2获取的。

步骤806：RSVP5接收RSVP6发送的Resv消息，缓存Resv消息，定期将Resv消息发送给PLR执行刷新。

通过上述对图8的说明，在FRR时MP实现了将流量切换到备份隧道上。当主LSP发生故障后，由MP中的备份隧道所在的RSVP实例(即RSVP5)来代替主LSP所在的RSVP实例(即RSVP6)实现业务处理。

本发明实施例还提供了一种摘要刷新的方法，该方法在节点中已经建立LSP后执行，当节点内的RSVP实例启动摘要刷新功能后，发生报文的RSVP实例可以为每个报文产生一个消息标识(Message ID)，将该消息标识发生给上/下游节点，当上/下游节点回复确认消息(即ACK消息)后，后续发生的刷新报文时，发生消息标识就可以，而不用发生整个刷新报文。下面以刷新报文为Path消息，举例发送端所在节点中的操作。

如图9所示是从发送端说明该摘要刷新的方法流程示意简图，该方法包括：

步骤901：RSVP1将Path消息发送给下游RSVP2进行发送；

其中，该RSVP1是产生发送给下游节点Path消息的RSVP实例，例如：RSVP1可以是接收上游节点发送的Path消息的入接口所在的RSVP实例，RSVP2则是Path消息出接口所在的RSVP实例。

步骤902：RSVP2接收到RSVP1发送的Path消息，为该Path消息生成信息标识(Message ID)，记录Message ID和Path消息的对应关系；

其中，不同RSVP实例可以分配相同的Message ID 。

步骤903：RSVP2向下游发送Path消息，其中，该Path消息携带message ID；

步骤904：RSVP2接收到下游发送的ACK消息；

步骤905：RSVP2根据接收到的ACK消息，发送Message ID执行后续刷新操作。

其中，当RSVP2接收到ACK消息后，后续刷新时将只发送Message ID进行刷新，不再发送完整的Path消息进行刷新。优选的，相同邻居的message ID打包在一起往下游刷新，大大减少消息刷新报文所消耗的资源。

需要理解的是，由于摘要刷新时，发送刷新报文的RSVP实例按照邻居将多个刷新报文的Message ID打包发送给上/下游节点，并且上/下游节点回复的ACK消息没有会话(Session)信息，无法查询到该刷新消息归属的LSP，只能根据摘要刷新报文目的地址匹配到对应的RSVP实例中进行处理。

还需要说明的是，如果ACK不是从发送Path消息的RSVP2收到，此时接收到下游回复的ACK的RSVP实例需要比较ACK的目的地址，如果不是自身RSVP实例管辖的接口地址则转给对应的RSVP实例进行处理。

如图10所示，仍然以Path消息为例，从接收端说明该摘要刷新的方法流程示意简图，该方法包括：

步骤110：RSVP1接收到携带有Message ID的Path消息，记录Message ID和Path消息的对应关系；

步骤111：RSVP1向发送Path消息的上游节点(也称为“邻居”)回复ACK消息；

步骤112：RSVP1判断接收到的Path消息是否是新建的Path消息，或者接收到的Path消息与前一次接收的Path消息是否相同；如果接收到的Path消息是新建的，或者是与前一次接收的Path消息有不同，则执行步骤113；否则，执行步骤114；

步骤113：根据当前接收到的Path消息，进行与新建业务相同的处理；

步骤114：继续接收上游节点发送的Message ID进行刷新。

其中，当接收到Message ID后，进行刷新操作具体可以包括：重新启动超时定时器，然后发送ACK给上游节点。

通过上述对图9和图10的说明，以Path消息为例说明了各节点中执行刷新操作的详细过程，由于Resv消息的传输方向与Path消息的传输方向恰好相反，则Resv消息的摘要刷新操作可以根据图9、图10的说明而容易的获得，此处不重述。

图11所示为本发明实施例还提供了一种建立业务的节点，该节点包括：第一RSVP实例P100，和第二RSVP实例P103；

上述第一RSVP实例，用于根据从上游节点接收到Path消息的入接口，接收Path消息，建立Path消息状态块；根据Path消息为Path消息对应的标签交换路径LSP预留带宽并申请标签；生成发送给下游节点的Path消息，将发送给下游节点的Path消息发送给第二RSVP实例，第二RSVP实例为Path消息出接口对应的RSVP实例；接收第二RSVP实例发送的Resv消息，根据Resv消息，建立LSP；生成发送给上游节点的Resv消息，并发送给上游节点；

上述第二RSVP实例，用于接收第一RSVP实例发送的发送给下游节点的Path消息，根据接收的发送给下游节点的Path消息，记录LSP与第一RSVP的绑定关系，将发送给下游节点的Path消息发送给下游节点；接收下游节点发送的Resv消息，其中，Resv消息与Path消息对应于相同的LSP；根据LSP与第一RSVP实例的绑定关系，将Resv消息发送给第一RSVP实例。

该节点还可以包括：转发代理模块P101，资源管理模块P102，其中，转发代理模块P101，资源管理模块P102与现有技术中的操作相同，此处不详细说明，参考现有技术和上述方法实施例中的说明即可容易获得。

优选的，第二RSVP实例，还用于定时向下游节点发送该发送给下游的Path消息；和，接收下游节点定时发送的Resv消息。

优选的，节点还包括：业务管理模块P104，路径计算模块P105，第零RSVP实例P106，和第三RSVP实例P107；

业务管理模块，用于接收配置隧道的命令，向路径计算模块请求计算隧道路径，获取路径计算模块返回的计算结果；向第零RSVP实例发送建立新的LSP的通知；

路径计算模块，用于计算隧道路径，将计算结果发送给业务管理模块；

第零RSVP实例，用于根据建立新的LSP的通知，为新的LSP预留带宽并申请标签；生成发送给下游节点的第二Path消息，并将第二Path消息发送给第三RSVP实例，第三RSVP实例为第二Path消息出接口对应的RSVP实例；

第三RSVP实例，用于根据第二Path消息，记录第二Path消息对应的LSP和第零RSVP实例的绑定关系，将第二Path消息发送给下游节点。

优选的，节点还包括：路径计算模块，业务管理模块，和转发代理模块P101，其中，

第一RSVP实例，还用于将保护LSP出接口的旁路隧道，和LSP发送给路径计算模块；向业务管理模块申请旁路隧道的带宽保护；向转发代理模块发送快速重路由出接口；

路径计算模块，用于检验出旁路隧道能够保护LSP时，返回检查结果给第一RSVP实例；

业务管理模块，用于扣减旁路隧道的保护带宽，将处理结果返回给第一RSVP实例；

转发代理模块，用于向转发平面发送快速重路由出接口。

优选的，上述业务管理模块P104，还用于将旁路隧道所保护的带宽信息周期性发布给节点中的每个RSVP实例。

优选的，节点还包括：业务管理模块P104和转发代理模块P101，其中，

第一RSVP实例，还用于指示业务管理模块创建自动旁路隧道；根据自动旁路隧道标识，建立快速重路由出接口，将快速重路由出接口发送给转发代理模块；

业务管理模块，用于建立自动旁路隧道后发送自动旁路隧道标识给第一RSVP实例；

转发代理模块，用于向转发平面发送快速重路由出接口。

优选的，节点还包括：第四RSVP实例P108和转发代理模块P101；则：

第一RSVP实例，还用于向转发代理模块发送快速重路由切换请求，根据旁路隧道的信息，将Path消息发送到第四RSVP实例，其中，第四RSVP实例是旁路隧道的出接口所在的RSVP实例，

转发代理模块，用于将收到快速重路由切换请求发送到转发平面；

第四RSVP实例，用于定时发送Path消息执行刷新，接收合并节点发送的Resv消息，缓存Resv消息，接收合并节点定时发送的Resv消息执行刷新。

优选的，节点还包括：第五RSVP实例P109和第六RSVP实例P110，

第五RSVP实例，用于接收到本地修复节点PLR发送的Path消息；当PLR发送的Path消息对应的LSP已经在第六RSVP实例中进行处理时，将PLR发送的Path消息发送给第六RSVP实例；向PLR发送Resv消息。

第六RSVP实例，用于接收到PLR发送的Path消息后，对流量进行快速重路由切换，发送Resv消息给第五RSVP实例。

优选的，第二RSVP实例，具体用于为发送给下游节点的Path消息生成信息标识，记录信息标识与发送给下游节点的Path消息的对应关系；将发送给下游节点的Path消息发送给下游节点，其中，发送给下游节点的Path消息中包括信息标识；接收下游发送的ACK消息；根据ACK消息，发送信息标识代替发送给下游节点的Path消息执行后续刷新操作。

需要说明的是，本发明实施例提供的节点的详细说明可以参考图1至图10建立业务的方法中关于节点的说明。在节点实施例中不重述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

以上对本发明实施例进行了详细介绍，本文中应用了具体实施方式对本发明进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及设备；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.一种建立业务的方法，其特征在于，包括：

所述第一RSVP实例根据所述Resv消息，建立所述LSP；

2.根据权利要求1所述的方法，其特征在于，

在所述第二RSVP实例接收的所述发送给下游节点的Path消息之后，所述方法还包括：

所述第二RSVP实例定时向下游节点发送所述发送给下游的Path消息；

在所述第二RSVP实例在接收到所述下游节点发送的Resv消息后，所述方法还包括：

第二RSVP实例接收下游节点定时发送的Resv消息。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

业务管理模块接收到配置隧道的命令，向路径计算模块请求计算隧道路径，获取所述路径计算模块返回的计算结果；所述业务管理模块向所述节点中的第零RSVP实例发送建立新的LSP的通知；

所述第零RSVP实例根据所述建立新的LSP的通知，为所述新的LSP预留带宽并申请标签；

所述第零RSVP实例生成发送给下游节点的第二Path消息，并将所述第二Path消息发送给第三RSVP实例，所述第三RSVP实例为所述第一Path消息出接口对应的RSVP实例；

第三RSVP实例根据所述第二Path消息，记录所述第二Path消息对应的LSP和第零RSVP实例的绑定关系，将所述第二Path消息发送给下游节点。

4.根据权利要求1所述的方法，其特征在于，所述第一RSVP实例根据所述Resv消息，建立所述LSP之后，所述方法还包括：

所述第一RSVP实例将保护所述LSP出接口的旁路隧道，和所述LSP发送给路径计算模块；

所述路径计算模块检验出所述旁路隧道能够保护所述LSP时，返回检查结果给所述第一RSVP实例；

所述第一RSVP实例向业务管理模块申请旁路隧道的带宽保护；

所述业务管理模块扣减所述旁路隧道的保护带宽，将处理结果返回给所述第一RSVP实例；

所述第一RSVP实例向转发代理模块发送快速重路由出接口；

所述转发代理模块向转发平面发送所述快速重路由出接口。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

所述业务管理模块将所述旁路隧道所保护的带宽信息周期性发布给节点中的每个RSVP实例。

6.根据权利要求1所述的方法，其特征在于，所述第一RSVP实例根据所述ResV消息，建立所述LSP之后，所述方法还包括：

所述第一RSVP实例指示业务管理模块创建自动旁路隧道；

所述业务管理模块建立自动旁路隧道后发送自动旁路隧道标识给所述第一RSVP实例；

所述第一RSVP实例根据自动旁路隧道标识，建立快速重路由出接口，将所述快速重路由出接口发送给转发代理模块；

所述转发代理模块向转发平面发送所述快速重路由出接口。

7.根据权利要求4至6任一项所述的方法，其特征在于，当发送给下游的Path消息的出接口故障时，所述方法还包括：

所述第一RSVP实例向转发代理模块发送快速重路由切换请求，转发代理模块将收到所述快速重路由切换请求发送到转发平面；

所述第一RSVP实例根据旁路隧道的信息，将Path消息发送到第四RSVP实例，其中，所述第四RSVP实例是所述旁路隧道的出接口所在的RSVP实例，由所述第四RSVP实例定时发送Path消息执行刷新；

所述第四RSVP实例接收到合并节点发送的Resv消息，缓存所述Resv消息，接收所述合并节点定时发送的Resv消息执行刷新。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

第五RSVP实例接收到本地修复节点PLR发送的Path消息；

当所述PLR发送的Path消息对应的LSP已经在第六RSVP实例中进行处理时，所述第五RSVP实例将所述PLR发送的Path消息发送给所述第六RSVP实例；

所述第六RSVP实例接收到所述PLR发送的Path消息后，对流量进行快速重路由切换，发送Resv消息给所述第五RSVP实例；

所述第五RSVP实例向所述PLR发送所述Resv消息。

9.根据权利要求1所述的方法，其特征在于，所述第二RSVP实例将所述发送给下游节点的Path消息发送给下游节点，还包括：

所述第二RSVP实例为所述发送给下游节点的Path消息生成信息标识，记录所述信息标识与所述发送给下游节点的Path消息的对应关系；

所述第二RSVP实例将所述发送给下游节点的Path消息发送给下游节点，其中，所述发送给下游节点的Path消息中包括所述信息标识；

所述第二RSVP实例接收下游发送的ACK消息；

所述第二RSVP实例根据所述ACK消息，发送所述信息标识代替所述发送给下游节点的Path消息执行后续刷新操作。

10.一种建立业务的节点，其特征在于，包括：第一RSVP实例和第二RSVP实例；

11.根据权利要求10所述的节点，其特征在于，所述第二RSVP实例，还用于定时向下游节点发送所述发送给下游的Path消息；和，接收下游节点定时发送的Resv消息。

12.根据权利要求10所述的节点，其特征在于，所述节点还包括：业务管理模块，路径计算模块，第零RSVP实例，和第三RSVP实例；

所述业务管理模块，用于接收配置隧道的命令，向路径计算模块请求计算隧道路径，获取所述路径计算模块返回的计算结果；向所述第零RSVP实例发送建立新的LSP的通知；

所述路径计算模块，用于计算隧道路径，将计算结果发送给所述业务管理模块；

所述第零RSVP实例，用于根据所述建立新的LSP的通知，为所述新的LSP预留带宽并申请标签；生成发送给下游节点的第二Path消息，并将所述第一Path消息发送给第三RSVP实例，所述第三RSVP实例为所述第二Path消息出接口对应的RSVP实例；

所述第三RSVP实例，用于根据所述第二Path消息，记录所述第二Path消息对应的LSP和第零RSVP实例的绑定关系，将所述第二Path消息发送给下游节点。

13.根据权利要求10所述的节点，其特征在于，所述节点还包括：路径计算模块，业务管理模块，和转发代理模块，其中，

所述第一RSVP实例，还用于将保护所述LSP出接口的旁路隧道，和所述LSP发送给路径计算模块；向业务管理模块申请旁路隧道的带宽保护；向转发代理模块发送快速重路由出接口；

所述路径计算模块，用于检验出所述旁路隧道能够保护所述LSP时，返回检查结果给所述第一RSVP实例；

所述业务管理模块，用于扣减所述旁路隧道的保护带宽，将处理结果返回给所述第一RSVP实例；

所述转发代理模块，用于向转发平面发送所述快速重路由出接口。

14.根据权利要求13所述的节点，其特征在于，所述业务管理模块，还用于将所述旁路隧道所保护的带宽信息周期性发布给节点中的每个RSVP实例。

15.根据权利要求10所述的节点，其特征在于，所述节点还包括：业务管理模块，和转发代理模块，其中，

所述第一RSVP实例，还用于指示业务管理模块创建自动旁路隧道；根据自动旁路隧道标识，建立快速重路由出接口，将所述快速重路由出接口发送给转发代理模块；

所述业务管理模块，用于建立自动旁路隧道后发送自动旁路隧道标识给所述第一RSVP实例；

16.根据权利要求13至15任一项所述的节点，其特征在于，所述节点还包括：第四RSVP实例；

所述第一RSVP实例，还用于向转发代理模块发送快速重路由切换请求，根据旁路隧道的信息，将Path消息发送到第四RSVP实例，其中，所述第四RSVP实例是所述旁路隧道的出接口所在的RSVP实例，

所述转发代理模块，还用于将收到所述快速重路由切换请求发送到转发平面；

所述第四RSVP实例，用于定时发送Path消息执行刷新，接收合并节点发送的Resv消息，缓存所述Resv消息，接收所述合并节点定时发送的Resv消息执行刷新。

17.根据权利要求10所述的节点，其特征在于，所述节点还包括：第五RSVP实例和第六RSVP实例，

所述第五RSVP实例，用于接收到本地修复节点PLR发送的Path消息；当所述PLR发送的Path消息对应的LSP已经在第六RSVP实例中进行处理时，将所述PLR发送的Path消息发送给所述第六RSVP实例；向所述PLR发送所述Resv消息；

所述第六RSVP实例，用于接收到所述PLR发送的Path消息后，对流量进行快速重路由切换，发送Resv消息给所述第五RSVP实例。

18.根据权利要求10所述的节点，其特征在于，

所述第二RSVP实例，具体用于为所述发送给下游节点的Path消息生成信息标识，记录所述信息标识与所述发送给下游节点的Path消息的对应关系；将所述发送给下游节点的Path消息发送给下游节点，其中，所述发送给下游节点的Path消息中包括所述信息标识；接收下游发送的ACK消息；根据所述ACK消息，发送所述信息标识代替所述发送给下游节点的Path消息执行后续刷新操作。