CN113452612A

CN113452612A - Path calculation method and device

Info

Publication number: CN113452612A
Application number: CN202110705089.1A
Authority: CN
Inventors: 邹燕喃
Original assignee: New H3C Security Technologies Co Ltd
Current assignee: New H3C Security Technologies Co Ltd
Priority date: 2021-06-24
Filing date: 2021-06-24
Publication date: 2021-09-28

Abstract

The embodiment of the application provides a path calculation method and device. The scheme is as follows: determining at least one flow transmission path between a source node and a destination node according to link information in the MPLS network; obtaining RSVP state information of each node in at least one flow transmission path; and on the basis of the RSVP state information, calculating a flow transmission path which meets a preset path constraint condition and is in an enabled state in at least one flow transmission path by using a preset path calculation algorithm, and taking the flow transmission path as a target path. By applying the technical scheme provided by the embodiment of the application, the RSVP is effectively distributed at each node in the target path determined by the path calculation, so that the normal establishment of the CRLSP tunnel is ensured, and the normal transmission of the flow in the MPLS network is ensured.

Description

Path calculation method and device

Technical Field

The present application relates to the field of internet technologies, and in particular, to a path calculation method and apparatus.

Background

In a Multiprotocol Label Switching (MPLS) network, efficient traffic transmission is realized in a Label Switching manner according to a pre-established traffic transmission path. In the related art, a preset Path calculation algorithm, such as a constrained-based Shortest Path First (CSPF) algorithm, is used to calculate a Shortest Path between a source node and a destination node that meets a preset Path Constraint condition, and the Shortest Path is used as a target Path. For example, the path with the smallest link overhead from the source node to the destination node, or the path with the largest ratio of the minimum available bandwidth from the source node to the destination node. And establishing a constrained-Routed Label Switched Path (CRLSP) tunnel based on the constrained route along the calculated target path based on the RSVP-TE protocol, and completing the construction of the traffic transmission path. The RSVP-TE Protocol is a label distribution Protocol (RSVP) that is extended to support distribution of MPLS labels.

In the path calculation process, since all nodes in the MPLS network are not configured with RSVP, the target path determined by the path calculation may include nodes not configured with RSVP.

Disclosure of Invention

An object of the embodiments of the present application is to provide a method and an apparatus for path computation, so as to ensure that each node in a target path determined by path computation is deployed with RSVP. The specific technical scheme is as follows:

the embodiment of the application provides a path calculation method, which is applied to a source node in an MPLS network, and the method comprises the following steps:

determining at least one flow transmission path between the source node and the destination node according to the link information in the MPLS network;

obtaining RSVP state information of each node in the at least one flow transmission path;

and calculating the traffic transmission path which meets the preset path constraint condition and is in an enabled state in the at least one traffic transmission path by using a preset path calculation algorithm based on the RSVP state information, and taking the traffic transmission path as a target path.

Optionally, before determining at least one traffic transmission path between the source node and the destination node according to the link information in the MPLS network, the method further includes:

receiving an RSVP state marking command triggered by a user;

sending a first routing protocol message to a neighbor node of the source node based on the RSVP state marking command, wherein the first routing protocol message carries local RSVP state information and remote RSVP state information; so that the neighbor node updates the RSVP state information in a stored first Traffic Engineering DataBase (TEDB) information list according to the first routing protocol message;

receiving a second routing protocol message sent by the neighbor node, wherein the second routing protocol message carries local RSVP state information and remote RSVP state information; updating the RSVP state information in a stored second TEDB information list according to the second routing protocol message;

the step of acquiring RSVP state information of each node in the at least one traffic transmission path includes:

reading the second TEDB information list;

and obtaining the local RSVP state information and the remote RSVP state information of each node from the second TEDB information list to obtain the RSVP state information of the node.

Optionally, the step of calculating, by using a preset path calculation algorithm based on the RSVP state information, a traffic transmission path that satisfies a preset path constraint condition and in which the RSVP state of each node is an enabled state in the at least one traffic transmission path, as a target path, includes:

for each flow transmission path, when the local RSVP state information and the remote RSVP state information of each node in the flow transmission path are both enabled states, determining that the path state of the flow transmission path is a first state;

acquiring a path to be calculated with the first state from the at least one traffic transmission path;

and calculating the traffic transmission path which meets the preset path constraint condition and is determined from the paths to be calculated by using the preset path calculation algorithm to serve as a target path.

Optionally, the method further includes:

and establishing a CRLSP tunnel based on the constraint route along the target path based on the RSVP-TE protocol.

Optionally, the method further includes:

after the CRLSP tunnel is established, a path state refreshing message is sent to the next node on the target path according to a preset time interval;

and receiving a resource reservation state refreshing message sent by the next node according to the preset time interval.

Optionally, the method further includes:

after the target path is monitored to be removed, updating the path state of the target path to a second state; the second state is different from the first state; the target path is removed when a first node in the target path does not receive a path state refreshing message sent by a previous node or a resource reservation state refreshing message sent by a next node within a preset time length;

and recalculating the target path between the source node and the destination node.

Optionally, the method further includes:

after the CRLSP tunnel is established, if a link state updating message sent by a second node in the target path is received, updating the RSVP state information of the second node in a stored second TEDB information list to be in an disabled state according to the link state updating message; the link state update state message is sent when the RSVP deployed by the second node is deleted;

The embodiment of the present application further provides a path computation apparatus, which is applied to a source node in an MPLS network, and the apparatus includes:

a determining module, configured to determine at least one traffic transmission path between the source node and the destination node according to link information in the MPLS network;

an obtaining module, configured to obtain RSVP state information of each node in the at least one traffic transmission path;

and the first calculation module is used for calculating the traffic transmission path which meets the preset path constraint condition and is in an enabling state in each node in the at least one traffic transmission path as a target path by utilizing a preset path calculation algorithm based on the RSVP state information.

