WO2021077972A1

WO2021077972A1 - Packet forwarding method, device, and storage medium

Info

Publication number: WO2021077972A1
Application number: PCT/CN2020/117228
Authority: WO
Inventors: 赵科强; 张华�
Original assignee: 华为技术有限公司
Priority date: 2019-10-22
Filing date: 2020-09-23
Publication date: 2021-04-29
Also published as: CN112702263A; CN112702263B

Abstract

Disclosed by the present application are a packet forwarding method, device, and storage medium, belonging to the technical field of segment routing. In the method, in order to enable nodes in a certain domain to determine a forwarding path across domains, a neighboring relationship of a boundary node in a first domain acquired by a first node comprises a neighboring relationship of a boundary node in a second domain, said second domain being a domain other than said first domain; thus the first node can determine the forwarding path in view of the neighboring relationship of the boundary node in the second domain, that is, the first node can use a link resource in another domain other than a link resource in the first domain when determining the forwarding path, thereby avoiding the problem that packets cannot be forwarded when there is no backup path in the current domain, and improving the rate of success of packet forwarding.

Description

Method, device and storage medium for forwarding messages

This application claims the priority of a Chinese patent application filed on October 22, 2019 with the application number 201911005235.9 and the invention title "Method, device and storage medium for message forwarding", the entire content of which is incorporated into this application by reference .

Technical field

This application relates to the technical field of segment routing (SR), and in particular to a method, device and storage medium for confirming forwarding of packets.

Background technique

At present, in order to facilitate the management of large-scale networks, the network is usually divided into multiple domains. Each domain includes a set of hosts and a set of routers. The hosts and routers in a domain are managed by a controller. At this time, how to forward the message to the destination node in the network has become a current research hotspot.

In related technologies, for any domain, the SR technology can be used to implement packet forwarding in the domain. That is, the ingress node of the domain inserts the message forwarding path in the domain into the message, and the ingress node forwards the message to the next hop node according to the forwarding path, and the next hop node receives the message after receiving the message. After the message, continue to forward the message according to the forwarding path until the message is forwarded to the egress node of the domain. The egress node forwards the message to the ingress node of another domain according to the controller's instruction, and the forwarding process of the message in the other domain is basically the same as the forwarding process of the message in the aforementioned domain. Through the above process, the message can be forwarded to the destination node in the network.

In the above process of forwarding messages, for any domain, when a node in the domain receives a message, and the link between the node and the next-hop node in the domain fails, the node determines that it is in Whether there is a backup path from the node to the next hop node in the domain? If there is no backup path from the node to the next hop node in the domain, the message will not be successfully forwarded to the destination node.

Summary of the invention

The present application provides a method, device and storage medium for forwarding messages, which can establish a cross-domain backup path when the link between the current node and the next hop node fails, thereby improving the success of message forwarding rate. The technical solution is as follows:

In the first aspect, a method for forwarding messages is provided. In this method, a first node receives a message, the first node is any node in a first domain, and the first domain is any domain in a plurality of domains in the network. The first node obtains one or more neighbor relationships of each node in the first domain, and the one or more neighbor relationships of border nodes in the first domain include the neighbor relationships of the border node in the second domain, and the second domain is divided by A domain outside the first domain; the first node determines a forwarding path to the destination node of the message according to one or more neighbor relationships of each node in the first domain; the first node forwards according to the determined forwarding path The message.

In the embodiment of the present application, in order to realize that nodes in a certain domain can determine the forwarding path across domains, the neighbor relationship of the border node in the first domain acquired by the first node includes the neighbor relationship of the border node in the second domain. It is a domain other than the first domain. In this way, the first node can determine the forwarding path based on the neighbor relationship of the border node in the second domain. That is, the first node can use other than the first domain when determining the forwarding path. Link resources in other domains other than the link resources of the domain, thereby avoiding the problem that packets cannot be forwarded when there is no backup path in the current domain, and thus improving the success rate of packet forwarding.

Optionally, the first node obtains one or more neighbor relationships of each node in the first domain, specifically: for a second node in each node, from one or more neighbor relationship types of the second node − Select a neighbor relationship TLV from the length-value TLV, and obtain the neighbor identifier in the selected neighbor relationship TLV. The second node is any one of the nodes; the neighbor identifier carried in the selected neighbor relationship TLV indicates one In the case of a virtual neighbor, a virtual neighbor sub-TLV is obtained from the selected neighbor relationship TLV, the virtual neighbor sub-TLV carries a neighbor identifier and a path label, and the neighbor identifier carried by the virtual neighbor sub-TLV is used to indicate the corresponding The identifier of the virtual neighbor, the path label carried by the virtual neighbor sub-TLV is used to indicate the path of the second node to the virtual neighbor, and the path of the second node to the virtual neighbor is constructed through link resources in the second domain ; Determine a neighbor relationship of the second node according to the neighbor identifier and path label carried by the virtual neighbor sub-TLV.

In the embodiment of the present application, virtual neighbors can be used to indicate the neighbor relationship of border nodes in the first domain in the second domain, so that when the link between the first node and the next hop node fails, it can be Determine other feasible backup paths based on the virtual neighbor.

Optionally, after the first node obtains the neighbor identifier in the selected neighbor relationship TLV, the first node may also use the selected neighbor relationship if the neighbor identifier carried in the selected neighbor relationship TLV indicates a normal neighbor. The TLV determines a neighbor relationship of the second node, and the normal neighbor refers to a node that constructs a path with the second node through link resources in the first domain.

The embodiment of the application extends the original neighbor relationship TLV, and the original neighbor relationship TLV can still indicate a normal neighbor in the domain.

Optionally, in the case that the neighbor identifier carried in the selected neighbor relationship TLV is the same as the identifier of the second node, the neighbor identifier carried in the selected neighbor relationship TLV indicates a virtual neighbor. In the case that the neighbor identifier carried in the selected neighbor relationship TLV is different from the identifier of the second node, the neighbor identifier carried in the selected neighbor relationship TLV indicates a normal neighbor.

Specifically, in this embodiment of the present application, whether the neighbor indicated in the neighbor relationship TLV is the node itself can be used to determine whether the neighbor indicated in the neighbor relationship TLV is a virtual neighbor or a normal neighbor in the domain.

Optionally, after the first node obtains the virtual neighbor sub-TLV from the selected neighbor relationship TLV, the first node may also obtain virtual neighbor function indication information from the virtual neighbor sub-TLV; where the virtual neighbor function indication information indicates the The virtual neighbor is used in the scenario of forwarding packets based on the segment routing optimal path SR-BE technology, and currently in the scenario of forwarding packets based on the SR-BE technology, the implementation is performed according to the neighbor identifier carried by the virtual neighbor sub-TLV And the path label to determine a neighbor relationship of the second node.

Optionally, after the first node obtains the virtual neighbor sub-TLV from the selected neighbor relationship TLV, the first node may also obtain virtual neighbor function indication information from the virtual neighbor sub-TLV; where the virtual neighbor function indication information indicates the The virtual neighbor is used in the scenario of forwarding packets based on the segmented routing process engineering SR-TE technology, and currently in the scenario of forwarding packets based on the SR-TE technology, the virtual neighbor is executed according to the neighbor identification and the sub-TLV carried by the virtual neighbor. The path label determines the step of a neighbor relationship of the second node.

Since the method for forwarding messages provided by the embodiments of the present application can be applied to the scenario where the forwarding message is determined by the SR-BE technology, it can also be applied to the scenario where the message is forwarded through the SR-TE technology, and the first in different scenarios The way for a node to reach the virtual neighbor through the second domain is different. Therefore, in order for the first node to quickly determine that the path label carried by the virtual neighbor sub-TLV can be used to determine the forwarding path, the virtual neighbor function indication information can also be configured in the virtual neighbor sub-TLV, and the virtual neighbor function indication information can be used to determine Indicate which scenario the path label carried by the virtual neighbor sub-TLV is applicable to.

Optionally, the virtual neighbor function indication information is carried in the control bit field of the virtual neighbor sub-TLV. Specifically, the virtual neighbor function indication information may be carried in the control bit field of the virtual neighbor sub-TLV.

Optionally, the first node obtains one or more neighbor relationships of each node in the first domain, specifically: for the second node in each node, select from one or more neighbor relationship TLVs of the second node A neighbor relationship TLV to obtain a neighbor sub-TLV in the selected neighbor relationship TLV, the neighbor sub-TLV is used to indicate the neighbor relationship from the second node to the third node, and the third node is the first domain or the second domain The second node is any node in each node.

In the scenario of forwarding packets based on the SR-TE technology, each node can also advertise the neighbor relationship through the neighbor sub-TLV (Adj-SID Sub TLV) in the neighbor relationship TLV. That is, in the scenario of forwarding packets based on the SR-TE technology, the neighbor relationship TLV originally carries a neighbor sub-TLV, and the neighbor sub-TLV is used to indicate the neighbor relationship in the domain. Therefore, in the embodiment of the present application, in the scenario of forwarding packets based on the SR-TE technology, the neighbor sub-TLV in the neighbor relationship TLV can also be directly reconfigured, so that the neighbor sub-TLV can carry the cross-domain neighbor relationship (In the embodiment of the present application, it specifically refers to the case where the third node is a node in the second domain), so that nodes in the first domain can establish tunnels between nodes in the second domain, that is, to establish a cross-domain Tunnel

Optionally, the first node determines the forwarding path of the message according to one or more neighbor relationships of each node in the first domain, specifically: starting from the first node, the first node sequentially executes The step of determining the next hop node of the current node until the determined next hop node is the destination node of the message, the forwarding path of the message is obtained.

In order to determine the forwarding path to the destination of the message, the next hop node needs to be determined hop by hop.

