CN105591905B - 算路处理方法及装置 - Google Patents

Abstract

本发明公开了一种算路处理方法及装置，其中，该方法包括：下游结点接收来自头结点的算路方式；下游结点使用该算路方式进行算路。通过本发明解决了现有技术中隧道头结点的算路方式与中间节点的算路方式不一致的问题，进而可以得到最优的路径，提升了用户体验。

Description

算路处理方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种算路处理方法及装置。

背景技术

在多协议标签交换(Multiprotocol Label Switching，简称为MPLS)网络中，利用资源预留协议(Resource ReserVation Protocol，简称为RSVP-TE)建立一条隧道。通常来说，建立隧道时对于链路代价Metric的约束有两种，一种是内部网关协议链路代价(Interior Gateway Protocol Metric，简称为IGP Metric)，另一种是流量工程链路代价(Traffic Engineering Metric，简称为TE Metric)。

如图1所示，R1、R2、R3、R4四节点拓扑，图中各个链路的IGP Metric和TE Metic分别标注了相应的数值，从R1建立一条隧道到R3，如果我们选取的是IGP Metric方式约束，那么算路结果走的路径为L12、L23，即R1→R2→R3，因为这条路径总的IGP Metric值是所有可达路径中最小的；如果选取的是TE Metric方式约束，那么算路走的路径为L14、L34，即R1→R4→R3，因为这条路径总的TE Metric值是所有可达路径中最小的。

在实际应用中，部署隧道的时候，存在跨域等应用场景，进行算路时候，并不能从头结点直接算路到尾节点，可能需要经过中间节点再次算路。如图2所示，AREA0和AREA1两个域，同样R1建立隧道至R3，由于源地址和目的地址不在一个域内，所以头结点R1算路只能算到域的边界R2或者R4，从R2或者R4再次算路到R3。如果在R2或者R4上再次算路，算路的Metric约束应该与头结点算路方式一致才能保证整条隧道的Metric约束符合隧道头结点的策略。目前来说这一约束没有一个明确的信令机制，从头结点传递给下游。

目前解决上述问题存在如下几种方案：

第一种：中间节点算路，如果不知道隧道头结点的Metric约束方式，用约定默认的算路方式。这种方案存在的弊端就是可能造成一条隧道头结点Metric约束方式与中间节点Metric约束方式不一致。

第二种：各个节点全局配置Metric算路方式，如果配置了全局Metric算路方式的节点对于一条隧道是头结点，隧道下没有配置隧道的Metric算路方式，那么以全局的配置为准；如果隧道下配置了Metric算路方式，那么以隧道下配置为准。如果配置了全局Metric算路方式的节点对于一条隧道是中间节点，并且需要算路，那么算路方式以全局配置的为准。这种解决方式，也是会导致隧道头结点Metric约束方式与中间节点Metric约束方式不一致。

针对相关技术中，隧道头结点Metric约束方式与中间节点Metric约束方式不一致的问题，还没有提出有效的解决方案。

发明内容

本发明提供了一种算路处理方法及装置，以至少解决现有技术中隧道头结点Metric约束方式与中间节点Metric约束方式不一致的问题。

根据本发明的一个方面，提供了一种算路处理方法，包括：下游结点接收来自头结点的所述头结点的算路方式；所述下游结点使用所述算路方式进行算路。

优选地，所述下游结点接收来自所述头结点的算路方式包括：所述下游结点接收来自所述头结点的PATH报文；从所述PATH报文中获取所述头结点的算路方式。

优选地，所述算路方式通过以下之一方式携带于所述PATH报文中：在所述PATH报文中的新增字段添加所述算路方式、在所述PATH报文中的未使用的字段添加所述算路方式。

优选地，在所述PATH报文中的未使用的字段添加所述算路方式包括：在SESSION_ATTRIBUTE对象的FLAG字段中添加所述算路方式。

优选地，所述算路方式包括：内部网关协议链路代价IGP Metric、流量工程链路代价TE Metric。

根据本发明的一个方面，提供了另一种算路处理方法，包括：头结点确定所述头结点的算路方式，其中，所述算路方式为下游结点进行算路所使用的算路方式；所述头结点将所述算路方式发送给所述下游结点。