Optionally, the apparatus further comprises:

a first receiving module, configured to receive an RSVP state marking command triggered by a user before determining at least one traffic transmission path between the source node and the destination node according to link information in the MPLS network;

a first sending module, configured to send a first routing protocol packet to a neighboring node of the source node based on the RSVP state marking command, where the first routing protocol packet carries local RSVP state information and remote RSVP state information; enabling the neighbor node to update the RSVP state information in the stored first TEDB information list according to the first routing protocol message;

a second receiving module, configured to receive a second routing protocol packet sent by the neighboring node, where the second routing protocol packet carries local RSVP state information and remote RSVP state information; updating the RSVP state information in a stored second TEDB information list according to the second routing protocol message;

the acquisition module is specifically configured to read the second TEDB information list; and obtaining the local RSVP state information and the remote RSVP state information of each node from the second TEDB information list to obtain the RSVP state information of the node.

Optionally, the first calculation module is specifically configured to, for each traffic transmission path, determine that a path state of the traffic transmission path is a first state when local RSVP state information and remote RSVP state information of each node in the traffic transmission path are both enabled states;

Optionally, the apparatus further comprises:

and the construction module is used for establishing the CRLSP tunnel based on the constraint route along the target path based on the RSVP-TE protocol.

Optionally, the apparatus further comprises:

a second sending module, configured to send a path state refresh message to a next node on the target path according to a preset time interval after the CRLSP tunnel is established;

and a third receiving module, configured to receive a resource reservation status refresh message sent by the next node according to the preset time interval.

Optionally, the apparatus further comprises:

the first updating module is used for updating the path state of the target path to a second state after the situation that the target path is removed is monitored; the second state is different from the first state; the target path is removed when a first node in the target path does not receive a path state refreshing message sent by a previous node or a resource reservation state refreshing message sent by a next node within a preset time length;

and the second calculation module is used for recalculating the target path between the source node and the destination node.

Optionally, the apparatus further comprises:

a second updating module, configured to, after the CRLSP tunnel is established, update, according to a link state update packet sent by a second node in the target path, RSVP state information of the second node in a stored second TEDB information list to an disabled state if the link state update packet is received; the link state update state message is sent when the RSVP deployed by the second node is deleted;

and the third calculation module is used for recalculating the target path between the source node and the destination node.

Embodiments of the present application further provide a source node, including a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being caused by the machine-executable instructions to: implementing any of the above-described path computation method steps.

Embodiments of the present application further provide a machine-readable storage medium storing machine-executable instructions executable by the processor, the processor being caused by the machine-executable instructions to: implementing any of the above-described path computation method steps.

In the technical solution provided in the embodiment of the present application, after a source node determines at least one traffic transmission path from the source node to a destination node, by obtaining RSVP state information of each node in the determined at least one traffic transmission path, when performing path calculation using a preset path calculation algorithm, it is ensured that RSVP states of each node in a target path are enabled while ensuring that a selected target path meets preset path constraint conditions in the related art, which effectively ensures that each node in the target path determined by the path calculation is deployed with RSVP, thereby ensuring normal establishment of a CRLSP tunnel and ensuring normal transmission of traffic in an MPLS network.

Of course, it is not necessary for any product or method of the present application to achieve all of the above-described advantages at the same time.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a schematic diagram of an architecture of an MPLS network;

fig. 2 is a first flowchart of a path calculation method according to an embodiment of the present application;

fig. 3 is a second flowchart of a path calculation method according to an embodiment of the present application;

fig. 4 is a third schematic flow chart of a path calculation method according to an embodiment of the present application;

fig. 5 is a schematic flowchart of a path establishment method according to an embodiment of the present application;

fig. 6 is a fourth flowchart illustrating a path calculation method according to an embodiment of the present application;

fig. 7 is a fifth flowchart illustrating a path calculation method according to an embodiment of the present application;

fig. 8 is a sixth flowchart illustrating a path calculation method according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a path computation apparatus according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a source node according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

In the related art, in the process of constructing the traffic transmission path, the source node may calculate, according to the link information in the MPLS network, a shortest path (i.e., a target path) between the tunnel from the source node to the destination node, which meets the preset path constraint condition, by using a CSPF algorithm, thereby establishing the CRLSP tunnel along the calculated target path by using an RSVP-TE protocol.

For ease of understanding, the description will be made with reference to fig. 1 as an example. Fig. 1 is a schematic diagram of an MPLS network. In the MPLS network shown in fig. 1, the source node is node 1 and the destination node is node 4. Now, assuming that the path constraint condition is a preset bandwidth value, a traffic transmission path conforming to the preset bandwidth value needs to be established between the node 1 and the node 4, and the traffic transmission path is used as a target path for transmitting traffic from the node 1 to the node 4.

In the MPLS network shown in fig. 1, there are 3 traffic transmission paths from node 1 to node 4, i.e., path 1: node 1-node 2-node 3-node 4; route 2: node 1-node 2-node 6-node 4; and path 3: node 1-node 5-node 3-node 4.

For the 3 traffic transmission paths, i.e., path 1 to path 3, node 1 may determine, as the target path, the shortest traffic transmission path having a bandwidth greater than or equal to the preset bandwidth value in path 1, path 2, and path 3 by using the CSPF algorithm. For example, path 1 is determined as the target path by the CSPF algorithm.

Since all nodes in the MPLS network may not be configured with RSVP, the target path determined by performing path calculation through the related art may include nodes not configured with RSVP, which may result in that the source node cannot establish a CRLSP tunnel using an RSVP-TE protocol, thereby affecting the construction of a traffic transmission path and the transmission of traffic in the MPLS network.