Optionally, the determining the next hop node of the current node according to one or more neighbor relationships of the current node is specifically: determining the optimal neighbor to the destination node from the one or more neighbor relationships of the current node Relationship; the current node is a boundary node, the optimal neighbor relationship is the neighbor relationship of the current node in the second domain, and the path between the current node and the node indicated by the optimal neighbor relationship has unidirectional In the case of reaching performance, the node indicated by the optimal neighbor relationship is determined as the next hop node of the current node.

Since the message forwarding method provided by the embodiment of the present application usually re-determines the forwarding path when the current link fails, it does not need to have two-way reachability at this time, and it can be used only after it has one-way reachability. The forwarding path can be determined based on the neighbor relationship, thereby improving the efficiency of re-determining the forwarding path.

Optionally, the first node obtains one or more neighbor relationships of each node in the first domain, specifically: the link between the first node and the next hop node indicated in the message is faulty In this case, one or more neighbor relationships of each node in the first domain are acquired.

Specifically, the message forwarding method provided in the embodiment of the present application can be applied in the case that the link between the first node and the next hop node indicated in the message is faulty, thereby avoiding the problem of being in the current domain. There is a problem that packets cannot be forwarded when there is no backup path, which improves the success rate of packet forwarding.

In a second aspect, a method for forwarding packets is provided. In the method, a border node between a first domain and a second domain determines a neighbor relationship TLV, and the neighbor relationship TLV is used to indicate that the border node is in the first domain. The neighbor relationship in the second domain; the border node publishes the neighbor relationship TLV in the first domain.

In the embodiment of the present application, in order to realize that nodes in a certain domain can determine the forwarding path across domains, the border node between the first domain and the second domain may determine the neighbor relationship used to indicate the neighbor relationship of the border node in the second domain TLV, and publish the neighbor relationship TLV in the first domain. In this way, the first node in the first domain can receive the neighbor relationship TLV, so that the subsequent first node can determine the forwarding path based on the neighbor relationship of the border node in the second domain, that is, the first node is determining the forwarding path It is possible to use link resources in other domains except the link resources in the first domain, thereby avoiding the problem that packets cannot be forwarded when there is no backup path in the current domain, thereby improving the success rate of packet forwarding.

Optionally, in the case that the neighbor identifier carried by the neighbor relationship TLV indicates a virtual neighbor, the neighbor relationship TLV includes a virtual neighbor sub-TLV, and the virtual neighbor sub-TLV carries the neighbor identifier and the path label, and the virtual neighbor TLV The neighbor identifier carried by the neighbor sub-TLV is used to indicate the identifier of the virtual neighbor corresponding to the border node, and the path label carried by the virtual neighbor sub-TLV is used to indicate the path of the border node to the virtual neighbor. The path to the virtual neighbor is constructed through link resources in the second domain.

Optionally, in the case that the neighbor identifier carried in the neighbor relationship TLV is the same as the identifier of the border node, the neighbor identifier carried in the neighbor relationship TLV indicates a virtual neighbor.

Optionally, the neighbor relationship TLV includes a neighbor sub-TLV, and the neighbor sub-TLV is used to indicate a neighbor relationship from the border node to a third node, and the third node is the first domain or the second domain. Nodes in the domain.

The foregoing beneficial effects of indicating the neighbor relationship of the border node in the second domain in different ways have been described in detail in the message forwarding method provided by the first aspect, and will not be repeated here.

In a third aspect, a first node is provided, and the first node includes:

A receiving module, configured to receive a message, the first node is any node in a first domain, and the first domain is any one of multiple domains in the network;

The obtaining module is configured to obtain one or more neighbor relationships of each node in the first domain, and the one or more neighbor relationships of border nodes in the first domain include the neighbor relationship of the border nodes in the second domain, so The second domain is a domain other than the first domain;

A determining module, configured to determine a forwarding path to the destination node of the message according to one or more neighbor relationships of each node in the first domain;

The forwarding module is configured to forward the message according to the determined forwarding path.

Optionally, the aforementioned acquisition module is specifically used for:

For the second node in each of the nodes, select a neighbor relationship TLV from one or more neighbor relationship type-length-value TLVs of the second node, and obtain the neighbor identifier in the selected neighbor relationship TLV, the The second node is any one of the nodes;

In the case where the neighbor identifier carried in the selected neighbor relationship TLV indicates a virtual neighbor, a virtual neighbor sub-TLV is obtained from the selected neighbor relationship TLV, and the virtual neighbor sub-TLV carries the neighbor identifier and the path label, so The neighbor identifier carried by the virtual neighbor sub-TLV is used to indicate the identifier of the virtual neighbor corresponding to the second node, and the path label carried by the virtual neighbor sub-TLV is used to indicate the path of the second node to the virtual neighbor, The path for the second node to reach the virtual neighbor is constructed through link resources in the second domain;

Determine a neighbor relationship of the second node according to the neighbor identifier and the path label carried by the virtual neighbor sub-TLV.

Optionally, in the case that the neighbor identifier carried in the selected neighbor relationship TLV is the same as the identifier of the second node, the neighbor identifier carried in the selected neighbor relationship TLV indicates a virtual neighbor.

Optionally, the aforementioned acquiring module is further specifically configured to: in the case that the neighbor identifier carried in the selected neighbor relationship TLV indicates a normal neighbor, determine one of the second nodes according to the selected neighbor relationship TLV Neighbor relationship, the normal neighbor refers to a node that constructs a path with the second node through link resources in the first domain.

Optionally, in the case that the neighbor identifier carried in the selected neighbor relationship TLV is different from the identifier of the second node, the neighbor identifier carried in the selected neighbor relationship TLV indicates a normal neighbor.

Optionally, the aforementioned acquisition module is also specifically used for:

Acquiring virtual neighbor function indication information from the virtual neighbor sub-TLV;

In the case where the virtual neighbor function indication information indicates that the virtual neighbor is used in the scenario of forwarding packets based on the segment routing optimal path SR-BE technology, and is currently in the scenario of forwarding packets based on the SR-BE technology, A step of determining a neighbor relationship of the second node according to the neighbor identifier and the path label carried by the virtual neighbor sub-TLV is performed.

When the virtual neighbor function indication information indicates that the virtual neighbor is used in the scenario of forwarding packets based on the segmented routing process engineering SR-TE technology, and is currently in the scenario of forwarding packets based on the SR-TE technology, execute The step of determining a neighbor relationship of the second node according to the neighbor identifier and the path label carried by the virtual neighbor sub-TLV.

Optionally, the virtual neighbor function indication information is carried in a control bit field of the virtual neighbor sub-TLV.

For the second node in each node, select a neighbor relationship TLV from one or more neighbor relationship TLVs of the second node, and obtain a neighbor sub-TLV in the selected neighbor relationship TLV, and the neighbor sub-TLV is used for Indicates the neighbor relationship between the second node and the third node, where the third node is a node in the first domain or the second domain, and the second node is any one of the nodes .

Optionally, the aforementioned determining module is also specifically used for:

Starting from the first node, the first node sequentially executes the step of determining the next hop node of the current node according to one or more neighbor relationships of the current node, until the determined next hop node is the When the destination node of the message, the forwarding path of the message is obtained.

Determining the optimal neighbor relationship to the destination node from one or more neighbor relationships of the current node;

The current node is a boundary node, the optimal neighbor relationship is the neighbor relationship of the current node in the second domain, and the path between the current node and the node indicated by the optimal neighbor relationship In the case of unidirectional reachability, the node indicated by the optimal neighbor relationship is determined as the next hop node of the current node.

In the case that the link between the first node and the next hop node indicated in the message is faulty, obtain one or more neighbor relationships of each node in the first domain.

The functions of the modules included in the first node provided in the above third aspect have been described in detail in the message forwarding method provided in the first aspect, and will not be repeated here.

In a fourth aspect, a boundary node between a first domain and a second domain is provided, and the boundary node includes:

A determining module, configured to determine a neighbor relationship TLV, where the neighbor relationship TLV is used to indicate the neighbor relationship of the border node in the second domain;

The publishing module is configured to publish the neighbor relationship TLV in the first domain.

The functions of the various modules included in the boundary node provided in the above fourth aspect have been described in detail in the message forwarding method provided in the second aspect, and will not be repeated here.

In a fifth aspect, a first node in a communication network is provided, the first node is any node in a first domain, the first domain is any one of a plurality of domains in the network, and the first node is One node includes memory and processor;

The memory is used to store a computer program;

The processor is configured to execute a computer program stored in the memory to execute the following method for forwarding messages:

Receive message;

Obtain one or more neighbor relationships of each node in the first domain, the one or more neighbor relationships of border nodes in the first domain include neighbor relationships of the border nodes in a second domain, and the second domain is Domains other than the first domain;

Determine a forwarding path to the destination node of the message according to one or more neighbor relationships of each node in the first domain;

Forward the message according to the determined forwarding path;

Optionally, the acquiring, by the first node, one or more neighbor relationships of each node in the first domain includes:

Optionally, after obtaining the neighbor identifier in the selected neighbor relationship TLV, the method further includes: in the case that the neighbor identifier carried in the selected neighbor relationship TLV indicates a normal neighbor, according to the selected neighbor relationship TLV A neighbor relationship of the second node is determined, and the normal neighbor refers to a node that constructs a path with the second node through link resources in the first domain.

Optionally, after obtaining the virtual neighbor sub-TLV from the selected neighbor relationship TLV, the method further includes:

Optionally, the first node determining the forwarding path of the message according to one or more neighbor relationships of each node in the first domain includes:

Optionally, the determining the next hop node of the current node according to one or more neighbor relationships of the current node includes:

In a sixth aspect, a boundary node in a communication network is provided, wherein the boundary node is a boundary node between a first domain and a second domain, and the boundary node includes a memory and a processor;

The memory is used to store a computer program;

Determining a neighbor relationship TLV, where the neighbor relationship TLV is used to indicate the neighbor relationship of the border node in the second domain;

