WO2016061967A1

WO2016061967A1 - Path computation processing method and device

Info

Publication number: WO2016061967A1
Application number: PCT/CN2015/073276
Authority: WO
Inventors: 付志涛
Original assignee: 中兴通讯股份有限公司
Priority date: 2014-10-21
Filing date: 2015-02-25
Publication date: 2016-04-28
Also published as: CN105591905B; CN105591905A

Abstract

The present invention provides a path computation processing method and device, the method comprising: a downstream node receives a path computation means from a head node; the downstream node uses the path computation means to compute a path. The present invention solves the problem in the prior art of the path computation means of a tunnel head node being inconsistent with the path computation means of an intermediate node; thus an optimal path may be obtained, improving user experience.

Description

Calculation method and device

Technical field

The present invention relates to the field of communications, and in particular to a method and apparatus for calculating a road.

Background technique

A Multi-Protocol Label Switching (MPLS) network is used to establish a tunnel by using the Resource Resire Protocol (RSVP-TE). Generally speaking, there are two kinds of constraints on the link cost metric when establishing a tunnel. One is the Interior Gateway Protocol Metric (IGP Metric), and the other is the traffic engineering link cost (Traffic). Engineering Metric, referred to as TE Metric).

As shown in Figure 1, the four-node topology of R1, R2, R3, and R4, the IGP Metric and TE Metric of each link in the figure are marked with corresponding values, and a tunnel is established from R1 to R3. If we select IGP Metric Mode constraint, then the path of the calculation result is L12, L23, that is, R1→R2→R3, because the total IGMMetric value of this path is the smallest of all reachable paths; if the TE Metric mode constraint is selected, then the calculation The path of the path is L14, L34, that is, R1→R4→R3, because the total TE Metric value of this path is the smallest of all reachable paths.

In actual applications, when a tunnel is deployed, there are application scenarios such as cross-domains. When calculating the road, you cannot directly calculate the way from the head node to the tail node. You may need to calculate the path again through the intermediate node. As shown in Figure 2, in the two domains of AREA0 and AREA1, the same R1 tunnel is established to R3. Since the source address and the destination address are not in one domain, the head node R1 can only calculate the boundary R2 or R4 of the domain. Calculate the path from R2 or R4 to R3 again. If the road is calculated again on R2 or R4, the metric constraint of the calculation should be consistent with the way of the head node calculation to ensure that the metric constraint of the entire tunnel conforms to the strategy of the tunnel head node. At present, this constraint does not have a clear signaling mechanism, and it is passed from the head node to the downstream.

At present, there are several solutions to the above problems:

The first type: the intermediate node calculates the way. If you don't know the metric constraint mode of the tunnel head node, you can use the default calculation method. The disadvantage of this scheme is that it may cause a tunnel head node metric constraint mode to be inconsistent with the intermediate node metric constraint mode.

The second type is that the global metrics are configured globally. If the node configured with the global metrics is a head node for a tunnel and the metric is not configured for the tunnel, the global configuration takes precedence. If the metric is configured in the tunnel, the configuration under the tunnel takes effect. If the node configured with the global metric method is an intermediate node for a tunnel and needs to calculate the path, the calculation mode is based on the global configuration. This solution also causes the tunnel head node metric constraint mode to be inconsistent with the intermediate node metric constraint mode.

For the related art, the problem that the tunnel head node metric constraint mode is inconsistent with the intermediate node metric constraint mode has not yet proposed an effective solution.

Summary of the invention

The invention provides a method and a device for processing a road to solve at least the problem that the tunnel head node metric constraint mode and the intermediate node metric constraint mode are inconsistent in the prior art.

According to an embodiment of the present invention, a method for processing a path is provided, including: a downstream node receives a method of calculating the head node from a head node; and the downstream node uses the method of calculating the path Count the road.

Preferably, the method for receiving the downlink node from the head node includes: the downstream node receiving a PATH message from the head node; and obtaining the head node from the PATH message The way to calculate the point.

Preferably, the computing mode is carried in the PATH packet by using one of the following manners: adding the computing mode to the newly added field in the PATH packet, and not using the PATH packet. The field adds the way to calculate.

Preferably, adding the calculation manner to an unused field in the PATH message includes: adding the calculation manner in a FLAG field of a SESSION_ATTRIBUTE object.

Preferably, the computing manner includes: an internal gateway protocol link cost IGP metric, and a traffic engineering link cost TE Metric.

According to an embodiment of the present invention, another method of calculating a path is provided, including: determining, by a head node, a way of calculating the head node, wherein the calculating method is used for calculating a downstream node. The way of calculating the path; the head node sends the way of calculating to the downstream node.