For example, when the target path determined by the path calculation is the path 1, if the node 3 in the path 1 does not deploy RSVP, at this time, the CRLSP tunnel on the path 1 cannot be established, that is, the path 1 cannot be successfully constructed, and the traffic cannot be transmitted from the node 1 to the node 4 along the path 1.

In this embodiment of the present application, the node not deployed with RSVP is specifically represented as: the link interface of the node is not deployed with RSVP. I.e. the link interface of the node is RSVP-free.

In order to solve the problems in the related art, embodiments of the present application provide a path calculation method. The method is applied to a source node in the MPLS network. The source node may be a network device such as a router, and the source node in the MPLS network is not particularly limited. As shown in fig. 2, fig. 2 is a first flowchart of a path calculation method according to an embodiment of the present application. The method specifically comprises the following steps.

Step S201, determining at least one traffic transmission path between the source node and the destination node according to the link information in the MPLS network.

Step S202, RSVP state information of each node in at least one traffic transmission path is obtained.

Step S203, based on the RSVP state information, using a preset path calculation algorithm to calculate a traffic transmission path that satisfies a preset path constraint condition and that the RSVP state of each node is an enabled state in at least one traffic transmission path, as a target path.

In this embodiment, the MPLS network includes a plurality of network devices (i.e., nodes). According to the difference between the sending end and the receiving end corresponding to each flow in the flow transmission process, the source node and the destination node of the flow transmission path corresponding to each flow are also different. Therefore, the source node in the MPLS network may be any node in the MPLS network. Here, the number of nodes included in the MPLS network is not particularly limited, and a node as a source node in the MPLS network is not particularly limited.

The traffic is transmitted in the form of packets or messages in the MPLS network, and is not specifically described herein.

Through the method shown in fig. 2, after the source node determines at least one traffic transmission path from the source node to the destination node, by acquiring RSVP state information of each node in the determined at least one traffic transmission path, when performing path calculation using a preset path calculation algorithm, it is ensured that RSVP states of each node in the target path are enabled while the selected target path meets preset path constraint conditions in the related art, which effectively ensures that each node in the target path determined by the path calculation is deployed with RSVP, thereby ensuring normal establishment of a CRLSP tunnel and ensuring normal transmission of traffic in the MPLS network.

The following examples are given to illustrate the examples of the present application.

In step S201, at least one traffic transmission path between the source node and the destination node is determined according to the link information in the MPLS network.

In this step, for each node in the MPLS network, a TEDB information list is stored in the node. The TEDB information list includes link information of each node in the MPLS network. E.g., neighbor nodes for each node, bandwidth resources, next hop, etc. The source node may determine all traffic transmission paths between the source node and the destination node according to link information of each node in a stored TEDB information list (for convenience of distinction, the TEDB information list stored in the source node is recorded as a second TEDB information list). I.e. all traffic transmission paths over which traffic is transmitted from the source node to the destination node.

In the embodiment of the application, each node in the MPLS network realizes synchronization of the TEDB information lists with each other through a routing protocol packet between the node and a neighboring node. Therefore, the information in the TEDB information list stored by each node in the MPLS network described above is the same. For synchronization between the stored TEDB information lists of each node in the MPLS network, reference may be made to the following description, which is not specifically described herein.

The TEDB information list may further include, in addition to the link information, other information, for example, information such as an area to which the node belongs, a gateway protocol inside the node, a maximum bandwidth available for the link, a reserved bandwidth of the link, and link overhead. Here, the information included in the TEDB information list is not particularly limited.

In this embodiment, the number of all traffic transmission paths between the source node and the destination node is at least one. That is, at least one traffic transmission path exists between the source node and the destination node. For example, at least one traffic transmission path between the source node (i.e., node 1) and the destination node (i.e., node 4) in the MPLS network shown in fig. 1 is the path 1, the path 2, and the path 3. Here, the number of traffic transmission paths between the source node and the destination node is not particularly limited.

In this step, the TEDB information list stored in each node in the MPLS network may further include RSVP state information of each node in the MPLS network. That is, the source node stores a second TEDB information list including RSVP state information of each node in the MPLS network. After determining each traffic transmission path between the source node and the destination node, the source node may determine RSVP state information of each node in the traffic transmission path from the second TEDB information list stored in the source node.

The RSVP state information of each node in the TEDB information list may be stored in the TEDB information list according to the current RSVP state after each node receives an RSVP state marking command triggered by a user. For the storage of RSVP state information of each node in the TEDB information list, reference may be made to the following description, which is not specifically described herein.

In the embodiment of the present application, the RSVP state information of each node in the TEDB information list includes local RSVP state information and remote RSVP state information. The Local RSVP state information may be determined according to a Local RSVP state data field (Local RSVP state Sub-TLV) in the routing protocol message, and the Remote RSVP state information may be determined according to a Remote RSVP state data field (Remote RSVP state Sub-TLV) in the routing protocol message. Reference is made specifically to the description below, which is not specifically made herein.

The values of the local RSVP state information and the remote RSVP state information may be a first preset value or a second preset value.

For ease of understanding, the local RSVP state information of node a is taken as an example for explanation. Indicating the RSVP state of node a as an enabled (enable) state when the value of the local RSVP state message is a first preset value, e.g., 0x 1. I.e. the link interface of node a is deployed with RSVP. Indicating the RSVP state of node a as an disabled state when the value of the local RSVP state message is a second preset value, such as 0x 0. I.e., the link interface of node a is not deployed with RSVP. Here, the numerical value of the first preset numerical value is not particularly limited, and the numerical value of the second preset numerical value is not particularly limited.

In this step, the source node may calculate, according to the obtained RSVP state information of each node, a traffic transmission path that satisfies a preset path constraint condition and in which the RSVP state of each node is an enabled state in the at least one traffic transmission path determined in step S201 by using a preset path calculation algorithm, as the target path. That is, in the traffic transmission process, traffic is transmitted from the source node to the destination node.