Publish the neighbor relationship TLV in the first domain.

In a seventh aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores instructions that, when run on a computer, cause the computer to execute any one of the first or second aspects described above. The method of forwarding the message.

In an eighth aspect, a computer program product containing instructions is provided, which when running on a computer, causes the computer to execute the method for forwarding a message as described in any one of the first or second aspects.

In a ninth aspect, a system for forwarding packets is provided. The system includes a first node and a second node. The first node is any node in a first domain, and the second node is the first node. The boundary node between the domain and the second domain;

The second node is used to determine a neighbor relationship TLV, and the neighbor relationship TLV is used to indicate the neighbor relationship of the border node in the second domain, and publish the neighbor relationship TLV in the first domain;

The first node is used to receive the neighbor relationship TLV.

Description of the drawings

Fig. 1 is a schematic diagram of a network system provided by an embodiment of the present application;

Figure 2 is a schematic diagram of another network system provided by an embodiment of the present application;

Figure 3 is a schematic diagram of another network system provided by an embodiment of the present application;

FIG. 4 is a flowchart of a method for forwarding packets provided by an embodiment of the present application;

FIG. 5 is a flowchart of another method for forwarding messages provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of the format of a TLV22 provided by an embodiment of the present application;

FIG. 7 is a schematic diagram of the format of a virtual neighbor sub-TLV provided by an embodiment of the present application;

FIG. 8 is a flowchart of another method for forwarding packets provided by an embodiment of the present application;

FIG. 9 is a schematic diagram of the format of a neighbor sub-TLV provided by an embodiment of the present application;

FIG. 10 is a schematic diagram of an apparatus of a first node provided by an embodiment of the present application;

FIG. 11 is a schematic diagram of a boundary node device provided by an embodiment of the present application;

Fig. 12 is a schematic structural diagram of a computer device provided by an embodiment of the present application.

Detailed ways

In order to make the objectives, technical solutions, and advantages of the present application clearer, the implementation manners of the present application will be further described in detail below with reference to the accompanying drawings.

It should be understood that the "plurality" mentioned herein refers to two or more. In the description of this application, unless otherwise specified, "/" means or, for example, A/B can mean A or B; "and/or" in this document is only an association relationship describing associated objects, It means that there can be three kinds of relationships, for example, A and/or B, which can mean: A alone exists, A and B exist at the same time, and B exists alone. In addition, in order to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish the same or similar items with substantially the same function and effect. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not limit the difference.

Before explaining the method for forwarding packets provided in the embodiment of the present application, the application scenario of the embodiment of the present application will be explained first.

Fig. 1 is a schematic diagram of a network system provided by an embodiment of the present application. As shown in Figure 1, the network system includes three cell site gateways (CSG), which are marked as CSG1, CSG2, and CSG3 in Figure 1. Among them, the CSG can also be referred to as an access service gateway, which is a role in the mobile bearer network. This role is in the access layer and is responsible for the access of the base station.

The network system 100 also includes two aggregation site gateways (ASG), which are marked as ASG1 and ASG2 in FIG. 1 respectively. ASG is also a role in the mobile bearer network. This role is located at the convergence layer and is used to converge the massive CSG service flows in the access layer of the mobile bearer network.

The network system 100 also includes two operator devices (providers), which are respectively marked as P1 and P2 in FIG. 1. The network system 100 also includes two radio service gateways (RSG), which are marked as RSG1 and RSG2 in FIG. 1 respectively. RSG is also a role in the mobile bearer network. The role is at the convergence layer and is used to connect to the wireless controller.

As shown in Figure 1, CSG1 is connected to CSG2 and CSG3 through wired or wireless connections for communication. CSG2 and ASG1 are connected by wire or wireless for communication. ASG1 and P1 are connected through a wired or wireless connection for communication. P1 and RSG1 are connected through a wired or wireless connection for communication. CSG3 and ASG2 are connected by wired or wireless for communication. ASG2 and P2 are connected through a wired or wireless connection for communication. P2 and RSG2 are connected through a wired or wireless connection for communication. ASG1 and ASG2 are connected through a wired or wireless connection for communication.

In addition, as shown in Fig. 1, three CSGs and two ASGs are located in one domain, which is marked as domain 1 in Fig. 1. Two ASGs, two P1s, and two RSGs are located in another domain, which is marked as domain 2 in Figure 1. In the embodiments of this application, the domain may be a domain divided based on the Interior Gateway Protocol (IGP), that is, nodes in the same domain communicate based on the same IGP, and nodes in different domains communicate based on different IGPs .

The network system shown in FIG. 1 is applied to a scenario where a route is determined by segment routing (Segment Routing-Best Effort, SR-BE) technology. In this scenario, suppose that the link between ASG1 and ASG2 fails, and the link between P1 and RSG1 also fails. At this time, when P1 receives a message, if the destination node of the message is RSG1 Since P1 can only determine the backup path based on the nodes in domain 2, but obviously there is no optional backup path in domain 2 to transmit the message, this will cause the message transmission to fail. The method for forwarding messages provided in the embodiments of the present application can obtain an optional path for forwarding messages in this scenario.

It should be noted that the layout of each node in the network system shown in FIG. 1 is only used for illustration, and the numbers of CSG, ASG, and RSG in FIG. 1 are only used for illustration, and do not constitute an impact on this application. limited.

Fig. 2 is a schematic diagram of another network system provided by an embodiment of the present application. As shown in Figure 2, the network system includes a CSG, an ASG, and an RSG. Among them, CSG and ASG are located in the same domain, which is marked as domain 1 in Figure 2. ASG and RSG are located in another domain, marked as domain 2 in Figure 2.

When the network system shown in Figure 2 forwards packets through the Segment Routing Traffic Engineering (SR-TE) technology, at this time, the CSG can establish a TE tunnel between the ASG to transfer the packets from CSG is forwarded to ASG. The ASG can also establish a TE tunnel to the RSG, which is used to forward packets from the ASG to the RSG. However, since CSG and RSG are not located in the same domain, CSG cannot directly establish TE tunnels to RSG. It is necessary to glue the tunnels from CSG to ASG and the tunnels between ASG to RSG by sticking labels to establish a cross-domain connection. TE tunnel, used to forward packets.

Fig. 3 is a schematic diagram of another network system provided by an embodiment of the present application. As shown in Fig. 3, the network system includes node R1, node R2, node R3, node R4, and node R5. The point R1, the node R2, and the node R3 are located in a domain, which is marked as domain 1 in Fig. 3. Node R2, node R3, node R4, and node R5 are located in another domain, which is marked as domain 2 in FIG. 3. The network connection relationship between the various nodes is shown in Figure 3, which will not be explained one by one here.

As shown in Figure 3, a TE tunnel between each node is established in each domain in advance, and the established TE tunnel is bound with the tunnel label. As shown in Figure 3, an SR-TE tunnel is established between node R1 and node R2, and the bound tunnel label is 1, and an SR-TE tunnel is established between node R2 and node R4, and the bound tunnel label is 2.

When you need to create a cross-domain TE tunnel, you can create a cross-domain TE tunnel by specifying the displayed path. The explicit path refers to the tunnel label that indicates at the ingress node of each domain that the packet passes through each single-segment tunnel in the domain along the way, and adds a sticky label corresponding to the egress node in the domain to the displayed path. The corresponding relationship between the sticky label and one or more tunnel labels in other domains is pre-configured at the location, which is used to instruct the egress node to replace the sticky label in the message with the corresponding one or more tunnels when receiving the message Labels to realize the continued forwarding of messages in other domains. For example, the displayed path deployed at node R1 is tunnel label 1 and adhesive label, where the mapping relationship between adhesive label and tunnel label 2 is pre-configured, so that when R2 receives the message, it can directly replace the adhesive label It is tunnel label 2, so that the packet is forwarded in domain 2 through the tunnel indicated by tunnel label 2.

However, this method needs to configure the display path including the sticky label at the network entrance, such as R1 in Figure 3, to indicate the forwarding path of the message. This path configuration method is static. For a node in the network, if there is a failure between the node and the next hop node, because the backup path cannot be determined dynamically and temporarily, the successful forwarding of the message cannot be guaranteed at this time. In addition, in the network system shown in Figure 3, if node R4 fails, R1 cannot perceive that the TE tunnel between R2 and R4 is down, but the TE tunnel between R1 and R2 is still operating normally. At this time, subsequent packets will continue to be forwarded to node R2 and be discarded, thus forming a forwarding black hole. However, the method for forwarding packets provided in the embodiment of the present application can dynamically establish a cross-domain TE tunnel.

It should be noted that the layout of each node in the network system shown in Figure 2 or Figure 3 is only used for illustration, and the numbers of CSG, ASG, and RSG in Figure 2 are only used for illustration and do not constitute Limitations on this application.

FIG. 4 is a flowchart of a method for forwarding packets provided by an embodiment of the present application, which is applied to any node in the network system shown in FIG. 1 to FIG. 3. As shown in FIG. 4, the method includes the following steps:

Step 401: The first node receives the message, the first node is any node in the first domain, and the first domain is any domain among multiple domains in the network.

The first domain is any domain in the network system shown in FIG. 1 to FIG. 3, and the first node may be any node in the first domain.

In the network system shown in Figures 1 to 3, in order to improve the efficiency of node forwarding messages, the forwarding path of the message can be deployed at the entrance of the network through the SR technology in advance, so that subsequent nodes will receive the message after receiving the message. Directly forward to the message according to the pre-deployed forwarding path. Therefore, when the first node receives the message to be forwarded, it can determine the next hop node of the message according to the pre-deployed forwarding path, and then forward the message to the determined next hop node.