优选地，所述头结点将所述头结点的算路方式发送给所述下游结点包括：所述头结点将PATH报文发送给所述下游结点，其中，所述PATH报文中携带有所述头结点的算路方式。

根据本发明的一个方面，提供了一种算路处理装置，该装置应用于下游结点，包括：接收模块，用于接收来自头结点的所述头结点的算路方式；算路模块，用于使用所述算路方式进行算路。

优选地，所述接收模块还用于接收来自所述头结点的PATH报文；从所述PATH报文中获取所述头结点的算路方式。

根据本发明的一个方面，还提供了另一种算路处理装置，该装置应用于头结点，包括：确定模块，用于确定所述头结点的算路方式，其中，所述算路方式为下游结点进行算路所使用的算路方式；发送模块，用于将所述算路方式发送给所述下游结点。

通过本发明，采用下游结点接收来自头结点的算路方式；下游结点使用该算路方式进行算路。解决了现有技术中隧道头结点的算路方式与中间节点的算路方式不一致的问题，进而可以得到最优的路径，提升了用户体验。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的四节点Metric算路示意图；

图2是根据本发明实施例的跨域四节点示意图；

图3是根据本发明实施例的算路处理方法的流程图；

图4是根据本发明实施例的算路处理装置的结构框图；

图5是根据本发明实施例的算路处理方法的流程图一；

图6是根据本发明实施例的算路处理装置的结构框图一；

图7是根据本发明优选实施例的SESSION_ATTRIBUTE对象格式图；

图8是根据本发明优选实施例的隧道Metric算路约束的通知方法流程图；

图9是根据本发明优选实施例的隧道中间节点算路的方法流程图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在本实施例中提供了一种算路处理方法，图3是根据本发明实施例的算路处理方法的流程图，如图3所示，该流程包括如下步骤：

步骤S302，下游结点接收来自头结点的算路方式；

步骤S304，下游结点使用该算路方式进行算路。

通过上述步骤，下游结点使用接收到的来自头结点的算路方式进行算路，相比于现有技术中采用默认的算路方式及为各个结点全局配置算路方式仍然会出现头结点和下游结点所使用了算路方式不一致，上述步骤解决了隧道头结点的算路方式与中间节点的算路方式不一致的问题，进而可以得到最优的路径，提升了用户体验。

上述步骤S302涉及到下游结点接收来自头结点的算路方式，需要说明的是，下游结点可以通过多种方式接收头结点的算路方式，下面对此进行举例说明。在一个优选实施例中，下游结点接收来自头结点的PATH报文，从PATH报文中获取头结点的算路方式。

同时，算路方式可以通过多种方式携带于PATH报文中，在一个优选实施例中，算路方式可以存在于PATH报文中的新增字段中或者PATH报文中的未使用的字段中。

当算路方式存在于PATH报文中的未使用的字段中时，在一个优选实施例中，算路方式存在于SESSION_ATTRIBUTE对象的FLAG字段中。

在一个优选实施例中，头结点和下游结点处于不同的域或者相同的域。

具体地，算路方式包括：内部网关协议链路代价IGP Metric、流量工程链路代价TEMetric。

在本实施例中还提供了一种算路处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图4是根据本发明实施例的算路处理装置的结构框图，该装置应用于下游结点，如图4所示，该装置包括：接收模块42，用于接收来自头结点的该头结点的算路方式；算路模块44，用于使用该算路方式进行算路。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：接收模块22和算路模块24均位于同一处理器中；或者，接收模块22和算路模块24分别位于第一处理器、第二处理器中。

优选地，接收模块22还用于接收来自所述头结点的PATH报文；从该PATH报文中获取头结点的算路方式。

在本实施例中提供了另一种算路处理方法，图5是根据本发明实施例的算路处理方法的流程图一，如图5所示，该流程包括如下步骤：

步骤S502，头结点确定该头结点的算路方式，其中，算路方式为下游结点进行算路所使用的算路方式；

步骤S504，头结点将该算路方式发送给下游结点。

通过上述步骤，头结点将该头结点的算路方式发送给下游结点，下游结点使用该算路方式进行算路，相比于现有技术中采用默认的算路方式及为各个结点全局配置算路方式仍然会出现头结点和下游结点所使用了算路方式不一致，上述步骤解决了隧道头结点的算路方式与中间节点的算路方式不一致的问题，进而可以得到最优的路径，提升了用户体验。