In an optional embodiment, according to the method shown in fig. 2, an embodiment of the present application further provides a path calculation method. As shown in fig. 3, fig. 3 is a second flowchart of the path calculation method according to the embodiment of the present application. Specifically, the above step S203 is reduced to the following step. Namely step S2031 to step S2033.

Step S2031, for each traffic transmission path, when the local RSVP state information and the remote RSVP state information of each node in the traffic transmission path are both enabled, determining that the path state of the traffic transmission path is the first state.

In this embodiment of the present application, after the source node acquires the RSVP state information of each node on at least one traffic transmission path through step S202, that is, after acquiring the local RSVP state information and the remote RSVP state information of each node, the source node may mark the path state of each traffic transmission path according to the local RSVP state information and the remote RSVP state information of all nodes on each traffic transmission path.

The RSVP state information of each node on each traffic transmission path includes at least the following two cases.

In a case of the first condition, the numerical values corresponding to the local RSVP state information and the remote RSVP state information of each node on the traffic transmission path are the first preset numerical values. That is, there is no node whose value of local RSVP state information is the second preset value on the traffic transmission path, or whose value of remote RSVP state information is the second preset value. At this time, RSVP is deployed on the link interface of each node on the traffic transmission path, and RSVP states deployed on the link interface of each node are all enabled states.

In case two, the value of the local RSVP state information of one or more nodes on the traffic transmission path is the second preset value, and the value of the remote RSVP state information of one or more nodes is the node of the second preset value. At this time, there exists a RSVP non-enabled node on the traffic transmission path (i.e., the RSVP non-enabled node is a node whose value of the local RSVP state information is the second predetermined value).

In the embodiment of the application, after the nodes in the MPLS network enable the RSVP globally, the link interface of each node can enable the RSVP. That is, the nodes in the MPLS network do not globally enable RSVP, nor will the link interface of each node enable RSVP. Therefore, the node not enabling RSVP may be specifically expressed as: the link interfaces of the nodes do not deploy RSVP, or the nodes do not globally deploy RSVP.

In the embodiment of the present application, if the RSVP state of the link interface of each node on a certain traffic transmission path is an enabled state, the path state of the traffic transmission path is a ready (ready) state, which is denoted as a first state. Therefore, when the above-described case one occurs, the source node can identify the path state of the traffic transmission path as the first state.

In this embodiment of the present application, if there is a node whose RSVP state is in an disabled state on a traffic transmission path, the path state of the traffic transmission path is in an unprepared (ready) state, and is marked as a second state. Therefore, when the above-described second condition occurs, the source node may identify the path state of the traffic transmission path as the second state.

In this embodiment, for each of the at least one traffic transmission path determined in step S201, according to a difference between each node included in the traffic transmission path and a difference between RSVP state information of each node, when the number of the determined traffic transmission paths is multiple, the at least one traffic transmission path may include a traffic transmission path whose path state is in the first state, and may also include a traffic transmission path whose path state is in the second state. Here, the path state of each of the at least one traffic transmission path is not particularly limited.

In view of the second situation, when the value of the local RSVP state information of a certain node on a certain traffic transmission path is the second preset value, at this time, the value of the remote RSVP state information of the neighboring node of the node on the traffic transmission path is the second preset value.

For ease of understanding, the path 1 shown in fig. 1 is described as an example. If the value of the local RSVP state information of node 2 is 0x 0. At this time, the remote RSVP state information in node 1 and node 3 has a value of 0x 0.

By marking the determined path state of each traffic transmission path in step S2031, the source node can accurately determine the traffic transmission path whose path state is the first state, that is, the source node can accurately determine the traffic transmission path whose RSVP state of each node is the enabled state. Therefore, the later-stage source node can directly obtain the path to be calculated according to the determined path state of each flow transmission path.

Step S2032, a path to be calculated having a first state is acquired from at least one traffic transmission path.

In this step, after determining the path state of each of the at least one traffic transmission path, the source node may obtain a path to be calculated from the at least one traffic transmission path according to the path state of each of the traffic transmission paths.

In an optional embodiment, the source node may obtain, according to the path state of the at least one traffic transmission path, all traffic transmission paths whose path states are the first state from the at least one traffic transmission path, as paths to be calculated.

In another optional embodiment, the source node may perform pruning processing on the determined at least one traffic transmission path according to the path state of the at least one traffic transmission path, and determine the remaining traffic transmission paths as paths to be calculated. That is, the traffic transmission path with the path state of the second state is removed from the determined at least one traffic transmission path, and the traffic transmission path with the path state of the first state is retained.

Step S2033, calculating a traffic transmission path which meets the constraint condition of the preset path and is determined from the paths to be calculated by using a preset path calculation algorithm, and using the traffic transmission path as a target path.

In this step, the source node may calculate, by using a preset path calculation algorithm, whether each traffic transmission path in the paths to be calculated obtained in step S2032 satisfies a preset path constraint condition, so as to determine the traffic transmission path satisfying the preset path constraint condition as the target path.

The preset path calculation algorithm may be a CSPF algorithm. The preset path constraint condition may be determined according to information such as bandwidth, link overhead (i.e., IGP COST), and the like.

For example, the preset path constraint condition is that the link cost is the minimum, and the target path satisfying the preset path constraint condition may be a traffic transmission path with the minimum link cost in the path to be calculated.

For another example, the preset path constraint condition may be that the minimum available bandwidth ratio between nodes is the maximum, and the target path satisfying the preset path constraint condition may be a transmission path having the maximum minimum available bandwidth ratio between nodes in the path to be calculated.

In an optional embodiment, the number of traffic transmission paths that satisfy the preset path constraint condition in the paths to be calculated may be multiple. At this time, the source node may determine a shortest traffic transmission path among a plurality of traffic transmission paths satisfying a preset path constraint condition as the target path.