After the first node forwards the message to the determined next hop node, if the link between the first node and the next hop node fails, the first node will not be able to successfully forward the message to the next hop node. At this time, in order to continue to realize the forwarding of the message, in this embodiment of the present application, the first node may re-determine the forwarding path of the message through the following

steps

402 and 503.

Step 402: The first node obtains one or more neighbor relations of each node in the first domain. The one or more neighbor relations of the border nodes in the first domain include the neighbor relations of the border nodes in the second domain. A domain outside of a domain.

In the network system shown in any one of Figures 1 to 3, when there is a neighbor relationship between any two nodes, messages can be forwarded between these two nodes. Therefore, in order to re-determine the forwarding path of the message, the first A node needs to obtain the neighbor relationship of each node in the first domain, so as to re-determine the forwarding path through the following step 402.

In the embodiments of the present application, in order to enable nodes in a certain domain to determine the forwarding path across domains, the one or more neighbor relationships of the border nodes in the first domain acquired by the first node include the neighbors of the border node in the second domain. The second domain is a domain other than the first domain. In this way, the first node can determine the forwarding path in conjunction with the nodes in the second domain, avoiding the problem that packets cannot be forwarded when there is no backup path in the current domain.

Among them, the border node in the first domain can obtain its neighbor relationship in the second domain in advance, and then publish its neighbor relationship in the second domain through the neighbor relationship TLV in the first domain, so that the nodes in the first domain can learn Neighbor relationship to border nodes in the first domain in the second domain. The border node in the first domain advertises its neighbor relationship in the second domain in the first domain, which will be described in detail in the following embodiments, and will not be elaborated here.

Step 403: The first node determines the forwarding path of the message according to one or more neighbor relationships of each node in the first domain, and forwards the message according to the determined forwarding path.

After determining the neighbor relationship of each node in the first domain, the first node can determine the forwarding path of the message according to the neighbor relationship of each node in the first domain. Step 403 will be explained in detail according to different scenarios later, and will not be explained here.

In the embodiments of the present application, in order to enable nodes in a certain domain to determine the forwarding path across domains, the neighbor relationship of the border node in the first domain acquired by the first node includes the neighbor relationship of the border node in the second domain, and the second domain For domains other than the first domain, in this way, the first node can determine the forwarding path in conjunction with the nodes in the second domain, which avoids the problem that packets cannot be forwarded when there is no backup path in the current domain.

The embodiment shown in FIG. 4 can be applied to the scenario where the link between the first node and the next hop node fails, and the first node cannot successfully forward the message to the next hop node, and can also be applied to In the scenario where the first node establishes a cross-domain TE tunnel, the following embodiments shown in FIG. 5 and FIG. 8 are respectively used to explain in detail the message forwarding process in these two scenarios.

In addition, the method for forwarding messages provided in the embodiments of the present application can be applied to SR-BE technology, and can also be applied to SR-TE technology. Of course, it can also be applied to scenarios where messages are forwarded through other technologies. limited. The following embodiments respectively take the SR-BE scenario and the SR-TE scenario as examples to illustrate the method for forwarding packets provided in the embodiments of the present application. When the message forwarding method provided in the embodiment of the present application is applied to a scenario where a message is forwarded through other technologies, the following embodiments may also be referred to to implement the message forwarding method provided in the embodiment of the present application.

FIG. 5 is a flowchart of another method for forwarding packets provided by an embodiment of the present application, which is applied to any node in the network system shown in FIG. 1 to FIG. 3, that is, it can be applied to SR-BE technology , Can also be applied to SR-TE technology, of course, it can also be applied to scenarios where messages are forwarded through other technologies. In the embodiments of the present application, the neighbor relationship of border nodes in the first domain in the second domain can be indicated by means of virtual neighbors. The virtual neighbor refers to the neighbor established by the first node through the neighbor relationship in the second domain. When the link between a node and the next-hop node fails, other feasible backup paths can be determined according to the virtual neighbor. The implementation will be explained in detail below. As shown in Figure 5, the method includes the following steps:

Step 501: The first node receives the message, the first node is any node in the first domain, and the first domain is any domain among multiple domains in the network.

For the implementation of step 501, reference may be made to the implementation of step 401 in the embodiment shown in FIG. 4, which will not be repeated here.

For any node in the network system, the node can pre-publish its neighbor relationship in the current domain through the neighbor relationship TLV. The neighbor relationship TLV may be a type-length-value (tag-length-value, TLV) TLV22. In the embodiments of the present application, in order to be able to indicate the neighbor relationship of border nodes in the first domain in the second domain through virtual neighbors, the neighbor relationship TLV is modified. The following uses TLV22 as an example to explain the neighbor relationship TLV What modifications have been made, other types of neighbor relationship TLVs can be modified with reference to TLV22 to implement the message forwarding method provided in the embodiments of the present application.

FIG. 6 is a schematic diagram of the format of a TLV22 provided by an embodiment of the present application. As shown in Figure 6, the TLV 22 includes TLV Type (TLV Type), TLV Length (TLV Length), Neighbour ID (Neighbour ID), Cost Value (Metric), SubTLV Length (SubTLV Length), and reserved optional subtypes. TLV (Optional SubTLV) and other fields.

The neighbor identifier is used to indicate the node that has a neighbor relationship with the node. In the embodiment of the present application, the neighbor identifier can be used to indicate whether the neighbor is a virtual neighbor or a normal neighbor in the current domain. In a possible implementation manner, for any node, if the neighbor relationship in the TLV22 published by the node is a virtual neighbor relationship, the neighbor identifier can be set as its own identifier and selected from the reserved optional sub-TLVs A sub-TLV carries information about virtual neighbors. For the convenience of subsequent description, the sub-TLV used to carry the related information of the virtual neighbor is referred to as the virtual neighbor sub-TLV, or SR virtual-adjacent sub-TLV (SR Virtual-Adj SID sub TLV).

If the neighbor relationship in the TLV 22 issued by the node is a normal neighbor relationship, the neighbor identifier can be directly set to the identifier of other nodes that have a neighbor relationship with the node, and the cost value field is used to indicate the routing cost of the neighbor relationship.

That is, in the embodiment of the present application, whether the neighbor indicated in the TLV 22 is a virtual neighbor or a normal neighbor in the domain can be determined by whether the neighbor identifier in the TLV 22 issued by the node is the node itself.

It should be noted that, other methods may also be used to indicate whether the current neighbor is a virtual neighbor or a normal neighbor in the domain. For example, the neighbor identifier can be set to a specific value, assuming 0 to indicate that the current neighbor is a virtual neighbor. Alternatively, other fields in the TLV 22 are used to indicate whether the current neighbor is a virtual neighbor or a normal neighbor in the domain, which is not specifically limited in the embodiment of the present application.

FIG. 7 is a schematic diagram of the format of a virtual neighbor sub-TLV provided by an embodiment of the present application. As shown in Figure 7, the virtual neighbor sub-TLV includes type (Type), length (Length), control bits (Flags), weight (Weight), bound path label segment identifier (Binding SID), and neighbor identifier (Neighbor SID) and other fields.

Among them, for any node, the neighbor identifier in the virtual neighbor sub-TLV in TLV22 issued by the node is used to indicate the identifier of the virtual neighbor corresponding to any node, and the segment identifier of the bound path label in the virtual neighbor sub-TLV is used as To indicate the path of any node to the virtual neighbor through the second domain.

In a possible implementation manner, the virtual neighbor function indication information is carried in the control bit field of the virtual neighbor sub-TLV. As shown in Figure 7, the first bit (0 bit) and the second bit (1 bit) of the control bit in the virtual neighbor sub-TLV can be marked as R bit and T bit. Two bits are used to configure the virtual neighbor function indication information. Specifically, if the R bit is set, it indicates that the path label carried by the virtual neighbor sub-TLV is used in the scenario of forwarding packets based on the SR-BE technology. If the T bit is set, it indicates that the path label carried by the virtual neighbor sub-TLV is used in the scenario of forwarding packets based on the SR-TE technology. Therefore, when the first node publishes the TLV 22, the bit values on the R bit and the T bit can be set according to the above configuration, so that the control bit is used to indicate to which scenario the path label carried by the virtual neighbor sub-TLV is applicable.

It should be noted that the virtual neighbor function indication information can also be configured through other bits of the control bit. Alternatively, the virtual neighbor function indication information can also be configured through other fields in the virtual neighbor sub-TLV. The embodiments of this application do not specifically limit this.

After the aforementioned extension of the neighbor relationship TLV, for any first domain, the border node in the first domain can predetermine its neighbor relationship in the second domain, and then advertise the neighbor in the first domain through the neighbor relationship TLV Relationship, so that other nodes in the first domain can learn the neighbor relationship of the border node in the second domain.

For example, for the network system shown in FIG. 1, it is assumed that the first domain in step 501 is domain 2 in FIG. 1, and the second domain is domain 1 in FIG. 1. The boundary node ASG1 in the second domain (that is, domain 1), the boundary node ASG1 can first determine the path to ASG2 through related resources in the second domain, such as Link State Database (LSDB), as ASG1 →CSG2→CSG1→CSG3→ASG2, and then generate TLV22 according to the determined path. And publish the TLV22 in the first domain (that is, domain 2). Among them, the neighbor identifier in the published TLV22 is the identifier of the node ASG1. At this time, it indicates that the TLV22 is used to publish a virtual neighbor of ASG1. Among them, the neighbor identifier carried in the virtual neighbor sub-TLV in TLV22 is ASG2, and the path label carried in the virtual neighbor sub-TLV is used to indicate the path: ASG1→CSG2→CSG1→CSG3→ASG2. Obviously, the neighbor relationship between the node ASG1 and the node ASG2 is constructed by the nodes in the second domain. Therefore, the node P1 in the first domain can use the node ASG2 as the virtual neighbor of the node ASG1.