Preferably, the sending, by the head node, the way of calculating the head node to the downstream node comprises: sending, by the head node, a PATH message to the downstream node, where the PATH report The text carries the way of calculating the head node.

According to an embodiment of the present invention, a circuit processing apparatus is provided, the apparatus being applied to a downstream node, comprising: a receiving module configured to receive a method of calculating the head node from the head node; The module is set to use the calculation method to perform the calculation.

Preferably, the receiving module is further configured to receive a PATH message from the head node, and obtain a path manner of the head node from the PATH message.

According to an embodiment of the present invention, there is further provided another method of processing a circuit, the device being applied to a head node, comprising: a determining module, configured to determine a way of calculating the head node, wherein the calculating The way of the way is the way of calculating the way for the downstream node to calculate the path; the sending module is configured to send the way of calculating the way to the downstream node.

Through the invention, the downstream node is used to receive the calculation method from the head node; the downstream node uses the calculation method to perform the calculation. The problem that the calculation method of the tunnel head node in the prior art is inconsistent with the calculation method of the intermediate node is solved, and the optimal path can be obtained, thereby improving the user experience.

DRAWINGS

The drawings described herein are intended to provide a further understanding of the invention, and are intended to be a part of the invention. In the drawing:

1 is a schematic diagram of a four-node Metric calculation circuit according to an embodiment of the present invention;

2 is a schematic diagram of a cross-domain four-node according to an embodiment of the present invention;

3 is a flow chart of a method of processing a road according to an embodiment of the present invention;

4 is a block diagram showing the structure of a road processing device according to an embodiment of the present invention;

FIG. 5 is a flowchart 1 of a method for processing a road according to an embodiment of the present invention; FIG.

6 is a block diagram 1 of a circuit processing apparatus according to an embodiment of the present invention;

7 is a format diagram of a SESSION_ATTRIBUTE object in accordance with a preferred embodiment of the present invention;

8 is a flowchart of a notification method of a tunnel metric road constraint according to a preferred embodiment of the present invention;

9 is a flow chart of a method for calculating a tunnel intermediate node in accordance with a preferred embodiment of the present invention.

detailed description

The invention will be described in detail below with reference to the drawings in conjunction with the embodiments. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict.

In this embodiment, a method for processing a road is provided. FIG. 3 is a flowchart of a method for processing a road according to an embodiment of the present invention. As shown in FIG. 3, the process includes the following steps:

Step S302, the downstream node receives the calculation method from the head node;

In step S304, the downstream node uses the calculation method to perform the calculation.

Through the above steps, the downstream node uses the received calculation method from the head node to perform the calculation. Compared with the prior art, the default calculation method is adopted, and the calculation method is globally configured for each node. The calculation method used by the node and the downstream node is inconsistent. The above steps solve the problem that the calculation method of the tunnel head node is inconsistent with the calculation method of the intermediate node, and the optimal path can be obtained, thereby improving the user experience.

The above step S302 involves the downstream node receiving the calculation method from the head node. It should be noted that the downstream node can receive the calculation method of the head node in various ways, which will be exemplified below. In a preferred embodiment, the downstream node receives the PATH message from the head node, and obtains the way of calculating the head node from the PATH message.

At the same time, the algorithm can be carried in the PATH packet in a plurality of manners. In a preferred embodiment, the algorithm can exist in a new field in the PATH packet or in an unused field in the PATH packet. .

When the way of computing exists in an unused field in the PATH message, in a preferred embodiment, the way of computing exists in the FLAG field of the SESSION_ATTRIBUTE object.

In a preferred embodiment, the head node and the downstream node are in different domains or the same domain.

Specifically, the calculation manner includes: an internal gateway protocol link cost IGP Metric, and a traffic engineering link cost TE Metric.

In the embodiment, a circuit processing device is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and has not been described again. As used below, the term "module" may implement a combination of software and/or hardware of a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.

4 is a block diagram showing the structure of a circuit processing device according to an embodiment of the present invention. The device is applied to a downstream node. As shown in FIG. 4, the device includes a receiving module 42 configured to receive the head node from the head node. The calculation method of the point; the calculation module 44 is set to use the calculation method to perform the calculation.

It should be noted that each of the foregoing modules may be implemented by software or hardware. For the latter, the foregoing may be implemented by, but not limited to, the receiving module 42 and the computing module 44 are all located in the same processor; or The receiving module 42 and the computing module 44 are respectively located in the first processor and the second processor.

Preferably, the receiving module 42 is further configured to receive a PATH message from the head node; and obtain a way of calculating the head node from the PATH message.