Through the steps S2031 to S2033, the source node can accurately determine the traffic transmission path in which the RSVP state of each node is enabled, that is, the path to be calculated, according to the determined path state of each traffic transmission path, thereby avoiding the occurrence of a node phenomenon in which the RSVP is not enabled in the traffic transmission path involved in the path calculation, ensuring that each node in the traffic transmission path involved in the path calculation enables the RSVP, ensuring the establishment of the CRLSP tunnel in the target path, and ensuring the transmission of traffic in the MPLS network.

In an optional embodiment, according to the method shown in fig. 2, an embodiment of the present application further provides a path calculation method. As shown in fig. 4, fig. 4 is a third schematic flow chart of the path calculation method according to the embodiment of the present application. The method comprises the following steps.

Step S401, receiving RSVP state marking command triggered by user.

In this step, before constructing the path of the MPLS network, the user may trigger RSVP state marking operation on each node in the MPLS network, and at this time, each node in the MPLS network receives an RSVP state marking command triggered by the user. I.e. the source node will also receive a user triggered RSVP state marking command.

Step S402, based on RSVP state marking command, sending first routing protocol message to neighbor node of source node, wherein the first routing protocol message carries local RSVP state information and remote RSVP state information; and enabling the neighbor node to update the RSVP state information in the stored first TEDB information list according to the first routing protocol message.

In this step, after receiving the RSVP state flag command, the source node may send a first routing protocol packet to its neighboring node. The first routing protocol message comprises the local RSVP state information and the remote RSVP state information. After receiving the first routing protocol message sent by the source node, the neighbor node of the source node may update RSVP state information in a stored TEDB information list (for convenience of distinguishing, the TEDB information list stored by the neighbor node of the source node is recorded as the first TEDB information list) according to local RSVP state information and remote RSVP state information included in the first routing protocol message.

In an optional embodiment, the Link Type, Length, and Value (Link Type Length Value, Link TLV) of the first routing protocol may include two additional Sub-TLV (Sub-TLV) data fields, that is, the local RSVP state information and the remote RSVP state information.

For example, two Sub-TLV data fields may be represented as:

Type	Length	Value
			Local RSVP Status Sub-TLV	4 bytes (bytes)	0x0 or 0x1

And

Type	Length	Value
			Remote RSVP Status Sub-TLV	4bytes	0x0 or 0x1

Step S403, receiving a second routing protocol message sent by the neighbor node, and local RSVP state information and remote RSVP state information carried by the second routing protocol message; and updating the RSVP state information in the stored second TEDB information list according to the second routing protocol message.

In this step, when the user triggers the RSVP state marking operation, each network device in the MPLS network may receive the RSVP state marking command. That is, the neighboring nodes of the source node may also receive the RSVP state mark command described above. At this time, the neighboring node of the source node sends a second routing protocol packet carrying local RSVP state information and remote RSVP state information to its corresponding neighboring node (including the source node) based on the RSVP state marking command. After receiving the second routing protocol message, the source node updates the RSVP state information in the second TEDB information list stored by the source node according to the local RSVP state information and the remote RSVP state information included in the second routing protocol message.

The above steps S401 to S403 are only described by taking the transmission of the routing protocol packet between the source node and the neighboring node of the source node as an example. In addition, each node in the MPLS network performs sending of a routing protocol packet and updating of RSVP state information in the TEDB information list according to the steps shown in the above steps S402 and S403, so that the RSVP state information in the TEDB information list updated by each node in the MPLS network is unified, and the source node can obtain the RSVP state information of each node in each traffic transmission path directly from the second TEDB information list stored in the source node while obtaining the RSVP state information of each node in each traffic transmission path.

Through the steps S401 to S403, RSVP state information in the TEDB information list of each node in the MPLS network can be unified, which is convenient for the source node to obtain RSVP state information of each node in each traffic transmission path in the path calculation at the later stage, so as to ensure that the RSVP state of each node in the target path determined by the path calculation is an enabled state, thereby improving the accuracy of the determined target path, and further ensuring the feasibility of establishing a CRLSP tunnel based on the target path and the availability of the established traffic transmission path.

In the embodiment of the present application, the execution sequence of the above steps S402 and S403 is not particularly limited.

Step S404, determining at least one flow transmission path between the source node and the destination node according to the link information in the MPLS network.

Step S404 is the same as step S201.

Step S405, RSVP state information of each node in at least one traffic transmission path is acquired.

In an optional embodiment, the step S405, that is, the step of acquiring RSVP state information of each node in at least one traffic transmission path, may specifically be represented as:

reading a second TEDB information list; and obtaining the local RSVP state information and the remote RSVP state information of each node from the second TEDB information list to obtain the RSVP state information of the node.

In the embodiment of the application, the source node can accurately determine the RSVP state information of each node in each traffic transmission path according to the local RSVP state information and the remote RSVP state information of each node included in the second TEDB information list, thereby ensuring the accuracy and convenience of the determined RSVP state information of each node.

Step S406, based on the RSVP state information, a traffic transmission path that satisfies a predetermined path constraint condition and has an RSVP state of each node in an enabled state is calculated as a target path by using a predetermined path calculation algorithm.

Step S406 is the same as step S203.

Based on the same inventive concept, according to the path calculation method provided by the embodiment of the present application, the embodiment of the present application further provides a path establishment method. As shown in fig. 5, fig. 5 is a schematic flow chart of a path establishment method according to an embodiment of the present application. The method specifically comprises the following steps.

Step S501, according to the link information in the MPLS network, at least one flow transmission path between the source node and the destination node is determined.

Step S502, RSVP state information of each node in at least one traffic transmission path is obtained.