For another example, for the network system shown in FIG. 2, it is assumed that the first domain in step 501 is domain 1 in FIG. 1, and the second domain is domain 2 in FIG. 1. For the node ASG in the second domain (that is, domain 2), you can first use related resources in the second domain (that is, domain 2), such as LSDB, to determine that the path to RSG is ASG→RSG, and then determine The path is a TE tunnel. Then generate TLV22 according to the determined path. And publish the TLV22 in the first domain (that is, domain 1). Among them, the neighbor identifier in the published TLV22 is the identifier of the node ASG. At this time, it indicates that the TLV22 is used to publish a virtual neighbor of the ASG. Among them, the neighbor identifier carried in the virtual neighbor sub-TLV in TLV22 is RSG, and the path label carried in the virtual neighbor sub-TLV is used to indicate the path: ASG→RSG. Obviously, the neighbor relationship between the node ASG and the node RSG is constructed through the TE tunnel in the second domain (that is, domain 2). Therefore, the node CSG in the first domain can use the node RSG as the virtual neighbor of the node ASG.

Based on the foregoing modification to the neighbor relationship TLV, the first node can obtain the neighbor relationship of each node in the first domain through the following steps 502 to 504.

In addition, as shown in Figure 7, when the T bit in the control bit in the virtual neighbor sub-TLV is set, that is, when the path label carried by the virtual neighbor sub-TLV is used in the scenario of forwarding packets based on the SR-TE technology At this time, the virtual neighbor sub-TLV may also include the Neighbor Label Switched Router Identification (Neighbor LSR-ID) field. The identification field of the label switching router of the neighbor is used to identify the IP of the virtual neighbor. In the scenario of forwarding packets based on SR-TE technology, the Neighbor LSR-ID of the virtual neighbor needs to be determined, and then the Neighbor LSR of the virtual neighbor must be determined. -Whether the ID is the destination IP of the tunnel, if it is, it indicates that the virtual neighbor is the destination node of the message, and then it can stop executing the operation of setting the next hop node of the virtual neighbor, that is, stop determining the path .

Step 502: In the case that the link between the first node and the next-hop node indicated in the message fails, for the second node among the nodes in the first domain, from one or more of the second nodes One neighbor relationship TLV is selected from among the neighbor relationship TLVs, and the neighbor identifier in the selected neighbor relationship TLV is obtained, and the second node is any one of the nodes.

In the SRv6 technology, a routing policy has been deployed in the header of the message to indicate each node through which the message passes. Therefore, when the first node receives the message, it can determine the next hop node from the header of the message, and then forward the message to the next hop node indicated in the message. In the event that the link between the first node and the next-hop node indicated in the message fails, the first node can determine a backup path through steps 502 to 505 to ensure that the message can be successfully forwarded To the destination node.

Based on step 501, since the neighbor identifier in the neighbor relationship TLV can be used to indicate whether the current neighbor is a virtual neighbor or a normal node in the domain, for any node in the first domain, when the first node needs to obtain the node's In the case of a neighbor relationship, the first node needs to first obtain the neighbor identifier in the neighbor relationship TLV issued by the node.

In addition, since the same node may pre-publish multiple neighbor relationship TLVs, that is, for the second node, there may be multiple neighbor relationship TLVs. Therefore, one needs to be selected from one or more neighbor relationship TLVs of the second node. The neighbor relationship TLV is then obtained, and the neighbor identifier in the selected neighbor relationship TLV is obtained, so as to determine the neighbor relationship indicated in the currently selected neighbor relationship TLV through the following

steps

503 and 504. For other neighbor relationship TLVs of the second node, the neighbor relationship can be determined by referring to the foregoing manner.

Step 503: In the case that the neighbor identifier carried in the selected neighbor relationship TLV indicates a virtual neighbor, the virtual neighbor sub-TLV is obtained from the selected neighbor relationship TLV, and the second is determined according to the neighbor identifier and path label carried in the virtual neighbor sub-TLV. A neighbor relationship of the node.

Among them, the virtual neighbor sub-TLV carries a neighbor identifier and a path label, the neighbor identifier carried by the virtual neighbor sub-TLV is used to indicate the identifier of the virtual neighbor corresponding to the second node, and the path label carried by the virtual neighbor sub-TLV is used to indicate that the second node reaches the virtual neighbor. The path of the neighbor, and the path from the second node to the virtual neighbor is constructed through link resources in the second domain.

In a possible implementation manner, whether the neighbor indicated in the neighbor relationship TLV is a virtual neighbor or a normal node in the domain is determined by whether the neighbor identifier in the neighbor relationship TLV issued by the node is the node itself. At this time, the implementation process of step 503 may be: if the neighbor identifier carried in the neighbor relationship TLV is the same as the identifier of any node, it is determined that the neighbor identifier carried in the neighbor relationship TLV indicates a virtual neighbor.

Optionally, if it is preset to determine whether the neighbor indicated in the neighbor relationship TLV is a virtual neighbor or a normal neighbor in the domain through other fields in the neighbor relationship TLV, you can also refer to the above method to determine under what circumstances the virtual neighbor needs to be acquired. TLV.

In addition, when the virtual neighbor function indication information in the virtual neighbor sub-TLV is used to indicate which scenario the path label carried by the virtual neighbor sub-TLV is applicable to, the first node obtains the virtual neighbor sub-TLV from the neighbor relationship TLV, and then obtains the virtual neighbor sub-TLV from the virtual neighbor Obtain the virtual neighbor function indication information from the neighbor sub-TLV. Assuming that you are currently in a scenario where packets are forwarded based on the SR-BE technology, if the virtual neighbor function indication information indicates that the virtual neighbor is used in the scenario where packets are forwarded based on the SR-BE technology, then execute the neighbor identification and The path label determines the steps of the neighbor relationship of any node. If the virtual neighbor function indication information indicates that the virtual neighbor is not used in the scenario of forwarding packets based on the SR-BE technology, the forwarding path cannot be determined based on the neighbor relationship. Therefore, the first node will discard the neighbor relationship of the node.

Or, assuming that you are currently in the scenario of forwarding packets based on SR-TE technology, if the virtual neighbor function indication information indicates that the virtual neighbor is used in the scenario of forwarding packets based on SR-TE technology, execute the neighbor based on the virtual neighbor sub-TLV The identification and path label determine the steps of the neighbor relationship of any node. Correspondingly, if the virtual neighbor function indication information indicates that the virtual neighbor is not used in the scenario of forwarding packets based on the SR-TE technology, the forwarding path cannot be determined based on the neighbor relationship. Therefore, the first node will discard the neighbor relationship of the node. .

For example, if the R bit in the control bit of the virtual neighbor sub-TLV is set, it is determined that the virtual neighbor is used in the scenario of forwarding packets based on the SR-BE technology, if the current situation happens to be the scenario of forwarding packets based on the SR-BE technology In the next step, the neighbor relationship of the node is used to determine the forwarding path. Otherwise, this neighbor relationship of the node cannot be used to determine the forwarding path in the next step.

For another example, if the T bit in the control bit of the virtual neighbor sub-TLV is set, it is determined that the virtual neighbor is used in the scenario of forwarding packets based on SR-TE technology. In the scenario, the neighbor relationship of the node is used to determine the forwarding path in the next step. Otherwise, this neighbor relationship of the node cannot be used to determine the forwarding path in the next step.

Step 504: In the case that the neighbor identifier carried in the selected neighbor relationship TLV indicates a normal neighbor, determine a neighbor relationship of the second node according to the selected neighbor relationship TLV.

Among them, the normal neighbor refers to a node that constructs a path with the second node through link resources in the first domain.

In a possible implementation manner, whether the neighbor indicated in the neighbor relationship TLV is a virtual neighbor or a normal node in the domain is determined by whether the neighbor identifier in the neighbor relationship TLV issued by the node is the node itself. At this time, the implementation process of step 504 may be: if the neighbor identifier carried in the neighbor relationship TLV is not the same as the identifier of the node issuing the neighbor relationship TLV, it is determined that the neighbor identifier carried in the neighbor relationship TLV indicates a normal neighbor.

Optionally, if it is preset to determine whether the neighbor indicated in the neighbor relationship TLV is a virtual neighbor or a normal neighbor in the domain by using other fields in the neighbor relationship TLV, the neighbor relationship can also be determined by referring to the foregoing manner.

For example, for the network system shown in Figure 1, assuming that the first node is P1, when the link between P1 and the next hop node RSG1 indicated in the received message fails, P1 can obtain the first domain ( That is, the neighbor relationship of each node in domain 2). The following takes obtaining the neighbor relationship of ASG1, P2, RSG2, and RSG1 in the first domain as an example to illustrate how P1 determines the neighbor relationship of each node in the first domain.

Based on step 501, it can be known that the node ASG1 publishes two TLVs 22 in advance. The neighbor identifier in a TLV22 is the identifier of the node ASG1. At this time, it indicates that the TLV22 is used to publish a virtual neighbor of ASG1. Among them, the neighbor identifier carried in the virtual neighbor sub-TLV in the TLV 22 is ASG2, and the path label carried in the virtual neighbor sub-TLV is used to indicate the path: ASG1→CSG2→CSG1→CSG3→ASG2. Obviously, the neighbor relationship between the node ASG1 and the node ASG2 is constructed by the nodes in the second domain. Therefore, the node P1 can use the node ASG2 as the virtual neighbor of the node ASG1 according to the TLV22.

The neighbor identifier in another TLV22 issued by node ASG1 is node P1, indicating that this TLV22 is used to publish a normal neighbor P1 of ASG2. Therefore, the node P1 can regard the node P1 as a normal neighbor of the node ASG1 according to the TLV22.