上述步骤S504涉及到头结点将算路方式发送给下游结点，需要说明的是，头结点可以通过多种方式将算路方式发送给下游结点，下面对此进行举例说明。在一个优选实施例中，头结点将PATH报文发送给下游结点，其中，PATH报文中携带有头结点的算路方式。

在本实施例中还提供了一种算路处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图6是根据本发明实施例的算路处理装置的结构框图一，该装置应用于头结点，如图6所示，该装置包括：确定模块62，用于确定头结点的算路方式，其中，算路方式为下游结点进行算路所使用的算路方式；发送模块64，用于将算路方式发送给下游结点。

针对相关技术中存在的问题，下面结合优选实施例进行说明，该优选实施例结合了上述实施例及其优选实施方式。

本优选实施例中定义了一套机制，用报文对象传递隧道头结点要求的Metric算路方式，使得下游各个节点知道头结点的策略要求，如果中间节点需要再次算路，需要解析出报文的对象内容，执行头结点的关于Metric算路方式的策略要求。

将头结点关于隧道Metric算路方式，在PATH报文中传递给下游。

在PATH报文中，可以新增对象，也可以在已有对象中，对于一些保留位或者未使用的字段进行标注，用作头结点算路方式的意义。

本优选实施例选取SESSION_ATTRIBUTE对象的FLAG字段，SESSION_ATTRIBUTE对象格式如图7所示。FLAG字段占8bit，目前已定义了其中的7个bit，利用第8个bit位，用来表示Metirc算路的方式。

其中0表示IGP Metric方式，1表示TE Metric方式。

下面结合附图对本优选实施例进行详细说明。

本优选实施例中，当隧道头结点确定某条隧道需要的Metric算路方式时，通过RSVP-TE信令PATH报文沿途传递到下游各个节点，各个节点(非头结点)接收到了头结点要求的Metric算路方式，在执行算路的时候，需要采用报文中携带的Metric算路方式。

实施例一

本优选实施例一提供了一种隧道Metric算路约束的通知方法，图8是根据本发明优选实施例的隧道Metric算路约束的通知方法流程图，如图8所示，该方法包括如下步骤：

步骤802，当头结点确定某条隧道的Metric算路方式策略时，需要向RSVP-TE的PATH报文中写入此策略信息。

具体的，所述写入的信息，可以是新增的对象，也可以是已有对象的保留位或者未占用位；例如，可以采用SESSION_ATTRIBUTE对象中的FLAG中尚未使用的一个BIT位。

步骤S804，将携带的Metirc约束信息的PATH报文发送下游各个节点。

实施例二

本优选实施例二提供了一种隧道中间节点算路的方法，图9是根据本发明优选实施例的隧道中间节点算路的方法流程图，如图9所示，该方法包括以下步骤：

步骤S902，中间节点接收到上游的PATH消息，解析上游Metirc约束算路的方式信息。

具体的由上游携带的对象来决定解析内容，可以是新增的对象，也可以是已有对象的保留位或者未占用位，本发明使用的SESSION_ATTRIBUTE对象FLAG字段，接收PATH消息，解析该字段的FLAG第八位。

步骤S904，根据解析出来的Metric约束算路方式，判断本节点是否需要算路，如果需要算路通过解析出来的Metric算路方式进行算路。

步骤S906，向下游发送PATH消息，保持原有的Metric约束算路方式信息传递给下游。

下面通过两个具体的实施例，对本优选实施例提供的RSVP-TE算路方法进行详细的介绍：

示例一

如图2所示，以R1作为头结点，R3作为尾节点的隧道。由于头结点和尾节点位于不同的域，所以R1算路的时候只能算路至域的边界，R2或者R4，假设算路至R2，头结点的隧道Metric约束算路方式是TE Metric方式。

那么，R1至R2的最优路径为R1→R4→R2，算路结束之后，发往R4的PATH报文在SESSION_ATTRIBUTE中的Flag字段0x80位上置1，表示算路方式为TE Metric约束算路方式。