Step S503, based on the RSVP state information, using a preset path calculation algorithm to calculate a traffic transmission path which satisfies a preset path constraint condition and in which the RSVP state of each node is an enabled state, as a target path.

The above steps S501 to S503 are the same as the above steps S201 to S203.

Step S504, based on RSVP-TE protocol, CRLSP tunnel based on constraint route is established along target path.

In the embodiment of the present application, the establishment procedure of the CRLSP tunnel is not specifically described.

Through the step S504, the CRLSP tunnel is established along the calculated target path, so that the establishment of the traffic transmission path between the source node and the destination node is completed, and the traffic transmission is performed directly according to the established target path in the later traffic transmission process.

In an optional embodiment, according to the method shown in fig. 5, an embodiment of the present application further provides a path calculation method. As shown in fig. 6, fig. 6 is a fourth flowchart illustrating a path calculation method according to an embodiment of the present application. The method comprises the following steps.

Step S601, determining at least one traffic transmission path between the source node and the destination node according to the link information in the MPLS network.

Step S602, obtaining RSVP state information of each node in at least one traffic transmission path.

Step S603, based on the RSVP state information, using a preset path calculation algorithm to calculate a traffic transmission path that satisfies a preset path constraint condition and in which the RSVP state of each node is an enabled state, as a target path.

Step S604, based on RSVP-TE protocol, CRLSP tunnel based on constraint route is established along target path.

The above steps S601 to S604 are the same as the above steps S501 to S504.

Step S605, after the CRLSP tunnel is established, sends a path state refresh message to the next node on the target path according to a preset time interval.

In this embodiment of the present application, after the CRLSP tunnel is established, each node on the target path maintains the path information of the target path and the resource reservation information by sending a timing refresh message. This mechanism may also be referred to as "soft state" refresh. Wherein the refreshed states include a link state refreshed according to a Path state refresh message (i.e., a Path refresh message) and a resource reservation state refreshed according to a resource reservation state refresh message (i.e., an RSVP refresh message).

After the CRLSP tunnel is established, each node except the destination node sends the Path refresh message to the next node according to a preset time interval according to the sequence of traffic transmitted on the destination Path. That is, the source node will send the Path refresh message to the next node of the source node on the target Path according to the preset time interval.

Step S606, receiving a resource reservation status refresh message sent by the next node according to a preset time interval.

In this embodiment, after the CRLSP tunnel is established, according to the sequence of traffic transmission on the target path, each node except the source node sends the RSVP refresh message to the next node according to a preset time interval. That is, the next node of the source node on the target path sends RSVP refresh message to the source node according to the preset time interval, and the source node receives the RSVP refresh message.

For ease of understanding, the target path is taken as follows: node a-node B-node C, the predetermined time interval is 30 seconds(s) for illustration.

After the CRLSP tunnel is established, node a sends a Path refresh message to node B every 30 s. Node B sends RSVP refresh messages to node a every 30s and sends Path refresh messages to node C. Node C sends RSVP refresh messages to node B every 30 s.

In this embodiment, the preset time interval may be set according to a network environment, a user requirement, and the like, and herein, the preset time interval is not specifically limited.

In the embodiment of the present application, by sending and receiving the inter-node path state refresh message and the resource reservation state refresh message, each node on the target path can determine the inter-node link state and the resource reservation state linked to the node, thereby maintaining the stability of the link state and the resource reservation state on the target path.

In the embodiment shown in fig. 6, the step S605 is executed after the step S606, and besides, the step S605 may be executed simultaneously with the step S606, or the step S605 may be executed after the step S606. Here, the execution order of step S605 and step S606 is not particularly limited.

In an optional embodiment, according to the method shown in fig. 6, an embodiment of the present application further provides a path calculation method. As shown in fig. 7, fig. 7 is a fifth flowchart illustrating a path calculation method according to an embodiment of the present application. Specifically, the following step, step S607, is added.

Step S607, after the target path removal is monitored, the path state of the target path is updated to the second state, and the step S601 is executed again.

In the embodiment of the present application, by sending and receiving the path state refresh message and the resource reservation state refresh message, each node on the target path can accurately determine the link state and the resource reservation state between the nodes linked to the node. When a link state or a resource reservation state corresponding to a certain node fails, the node may remove the target path. That is, when a first node on the target path does not receive a path state refresh message sent by a previous node within a preset time length, the first node can remove the target path; or the first node may tear down the target path when not receiving the resource reservation state refresh message sent by the next node within the preset time length. Here, the dismantling process of the target path is not specifically described.

The first node may be any one or more nodes in the target path, and the first node is not particularly limited. In addition, the preset time duration may be greater than or equal to a time duration corresponding to the preset time interval. Here, the preset time period is not particularly limited.

In this embodiment, after the target path is removed, the source node may determine that a link or resource reservation between nodes on the target path fails, so that RSVP deployed on the target path fails. At this time, the source node may update the path state of the target path. That is, the source node re-marks the path state of the target path to the second state. At this time, the source node may reconstruct the target path from the source node to the destination node. That is, the above-described steps S601 to S604 are executed in return.

In this embodiment, when the step S601 is executed back, the at least one traffic transmission path determined by the source node still includes the target path removed in the step S607, that is, the traffic transmission path marked again in the second state. However, since the path state of the path transmission path of the traffic transmission path has been updated to the second state at this time, when the step S603 is performed back, the traffic transmission path will not be determined as the target path, so as to avoid that the traffic transmission path continues to be the target path and affects the traffic transmission process.

Compared with the prior art, if the RSVP deployed on the target path fails, the new target path cannot be reconstructed, and through the steps S605 to S607, the source node can determine whether the RSVP deployed on the target path fails in time and reconstruct the target path in time when the RSVP deployed on the target path fails, so that normal transmission of traffic between the source node and the target node is ensured, and stability of traffic transmission in the MPLS network is ensured.