In addition, the node P2 may pre-publish two TLVs 22, the neighbor identifier in one TLV 22 is the node ASG2, and the neighbor identifier in the other TLV 22 is the node RSG2. The node RSG2 may pre-publish two TLV22, the neighbor identifier in one TLV22 is the node P2, and the neighbor identifier in the other TLV22 is the node RSG1. The node RSG1 may pre-publish two TLVs 22, the neighbor identifier in one TLV 22 is the node P1, and the neighbor identifier in the other TLV 22 is the node RSG2. The node P1 can also determine the neighbor relationship of each node in the first domain (that is, domain 2 in FIG. 1) according to the above-mentioned TLV22.

For another example, for the network system shown in FIG. 2, assuming that the first node is a CSG, the CSG can obtain the neighbor relationship of each node in the first domain (that is, domain 1). In the network system shown in FIG. 2, there is only one ASG in addition to the CSG in the first domain. The neighbor identifier in a TLV22 pre-published by the node ASG is the identifier of the node ASG. At this time, it indicates that the TLV22 is used to publish a virtual neighbor of the ASG. Among them, the neighbor identifier carried in the virtual neighbor sub-TLV in TLV22 is RSG, and the path label carried in the virtual neighbor sub-TLV is used to indicate the path: ASG→RSG. Obviously, the neighbor relationship between the node ASG and the node RSG is constructed through the tunnel in the second domain. Therefore, the node CSG in the first domain can use the node RSG as the virtual neighbor of the node ASG.

Step 505: The first node determines the forwarding path of the message according to one or more neighbor relationships of each node in the first domain, and forwards the message according to the determined forwarding path.

In a possible implementation manner, the implementation process of step 505 can be: starting from the first node, the first node sequentially executes the steps of determining the next hop node in the forwarding path according to the neighbor relationship of the current node, until it is determined The next hop node is the destination node of the message. The path formed by the first node and each determined next-hop node is the forwarding path of the message.

The foregoing first node determines the optimal neighbor relationship to the destination node from one or more neighbor relationships of the current node. The implementation manner may be: the current node is a boundary node, and the optimal neighbor relationship is the neighbor of the current node in the second domain. In the case where the path between the current node and the node indicated by the optimal neighbor relationship has unidirectional reachability, the node indicated by the optimal neighbor relationship is determined as the next hop node of the current node.

In the embodiment of the present application, for any two nodes in the first domain, it is usually necessary for the two nodes to have bidirectional reachability between them before establishing a path from one node to another node. The two-way reachability between node A and node B means that node A advertises a neighbor relationship to node B, and node B also advertises a neighbor relationship to node A. However, for the neighbor relationship based on virtual neighbors, the forwarding path is usually re-determined when the current link fails. At this time, it does not need to have two-way reachability. It can be based on only one-way reachability. The neighbor relationship determines the forwarding path, thereby improving the efficiency of re-determining the forwarding path.

In addition, for the first node and other nodes other than the boundary node among the determined next hop nodes, determine the two-way reachability between the nodes indicated in the neighbor relationship between other nodes and other nodes, if other nodes are The nodes indicated in the neighbor relationship of other nodes have bidirectional reachability, and the node indicated in the neighbor relationship of other nodes is determined as the next hop node of the other node.

Of course, for the first node and the nodes other than the border node among the determined next hop nodes, the forwarding path can be determined based on the neighbor relationship after only one-way reachability, thereby improving Re-determine the efficiency of the forwarding path. The embodiment of the application does not specifically limit this.

Optionally, for the first node and any one of the determined next-hop nodes, the node may also be reachable in both directions when the node indicated in the neighbor relationship between the node and the node has two-way reachability. The node indicated in the neighbor relationship of is determined as the next hop node of the node. That is, no matter whether the neighbor of the node is a normal neighbor or a virtual neighbor, the neighbor of the node is determined as the next hop node of the node after checking the two-way reachability between the node and the neighbor of the node. .

In addition, the method for the first node to determine the optimal neighbor relationship to the destination node from one or more neighbor relationships of the current node can be as follows: determine the cost value of each neighbor relationship in the one or more neighbor relationships, from this Select the neighbor relationship with the smallest cost value among one or more neighbor relationships. The cost value has been explained in the above-mentioned related content of introducing TLV22, and the explanation will not be repeated here.

In addition, in step 505, because the link between the first node and the next hop node indicated in the message has failed, the first node needs to exclude the message when determining its own next hop node. The next hop node indicated in to ensure that the finally determined path can be successfully used to forward the message.

The embodiment shown in Figure 5 above uses virtual neighbor sub-TLVs to indicate the neighbor relationship of border nodes in the first domain in the second domain, so that the first node can determine the forwarding path in combination with link resources in the second domain. , To avoid the problem that packets cannot be forwarded when there is no backup path in the current domain. In the scenario of forwarding packets based on the SR-TE technology, each node can also advertise the neighbor relationship through the neighbor sub-TLV (Adj-SID Sub TLV) in the neighbor relationship TLV. For the neighbor relationship TLV shown in Fig. 6, the neighbor sub-TLV can be implemented by one of one or more optional sub-TLVs (not shown in Fig. 6). That is, in the scenario of forwarding packets based on the SR-TE technology, the neighbor relationship TLV originally carries a neighbor sub-TLV, and the neighbor sub-TLV is used to indicate the neighbor relationship in the domain. Therefore, in the embodiment of this application, in the scenario of forwarding packets based on SR-TE technology, the neighbor sub-TLV in the neighbor relationship TLV can also be directly reconfigured, so that the neighbor sub-TLV can carry neighbors in this domain. The relationship function can also carry a cross-domain neighbor relationship, so that nodes in the first domain can establish tunnels between nodes in the second domain, that is, to establish a cross-domain tunnel. The implementation will be explained in detail below.

FIG. 8 is a flowchart of another method for forwarding packets provided by an embodiment of the present application, which is applied to any node in the network system shown in FIG. 2. As shown in Figure 8, the method includes the following steps:

Step 801: The first node receives the message, the first node is any node in the first domain, and the first domain is any domain among multiple domains in the network.

For the implementation of step 801, reference may be made to the implementation of step 401 in the embodiment of FIG. 4, which will not be described in detail here.

In the embodiment of the present application, in the scenario of forwarding packets based on the SR-TE technology, in order to be able to establish a cross-domain tunnel, for any node in the second domain, first allow the node to publish the neighbor relationship TLV in the first domain The neighbor identifier in can indicate neighbors in the second domain, and the neighbor sub-TLV in the neighbor relationship TLV is extended, so that the neighbor sub-TLV can carry the neighbor relationship between the node and the neighbor.

That is, for the embodiment shown in FIG. 8, for the neighbor relationship TLV issued by the second node in the first domain, the neighbor flag in the neighbor relationship TLV may directly indicate a neighbor of the second node, and the neighbor may be The neighbors of the first node in the same domain may also be neighbors that are not in the same domain with the first node. Instead of using the neighbor identifier in the neighbor relationship TLV to indicate whether the neighbor is a cross-domain neighbor as in the embodiment shown in FIG. 4.

For example, for the network system shown in FIG. 2, for the node ASG, the ASG can create an SR-TE tunnel to the RSG, and the SR-TE tunnel can be determined by the LSDB in the second domain. Then, the ASG configures a neighbor relationship (Forwarding Adjacency, FA) for the SR-TE tunnel. Among them, configuring the neighbor relationship refers to generating a neighbor relationship TLV including neighbor sub-TLVs, and setting the neighbor identifier in the neighbor relationship TLV to RSG, and then publishing the neighbor relationship TLV so that the CSG in the first domain can pass the following step 802 Go to step 803 to determine the forwarding path to the RSG based on the neighbor relationship.

In addition, because the neighbor relationship is usually used to determine the backup path when the link fails, it is usually not necessary to have two-way reachability between the two nodes to establish the path when determining the forwarding path. Therefore, you can also The neighbor sub-TLV in the neighbor relationship TLV is modified so that the first node can confirm the path only after checking that the unidirectional reachability is satisfied when determining the forwarding path based on the neighboring sub-TLV.

For example, for the network system shown in Figure 2, after the ASG generates the neighbor sub-TLV for indicating the TE tunnel to the RSG, if the neighbor relationship TLV carrying the neighbor sub-TLV is currently released in domain 1, the ASG can send the neighbor The O bit in the control bit in the sub-TLV is set, so that when the node CSG in the subsequent domain 1 obtains the neighbor relationship, it can confirm the path only after checking that the unidirectional reachability is satisfied.

In addition, the neighbor relationship sub-TLV will carry other one or more sub-TLVs as needed according to the configuration of the cross-domain neighbor relationship, and these one or more sub-TLVs are used to describe some attributes of the cross-domain neighbor relationship. For example, attributes such as maximum link bandwidth, maximum reserved bandwidth, unreserved bandwidth, and TE tunnel cost value. Among them, the other one or more sub-TLVs can be implemented through sub-TLV 9/10/11/18 in TLV22.

For example, when the neighbor relationship TLV is TLV22 shown in FIG. 6, the neighbor identifier in the TLV22 is used to indicate a neighbor of the node that publishes the TLV22, and the TLV22 also includes a neighbor sub-TLV, and the neighbor sub-TLV may be as shown in FIG. 6. One of the optional sub-TLVs (not shown in Figure 6). FIG. 9 is a schematic diagram of the format of a neighbor sub-TLV provided by an embodiment of the present application. As shown in Figure 9, the neighbor sub-TLV includes fields such as type, length, control bits, weight, and SID/Label/Index. The SID/label/index field is used to indicate the label of the established cross-domain tunnel, that is, the SID/label/index field is used to indicate the node issuing the neighbor relationship TLV and the neighbor identifier in the neighbor relationship TLV indicated Tunnel between nodes. The O bit in the control bit is used to indicate that only one-way reachability needs to be checked when establishing a tunnel.