Another method for calculating a road is provided in this embodiment. FIG. 5 is a flowchart 1 of a method for processing a road according to an embodiment of the present invention. As shown in FIG. 5, the process includes the following steps:

Step S502, the head node determines a path calculation manner of the head node, wherein the calculation method is a calculation method used by the downstream node for calculating a road;

In step S504, the head node sends the calculation mode to the downstream node.

Through the above steps, the head node sends the calculation method of the head node to the downstream node, and the downstream node uses the calculation method to calculate the road, compared with the default calculation method in the prior art. In the node global configuration calculation method, the calculation method of the head node and the downstream node is still inconsistent. The above steps solve the problem that the calculation method of the tunnel head node is inconsistent with the calculation method of the intermediate node, and thus Get the optimal path and improve the user experience.

In the above step S504, the head node sends the calculation mode to the downstream node. It should be noted that the head node can send the calculation mode to the downstream node in various manners, which will be exemplified below. In a preferred embodiment, the head node sends the PATH message to the downstream node, where the PATH message carries the way of calculating the head node.

6 is a block diagram 1 of a circuit processing apparatus according to an embodiment of the present invention. The apparatus is applied to a head node. As shown in FIG. 6, the apparatus includes: a determining module 62 configured to determine a method of calculating a head node. , where the road The method is a calculation method used for the calculation of the downstream node; the sending module 64 is configured to send the calculation method to the downstream node.

In view of the problems in the related art, the following description will be made in conjunction with the preferred embodiments, which combine the above-described embodiments and preferred embodiments thereof.

In the preferred embodiment, a set of mechanisms is defined, and the Metric algorithm required by the tunnel head node is transmitted by the message object, so that each downstream node knows the policy requirements of the head node. If the intermediate node needs to calculate the path again, it needs to be parsed out. The object content of the message, and the policy requirements of the head node for the Metric algorithm.

The head node is referred to the tunnel Metric algorithm and passed to the downstream in the PATH message.

In the PATH message, you can add an object, or you can mark some reserved or unused fields in the existing object, which is used as the way of the head node calculation method.

The preferred embodiment selects the FLAG field of the SESSION_ATTRIBUTE object, and the format of the SESSION_ATTRIBUTE object is as shown in FIG. 7. The FLAG field occupies 8 bits. Currently, 7 bits have been defined, and the 8th bit is used to indicate the way the Subway is calculated.

0 indicates the IGP Metric mode and 1 indicates the TE Metric mode.

The preferred embodiment will be described in detail below with reference to the accompanying drawings.

In the preferred embodiment, when the tunnel head node determines the Metric calculation mode required by a certain tunnel, the RSVP-TE signaling PATH message is transmitted to each downstream node along the way, and each node (non-head node) receives the same. The Metric calculation method required by the head node needs to adopt the Metric calculation method carried in the message when performing the calculation.

Embodiment 1

The preferred embodiment 1 provides a method for notifying a tunnel metric road constraint, and FIG. 8 is a flowchart of a method for notifying a tunnel metric road constraint according to a preferred embodiment of the present invention. As shown in FIG. 8 , the method includes the following steps. :

Step 802: Determine the Metric constraint calculation mode of the head node, and write the information into the PATH message: when the head node determines the Metric calculation mode policy of a certain tunnel, it needs to write to the PATH message of the RSVP-TE. This policy information.

Specifically, the written information may be a newly added object, or may be a reserved bit or an unoccupied bit of the existing object; for example, a BIT bit that is not used in the FLAG in the SESSION_ATTRIBUTE object may be used.

Step S804, the head node sends a PATH message, and the node constraint information is transmitted by each node along the way: the PATH message of the carried Meditri constraint information is sent to each downstream node.

Embodiment 2

The preferred embodiment 2 provides a method for calculating the intermediate node of the tunnel, and FIG. 9 is a flowchart of a method for calculating the intermediate node of the tunnel according to a preferred embodiment of the present invention. As shown in FIG. 9, the method includes the following steps:

Step S902, the intermediate node receives the upstream PATH message, and parses the mode information of the upstream Metrotr constraint calculation path.

Specifically, the object that is carried by the upstream determines the parsing content, which may be a newly added object, or may be a reserved bit or an unoccupied bit of the existing object. The SLAGSION_ATTRIBUTE object FLAG field used by the present invention receives the PATH message and parses the field. FLAG eighth place.

In step S904, according to the analyzed Metric constraint calculation method, it is determined whether the node needs to calculate the path, and if the calculation path is required, the calculation is performed by the analyzed Metric calculation method.

In step S906, the metric constraint calculation path information is put into the PATH message that needs to be sent downstream: the PATH message is sent downstream, and the original metric constraint calculation path information is transmitted to the downstream.