In an optional embodiment, after determining that the RSVP in the target path has a failure, the source node may output a prompt message for the RSVP failure, so that the user may find and remove the failure in time, and the stability of the MPLS network is ensured.

In an optional embodiment, according to the method shown in fig. 5, an embodiment of the present application further provides a path calculation method. As shown in fig. 8, fig. 8 is a sixth flowchart illustrating a path calculation method according to an embodiment of the present application. The method specifically comprises the following steps.

Step S801, determining at least one traffic transmission path between the source node and the destination node according to the link information in the MPLS network.

Step S802, RSVP state information of each node in at least one traffic transmission path is obtained.

Step S803, based on the RSVP state information, using a preset path calculation algorithm to calculate a traffic transmission path that satisfies a preset path constraint condition and the RSVP state of each node is an enabled state in at least one traffic transmission path, as a target path.

Step S804, based on RSVP-TE protocol, CRLSP tunnel based on constraint route is established along target path.

The above steps S801 to S804 are the same as the above steps S501 to S504.

Step S805, after the CRLSP tunnel is established, if a link state updating message sent by a second node in the target path is received, updating the RSVP state information of the second node in the stored second TEDB information list to be in an disabled state according to the link state updating message; the link state update status message is sent when the RSVP deployed by the second node is deleted, and the step S801 is executed again.

In this embodiment of the present application, after the CRLSP tunnel is established along the target path, when a certain node in the target path deletes the RSVP that is deployed, the node sends a link state update packet to its neighboring node, and the source node receives the link state update packet by forwarding of other nodes on the target path.

After the CRLSP tunnel is established along the target path, at a certain time, after the source node receives a link state update packet sent by the second node on the target path, the source node may determine that the second node deletes the RSVP that is deployed, at this time, the source node updates, according to the received link state update packet, the numerical value of RSVP state information related to the second node in the stored second TEDB information list, that is, updates the numerical value of RSVP state information of the second node to the second preset numerical value, and reconstructs the target path between the source node and the destination node, that is, returns to perform steps S801 to S804.

The second node may be any one or more nodes in the target path, and the second node is not particularly limited.

The second node deleting the deployed RSVP may indicate that the RSVP interface in the second node is in an disabled state.

In this embodiment of the present application, when the RSVP state information of the second node in the second TEDB information list is updated, the value of the local RSVP state information of the second node in the second TEDB information list is updated to the second preset value, and the value of the remote RSVP state information of the neighboring node as the second node in the second TEDB information list is updated to the second preset value.

In this embodiment, after the second node sends the link state update message to its neighboring node, in addition to the source node receiving the link state update message, other nodes in the MPLS network may also receive the link state update message, and at this time, other nodes in the MPLS network also update the RSVP state information of the second node in the stored TEDB information list, specifically refer to the update of the RSVP state information of the second node in the second TEDB information list stored by the source node, which is not specifically described herein.

In this embodiment of the present application, when the step S801 is executed back, the at least one traffic transmission path determined by the source node still includes the target path in the step S805, but since the RSVP state information of the traffic transmission path (i.e., the target path in the step S805) acquired when the step S802 is executed is updated, when the step S803 is executed again, the traffic transmission path will not be determined as the target path, so that the traffic transmission process is prevented from being affected by the fact that the traffic transmission path continues to be the target path.

Compared with the prior art, if the node in the target path deletes the RSVP, a new target path cannot be reconstructed, through the step S805, the source node can determine the node on the target path that deletes the RSVP in time, so that the target path is reconstructed in time, and normal traffic transmission between the source node and the target node and stability of traffic transmission in the MPLS network are ensured.

In the embodiment of the present application, both the case of RSVP failure shown in fig. 7 and the case of RSVP deletion shown in fig. 8 are accompanied by the tear down of the target path, i.e., the tear down of the CRLSP tunnel in the target path in which RSVP failure or RSVP deletion occurs. Here, the specific procedure of the above-described path removal is not particularly limited.

Based on the same inventive concept, according to the path calculation method provided by the embodiment of the present application, the embodiment of the present application further provides a path calculation device. As shown in fig. 9, fig. 9 is a schematic structural diagram of a path calculation device according to an embodiment of the present application. The device is applied to a source node in the MPLS network, and specifically comprises the following modules.

A determining module 901, configured to determine at least one traffic transmission path between a source node and a destination node according to link information in an MPLS network;

an obtaining module 902, configured to obtain RSVP state information of each node in at least one traffic transmission path;

a first calculating module 903, configured to calculate, based on the RSVP state information, a traffic transmission path that meets a preset path constraint condition and has an RSVP state of each node in an enabled state in at least one traffic transmission path by using a preset path calculation algorithm, as a target path.

Optionally, the path calculating device may further include:

a first receiving module, configured to receive an RSVP state marking command triggered by a user before determining at least one traffic transmission path between a source node and a destination node according to link information in an MPLS network;

the first sending module is used for sending a first routing protocol message to a neighbor node of a source node based on an RSVP state marking command, wherein the first routing protocol message carries local RSVP state information and remote RSVP state information; enabling the neighbor node to update the RSVP state information in the stored first TEDB information list according to the first routing protocol message;

the second receiving module is used for receiving a second routing protocol message sent by the neighbor node, and local RSVP state information and remote RSVP state information carried by the second routing protocol message; updating the RSVP state information in the stored second TEDB information list according to the second routing protocol message;

the obtaining module 902 may be specifically configured to read a second TEDB information list; and obtaining the local RSVP state information and the remote RSVP state information of each node from the second TEDB information list to obtain the RSVP state information of the node.

Optionally, the first calculating module 903 may be specifically configured to determine, for each traffic transmission path, that a path state of the traffic transmission path is a first state when local RSVP state information and remote RSVP state information of each node in the traffic transmission path are both enabled states;