In addition, F, B, V, L, S, and P in the control bits shown in FIG. 9 are the bits that have been defined in the protocol. Among them, the F bit is the address family flag. If the F bit is not set, it represents IPv4; if the F bit is set, it represents IPv6. The B bit is a backup flag. If the B bit is set, the Adj-SID (referring to the neighbor identifier in the TLV22 in this embodiment) is used to protect other nodes. The V bit is the Value flag. If the V bit is set, the Adj-SID carries the tag value Value, which is set by default. L: Local logo. If set, it means that the Value/Index carried by the Adj-SID has local meaning and is set by default. The S bit is a sequence flag. If the S bit is set, it means that the Adj-SID is an Adjacency sequence. The P bit refers to a permanent flag. If the P bit is set, it means that the Adj-SID is a permanently allocated SID, and the SID will not change regardless of device restart or interface shock. Regarding the detailed function description of these bits in the control bit, you can refer to the relevant protocol, which will not be explained one by one here.

In addition, step 802: For the second node in each node in the first domain, select a neighbor relationship TLV from one or more neighbor relationship TLVs of the second node, and obtain neighbor sub-TLVs in the selected neighbor relationship TLV, and neighbor sub-TLVs. The TLV is used to indicate the neighbor relationship from the second node to the third node. The third node is a node in the first domain or the second domain, and the second node is any node in each node in the first domain.

Based on the above modification to the neighbor relationship TLV, it can be seen that in the scenario of forwarding packets based on the SR-TE technology, a neighbor can be determined by the neighbor identifier in the neighbor relationship TLV, and the forwarding path to the neighbor can be determined by the neighbor sub-TLV in the neighbor relationship TLV. . Therefore, for each neighbor relationship TLV in one or more neighbor relationship TLVs of any second node, the first node needs to first obtain neighbor sub-TLVs from the neighbor relationship TLV.

For the network system shown in Figure 2, assuming that the first node is a CSG, the current CSG needs to create a path to the RSG. At this time, the CSG needs to first obtain the neighbor relationship TLV issued by the ASG. The neighbor identifier in the neighbor relationship TLV issued by the ASG is used to indicate the RSG, that is, the third node is the RSG at this time. The SID/tag/index field included in the neighbor sub-TLV in the neighbor relationship TLV is used to indicate the tunnel from the ASG to the RSG.

Step 803: The first node determines a forwarding path of the message according to one or more neighbor relationships of each node in the first domain, and forwards the message according to the determined forwarding path.

For example, for the network system shown in Figure 2, suppose the first node is a CSG, and the current CSG needs to create a path to the RSG. At this time, the CSG first creates a TE tunnel to the ASG based on the neighbor relationship with the ASG, and then passes Neighbor relationship between ASG and RSG, creating a TE tunnel from ASG to RSG.

And when CSG creates the TE tunnel from ASG to RSG, because the O bit of the control bit in the neighbor sub-TLV in the neighbor relationship TLV released by the ASG is set, only the one-way reachability from ASG to RSG needs to be checked. .

FIG. 10 is a schematic diagram of an apparatus of a first node according to an embodiment of the present application. As shown in FIG. 10, the first node 1000 includes:

The receiving module 1001 is configured to receive a message, the first node is any node in the first domain, and the first domain is any one of multiple domains in the network;

The obtaining module 1002 is used to obtain one or more neighbor relations of each node in the first domain. The one or more neighbor relations of the border nodes in the first domain include the neighbor relations of the border nodes in the second domain. A domain outside of one domain;

The determining module 1003 is configured to determine a forwarding path to the destination node of the message according to one or more neighbor relationships of each node in the first domain;

The forwarding module 1004 is configured to forward the message according to the determined forwarding path.

Optionally, the aforementioned acquisition module is specifically used for:

For the second node of each node, select a neighbor relationship TLV from one or more neighbor relationship type-length-value TLVs of the second node, and obtain the neighbor identifier in the selected neighbor relationship TLV. The second node is each node Any node in;

In the case that the neighbor identifier carried in the selected neighbor relationship TLV indicates a virtual neighbor, the virtual neighbor sub-TLV is obtained from the selected neighbor relationship TLV, the virtual neighbor sub-TLV carries the neighbor identifier and path label, and the neighbor carried by the virtual neighbor sub-TLV The identifier is used to indicate the identifier of the virtual neighbor corresponding to the second node. The path label carried by the virtual neighbor sub-TLV is used to indicate the path of the second node to the virtual neighbor. The path of the second node to the virtual neighbor is through a link in the second domain. Resource-based

Determine a neighbor relationship of the second node according to the neighbor identifier and the path label carried in the virtual neighbor sub-TLV.

Optionally, the aforementioned acquisition module is further specifically configured to: in the case that the neighbor identifier carried in the selected neighbor relationship TLV indicates a normal neighbor, determine a neighbor relationship of the second node according to the selected neighbor relationship TLV, and the normal neighbor is Refers to a node that constructs a path through link resources in the first domain and the second node.

Obtain virtual neighbor function indication information from the virtual neighbor sub-TLV;

When the virtual neighbor function indication information indicates that the virtual neighbor is used in the scenario of forwarding packets based on the segment routing optimal path SR-BE technology, and the current situation is in the scenario of forwarding packets based on the SR-BE technology, the virtual neighbor is executed according to the virtual neighbor The step of determining a neighbor relationship of the second node by the neighbor identifier and path label carried by the sub-TLV.

When the virtual neighbor function instruction information indicates that the virtual neighbor is used in the scenario of forwarding packets based on the segmented routing process engineering SR-TE technology, and the current situation is in the scenario of forwarding packets based on the SR-TE technology, the virtual neighbor is executed according to the virtual neighbor. The step of determining a neighbor relationship of the second node by the neighbor identifier and the path label carried in the TLV.

Optionally, the virtual neighbor function indication information is carried in the control bit field of the virtual neighbor sub-TLV.

For the second node in each node, select a neighbor relationship TLV from one or more neighbor relationship TLVs of the second node, and obtain the neighbor sub-TLV in the selected neighbor relationship TLV. The neighbor sub-TLV is used to indicate the second node to the second node. The neighbor relationship of three nodes, the third node is a node in the first domain or the second domain, and the second node is any node in each node.

Starting from the first node, the first node sequentially executes the steps of determining the next hop node of the current node according to one or more neighbor relationships of the current node, until the next hop node is determined as the destination node of the message, the result is The forwarding path of the packet.

Determine the optimal neighbor relationship to the destination node from one or more neighbor relationships of the current node;

When the current node is a boundary node, the optimal neighbor relationship is the neighbor relationship of the current node in the second domain, and the path between the current node and the node indicated by the optimal neighbor relationship has unidirectional reachability, the most The node indicated by the good neighbor relationship is determined as the next hop node of the current node.

In the case that the link between the first node and the next-hop node indicated in the message is faulty, obtain one or more neighbor relationships of each node in the first domain.

In the embodiment of the present application, in order to realize that nodes in a certain domain can determine the forwarding path across domains, the neighbor relationship of the border node in the first domain acquired by the first node includes the neighbor relationship of the border node in the second domain. It is a domain other than the first domain. In this way, the first node can determine the forwarding path based on the neighbor relationship of the border node in the second domain. That is, the first node can use other than the first domain when determining the forwarding path. Link resources in other domains other than the link resources of the domain, thereby avoiding the problem that messages cannot be forwarded when there is no backup path in the current domain, thereby improving the success rate of message forwarding.

It should be noted that when the first node provided in the above embodiment forwards a message, only the division of the above functional modules is used as an example for illustration. In actual applications, the above function allocation can be completed by different functional modules according to needs. That is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the first node provided in the foregoing embodiment belongs to the same concept as the embodiment of the method for forwarding a message. For the specific implementation process, please refer to the method embodiment, which will not be repeated here.

FIG. 11 is a schematic diagram of a boundary node device provided by an embodiment of the present application. The boundary node is a boundary node between a first domain and a second domain. As shown in FIG. 11, the boundary node 1100 includes:

The determining module 1101 is used to determine the neighbor relationship TLV, and the neighbor relationship TLV is used to indicate the neighbor relationship of the border node in the second domain;

The publishing module 1102 is used to publish the neighbor relationship TLV in the first domain.

Optionally, in the case where the neighbor identifier carried in the neighbor relationship TLV indicates a virtual neighbor, the neighbor relationship TLV includes a virtual neighbor sub-TLV, the virtual neighbor sub-TLV carries the neighbor identifier and path label, and the neighbor identifier carried in the virtual neighbor sub-TLV is used for To indicate the identifier of the virtual neighbor corresponding to the border node, the path label carried by the virtual neighbor sub-TLV is used to indicate the path of the border node to the virtual neighbor, and the path from the border node to the virtual neighbor is constructed through link resources in the second domain.

Optionally, the neighbor relationship TLV includes a neighbor sub-TLV, and the neighbor sub-TLV is used to indicate the neighbor relationship from the border node to the third node, and the third node is a node in the first domain or the second domain.

It should be noted that when the boundary node provided in the foregoing embodiment forwards a message, only the division of the foregoing functional modules is used as an example for illustration. In actual applications, the foregoing function allocation can be completed by different functional modules according to needs, i.e. The internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the boundary node provided in the foregoing embodiment and the method embodiment for forwarding a message belong to the same concept. For the specific implementation process, please refer to the method embodiment, which will not be repeated here.

FIG. 12 is a schematic structural diagram of a computer device provided by an embodiment of the present invention. Any node in the network system of the foregoing embodiment can be implemented by the computer device shown in FIG. 12. Referring to FIG. 12, the computer device includes at least one processor 1201, a communication bus 1202, a memory 1203, and at least one communication interface 1204.

The processor 1201 may be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling program execution of the solution of this application.

The communication bus 1202 may include a path for transferring information between the above-mentioned components.