The RSVP-TE calculation method provided by the preferred embodiment is described in detail below through two specific embodiments:

Example one

As shown in Figure 2, R1 is used as the head node and R3 is used as the tail node tunnel. Since the head node and the tail node are located in different domains, R1 can only calculate the path-to-domain boundary when calculating R2, R2 or R4, and assume the calculation path to R2. The tunnel Metric constraint calculation method of the head node is TE Metric. the way.

Then, the optimal path of R1 to R2 is R1→R4→R2. After the end of the calculation, the PATH message sent to R4 is set to 1 in the Flag field 0x80 of SESSION_ATTRIBUTE, indicating that the calculation mode is TE Metric constraint calculation. the way.

R4 receives the PATH packet, because the path has been counted to R2, so there is no need to calculate the path again. R4 passes the PATH packet carrying the TE Metric constraint algorithm information to R2.

R2 receives the PATH packet. Since there is no subsequent path, it needs to calculate the path to the tail node of the tunnel again. The Metric constraint calculation method carried in the PATH packet by the tunnel head node is TE Metric mode, and the calculation is performed in this manner, and the result of the calculation is R2→R3.

The PATH message sent by R2 to R3 also carries the metric constraint path information. R3 receives the message and terminates the signaling of the PATH message because it is a tail node.

Example two

As shown in Figure 1, the tunnel head node R1 and the tunnel tail node R3 are in the same domain, and R1 directly calculates the way to the tail node R3. If the head node calculation method is TE Metric, the calculated path is R1→ R4 → R3.

Similarly, the PATH message sent by R1 to R4 and R4 to R3 needs to carry the information of the TE Metric algorithm. Just because the intermediate nodes do not need to calculate the way, this information is only transparent to the downstream.

In summary, a new mechanism is proposed by the preferred embodiment, and the Metric calculation path constraint required under one tunnel is transmitted to each downstream node in the manner of RSVP-TE signaling transmission, so that the downstream node of the tunnel is clear. For the constraint mode of the Metric algorithm, if the downstream nodes need to calculate the path, then the Metric calculation information in the message can be parsed to obtain the required calculation mode, so as to obtain an optimal path that meets the user's requirements.

It will be apparent to those skilled in the art that the various modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, thereby Storing them in a storage device is performed by a computing device, and in some cases, the steps shown or described may be performed in an order different than that herein, or separately fabricated into individual integrated circuit modules, or Multiple of these modules or steps are fabricated as a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software.

The above description is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Industrial applicability

According to the above technical solution provided by the embodiment of the present invention, the downstream node is used to receive the calculation method from the head node; the downstream node uses the calculation method to perform the calculation. The problem that the calculation method of the tunnel head node in the prior art is inconsistent with the calculation method of the intermediate node is solved, and the optimal path can be obtained, thereby improving the user experience.

Claims

A method of processing a road, comprising:

The downstream node receives the way of calculating the head node from the head node;

The downstream node uses the calculation method to perform the calculation.
The method of claim 1 wherein said downstream node receiving a way of calculating from said head node comprises:

The downstream node receives a PATH message from the head node; and obtains a method for calculating the head node from the PATH message.
The method according to claim 2, wherein the computing mode is carried in the PATH message by one of the following methods:

Adding the calculation mode to the newly added field in the PATH message, and adding the calculation mode to an unused field in the PATH message.
The method of claim 3, wherein adding the method of calculating the unused fields in the PATH message comprises:

The calculation method is added in the flag field FLAG field of the SESSION_ATTRIBUTE object.
The method according to any one of claims 1 to 4, wherein the way of calculating comprises:

The internal gateway protocol link costs IGP Metric, traffic engineering link cost TE Metric.
A method of processing a road, comprising:

The head node determines a way of calculating the head node, wherein the calculation method is a calculation method used by the downstream node for calculating a road;

The head node sends the way of calculating to the downstream node.
The method of claim 6, wherein the sending, by the head node, the way of calculating the head node to the downstream node comprises:

The head node sends the PATH message to the downstream node, where the PATH message carries the way of calculating the head node.
A circuit processing device for a downstream node, comprising:

a receiving module configured to receive a method of calculating the head node from the head node;

The calculation module is set to use the calculation method to perform the calculation.
The apparatus according to claim 8, wherein the receiving module is further configured to receive a PATH message from the head node; and obtain a way of calculating the head node from the PATH message.
A circuit processing device for use in a head node, comprising:

a determining module, configured to determine a method for calculating the head node, wherein the calculating method is a calculating method used by the downstream node for calculating a road;

The sending module is configured to send the computing mode to the downstream node.