R4接收到该PATH报文，因为路径已经算至R2了，所以不需要再次算路，R4将该携带TE Metric约束算路方式信息的PATH报文传递给R2。

R2接收到PATH报文，由于没有后续的路径，需要再次算路至隧道尾节点。提取PATH报文中由隧道头结点携带的Metric约束算路方式为TE Metric方式，以该方式进行算路，算路的结果为R2→R3。

R2向R3发送的PATH消息同样携带Metric约束算路信息。R3接收到该报文，由于是尾节点，终止PATH消息的信令。

实例二

如图1所示，隧道头结点R1和隧道尾节点R3在同一个域中，由R1直接算路到尾节点R3，如果头结点算路方式为TE Metric，那么算出的路径为R1→R4→R3。

同理，R1向R4、R4向R3发送的PATH消息需要携带TE Metric算路的信息。只是由于中间节点不需要算路，这些信息只是一直透传给下游。

综上所述，通过本优选实施例提出一种新的机制，以RSVP-TE信令传递的方式，将一条隧道下要求的Metric算路约束传递到下游各个节点，使得隧道的下游节点清楚头结点对于Metric算路的约束方式，下游各个节点如果需要算路，那么可以解析报文中的Metric算路信息得到需要的算路方式，从而得到一条满足用户要求的最优的路径。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种算路处理方法，其特征在于，包括：

下游结点接收来自头结点的所述头结点的算路方式；

所述下游结点使用所述算路方式进行算路；

其中，所述算路方式包括：内部网关协议链路代价IGP Metric、流量工程链路代价TEMetric；

其中，所述下游结点接收来自所述头结点的算路方式包括：所述下游结点接收来自所述头结点的PATH报文；从所述PATH报文中获取所述头结点的算路方式；

所述算路方式通过以下之一方式携带于所述PATH报文中：在所述PATH报文中的新增字段添加所述算路方式、在所述PATH报文中的未使用的字段添加所述算路方式。

2.根据权利要求1所述的方法，其特征在于，在所述PATH报文中的未使用的字段添加所述算路方式包括：

在SESSION_ATTRIBUTE对象的标志字段FLAG字段中添加所述算路方式。

3.一种算路处理方法，其特征在于，包括：

头结点确定所述头结点的算路方式，其中，所述算路方式为下游结点进行算路所使用的算路方式；

所述头结点将所述算路方式发送给所述下游结点；

其中，所述算路方式包括：内部网关协议链路代价IGP Metric、流量工程链路代价TEMetric；

所述头结点将所述头结点的算路方式发送给所述下游结点包括：所述头结点将PATH报文发送给所述下游结点，其中，所述PATH报文中携带有所述头结点的算路方式；

所述算路方式通过以下之一方式携带于所述PATH报文中：在所述PATH报文中的新增字段添加所述算路方式、在所述PATH报文中的未使用的字段添加所述算路方式。

4.一种算路处理装置，该装置应用于下游结点，其特征在于，包括：

接收模块，用于接收来自头结点的所述头结点的算路方式；

算路模块，用于使用所述算路方式进行算路；

其中，所述算路方式包括：内部网关协议链路代价IGP Metric、流量工程链路代价TEMetric；

其中，所述接收模块还用于接收来自所述头结点的PATH报文；从所述PATH报文中获取所述头结点的算路方式；

所述算路方式通过以下之一方式携带于所述PATH报文中：在所述PATH报文中的新增字段添加所述算路方式、在所述PATH报文中的未使用的字段添加所述算路方式。

5.一种算路处理装置，该装置应用于头结点，其特征在于，包括：

确定模块，用于确定所述头结点的算路方式，其中，所述算路方式为下游结点进行算路所使用的算路方式；

发送模块，用于将所述算路方式发送给所述下游结点；

其中，所述算路方式包括：内部网关协议链路代价IGP Metric、流量工程链路代价TEMetric；

所述头结点通过以下方式将所述头结点的算路方式发送给所述下游结点：所述头结点将PATH报文发送给所述下游结点，其中，所述PATH报文中携带有所述头结点的算路方式；

所述算路方式通过以下之一方式携带于所述PATH报文中：在所述PATH报文中的新增字段添加所述算路方式、在所述PATH报文中的未使用的字段添加所述算路方式。