The memory 1203 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (RAM), or other types that can store information and instructions The dynamic storage device can also be electrically erasable programmable read-only memory (EEPROM), compact disc read-only Memory (CD-ROM) or other optical disc storage, optical disc storage (Including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, or can be used to carry or store desired program codes in the form of instructions or data structures and can be accessed by a computer Any other media, but not limited to this. The memory 1203 may exist independently, and is connected to the processor 1201 through the communication bus 1202. The memory 1203 may also be integrated with the processor 1201.

Among them, the memory 1203 is used to store program codes for executing the solutions of the present application, and the processor 1201 controls the execution. The processor 1201 is configured to execute program codes stored in the memory 1203. The program code may include one or more software modules, and any node in the foregoing embodiments may determine the data used to develop the application through one or more software modules in the program code in the processor 1201 and the memory 1203.

The communication interface 1204 uses any device such as a transceiver to communicate with other devices or communication networks, such as Ethernet, radio access network RAN, wireless local area networks (WLAN), and so on.

In specific implementation, as an embodiment, the computer device may include multiple processors, such as the processor 1201 and the processor 1205 shown in FIG. 12. Each of these processors can be a single-CPU (single-CPU) processor or a multi-core (multi-CPU) processor. The processor here may refer to one or more devices, circuits, and/or processing cores for processing data (for example, computer program instructions).

In the above-mentioned embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, it can be implemented in the form of a computer program product in whole or in part. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on the computer, the processes or functions according to the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center. Transmission to another website, computer, server or data center via wired (for example: coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (for example: infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrated with one or more available media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a digital versatile disc (DVD)), or a semiconductor medium (for example, a solid state disk (SSD)) )Wait.

A person of ordinary skill in the art can understand that all or part of the steps in the above embodiments can be implemented by hardware, or by a program to instruct relevant hardware. The program can be stored in a computer-readable storage medium. The storage medium mentioned can be a read-only memory, a magnetic disk or an optical disk, etc.

The above-mentioned examples provided for this application are not intended to limit this application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included in the protection scope of this application. Inside.

Claims

A method for forwarding messages, characterized in that the method includes:

A first node receives the message, the first node is any node in a first domain, and the first domain is any domain among multiple domains in the network;

The first node obtains one or more neighbor relationships of each node in the first domain, and the one or more neighbor relationships of border nodes in the first domain include neighbor relationships of the border nodes in the second domain, so The second domain is a domain other than the first domain;

Determining, by the first node, a forwarding path to the destination node of the message according to one or more neighbor relationships of each node in the first domain;

The first node forwards the message according to the determined forwarding path.
The method according to claim 1, wherein the first node acquiring one or more neighbor relationships of each node in the first domain comprises:

For the second node in each of the nodes, select a neighbor relationship TLV from one or more neighbor relationship type-length-value TLVs of the second node, and obtain the neighbor identifier in the selected neighbor relationship TLV, the The second node is any one of the nodes;

In the case where the neighbor identifier carried in the selected neighbor relationship TLV indicates a virtual neighbor, a virtual neighbor sub-TLV is obtained from the selected neighbor relationship TLV, and the virtual neighbor sub-TLV carries the neighbor identifier and the path label, so The neighbor identifier carried by the virtual neighbor sub-TLV is used to indicate the identifier of the virtual neighbor corresponding to the second node, and the path label carried by the virtual neighbor sub-TLV is used to indicate the path of the second node to the virtual neighbor, The path for the second node to reach the virtual neighbor is constructed through link resources in the second domain;

Determine a neighbor relationship of the second node according to the neighbor identifier and the path label carried by the virtual neighbor sub-TLV.
The method according to claim 2, wherein in the case that the neighbor identifier carried in the selected neighbor relationship TLV is the same as the identifier of the second node, the neighbor relationship carried in the selected neighbor relationship TLV The logo indicates a virtual neighbor.
The method according to claim 2, wherein after obtaining the neighbor identifier in the selected neighbor relationship TLV, the method further comprises: when the neighbor identifier carried in the selected neighbor relationship TLV indicates a normal neighbor Determine a neighbor relationship of the second node according to the selected neighbor relationship TLV, and the normal neighbor refers to a node that constructs a path with the second node through link resources in the first domain.
The method according to claim 4, wherein in the case that the neighbor identifier carried in the selected neighbor relationship TLV is different from the identifier of the second node, the selected neighbor relationship TLV carries The neighbor identifier indicates a normal neighbor.
The method according to any one of claims 2 to 5, wherein after obtaining a virtual neighbor sub-TLV from the selected neighbor relationship TLV, the method further comprises:

Acquiring virtual neighbor function indication information from the virtual neighbor sub-TLV;

In the case where the virtual neighbor function indication information indicates that the virtual neighbor is used in the scenario of forwarding packets based on the segment routing optimal path SR-BE technology, and is currently in the scenario of forwarding packets based on the SR-BE technology, A step of determining a neighbor relationship of the second node according to the neighbor identifier and the path label carried by the virtual neighbor sub-TLV is performed.
The method according to any one of claims 2 to 5, wherein after obtaining a virtual neighbor sub-TLV from the selected neighbor relationship TLV, the method further comprises:

Acquiring virtual neighbor function indication information from the virtual neighbor sub-TLV;

When the virtual neighbor function indication information indicates that the virtual neighbor is used in the scenario of forwarding packets based on the segmented routing process engineering SR-TE technology, and is currently in the scenario of forwarding packets based on the SR-TE technology, execute The step of determining a neighbor relationship of the second node according to the neighbor identifier and the path label carried by the virtual neighbor sub-TLV.
The method according to claim 6 or 7, wherein the virtual neighbor function indication information is carried in a control bit field of the virtual neighbor sub-TLV.
The method according to claim 1, wherein the first node acquiring one or more neighbor relationships of each node in the first domain comprises:

For the second node in each node, select a neighbor relationship TLV from one or more neighbor relationship TLVs of the second node, and obtain a neighbor sub-TLV in the selected neighbor relationship TLV, and the neighbor sub-TLV is used for Indicates the neighbor relationship between the second node and the third node, where the third node is a node in the first domain or the second domain, and the second node is any one of the nodes .
The method according to any one of claims 1 to 9, wherein the first node determines the forwarding path of the message according to one or more neighbor relationships of each node in the first domain, comprising:

Starting from the first node, the first node sequentially executes the step of determining the next hop node of the current node according to one or more neighbor relationships of the current node, until the determined next hop node is the When the destination node of the message, the forwarding path of the message is obtained.
The method according to claim 10, wherein the determining the next hop node of the current node according to one or more neighbor relationships of the current node comprises:

Determining the optimal neighbor relationship to the destination node from one or more neighbor relationships of the current node;

The current node is a boundary node, the optimal neighbor relationship is the neighbor relationship of the current node in the second domain, and the path between the current node and the node indicated by the optimal neighbor relationship In the case of unidirectional reachability, the node indicated by the optimal neighbor relationship is determined as the next hop node of the current node.
The method according to any one of claims 1 to 11, wherein the first node acquiring one or more neighbor relationships of each node in the first domain comprises:

In the case that the link between the first node and the next hop node indicated in the message is faulty, obtain one or more neighbor relationships of each node in the first domain.
A method for forwarding messages, characterized in that the method includes:

The border node between the first domain and the second domain determines a neighbor relationship TLV, where the neighbor relationship TLV is used to indicate the neighbor relationship of the border node in the second domain;

The border node publishes the neighbor relationship TLV in the first domain.
The method according to claim 13, wherein in the case that the neighbor identifier carried in the neighbor relationship TLV indicates a virtual neighbor, the neighbor relationship TLV includes a virtual neighbor sub-TLV, and the virtual neighbor sub-TLV carries Neighbor ID and path label, the neighbor ID carried by the virtual neighbor sub-TLV is used to indicate the ID of the virtual neighbor corresponding to the border node, and the path label carried by the virtual neighbor sub-TLV is used to indicate that the border node arrives at the border node. The path of the virtual neighbor, and the path from the border node to the virtual neighbor is constructed through link resources in the second domain.
The method according to claim 14, wherein in the case that the neighbor identifier carried in the neighbor relationship TLV is the same as the identifier of the border node, the neighbor identifier carried in the neighbor relationship TLV indicates a virtual neighbor .
The method according to claim 13, wherein the neighbor relationship TLV includes a neighbor sub-TLV, and the neighbor sub-TLV is used to indicate the neighbor relationship from the border node to a third node, and the third node is A node in the first domain or the second domain.
A first node in a communication network, wherein the first node is any node in a first domain, the first domain is any one of a plurality of domains in the network, and the first The node includes a memory and a processor;

The memory is used to store a computer program;

The processor is configured to execute a computer program stored in the memory to execute the following method for forwarding messages:

Receive message;

Obtain one or more neighbor relationships of each node in the first domain, the one or more neighbor relationships of border nodes in the first domain include neighbor relationships of the border nodes in a second domain, and the second domain is Domains other than the first domain;

Determine a forwarding path to the destination node of the message according to one or more neighbor relationships of each node in the first domain;

The message is forwarded according to the determined forwarding path.
A boundary node in a communication network, wherein the boundary node is a boundary node between a first domain and a second domain, and the boundary node includes a memory and a processor;

The memory is used to store a computer program;

The processor is configured to execute a computer program stored in the memory to execute the following method for forwarding messages:

Determining a neighbor relationship TLV, where the neighbor relationship TLV is used to indicate the neighbor relationship of the border node in the second domain;

Publish the neighbor relationship TLV in the first domain.
A system for forwarding messages, characterized in that the system includes a first node and a second node, the first node is any node in the first domain, and the second node is the first domain and The boundary node between the second domain;

The second node is used to determine a neighbor relationship TLV, and the neighbor relationship TLV is used to indicate the neighbor relationship of the border node in the second domain, and publish the neighbor relationship TLV in the first domain;

The first node is used to receive the neighbor relationship TLV.