acquiring a path to be calculated with a first state from at least one traffic transmission path;

and calculating the traffic transmission path which meets the preset path constraint condition and is determined from the paths to be calculated by using a preset path calculation algorithm to serve as a target path.

Optionally, the path calculating device may further include:

and the building module is used for building the CRLSP tunnel based on the constraint route along the target path based on the RSVP-TE protocol.

Optionally, the path calculating device may further include:

and the third receiving module is used for receiving the resource reservation state refreshing message sent by the next node according to the preset time interval.

Optionally, the path calculating device may further include:

the first updating module is used for updating the path state of the target path to a second state after the situation that the target path is removed is monitored; the second state is different from the first state; the target path is removed when the first node in the target path does not receive the path state refreshing message sent by the previous node or the resource reservation state refreshing message sent by the next node within the preset time length;

Optionally, the path calculating device may further include:

a second updating module, configured to update, according to a link state update message, RSVP state information of a second node in a stored second TEDB information list to an disabled state if the link state update message sent by the second node in the target path is received after the CRLSP tunnel is established; the link state updating state message is sent when RSVP deployed by the second node is deleted;

By the device provided by the embodiment of the application, after the source node determines at least one traffic transmission path from the source node to the destination node, the RSVP state information of each node in the determined at least one traffic transmission path is acquired, so that when the path calculation is performed by using a preset path calculation algorithm, the RSVP state of each node in the target path is guaranteed to be an enabled state while the selected target path meets the preset path constraint condition in the related art, which effectively guarantees that each node in the target path determined by the path calculation is deployed with RSVP, thereby guaranteeing the normal establishment of the CRLSP tunnel and guaranteeing the normal transmission of traffic in the MPLS network.

Based on the same inventive concept, according to the path calculation method provided in the embodiment of the present application, the embodiment of the present application further provides a source node, as shown in fig. 10, including a processor 1001 and a machine-readable storage medium 1002, where the machine-readable storage medium 1002 stores machine-executable instructions capable of being executed by the processor 1001. Processor 1001 is caused by machine executable instructions to implement any of the steps shown in fig. 2-8 described above.

In an alternative embodiment, as shown in fig. 10, the electronic device may further include: a communication interface 1003 and a communication bus 1004; the processor 1001, the machine-readable storage medium 1002, and the communication interface 1003 complete communication with each other through the communication bus 1004, and the communication interface 1003 is used for communication between the source node and other devices.

Based on the same inventive concept, according to the path calculation method provided in the embodiments of the present application, the embodiments of the present application further provide a machine-readable storage medium storing machine-executable instructions that can be executed by a processor. The processor is caused by machine executable instructions to implement any of the steps shown in fig. 2-8 described above.

The communication bus may be a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc.

The machine-readable storage medium may include a RAM (Random Access Memory) and a NVM (Non-Volatile Memory), such as at least one disk Memory. Additionally, the machine-readable storage medium may be at least one memory device located remotely from the aforementioned processor.

The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also DSPs (Digital Signal Processing), ASICs (Application Specific Integrated circuits), FPGAs (Field Programmable Gate arrays) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, it relates to an apparatus, a source node and a machine-readable storage medium for path computation. For the embodiment of the machine-readable storage medium, since it is substantially similar to the embodiment of the path calculation method, the description is simple, and for relevant points, reference may be made to part of the description of the embodiment of the path calculation method.

The above description is only for the preferred embodiment of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application are included in the protection scope of the present application.

Claims

1. A method for path computation, applied to a source node in a multi-protocol label switching, MPLS, network, the method comprising:

acquiring resource reservation protocol (RSVP) state information of each node in the at least one flow transmission path;

2. The method of claim 1, before determining at least one traffic transmission path between the source node and the destination node according to the link information in the MPLS network, further comprising:

receiving an RSVP state marking command triggered by a user;

sending a first routing protocol message to a neighbor node of the source node based on the RSVP state marking command, wherein the first routing protocol message carries local RSVP state information and remote RSVP state information; enabling the neighbor node to update the RSVP state information in the stored TEDB information list of the first traffic engineering database according to the first routing protocol message;

reading the second TEDB information list;

3. The method according to claim 2, wherein the step of calculating, based on the RSVP state information, a traffic transmission path that satisfies a predetermined path constraint condition and has the RSVP state of each node in an enabled state by using a predetermined path calculation algorithm as a target path comprises:

4. The method according to any one of claims 1-3, further comprising:

and establishing a label switching path (CRLSP) tunnel based on the constraint route along the target path based on the RSVP-TE protocol.

5. The method of claim 4, further comprising:

6. The method of claim 5, further comprising:

7. The method of claim 4, further comprising:

8. A path computation apparatus, applied to a source node in a multi-protocol label switching, MPLS, network, the apparatus comprising:

an obtaining module, configured to obtain resource reservation protocol RSVP state information of each node in the at least one traffic transmission path;

9. The apparatus of claim 8, further comprising:

a first sending module, configured to send a first routing protocol packet to a neighboring node of the source node based on the RSVP state marking command, where the first routing protocol packet carries local RSVP state information and remote RSVP state information; enabling the neighbor node to update the RSVP state information in the stored TEDB information list of the first traffic engineering database according to the first routing protocol message;

10. The apparatus of claim 9, wherein the first calculating module is specifically configured to determine, for each traffic transmission path, that the path status of the traffic transmission path is the first status when the local RSVP state information and the remote RSVP state information of each node in the traffic transmission path are both enabled statuses;

11. The apparatus of any of claims 8-10, further comprising:

and the construction module is used for establishing a label switching path CRLSP tunnel based on the constraint route along the target path based on the RSVP-TE protocol.

12. The apparatus of claim 11, further comprising:

13. The apparatus of claim 12, further comprising:

14. The apparatus of claim 11, further comprising: