P2MP tree connectivity detection method, device, and system

Abstract

The present application provides a P2MP tree connectivity detection method, device, and system. The method is applied to an SR domain. The SR domain includes a P2MP tree. The P2MP tree includes a first node. The first node is a root node or an intermediate replication node of the P2MP tree. The method includes the first node determining a first next-hop node of the first node based on replication branch information, and the first node sending a first request message to the first next-hop node. The first request message includes a segment identifier (SID) of the first next-hop node. The first request message includes a first identifier. The first identifier indicates that the first request message is for connectivity detection.

Description

Technical Field

[0001] This application claims priority to Chinese Patent Application No. 202010725197.0, titled "Packet Detection Method, Device, and System", filed with the China National Intellectual Property Administration on July 24, 2020, and claims priority to Chinese Patent Application No. 202011035873.8, titled "P2MP Tree Connectivity Detection Method, Device, and System", filed with the China National Intellectual Property Administration on September 27, 2020. The aforementioned Chinese patent applications are hereby incorporated by reference in their entirety into this specification.

[0002] This application relates to the field of communications, and more specifically, to a point-to-multipoint (P2MP) tree connectivity detection method, device, and system.

Background Art

[0003] A replication segment provides a building block for P2MP services. For example, a P2MP tree is constructed by connecting replication segments on nodes within a segment routing domain. An ingress node, serving as the root node of the P2MP tree, replicates packets so that point-to-multipoint transmission of the packets can be carried out by the P2MP tree within the SR domain, and sends the packets to an egress node through one or more intermediate replication nodes. Different from traditional Internet Protocol (IP) multicast technology, this technology does not use a multicast group address as the destination address of the packets and does not need to use Protocol Independent Multicast (PIM) to establish a multicast forwarding tree and multicast forwarding entries. Therefore, it is possible to reduce network load and improve packet transfer efficiency.

[0004] However, currently there is no way to detect the connectivity of P2MP trees within an SR domain, and connectivity detection on P2MP trees and their associated replication segment paths is not possible. [Overview of the Initiative] [Means for solving the problem]

[0005] This application provides a P2MP tree connectivity detection method, device, and system for performing connectivity detection on a P2MP tree and on a replication segment path associated with the P2MP tree.

[0006] According to a first aspect, the present application provides a P2MP tree connectivity detection method. The method is applied to an SR domain, which includes a P2MP tree. It will be understood that the P2MP tree is constructed by concatenating replica segments on nodes within the SR domain. The P2MP tree includes a first node, which is the root node or an intermediate replica node of the P2MP tree. The method includes the first node determining the first next-hop node of the first node based on replica branch information. The first node sends a first request message to the first next-hop node, the first request message including the segment identifier (SID) of the first next-hop node, the first request message including a first identifier, the first identifier indicating that the first request message is for connectivity detection, or the first identifier may be understood to indicate that the first request message is for P2MP tree failure detection or P2MP tree connectivity verification.

[0007] In the method described above, a first request message for connectivity detection is sent on the P2MP tree so that connectivity detection on the P2MP tree in the SR domain is provided in order to perform fault detection on the P2MP tree and the replication segment path associated with the P2MP tree.

[0008] In possible implementations, when the first node is the root node of a P2MP tree and the first next-hop node is a leaf node of a P2MP tree, the first node may, in some cases, determine that the path from the first node to the first next-hop node is established in response to receiving a first response message sent by the first next-hop node, and the first node may, in some cases, determine that the path from the first node to the first next-hop node is broken in response to receiving a first response message in response to a first request message, or in other cases, in response to not receiving a response message in response to a first request message.

[0009] It should be understood that if there is a failure in the path within the P2MP tree, the first request message sent by the root node cannot reach the leaf node. Therefore, the root node also cannot receive the response message sent by the leaf node. In this case, the root node can determine that the path to the leaf node is broken. If the paths within the P2MP tree are connected and free of failures, the first request message is forwarded to the leaf node, the leaf node sends a response message to the root node based on the first request message, and the root node determines, based on the received response message, that the path to the leaf node is connected.

[0010] In possible implementations, when the first node is the root node of a P2MP tree and the first next-hop node is an intermediate replica node of the P2MP tree, the first node may, in some cases, determine that the path from the first node to the leaf node, which passes through the first next-hop node, is connected, in response to receiving a second response message sent by a leaf node on a path passing through the first next-hop node, and the second response message is a response message to the first request message, or, in other cases, determine that the path from the first node to the leaf node is disconnected, in response to not receiving a response message sent by a leaf node on a path passing through the first next-hop node that is a response to the first request message.

[0011] In possible implementations, the replication branch information includes the path from the first node to the downstream nodes, and the first next-hop node is a node on that path. The first node determining its first next-hop node based on the replication branch information includes the first node determining the first next-hop node based on the path identifier.

[0012] In the method described above, the explicit path from the first node to the downstream node is specified in the SR policy; in other words, the replication branch information includes the path from the first node to the downstream node, and the first next-hop node is a node on that path. It should be understood that the first node determines the first next-hop node based on the identifier of the path to the downstream node.

[0013] In possible implementations, the replication branch information includes the segment identifier SID of a downstream node of the first node, the SID includes the SID of the first next-hop node, and the first node determining its first next-hop node based on the replication branch information includes the first node determining the SID of the first next-hop node based on the SID of the downstream node. For example, a downstream node of the first node may be represented not only by the node's Node SID, but also by its neighbor SIDs or by a list of SIDs.

[0014] In the method described above, the replication branch information includes the segment identifier SID of the downstream node of the first node, and the SID includes the SID of the next hop node of the first node. It should be understood that the first node determines the SID of the next hop node of the first node based on the SID of the downstream node.

[0015] In possible implementations, when a SID within a SID is a Segment Routing over IPv6 Segment Identifier (SRv6 SID), the SID of the first next-hop node contains the IPv6 address of the first next-hop node.

[0016] In a possible implementation, the first node can determine multiple next-hop nodes based on replication branch information, for example, it can determine two next-hop nodes called the first next-hop node and the second next-hop node. The first node determines the first and second next-hop nodes based on replication branch information. The first node sends a second request message to the second next-hop node, the second request message containing the SID of the second next-hop node and the first identifier.

[0017] The method described above can be applied to scenarios where the next hop node of the first node is multiple intermediate replication nodes or multiple leaf nodes.

[0018] In possible implementations, the first identifier is used to identify that the first request message is an operation, administration and maintenance (OAM) packet. For example, the first request The message is an Echo Request packet.

[0019] In possible implementations, the first identifier is a User Datagram Protocol (UDP) port number, for example, the UDP destination port number carried in the first request message.

[0020] In possible implementations, the first request message further includes the address of the root node of the P2MP tree, and the root node address is used to indicate the leaf node of the P2MP tree to send a response message in response to the first request message, based on the root node address.

[0021] In possible implementations, the first request message includes a second identifier, which identifies the P2MP tree.

[0022] In possible implementations, the second identifier may be the address of the root node of the P2MP tree or a single integer value, or the second identifier may be a combination of the address of the root node of the P2MP tree and a single integer value. In one example, the integer value may be the Replication-ID of the replication segment. Different P2MP trees with the same root node, and different P2MP trees with different root nodes, can be identified by a globally unique Replication-ID. For example, the global Replication-ID values ​​corresponding to two P2MP trees whose root node is A are 1 and 2, respectively, and the global Replication-ID values ​​corresponding to three P2MP trees whose root node is B are 3, 4, and 5, respectively. In another example, the value may be the Tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. It should be understood that a single P2MP tree is identified together by the Tree ID and the root node. A second identifier may be further used by the leaf nodes to verify the validity of the first request message.

[0023] In possible implementations, the first request message includes a time to live (TTL) or hop limit (HL), where the values ​​of TTL and HL are natural numbers. For example, a root node might set its TTL to 255 and include the TTL value in the first request message so that the first request message is sent to a leaf node.

[0024] In the foregoing method, the root node of the P2MP tree can not only perform connectivity detection for the P2MP by setting the value of TTL or HL, but also perform multi-round detection to further detect the location of the failure.

[0025] According to a second aspect, the present application provides a P2MP tree connectivity detection method. The method is applied to an SR domain. The SR domain includes a P2MP tree. It will be understood that the P2MP tree is constructed by connecting replicated segments on nodes within the SR domain. The P2MP tree includes leaf nodes. The method includes a leaf node receiving a first request message, the first request message including the address of the root node of the P2MP tree and a first identifier, the first identifier indicating that the first request message is for connectivity detection. The leaf node transmits a first response message to the root node based on the address of the root node.

[0026] In the foregoing method, the leaf node of the P2MP tree transmits a response message in response to the first request message so that the implementation of connectivity detection on the P2MP tree within the SR domain is provided for performing connectivity detection on the P2MP tree and on the replicated segment path associated with the P2MP tree.

[0027] In a possible implementation form, the first identifier is First request message for identifying that it is an operation, maintenance and management OAM packet. For example, the first request message is an Echo Request packet.

[0028] In a possible implementation form, the first identifier is a User Datagram Protocol UDP port number, for example, a UDP destination port number.

[0029] In a possible implementation form, before the leaf node sends the first response message to the root node and after the first request message is received, the method further includes the leaf node verifying the validity of the first request message based on a second identifier. The leaf node sends the first response message to the root node in response to a successful validity verification for the second identifier.

[0030] In the foregoing method, the implementation of verifying the validity of the first request message is provided such that, in order to improve the reliability and security of the verification, after verifying the validity of the first request message, the leaf node sends a response message to the root node.

[0031] In possible implementations, the second identifier is the address of the root node of the P2MP tree and / or a single integer value. In one example, the second identifier is the address of the root node of the P2MP tree. In another example, the second identifier is a single integer value. In yet another example, the second identifier is a combination of the address of the root node of the P2MP tree and a single integer value. For example, the integer value is the Replication-ID of the replication segment. Different P2MP trees with the same root node, and different P2MP trees with different root nodes, can be identified by a globally unique Replication-ID. For example, the global Replication-ID values ​​corresponding to two P2MP trees whose root node is A are 1 and 2, respectively, and the global Replication-ID values ​​corresponding to three P2MP trees whose root node is B are 3, 4, and 5, respectively. Alternatively, the value is the Tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. It should be understood that a single P2MP tree can be identified together by the Tree ID and the root node. The second identifier may be used by the leaf nodes to verify the validity of the first request message.

[0032] In possible implementations, a leaf node verifying the validity of a first request message based on a second identifier includes the leaf node verifying the validity of the first request message based on a second identifier carried in the first request message. Successful validity verification for the second identifier includes the leaf node determining that information about the control plane corresponding to the P2MP tree matches the second identifier.

[0033] In the method described above, the validity of the first request message can be verified by linking information about the control plane corresponding to the P2MP tree with a second identifier on the forwarding plane.

[0034] In possible implementations, the root node's address is an IPv6 address.

[0035] In possible implementations, the first request message includes the time-to-live (TTL) or hop limit (HL), where the values ​​of TTL and HL are natural numbers.

[0036] According to a third aspect, a point-to-multipoint P2MP tree connectivity detection method is provided. The method is applied to an SR domain, which includes a P2MP tree. It will be understood that the P2MP tree is constructed by concatenating replica segments on nodes within the SR domain. A first node is the root node of the P2MP tree. The method includes the first node sending a first request message to a first leaf node of the P2MP tree based on replica branch information, the first request message including the SID of the next hop node. In response to the first node receiving a first response message sent by the leaf, the first node determines that the path from the first node to the first leaf node is connected, and in response to the first response message being a response message to the first request message, or in response to the first node not receiving a response packet in response to the first request message, the first node determines that the path from the first node to the leaf node is disconnected.

[0037] In possible implementations, the replication branch information includes the path from the first node to the downstream nodes of the P2MP tree. The first node determines the next hop node based on the path identifier and sends a first request message to the first leaf node of the P2MP tree.

[0038] In possible implementations, the replication branch information includes segment identifiers (SIDs) of the downstream nodes of the first node in the P2MP tree. The first node determines the SID of the next hop node based on the SIDs of the downstream nodes until the first request message is sent to the first leaf node of the P2MP tree. For example, the downstream nodes of the first node may be represented not only by the node's Node SID, but also by the neighbor SIDs or by a list of SIDs.

[0039] In possible implementations, when a SID within a SID is an SRv6 SID, the SID of the next hop node includes the IPv6 address of the next hop node.

[0040] In possible implementations, the first request message carries a first identifier. The first identifier identifies the first request message as an OAM packet. For example, the first request The message is an Echo Request packet.

[0041] In possible implementations, the first identifier is a User Datagram Protocol (UDP) port number, for example, the UDP destination port number carried in the first request message.

[0042] In possible implementations, the first request message further includes the address of the root node of the P2MP tree, and the root node address is used to indicate the leaf node of the P2MP tree to send a response message in response to the first request message, based on the root node address.

[0043] In possible implementations, the first request message includes a second identifier, which identifies the P2MP tree.

[0044] In possible implementations, the second identifier is the address of the root node of the P2MP tree and / or a single integer value. In one example, the second identifier is the address of the root node of the P2MP tree. In another example, the second identifier is a single integer value. In yet another example, the second identifier is a combination of the address of the root node of the P2MP tree and a single integer value. For example, the integer value is the Replication-ID of the replication segment. Different P2MP trees with the same root node, and different P2MP trees with different root nodes, can be identified by a globally unique Replication-ID. For example, the global Replication-ID values ​​corresponding to two P2MP trees whose root node is A are 1 and 2, respectively, and the global Replication-ID values ​​corresponding to three P2MP trees whose root node is B are 3, 4, and 5, respectively. Alternatively, the value is the Tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. It should be understood that a single P2MP tree can be identified together by the Tree ID and the root node. The second identifier may be used by the leaf nodes to verify the validity of the first request message.

[0045] In possible implementations, the first request message includes a time to live (TTL) or hop limit (HL), where the values ​​of TTL and HL are natural numbers. For example, a root node might set its TTL to 255 and include the TTL value in the first request message so that the first request message is sent to a leaf node.

[0046] According to a fourth aspect, a point-to-multipoint P2MP tree connectivity detection method is provided. The method is applied to an SR domain, which includes a P2MP tree. It will be understood that the P2MP tree is constructed by concatenating replica segments on nodes within the SR domain. A second node is an intermediate replica node of the P2MP tree. The method includes the second node receiving a first request message sent by the first node. The second node determines the next hop node based on replica branching information. The second node sends the first request message to the next hop node.

[0047] In possible implementations, the replication branch information includes the path from the second node to the downstream node in the P2MP tree. The second node determines the next hop node based on the path identifier.

[0048] In possible implementations, the replication branch information includes the segment identifier SID of the downstream node of the second node in the P2MP tree. The second node determines the SID of the next hop node based on the SID of the downstream node. For example, 2 Downstream nodes of a node can be represented not only by the node's Node SID, but also by neighboring SIDs or by a list of SIDs.

[0049] In possible implementations, when a SID within a SID is an SRv6 SID, the SID of the next hop node includes the IPv6 address of the next hop node.

[0050] In possible implementations, the first request message carries a first identifier. The first identifier identifies the first request message as an OAM packet. For example, the first request The message is an Echo Request packet.

[0051] In possible implementations, the first identifier is a User Datagram Protocol (UDP) port number, for example, the UDP destination port number carried in the first request message.

[0052] In possible implementations, the first request message further includes the address of the root node of the P2MP tree, and the root node address is used to indicate the leaf node of the P2MP tree to send a response message in response to the first request message, based on the root node address.

[0053] In possible implementations, the first request message includes a second identifier, which identifies the P2MP tree.

[0054] In possible implementations, the second identifier is the address of the root node of the P2MP tree and / or a single integer value. In one example, the second identifier is the address of the root node of the P2MP tree. In another example, the second identifier is a single integer value. In yet another example, the second identifier is a combination of the address of the root node of the P2MP tree and a single integer value. For example, the integer value is the Replication-ID of the replication segment. Different P2MP trees with the same root node, and different P2MP trees with different root nodes, can be identified by a globally unique Replication-ID. For example, the global Replication-ID values ​​corresponding to two P2MP trees whose root node is A are 1 and 2, respectively, and the global Replication-ID values ​​corresponding to three P2MP trees whose root node is B are 3, 4, and 5, respectively. Alternatively, the value is the Tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. It should be understood that a single P2MP tree can be identified together by the Tree ID and the root node. The second identifier may be used by the leaf nodes to verify the validity of the first request message.

[0055] In possible implementations, the first request message includes TTL or HL, where the values ​​of TTL and HL are natural numbers. For example, the root node sets the TTL value to 255 and includes the TTL value in the first request message so that the first request message is sent to the leaf nodes.

[0056] According to a fifth aspect, a first node is provided and configured to perform one of the methods of the first aspect or a possible implementation of the first aspect. Specifically, the first node includes a unit configured to perform one of the methods of the first aspect or a possible implementation of the first aspect.

[0057] According to the sixth aspect, a leaf node is provided and configured to perform one of the methods of the second aspect or a possible implementation of the second aspect. Specifically, the leaf node includes a unit configured to perform one of the methods of the second aspect or a possible implementation of the second aspect.

[0058] According to the seventh aspect, a first node is provided and configured to perform one of the methods of the third aspect or any possible implementation of the third aspect. Specifically, the first node includes a unit configured to perform one of the methods of the third aspect or any possible implementation of the third aspect.

[0059] According to the eighth aspect, a second node is provided and configured to perform one of the methods of the fourth aspect or any possible implementation of the fourth aspect. Specifically, the second node includes a unit configured to perform one of the methods of the fourth aspect or any possible implementation of the fourth aspect.

[0060] According to the ninth aspect, a first node is provided. The first node includes a processor, a communication interface, and memory. The communication interface is configured to receive or transmit packets. The memory may be configured to store a program or code. The processor is configured to invoke the program or code in memory to perform a method in the first aspect or any one of the possible implementations of the first aspect. For further details, see the detailed description in the example of the method. Details are not described again here.

[0061] According to the tenth aspect, a leaf node is provided. The leaf node includes a processor, a communication interface, and memory. The communication interface is configured to receive or transmit packets. The memory may be configured to store a program or code. The processor is configured to invoke the program or code in memory to perform a method in the second aspect or any one of the possible implementations of the second aspect. For further details, see the detailed description in the example of the method. Details are not described again here.

[0062] According to the eleventh aspect, a first node is provided. The first node includes a processor, a communication interface, and memory. The communication interface is configured to receive or transmit packets. The memory may be configured to store a program or code. The processor is configured to invoke the program or code in memory to perform a method in the third aspect or any one of the possible implementations of the third aspect. For further details, see the detailed description in the example of the method. Details are not described again here.

[0063] According to the twelfth aspect, a second node is provided. 2 The node includes a processor, a communication interface, and memory. The communication interface is configured to receive or send packets. The memory may be configured to store programs or code. The processor is configured to invoke the programs or code in memory to execute one of the methods of the fourth aspect or any possible implementation of the fourth aspect. For further details, see the detailed explanation in the example of the method. Details are not described again here.

[0064] According to a thirteenth aspect, a P2MP tree connectivity detection system is provided. The system includes a first node configured to perform one of the methods of the first aspect or any possible implementation of the first aspect, and a leaf node configured to perform one of the methods of the second aspect or any possible implementation of the second aspect. For example, the first node is configured to determine the first next-hop node of the first node based on replication branch information and to send a first request message to the first next-hop node. The first request message includes the SID of the first next-hop node. The first request message includes a first identifier. The first identifier indicates that the first request message is for connectivity detection. The leaf node is configured to receive the first request message, which includes the address of the root node of the P2MP tree, and to send a first response message to the root node based on the address of the root node.

[0065] According to the 14th aspect, a P2MP tree connectivity detection system is provided. The P2MP tree is located in an SR domain. The system includes a root node, intermediate replication nodes, and leaf nodes in the P2MP tree. The root node is configured to determine, based on replication branching information, that the next hop node of the root node is an intermediate replication node, to send a first request message to the intermediate replication node, to receive a first response message sent by a leaf node, and to determine, based on the first response message, that a path from the root node to the leaf node is connected. The first request message includes the SID of the next hop node. The first request message includes a first identifier, which indicates that the first request message is for connectivity detection. The intermediate replication node is configured to receive the first request message, determine, based on replication branching information, that the next hop node is a leaf node, and to send a first request message to the leaf node. The leaf node is configured to receive the first request message and to send a first response message to the root node.

[0066] According to the 15th aspect, the system includes a first node configured to perform any one of the third aspect or any possible implementations of the third aspect, and a second node configured to perform any one of the fourth aspect or any possible implementations of the fourth aspect.

[0067] According to the sixteenth aspect, a computer-readable medium containing instructions is provided. When the instructions are executed on a computer, the computer is enabled to execute one of the methods of the first aspect or a possible implementation of the first aspect, one of the methods of the second aspect or a possible implementation of the second aspect, one of the methods of the third aspect or a possible implementation of the third aspect, or one of the methods of the fourth aspect or a possible implementation of the fourth aspect.

[0068] According to the 17th aspect, a computer program product including instructions is provided. When the computer program product is executed on a computer, the computer is enabled to execute one of the first aspect or a possible implementation of the first aspect, one of the second aspect or a possible implementation of the second aspect, one of the third aspect or a possible implementation of the third aspect, or one of the fourth aspect or a possible implementation of the fourth aspect. [Brief explanation of the drawing]

[0069] [Figure 1] This is a schematic diagram illustrating an application scenario for forwarding packets within a P2MP tree, as described in this application. [Figure 2] This is a schematic diagram of another application scenario for forwarding packets within a P2MP tree, as described in this application. [Figure 3] This is a schematic diagram illustrating the application scenario of P2MP tree connectivity detection as described in this application. [Figure 4] This is a schematic flowchart of the P2MP tree connectivity detection method described in this application. [Figure 5] This is a schematic diagram of the packet format of the request message according to this application. [Figure 6] This is a schematic flowchart of the P2MP tree connectivity detection method described in this application. [Figure 7A] This is a schematic flowchart of another P2MP tree connectivity detection method according to this application. [Figure 7B] This is a schematic flowchart of another P2MP tree connectivity detection method according to this application. [Figure 8] This is a schematic diagram of the node structure according to this application. [Figure 9] This is a schematic diagram of the structure of another node according to this application. [Figure 10] This is a schematic diagram of the node hardware structure according to this application. [Figure 11] This is a schematic diagram of the hardware structure of another node according to this application. [Figure 12] This is a schematic diagram of the structure of the P2MP tree connectivity detection system described in this application. [Modes for carrying out the invention]

[0070] A replication segment provides a way for a node to replicate packets to a group of other nodes within a Segment Routing Domain (SR). In an SR domain, a replication segment is a logical segment that connects a replication node to a group of downstream nodes. A replication segment is a local segment instantiated by a replication node. A replication segment can be configured locally on a node or programmed by a path computation element (PCE). A replication segment is identified using a 2-tuple <Replication-IDentifier (Replication-ID), Node identifier (Node-ID)>. The Replication-ID is used to identify the replication segment. For example, the Replication-ID may be a 32-bit integer value or may be extended based on requirements. The Node-ID is the address of the node instantiating the replication segment, and may be, for example, the IPv6 address of the replication node. The content of a replication segment includes the Replication Segment Identifier (Replication SID), Downstream Nodes, and Replication State. The downstream nodes and replication status of a replication segment can change over time. The replication status is a list of replication branches pointing to downstream nodes, and this list of replication branches may also be called replication branch information. Each replication branch is:<Downstream Node,DownstreamReplication SID> It can be abstracted as follows: A Replication SID is a Segment Routing-Multiprotocol Label Switching (SR-MPLS) label or SRv6 SID used to identify a replication segment on the forwarding plane.It will be understood that a replication branch reaching a specific downstream node can be represented by the node SID or the node's neighbor SID. Simply put, downstream nodes may be represented by an SID list or an SR policy. An SR policy specifies an explicit path from the replication node to the downstream node. It will be understood that the replication node replicates packets and sends them to downstream nodes based on the replication branch information. If the downstream node is an exit node, in other words, if the downstream node does not need to continue replicating packets, it performs an action such as NEXT. For more information on replication segments, see the description in draft-voyer-spring-sr-replication-segment-04.

[0071] Replication segments provide building modules for P2MP services. For example, replication segments on ingress nodes (which may also be called the root node of the P2MP tree), intermediate nodes, and egress nodes (which may also be called leaf nodes of the P2MP tree) are linked together to build a P2MP tree. The ingress node, as the root node of the P2MP tree, replicates packets and sends them to the egress nodes through one or more intermediate replication nodes. Thus, unlike conventional IP multicast technology, this technology can reduce network load and improve packet forwarding efficiency, and because point-to-multipoint transmission of packets can be carried out by P2MP trees within an SR domain, this technology uses multicast group addresses as destination addresses for packets and does not require the establishment of multicast forwarding trees and multicast forwarding entries using Protocol Independent Multicast (PIM). SR P2MP policies can be delivered by PCE to instantiate P2MP trees. SR P2MP policies are identified by a 2-tuple <Root, Tree-identifier (Tree-ID)>. The Root is the address of the root node of the instantiated P2MP tree within the SR P2MP policy, for example, the root node's IPv6 address. The Tree-ID is used to uniquely identify the Root. In one implementation, the P2MP tree can be established using a control device, for example, using a path computation element (PCE). For the process of creating a P2MP, please refer to the relevant explanation in draft-voyer-pim-sr-p2mp-policy-02. Details will not be explained again here.

[0072] However, currently there is no method for detecting the connectivity of SR P2MP trees constructed using replicated segments, and connectivity detection on P2MP trees and the replicated segment paths associated with them cannot be performed. To address the aforementioned technical problems, this application provides a P2MP tree connectivity detection method, which performs connectivity detection on P2MP trees and the replicated segment paths associated with them.

[0073] Before describing the P2MP tree connectivity detection method, an example of how to forward packets in a P2MP tree within an SR domain will be explained to facilitate understanding of the P2MP tree connectivity detection method.

[0074] Figure 1 is a schematic diagram of an application scenario for forwarding packets within a P2MP tree. The P2MP tree is constructed using replication segments within an SR domain. In Figure 1, R1 is the root node of the P2MP tree and is connected to intermediate replication node R3. Intermediate replication node R3 is connected to intermediate replication node R5 and leaf node R6. Intermediate replication node R5 is connected to leaf nodes R6, R7, and R8. In one implementation, when a P2MP tree needs to be established using replication segments within an SR domain, the control device assigns a "Replication-ID" to identify the replication segment. For example, the assigned Replication-ID value is 1. The control device distributes a node replication branch list to each node in the P2MP tree. The list may also be called replication branch information. The node's replication branch information contains information about one or more downstream nodes. For example, each piece of replication branch information contains one<Downstream Node,Replication SID> It may be abstracted as follows. For example, branch=R3 indicates that one downstream node is R3, and branch=R5 / R6 indicates that two downstream nodes are R5 and R6. In one implementation, the replication branch information may alternatively not have downstream nodes. In this case, it should be understood that the node is a leaf node or exit node in the P2MP tree, and that the node needs to decapsulate the received packet and then forward the inner layer data packet. For example, the replication branch information of a leaf node may be represented by Decap.

[0075] In Figure 1, nodes R1, R3, R5, R6, R7, and R8 each have a corresponding Node-ID and Replication SID. An example is shown below.

[0076] In the case of R1, the Node-ID is R1_0 and the Replication SID is R1_1.

[0077] In the case of R3, the Node-ID is R3_0 and the Replication SID is R3_1.

[0078] In the case of R5, the Node-ID is R5_0 and the Replication SID is R5_1.

[0079] In the case of R6, the Node-ID is R6_0 and the Replication SID is R6_1.

[0080] In the case of R7, the Node-ID is R7_0 and the Replication SID is R7_1.

[0081] In the case of R8, the Node-ID is R8_0 and the Replication SID is R8_1.

[0082] Nodes R1, R3, R5, R6, R7, and R8 retrieve the Node ID, Replication-ID, and replication branch information. The following describes how to forward packets in a P2MP tree using an example where the SID is an SRv6 SID. The value of each node's Replication SID may also be the IPv6 address of each node. In this case, it should be understood that the replication branch information for each node includes a list of downstream node IPv6 addresses, and the replication branch information may be represented by branch_IP. Nodes R1, R3, R5, R6, R7, and R8 each store the entries shown in Table 1 below.

[0083] [Table 1]

[0084] In one implementation, the entry node (root node of the P2MP tree) R1 imports packets into the corresponding P2MP tree based on the contents of Table 2 below; in other words, the entry node encapsulates the P2MP tunnel header in the packet.

[0085] [Table 2]

[0086] The configuration shown in Table 2 is delivered on the entry node (root node of the P2MP tree) R1, and in response, entry node R1 generates the forwarding entries shown in Table 3.

[0087] [Table 3]

[0088] For example, when an interface belonging to Instance Virtual Routing Forwarding (VRF) 1 on the ingress node R1 receives a packet with a multicast address (S1, G1), the ingress node R1 encapsulates R1's IPv6 address in the packet's P2MP tunnel header based on the forwarding entry shown in Table 3, with the source address being R1 (or any IP address on R1). The ingress node R1 searches for the forwarding entry DA=R1_1 in Table 1 and, based on the replication branching information, knows that the packet needs to be replicated to R3_1. The ingress node encapsulates the packet's destination address as R3_1 and replicates the packet to node R3. After receiving the packet, node R3 searches for the forwarding entry DA=R3_1 shown in Table 1 and, based on the replication branching information, knows that the packet needs to be replicated to downstream nodes R5_1 and R6_1. R3 replicates the packet and sends it to nodes R5 and R6. The packet is ultimately sent to each leaf node of the P2MP tree, and each leaf node decapsulates the packet to retrieve the data within it.

[0089] Similarly, when a P2MP multicast tree identified by the dashed line shown in Figure 1 needs to be established, the controller assigns a "Replication-ID" to identify the replication segment. For example, Replication-ID=2 is assigned to the P2MP tree identified by the dashed line, and the controller distributes replication branch information to each node of the multicast tree. This is shown in Table 4.

[0090] [Table 4]

[0091] The P2MP entries identified by dashed lines, which are generated on the node based on the information in Table 4, are shown in Table 5 below.

[0092] [Table 5]

[0093] Table 6 shows the configuration for importing multicast flows (vrf2, S2, G2) into a P2MP tree identified by a dashed line on the entry node (or root node of the P2MP tree) R1.

[0094] [Table 6]

[0095] The configuration shown in Table 6 is delivered on the entry node (or root node of the P2MP tree) R1, and in response, node R1 generates the forwarding entries shown in Table 7.

[0096] [Table 7]

[0097] The entry node R1 searches for replication branch information based on the forwarding entries shown in Table 5 to determine the next hop node and replicates the packet to the next hop node. The packet is then sequentially sent to each leaf node based on the forwarding entries in Table 5, and each leaf node decapsulates the packet to retrieve the data within it.

[0098] Figure 2 is a schematic diagram of another application scenario for forwarding packets within a P2MP tree. The P2MP tree is constructed using replication segments within an SR domain. In Figure 2, R1 is the root node of the P2MP tree and is connected to intermediate replication node R3. Intermediate replication node R3 is connected to intermediate replication node R5 and leaf node R6. Intermediate replication node R5 is connected to leaf nodes R6, R7, and R8. In one implementation, when the root is R1 and identified by a solid line, and the P2MP tree shown in Figure 2 needs to be established, the controller assigns the IP address R1_1 to R1 and distributes the R1_1 address and replication branch information for each node to each node in the P2MP tree. In another implementation, alternatively, a control plane message may assign the IP address R1_1 to R1 and distribute the R1_1 address and replication branch information for the multicast tree to each node in the P2MP tree.

[0099] In one implementation, when multiple P2MP trees are established with R1 as their root, different IPv6 addresses may be assigned to R1 to distinguish between different P2MP trees (for example, different IPv6 addresses may be assigned to each P2MP tree), and other nodes may not need to assign IPv6 addresses to each P2MP tree. For example, intermediate nodes and leaf nodes do not need to use different IPv6 addresses for each P2MP tree. For example, the controller distributes the R1 address corresponding to the P2MP tree and branching information of the P2MP tree to each node. Nodes R1, R3, R5, R6, R7, and R8 each consist of an SID as the packet destination address. The SID identifies the node and identifies [Dst-Src lookup and forwarding]. When the packet destination address received by a node is the node's SID, the node performs Dst-Src lookup and forwarding on the packet. The SIDs assigned to nodes R1, R3, R5, R6, R7, and R8, indicating [Dst-Src lookup and forwarding], are R1_0, R3_0, R5_0, R6_0, R7_0, and R8_0, respectively.

[0100] Table 8 below contains information about the P2MP tree identified by the solid lines. The P2MP tree uses R1 as the root node, and the tree is used to identify the root node R1. For example, the address R1_1 of R1 may be used to identify the root node R1. In alternative implementations, the tree may instead identify the P2MP tree together with the root node R1.

[0101] [Table 8]

[0102] Table 9 shows the forwarding entries generated by nodes R1, R3, R5, R6, R7, and R8, identified by solid lines, and containing node replication branch information branch_IP.

[0103] [Table 9]

[0104] Table 10 shows the configuration for importing multicast flows (vrf1, S1, G1) into a P2MP tree identified by a solid line on the entry node (or root node of the P2MP tree).

[0105] [Table 10]

[0106] table 10 The configuration shown is delivered on the entry node (or root node of the P2MP tree) R1, and in response, node R1 generates the forwarding entries in Table 11.

[0107] [Table 11]

[0108] For example, entry node R1 receives a multicast data packet (S1, G1) from the interface belonging to vrf1, and based on the forwarding entry in Table 11, encapsulates the multicast data packet with its external IPv6 address as R1_1 and its destination address as R1_0, and obtains the encapsulated packet. Entry node R1 further searches for the forwarding entry DA=R1_0, obtains the [Dst-Src lookup and forwarding] instruction information, and based on the forwarding entry shown in Table 9, determines that the replication branching information includes R3_0 as the next hop. Entry node R1 changes the packet's destination address to R3_0 and sends the packet to node R3. Node R3 receives the packet, searches for the forwarding entry based on DA=R3_0, obtains the [Dst-Src lookup and forwarding] instruction information, and based on the replication branching information in the forwarding entry in Table 9, determines that the next hops are R5_0 and R6_0, respectively. Therefore, node R3 replicates the packet to nodes R5 and R6. Node R5 receives the packet, searches the forwarding entry based on DA=R5_0, obtains the [Dst-Src Lookup and Forward] instruction information, and determines that the next hops are R7_0 and R8_0 based on the replication branch information in the forwarding entry shown in Table 9. Node R5 replicates the packet and sends it to nodes R7 and R8. Node R6 receives the packet, searches the forwarding table based on DA=R6_0, obtains the [Dst-Src Lookup and Forward] instruction information, and determines that node R6 is a leaf node in the P2MP tree and has no next hop based on the replication branch information in the forwarding entry in Table 9. Node R6 decapsulates the packet to obtain the multicast data packet. Similarly, nodes R7 and R8 receive the packet and determine that there are no next hop nodes based on the replication branch information in Table 9. This indicates that nodes R7 and R8 are leaf nodes in the P2MP tree. Nodes R7 and R8 decapsulate the packet to obtain the multicast data packet.

[0109] In one implementation, when the root is R1, identified by a dashed line, and a P2MP multicast tree as shown in Figure 2 needs to be established, the controller assigns the IP address R1_2 to R1, and the controller distributes replication branch information separately to each node of the P2MP tree. Table 12 shows information about the P2MP tree identified by a dashed line, including the root node address and replication branch information for each node.

[0110] [Table 12]

[0111] Table 13 shows, Break This indicates forwarding entries generated by nodes R1, R3, R5, R6, R7, and R8, identified by lines and containing node replication branch information branch_IP.

[0112] [Table 13]

[0113] Table 14 shows the configuration for importing multicast flows (vrf2, S2, G2) into a P2MP tree identified by a dashed line on the entry node (or root node of the P2MP tree) R1.

[0114] [Table 14]

[0115] The configuration shown in Table 14 is delivered on the entry node (or root node of the P2MP tree) R1, and in response, node R1 generates the forwarding entries shown in Table 15.

[0116] [Table 15]

[0117] For example, in Figure 2, the process by which an entry node imports a multicast data packet into a P2MP tunnel identified by a dashed line, and the multicast data packet is forwarded through the P2MP tunnel identified by the dashed line, is as follows: Entry node R1 receives a multicast data packet (S2, G2) from the interface belonging to vrf2, and based on the forwarding entries in Table 15, encapsulates the multicast data packet with its external IPv6 address as R1_2 and its destination address as R1_0, and retrieves the packet. Entry node R1 further searches for the forwarding entry DA=R1_0, obtains the [Dst-Src lookup and forwarding] instruction information, and based on the forwarding entries in Table 13, determines that the replication branching information includes R3_0 as the next hop. Entry node R1 changes the packet's destination address to R3_0 and sends the packet to node R3. Node R3 receives the packet, searches the forwarding entry based on DA=R3_0, obtains the [Dst-Src lookup and forwarding] instruction information, and determines, based on the forwarding entry shown in Table 13, that the replication branch information includes R5_0 and R6_0 as the next hops, respectively. Node R3 sends copies of the packet to nodes R5 and R6. Node R5 receives the packet, searches the forwarding table based on DA=R5_0, obtains the [Dst-Src lookup and forwarding] instruction information, and determines, based on the forwarding entry shown in Table 13, that the next hop nodes included in the replication branch information are nodes R7_0 and R8_0, respectively. R5 replicates the packet and sends the packet to R7 and R8. Node R6 receives the packet, searches the forwarding table based on DA=R6_0, obtains the [Dst-Src lookup and forwarding] instruction information, and determines, based on the replication branch information in the forwarding entry in Table 13, that node R6 is a leaf node in the P2MP tree and has no next hops. Node R6 decapsulates the packet to obtain the multicast data packet. Similarly, nodes R7 and R8 receive the packet and determine that there is no next-hop node based on the replication branching information in Table 13.This indicates that nodes R7 and R8 are leaf nodes in the P2MP tree. Nodes R7 and R8 decapsulate the packets to receive multicast data packets.

[0118] The explanation of packet forwarding in the P2MP tree in Figures 1 and 2 should be understood as helpful in understanding the P2MP tree connectivity detection method. Figure 3 is a schematic diagram of an application scenario for P2MP tree connectivity detection. Figure 4 is a schematic flowchart of the P2MP tree connectivity detection method. The P2MP tree connectivity detection method will be explained below with reference to Figures 3 and 4. The method includes the following steps.

[0119] Step 401: The first node determines its first next hop node based on the replication branch information.

[0120] The P2MP tree to which the first node belongs is segment routing (SR), and a P2MP tree within an SR domain may be called an SR P2MP tree. An SR P2MP tree is constructed by concatenating groups of replicated segments. In SR P2MP, it is understood that the replicated segment at the root is concatenated with the replicated segments of intermediate replicated nodes, eventually reaching the leaf nodes. In other words, an SR P2MP tree sends packets from the root node to the group of leaf nodes through intermediate replicated nodes. The first node is a node in the P2MP tree, and the first node may be the root node of the P2MP tree or an intermediate replicated node of the P2MP tree.

[0121] Based on the descriptions in Figures 1 and 2, it will be understood that the first node stores the replication branch information of the SR P2MP tree to which the first node belongs, for example, the replication branch information branch_IP shown in Table 1, Table 5, or Table 9. The replication branch information includes information about downstream nodes represented by an SID list or SR policy. For example, downstream nodes of the first node may be represented not only by the node's Node SID, but also by neighboring SIDs or by an SID list. In one implementation, the replication branch information includes the path from the first node to the downstream nodes, along with the information about downstream nodes represented by the SR policy, and the first next-hop node is a node on the path. It will be understood that the first node determines the first next-hop node based on the identifier of the path to the downstream node. In another implementation, the replication branch information includes the SIDs of the downstream nodes of the first node, and the SIDs include the SIDs of the first next-hop nodes. It will be understood that the first node determines the SID of the first next-hop node based on the SIDs of the downstream nodes. If there are multiple next-hop nodes to the first node, the downstream nodes may be represented by a list of SIDs. For example, the first node determines the NodeSID of the next-hop node based on the replication branch information of the P2MP tree to which the first node belongs. When the SID in the list is a segment routing SRv6 SID over IPv6, the SID of the first next-hop node includes the IPv6 address of the first next-hop node.

[0122] In one implementation, the first node can determine multiple next-hop nodes based on replication branching information, for example, two next-hop nodes called the first next-hop node and the second next-hop node. In this case, the first node determines the SID of the first next-hop node and the SID of the second next-hop node based on replication branching information. The number of next-hop nodes is not limited in this application and may be one, two, or any other number. In another implementation, the first node determines the adjacent SID of the first next-hop node and the adjacent SID of the second next-hop node based on replication branching information.

[0123] Step 402: The first node sends the first request message to the first next hop node.

[0124] The first request message includes the SID of the first next-hop node. The first request message includes a first identifier. The first identifier indicates that the first request message is for connectivity detection. The first identifier can also be understood to indicate that the first request message is for fault detection on the data plane of the P2MP tree or for connectivity checks to the P2MP tree. In one implementation, the first identifier identifies that the first request message is an operation, administration and maintenance (OAM) packet. For example, the first identifier is the UDP port number carried in the first request message. In another implementation, the first request message further includes the address of the root node of the P2MP tree, and the root node address is to indicate, based on the root node address, which leaf node should send a response message in response to the first request message.

[0125] In one implementation, the first request message may further include a second identifier, which identifies the P2MP tree. The second identifier includes the address of the root node of the P2MP tree and / or a single integer value. In one example, the integer value may be the Replication-ID of the replication segment or the Tree ID of the P2MP tree. In another example, the second identifier may be the address of the root node and the Replication-ID, or the Tree ID. In yet another example, the second identifier is a combination of the root node address and the Replication-ID. In yet another example, the second identifier is a combination of the root node address and the Tree ID. For example, the integer value may be the Replication-ID of the replication segment. Different P2MP trees with the same root node, and different P2MP trees with different root nodes, can be identified by a globally unique Replication-ID. For example, the global Replication-ID values ​​corresponding to the two P2MP trees whose root node is A are 1 and 2, respectively, and the global Replication-ID values ​​corresponding to the three P2MP trees whose root node is B are 3, 4, and 5, respectively. Alternatively, the value may be the tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. It should be understood that a single P2MP tree is identified together by the Tree ID and the root node. A second identifier may be further used by the leaf nodes to verify the validity of the first request message.

[0126] In one implementation, the first node is an intermediate replication node of the P2MP tree. In this case, the first node receives a first request message sent by the root node of the P2MP tree. Since connectivity from the root node of the P2MP tree to the leaf nodes of the P2MP tree needs to be detected, the first node sends the first request message to the leaf nodes of the P2MP tree based on replication branch information, according to the method described in Figure 1 or Figure 2.

[0127] In one implementation, the first node is the root node of the P2MP tree. In this case, the first node generates the first request message, sends the first request message to the next hop, and the nodes of the P2MP tree replicate the first request message to the leaf nodes based on the replication branch information, according to the method described in Figure 1 or Figure 2.

[0128] For example, when the first request message is an Echo Request packet, as shown in Figure 3, the root node R1 of the P2MP tree generates an Echo Request packet and forwards it through the P2MP tree. The Echo Request packet is forwarded to the leaf node R7. Leaf node R7 decapsulates the Echo Request packet and identifies it. Similarly, after receiving the Echo Request packet, leaf nodes R6 and R8 decapsulate the Echo Request packet and identify it.

[0129] In one implementation, Figure 5 is a schematic diagram of the packet format of a request message according to this application. The request message includes a P2MP tunnel header, a UDP header, and an OAM header. For example, the P2MP tunnel header may be an SR-MPLS label or an SRv6 SID. When the P2MP tunnel header is an SRv6 SID, the packet-encapsulated P2MP tunnel header is an IPv6 address, and the internal IPv6 header is an address within the 0:0:0:0:0:FFFF:7F00:0 / 104 address segment (e.g., 0:0:0:0:0:FFFF:7F00:1). The UDP port number is to identify that the request message is a connectivity discovery packet. For example, the UDP port number 12345 is used to identify that the request message is an OAM packet. It should be understood that the external IPv6 header is encapsulated on the outer layer of the request message and is for forwarding the request message in the P2MP tree. For example, root node R1 sends the first request message to intermediate replication node R3, and the first request message reaches leaf nodes R6, R7, and R8 through the P2MP forwarding path. As P2MP exit nodes, leaf nodes R6, R7, and R8 decapsulate the external IPv6 header of the first request message, determine that the first request message is an OAM for connectivity detection based on the UDP port number, and send a response message to root node R1.

[0130] In one implementation, the first request message may carry the address of the root node of the P2MP tree, which is used to instruct the leaf nodes to use the address as the destination address for the response message. The root node's address may be different from or the same as the source address in the outer IPv6 header of the first request message.

[0131] In one implementation, the first request message further carries a Replication-ID. For example, the internal OAM header of the first request message carries the Replication-ID. The leaf node uses the Replication-ID to verify the validity of the first request message. When the Replication-ID value carried in the OAM header of the first request message is the same as the Replication-ID value of the control plane corresponding to the P2MP tree, this indicates that the first request message has passed verification, and the leaf node sends a response message in response to the first request message to perform data plane verification by the control plane based on the successful verification result. In another implementation, the first request message may further carry the address of the root node of the P2MP tree, i.e., the address located in the external IPv6 header. In other words, the external IPv6 header of the first request message has the address of one of the root nodes that identifies the P2MP tree, and the internal layer of the first request message also contains the same IPv6 address. When the internal IPv6 address in the first request message is the same as the source address in the external IPv6 header, this indicates that the first request message has passed verification, and the leaf node sends a response message in response to the first request message based on the successful verification result.

[0132] It should be understood that nodes in a P2MP tree forward the first request message from the root node to the leaf nodes based on replication branch information. The following further explains how a leaf node receives the first request message and sends a first response message to the root node based on the root node's address in the first request message.

[0133] In one implementation, when the first node in Figure 4 is the root node of the P2MP tree and the first next-hop node is a leaf node of the P2MP tree, the method shown in Figure 4 further includes the fact that, in response to the first node receiving a first response message sent by the first next-hop node, the first node determines that the path from the first node to the first next-hop node is connected, and the first response message is a response message to the first request message. In another implementation, in response to the first node not receiving a response message in response to the first request message, the first node determines that the path from the first node to the first next-hop node is disconnected.

[0134] In one implementation, when the first node in Figure 4 is the root node of the P2MP tree and the first next-hop node is an intermediate replica node of the P2MP tree, the method shown in Figure 4 further includes, in response to the first node receiving a second response message sent by a leaf node on a path through the first next-hop node, the first node determines that the path from the first node to the leaf node, which passes through the first next-hop node, is connected, and the second response message is a response message to the first request message. In another implementation, in response to the first node not receiving a response message sent by a leaf node on a path through the first next-hop node, which responds to the first request message, the first node determines that the path from the first node to the leaf node, which passes through the first next-hop node, is disconnected.

[0135] for example, First request messageBoth the first request message and the first response message are OAM packets, and the first request message is an Echo Request packet. As shown in Figure 3, the root node R1 of the P2MP tree generates the first request message, which is an Echo Request packet, and replicates the Echo Request packets through the P2MP tree to the leaf nodes R6, R7, and R8. The leaf nodes R6, R7, and R8 receive and identify the Echo Request packets separately and then send Echo Reply packets separately to the root node R1. Based on the Echo Reply packets sent and received by the leaf nodes R6, R7, and R8, the root node R1 determines that all paths from the root node R1 to the leaf nodes R6, R7, and R8 in the P2MP tree are connected. It should be understood that if there is a link failure between the intermediate replication node R5 and the leaf node R8, the leaf node R8 will not be able to receive the Echo Request packets sent by the root node R1, and the root node R1 will not be able to receive the Echo Reply packets from the leaf node R8. In this case, the root node R1 may determine that the path from the intermediate replication node R5 to the leaf node R8 is broken.

[0136] In one implementation, the first response message includes an IPv6 header, a UDP header, and an OAM header. The first response message includes the address of the root node of the P2MP tree, and it will be understood that the first response message is sent based on the root node's address. Therefore, the first response message does not need to be encapsulated in an external IPv6 header as a P2MP tunnel header. For example, the destination address in the IPv6 header of the first response message is the address of the root node, and the source address of the first response message is the address of the sending node. In one example, the first response message uses a UDP port number to identify that the first response message is an OAM packet. The UDP source port number of the first response message is First request messageThe destination port may be the same as the UDP destination port number of the first response message. First request message It may be the same as the source port number.

[0137] In one implementation, before a leaf node sends a first response message to the root node of the P2MP tree, and after a leaf node receives a first request message, the leaf node verifies the validity of the first request message based on a second identifier. In response to the success of the leaf node's validity verification against the second identifier, the leaf node sends a first response message to the root node of the P2MP tree.

[0138] Ping is an important method for checking whether a network path is connected. The Ping command sends an Internet Control Message Protocol (ICMP) echo request packet to a target node and waits for the target host to return an ICMP echo reply packet. If the local device receives a response from the target node within a certain period, this indicates that the path from the local device to the target node is connected. If the local device does not receive a response from the target node within a certain period, this indicates that the path from the local device to the target node is broken and a connection cannot be established. Traceroute is another important method for checking whether a network path is connected. Traceroute sends a UDP data packet and can set an unreachable port within the UDP data packet. Depending on whether the returned ICMP packet times out or the port is unreachable, it is determined whether the Traceroute program terminates. Referring to Figures 6, 7A, and 7B, the following describes P2MP tree connectivity detection using two implementations of Ping and Traceroute.

[0139] Figure 6 is a schematic flowchart of the P2MP tree connectivity detection method according to this application. The method will be described with reference to the network scenario shown in Figure 3. The method includes the following steps:

[0140] Step 601: Based on the replication branch information, the root node R1 determines that the next hop is the intermediate replication node R3.

[0141] The root node R1 determines the next hop node according to the method for forwarding packets in the SR P2MP tree shown in Figure 1, Figure 2, or Figure 3. For example, the next hop for an Echo Request packet is determined based on the specific P2MP tree being detected. If connectivity to the P2MP tree with Replication-ID=1 is detected in Figure 1, the replication branch information corresponding to Replication-ID=1 can be determined by using the device's forwarding table, and the next hop corresponding to Replication-ID=1 may be determined to be intermediate replication node R3. Therefore, the Echo Request packet is sent to intermediate replication node R3. If connectivity detection is performed on the P2MP tree with SA=R1_1 in Figure 2, the next hop is intermediate replication node R3 by detecting the replication branch information for SA=R1_1. Therefore, the Echo Request packet is sent to intermediate replication node R3.

[0142] Step 602: Root node R1 constructs an Echo Request packet and sends the Echo Request packet to intermediate replication node R3.

[0143] An Echo Request packet constructed by root node R1 includes an IPv6 header, a UDP header, and an OAM header. The destination address in the IPv6 header is an address within the address segment 0:0:0:0:0:FFFF:7F00:0 / 104. The destination port number in the UDP header may be used to identify the OAM header. For example, the method of encapsulating the outer IPv6 header of the Echo Request packet is an encapsulation method corresponding to a P2MP tunnel based on IPv6 unicast addresses, for example, with source address R1 and destination address R3.

[0144] In one implementation, the Echo Request packet further includes a "reply packet address." This address may be the IPv6 address of the root node R1, and may be carried in the source address field of the IPv6 header of the Echo Request packet, or in the field of the OAM header. The "reply packet address" is used by the leaf nodes of the P2MP tree to feed back the Echo Reply packet to the root node based on the "reply packet address."

[0145] In one implementation, the Echo Request packet may further include an identifier for identifying the P2MP tree. The identifier may be, for example, the address of the root node of the P2MP tree and / or a single integer value. In one example, the integer value may be the Replication-ID of the replication segment or the P2MP tree identifier, the Tree ID. In another example, the second identifier may be the address of the root node and the Replication-ID, or the Tree ID. In yet another example, the second identifier is a combination of the root node address and the Replication-ID. In yet another example, the second identifier is a combination of the root node address and the Tree ID. For example, the integer value may be the Replication-ID of the replication segment. Different P2MP trees with the same root node, and different P2MP trees with different root nodes, may be identified by a globally unique Replication-ID. For example, the global Replication-ID values ​​corresponding to the two P2MP trees whose root node is A are 1 and 2, respectively, and the global Replication-ID values ​​corresponding to the three P2MP trees whose root node is B are 3, 4, and 5, respectively. Alternatively, the value may be the tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. It is important to understand that a single P2MP tree is identified by both the Tree ID and the root node.

[0146] In one implementation, a Replication-ID may be used by a node in the P2MP tree to verify the validity of an Echo Request packet. The value of the Replication-ID may be carried in the OAM header of the Echo Request packet. In another implementation, the Echo Request packet may further include an external IPv6 source address. The external IPv6 source address is for verifying the validity of the Echo Request packet. The address field may be in the IPv6 header of the Echo Request or in the OAM header of the Echo Request.

[0147] Step 603: Intermediate replication node R3 determines, based on replication branch information, that the next hops are R5 and R6, respectively.

[0148] Intermediate replication node R3 determines that the next hops are R5 and R6, respectively, based on the replication branch information corresponding to Replication-ID=1, following the method of forwarding packets in the SR P2MP tree described in Figure 1, Figure 2, or Figure 3.

[0149] Step 604: Intermediate replication node R3 receives the Echo Request packet Leaf Duplicate to node R6.

[0150] Intermediate replication node R3 processes the packets Leaf Duplicate to R6

[0151] Step 605: Intermediate replication node R3 receives the Echo Request packet intermediate replication Duplicate to node R5.

[0152] Intermediate replication node R3 processes the packets intermediate replication Duplicate to node R5.

[0153] Step 606: Intermediate replication node R5 determines, based on replication branch information, that the next hops are R7 and R8, respectively.

[0154] Intermediate replication node R5 determines that the next hops are R8 and R7, respectively, based on the replication branch information corresponding to Replication-ID=1, following the method of forwarding packets in the SR P2MP tree described in Figure 1, Figure 2, or Figure 3.

[0155] Step 607: Intermediate replication node R5 replicates the Echo Request packet to leaf node R8.

[0156] Intermediate replication node R5 replicates Echo Request packets to leaf node R8.

[0157] Step 608: Intermediate replication node R5 replicates the Echo Request packet to leaf node R7.

[0158] Intermediate replication node R5 replicates Echo Request packets to leaf node R7.

[0159] Step 609: Leaf node R6 sends an Echo Reply packet to root node R1.

[0160] Leaf node R6 receives the Echo Request packet and, based on the external IPv6 header and replication branch information, determines that there are no next hops for the packet to be forwarded. Instead, leaf node R6 decapsulates the Echo Request packet. After decapsulating the Echo Request packet, leaf node R6 identifies that the inner layer of the Echo Request packet is an IPv6 packet and that the IPv6 destination address is within the address segment 0:0:0:0:0:FFFF:7F00:0 / 104. Based on the IPv6 UDP destination port in the Echo Request packet, leaf node R6 determines that the packet is an Echo Request packet. Therefore, leaf node R6 sends an Echo Reply packet to root node R1.

[0161] In one implementation, before sending an Echo packet to R1, the leaf node R6 verifies the validity of the Echo Request packet and sends an Echo Reply packet after successful verification. The leaf nodes of the P2MP tree receive the Echo Request packet and verify it. If the Replication-ID value carried in the OAM header of the Echo Request packet is the same as the Replication-ID value of the control plane corresponding to the P2MP tree, this indicates that the Echo Request packet has passed verification, and the leaf node sends a response message in response to the first request message to perform data plane verification by the control plane based on the successful verification result. Alternatively, the leaf nodes of the P2MP tree receive the Echo Request packet and check whether the IPv6 address carried in the Echo Request packet for verification is the same as the source address in the external IPv6 header of the Echo Request packet. If the IPv6 address carried in the Echo Request packet for verification is the same as the source address in the external IPv6 header of the Echo Request packet, the verification is successful.

[0162] In one implementation, before sending an Echo Reply packet to the root node R1, leaf node R6 uses the "reply packet address" in the Echo Request as the destination address for sending the Echo Reply packet. If the Echo Request packet does not contain a "reply packet address," the source address in the external IPv6 header is used as the destination address for sending the Echo Reply packet.

[0163] Step 610: Leaf node R8 sends an Echo Reply packet to root node R1.

[0164] For specific implementations in which leaf node R8 sends Echo Reply packets to root node R1, please refer to the implementation in step 609.

[0165] Step 611: Leaf node R7 sends an Echo Reply packet to root node R1.

[0166] For specific implementations in which leaf node R7 sends Echo Reply packets to root node R1, please refer to the implementation in step 609.

[0167] It should be understood that root node R1 determines that all paths from root node R1 to leaf nodes R6, R7, and R8 are connected by receiving Echo Reply packets sent by leaf nodes R6, R7, and R8. If the path from the root node to leaf node R7 is broken, the leaf node will not receive Echo Request packets sent by root node R1, and leaf node R7 will not feed back Echo Reply packets to the root node. Based on the fact that root node R1 does not receive Echo Reply packets sent by leaf node R7, root node R1 can determine that the path from root node R1 to leaf node R7 or R8 is broken.

[0168] Figures 7A and 7B are schematic flowcharts of another P2MP tree connectivity detection method according to this application. The method will be described with reference to the example scenario diagram shown in Figure 3. The method can not only perform P2MP tree connectivity detection but also detect fault locations. The method includes the following steps:

[0169] 1. Steps 701 to 704 are the first round of discovering the root node R1.

[0170] Step 701: Based on the replication branch information, the root node R1 determines that the next hop is R3.

[0171] The root node R1 determines the next hop node according to the method for forwarding packets in the SR P2MP tree shown in Figure 1, Figure 2, or Figure 3. For example, the next hop to which an Echo Request packet is sent is determined based on the specific P2MP tree that is detected. If connectivity is detected for the P2MP tree corresponding to Replication-ID=1 in Figure 1, the replication branch information corresponding to Replication-ID=1 can be determined by using the device's forwarding table, and the next hop corresponding to Replication-ID=1 may be determined to be the intermediate replication node R3. Therefore, the Echo Request packet is sent to the intermediate replication node R3. If connectivity detection is performed for the P2MP tree SA=R1_1 in Figure 2, the next hop is the intermediate replication node R3 by detecting the replication branch information for SA=R1_1. Therefore, the Echo Request packet is sent to the intermediate replication node R3.

[0172] Step 702: Root node R1 sends an Echo Request packet to intermediate replication node R3, and the Echo Request packet carries TTL=1.

[0173] The root node R1 constructs an Echo Request packet, encapsulates the external IPv6 header within the packet, and sets the Hop Limit (HL) or Time to Live (TTL) value carried in the Echo Request packet to 1. The Echo Request packet includes an internal IPv6 header, a UDP header, and an OAM header. The destination address in the internal IPv6 header is an address within the address segment 0:0:0:0:0:FFFF:7F00:0 / 104. The port number in the UDP header may be used to identify the OAM header. In one example, the method of encapsulating the external IPv6 header of the Echo Request packet corresponds to the encapsulation method for a P2MP tunnel based on an IPv6 unicast address, with the source address being R1 and the destination address being R3.

[0174] In one implementation, the Echo Request packet further includes a "reply packet address." This address may be the IPv6 address of the root node R1, and may be carried in the source address field of the IPv6 header of the Echo Request packet, or in the field of the OAM header. The "reply packet address" is used by the leaf nodes of the P2MP tree to feed back the Echo Reply packet to the root node based on the "reply packet address."

[0175] In one implementation, the Echo Request packet may further include an identifier for identifying the P2MP tree. The identifier may be, for example, the address of the root node of the P2MP tree and / or a single integer value. In one example, the integer value may be the Replication-ID of the replication segment or the P2MP tree identifier, the Tree ID. In another example, the second identifier may be the address of the root node and the Replication-ID, or the Tree ID. In yet another example, the second identifier is a combination of the root node address and the Replication-ID. In yet another example, the second identifier is a combination of the root node address and the Tree ID. For example, the integer value may be the Replication-ID of the replication segment. Different P2MP trees with the same root node, and different P2MP trees with different root nodes, may be identified by a globally unique Replication-ID. For example, the global Replication-ID values ​​corresponding to the two P2MP trees whose root node is A are 1 and 2, respectively, and the global Replication-ID values ​​corresponding to the three P2MP trees whose root node is B are 3, 4, and 5, respectively. Alternatively, the value may be the tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. It is important to understand that a single P2MP tree is identified by both the Tree ID and the root node.

[0176] In one implementation, the Echo Request packet may further include a Replication-ID. The Replication-ID is used by nodes in the P2MP tree to verify the validity of the Echo Request packet. The value of the Replication-ID may also be carried in the OAM header of the Echo Request packet. In another implementation, the Echo Request packet may further include an external IPv6 source address. The external IPv6 source address is used to verify the validity of the Echo Request packet.

[0177] Step 703: Intermediate replication node R3 identifies TTL=1 in the Echo Request packet.

[0178] Intermediate replication node R3 determines, based on the TTL=1 in the Echo Request packet, that the Echo Request packet does not need to be forwarded to the downstream node. Intermediate replication node R3 parses the Echo Request packet, identifies that the internal packet is an Echo Request packet, and sends an Echo Reply packet to root node R1.

[0179] Step 704: Intermediate replication node R3 replicates the Echo Reply packet to root node R1.

[0180] In one implementation, the first request message may further include a second identifier, which is used to identify a P2MP tree. The second identifier includes the address of the root node of the P2MP tree and / or a single integer value. In one example, the integer value may be the Replication-ID of a replication segment or the Tree ID of the P2MP tree. In another example, the second identifier may be the address of the root node and the Replication-ID, or the Tree ID. In yet another example, the second identifier is a combination of the root node address and the Replication-ID. In yet another example, the second identifier is a combination of the root node address and the Tree ID. For example, the integer value may be the Replication-ID of a replication segment. Different P2MP trees with the same root node, and different P2MP trees with different root nodes, can be identified by a globally unique Replication-ID. For example, the global Replication-ID values ​​corresponding to the two P2MP trees whose root node is A are 1 and 2, respectively, and the global Replication-ID values ​​corresponding to the three P2MP trees whose root node is B are 3, 4, and 5, respectively. Alternatively, the value may be the tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. It is important to understand that a single P2MP tree is identified by both the Tree ID and the root node.

[0181] In one implementation, the Echo Request packet further includes a "reply packet address." This address may be the IPv6 address of the root node R1, and may be carried in the source address field of the IPv6 header of the Echo Request packet, or in the field of the OAM header. The "reply packet address" is used by the leaf nodes of the P2MP tree to feed back the Echo Reply packet to the root node based on the "reply packet address."

[0182] It should be understood that, based on the root node R1 receiving an Echo Reply packet sent by the intermediate replication node R3 in the first round of detection, it can determine that the path from root node R1 to intermediate replication node R3 is connected and free of failures.

[0183] 2. Steps 705 to 713 are the second round of discovering the root node R1.

[0184] Step 705: Based on the replication branch information, the root node R1 determines that the next hop is R3.

[0185] For specific implementation details, please refer to the explanation in Step 701.

[0186] Step 706: Root node R1 sends an Echo Request packet to intermediate replication node R3, and the Echo Request packet carries TTL=2.

[0187] For specific implementation details, please refer to the explanation in step 702. The difference is that the TTL value in the Echo Request packet is set to 2.

[0188] Step 707: Intermediate replication node R3 determines, based on replication branch information, that the next hops are R5 and R6, respectively.

[0189] Intermediate replication node R3 receives the Echo Request packet and decrements the TTL value carried in the Echo Request packet by 1 in order to obtain TTL=1.

[0190] Intermediate replication node R3 can determine that the next hops are R5 and R6, respectively, based on the replication branch information with Replication-ID=1, following the method of forwarding packets in the SR P2MP tree shown in Figure 1, Figure 2, or Figure 3.

[0191] Step 708: Intermediate replication node R3 sends an Echo Request packet to intermediate replication node R5, and the Echo Request packet carries TTL=1.

[0192] Step 709: Intermediate replication node R3 sends an Echo Request packet to leaf node R6, and the Echo Request packet carries TTL=1.

[0193] Step 710: Intermediate replication node R5 identifies TTL=1 in the Echo Request packet.

[0194] Intermediate replication node R5 determines, based on the TTL=1 in the Echo Request packet, that the Echo Request packet does not need to be forwarded to the downstream node. Intermediate replication node R5 parses the Echo Request packet, identifies that the internal packet is an Echo Request packet, and sends an Echo Reply packet to root node R1. In one example, intermediate replication node R5 determines that the packet is an OAM packet based on the IPv6 UDP destination port in the Echo Request packet.

[0195] Step 711: Leaf node R6 identifies TTL=1 in the Echo Request packet.

[0196] LeafR6 determines that the Echo Request packet does not need to be forwarded to the downstream node based on the TTL=1 in the Echo Request packet. Leaf R6 analyzes the Echo Request packet, identifies that the internal packet is an Echo Request packet, and sends an Echo Reply packet to the root node R1.

[0197] Step 712: Intermediate replication node R5 replicates the Echo Reply packet to root node R1.

[0198] For details on the implementation, please refer to the explanation in step 704.

[0199] Step 713: Leaf node R6 sends an Echo Reply packet to root node R1.

[0200] For details on the implementation, please refer to the explanation in step 704.

[0201] It should be understood that, based on root node R1 receiving Echo Reply packets sent by intermediate replication node R5 and leaf node R6 in the second round of detection, it can be determined that the path from root node R1 to leaf node R6, which passes through intermediate replication node R5, is connected and free of faults. If root node R1 does not receive Echo Reply packets sent by intermediate replication node R5 and leaf node R6, but receives an Echo Reply packet sent by intermediate replication node R3 in the first round of detection, this indicates that the path from intermediate replication node R3 to intermediate replication node R5 and the path from intermediate replication node R3 to leaf node R6 are connected. Therefore, the fault location is detected according to the method described above.

[0202] 3. Starting from Step 714 726 This is the third round of detection for the root node R1.

[0203] Step 714: Based on the replication branch information, the root node R1 determines that the next hop is R3.

[0204] For specific implementation details, please refer to the explanation in Step 701.

[0205] Step 715: Root node R1 sends an Echo Request packet to intermediate replication node R3, and the Echo Request packet carries TTL=3.

[0206] For specific implementation details, please refer to the explanation in step 702. The difference is that the TTL value in the Echo Request packet is set to 3.

[0207] Step 716: Intermediate replication node R3 determines, based on replication branch information, that the next hops are R5 and R6, respectively.

[0208] Intermediate replication node R3 receives the Echo Request packet and decrements the TTL value carried in the Echo Request packet by 1 in order to obtain TTL=2.

[0209] Intermediate replication node R3 can determine that the next hops are R5 and R6, respectively, based on the replication branch information corresponding to Replication-ID=1, following the method of forwarding packets in the SR P2MP tree shown in Figure 1, Figure 2, or Figure 3.

[0210] Step 717: intermediate replication Node R3 sends an Echo Request packet to intermediate replication node R5, and the Echo Request packet carries TTL=2.

[0211] Step 718: intermediate replication Node R3 sends an Echo Request packet to leaf node R6, and the Echo Request packet carries TTL=2.

[0212] Step 719: Leaf node R6 sends an Echo Reply packet to root node R1.

[0213] Leaf node R6 receives the Echo Request packet and, based on the external IPv6 header and replication branch information, decides to decapsulate the Echo Request packet. After decapsulating the Echo Request packet, R6 identifies that the inner layer of the Echo Request packet is an IPv6 packet, that the IPv6 destination address is within the address segment 0:0:0:0:0:FFFF:7F00:0 / 104, and determines that the packet is an OAM packet based on the IPv6 UDP destination port. Leaf node R6 sends an Echo Reply packet to root node R1.

[0214] Step 720: Intermediate replication node R5 determines, based on replication branch information, that the next hops are R7 and R8.

[0215] Intermediate replication node R5, following the method of forwarding packets in the SR P2MP tree described in Figure 1, Figure 2, or Figure 3, determines that the next hops are R8 and R7, respectively, based on the replication branch information with Replication-ID=1, and can decrement the TTL value carried in the Echo Request packet by 1 to obtain TTL=1.

[0216] Step 721: The intermediate replication node replicates the Echo Request packet to the leaf node R7, and the Echo Request packet carries TTL=1.

[0217] Step 722: The intermediate replication node replicates the Echo Request packet to the leaf node R8, and the Echo Request packet carries TTL=1.

[0218] Step 723: Leaf node R7 identifies TTL=1 in the Echo Request packet.

[0219] Leaf Node R7 determines, based on the TTL=1 in the Echo Request packet, that the Echo Request packet does not need to be forwarded to the downstream node. Leaf Node R7 analyzes the Echo Request packet, identifies that the internal packet is an Echo Request packet, and sends an Echo Reply packet to root node R1.

[0220] Step 724: Leaf node R8 identifies TTL=1 in the Echo Request packet.

[0221] Leaf Node R8 determines, based on the TTL=1 in the Echo Request packet, that the Echo Request packet does not need to be forwarded to the downstream node. Leaf Node R8 analyzes the Echo Request packet, identifies that the internal packet is an Echo Request packet, and sends an Echo Reply packet to root node R1.

[0222] Step 725: Leaf node R7 sends an Echo Reply packet to root node R1.

[0223] For specific implementation details, please refer to the explanation in Step 704.

[0224] Step 726: Leaf node R8 sends an Echo Reply packet to root node R1.

[0225] For specific implementation details, please refer to the explanation in Step 704.

[0226] The third round of detection is complete, and all leaf nodes are returning Echo Reply messages. Therefore, the path from root node R1 to each leaf node is connected and without faults.

[0227] Figure 1 to Figure 7 Referring to the above, the details of the P2MP tree connectivity detection method provided in the embodiments of this application are described. Referring to Figures 8 to 12, embodiments of the apparatus and system of this application are described in detail below. Please understand that the description of the method embodiments corresponds to the description of the apparatus embodiments. Therefore, for parts not described in detail, please refer to the description of the method embodiments above.

[0228] Figure 8 is a schematic diagram of the structure of a first node 800 according to one embodiment of the present application. The first node 800 shown in Figure 8 can perform the corresponding steps performed by the first node, root node, or intermediate replication node in the methods shown in Figures 1 to 7A and 7B of the aforementioned embodiments. For example, the first node 800 can perform the method steps performed by the first node as described in the embodiments of steps 401 and 402 of Figure 4. As shown in Figure 8, the first node 800 includes a processing unit 801 and a transmission unit 802. The processing unit 801 is configured to determine the first next-hop node of the first node based on replication branch information. The transmission unit 802 is configured to send a first request message to the first next-hop node, the first request message includes the SID of the first next-hop node, the first request message includes a first identifier, the first identifier indicating that the first request message is for connectivity detection.

[0229] In one implementation, the first node is the root node of the P2MP tree, the first next-hop node is a leaf node of the P2MP tree, and the first node further includes a receiving unit.

[0230] The receiving unit is configured to receive a first response message sent by the first next-hop node.

[0231] The processing unit 801 is further configured such that, in response to the receiving unit receiving a first response message, it determines that a path from the first node to the first next hop node is connected, and the first response message is a response message to the first request message.

[0232] In one implementation, the first node is the root node of the P2MP tree, the first next-hop node is a leaf node of the P2MP tree, and the first node includes a receiving unit.

[0233] The processing unit 801 is further configured to determine that the path from the first node to the first next hop node is broken in response to the receiving unit not receiving a response message in response to the first request message.

[0234] In one implementation, the first node is the root node of the P2MP tree, the first next-hop node is an intermediate replication node of the P2MP tree, and the first node further includes a receiving unit.

[0235] The receiving unit is configured to receive a second response message sent by the first next-hop node.

[0236] The processing unit 801 is further configured such that, in response to the receiving unit receiving a second response message, it determines that a path from the first node to the leaf node is connected, and the second response message is a response message to the first request message.

[0237] In one implementation, the first node is the root node of the P2MP tree, the first next-hop node is an intermediate replication node of the P2MP tree, and the first node further includes a receiving unit.

[0238] The processing unit 801 is further configured to determine that the path from the first node to the first next hop node is broken in response to the receiving unit not receiving a response message in response to the first request message.

[0239] In one implementation, the processing unit 801 is further configured to determine the second next hop node of the first node based on the replication branching information.

[0240] The transmitting unit 802 is further configured to transmit a second request message to a second next-hop node, the second request message including the SID of the second next-hop node, and the second request message including a first identifier.

[0241] In one implementation, the first identifier is used to identify that the first request message is an OAM packet for operation and maintenance management.

[0242] In one implementation, the first identifier is the User Datagram Protocol UDP port number.

[0243] In one implementation, the first request message further includes the address of the root node of the P2MP tree, and the root node address is used to indicate the leaf node of the P2MP tree to send a response message in response to the first request message, based on the address of the root node.

[0244] In one implementation, the first request message includes a second identifier, which is used to identify the P2MP tree.

[0245] In one implementation, the second identifier may be the address of the root node of the P2MP tree or a single integer value, or the second identifier may be a combination of the address of the root node of the P2MP tree and a single integer value. In one example, the integer value may be the Replication-ID of the replication segment. Different P2MP trees with the same root node, and different P2MP trees with different root nodes, can be identified by a globally unique Replication-ID. For example, the global Replication-ID values ​​corresponding to two P2MP trees whose root node is A are 1 and 2, respectively, and the global Replication-ID values ​​corresponding to three P2MP trees whose root node is B are 3, 4, and 5, respectively. In another example, the value may be the Tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. A single P2MP tree is identified together by the Tree ID and the root node. A second identifier may be used by the leaf nodes to verify the validity of the first request message.

[0246] The first node 900 shown in Figure 9 can perform the corresponding steps performed by the leaf node in the manner of the embodiments described above. For example, the leaf node 900 can perform the steps performed by the leaf node in Figures 1 to 4, Figure 6, and Figures 7A and 7B. As shown in Figure 9, the leaf node 900 includes a receiving unit 901 and a transmitting unit 902. The leaf node is a leaf node of a point-to-multipoint P2MP tree. The P2MP tree is in a segment routing SR domain. The receiving unit 901 is configured to receive a first request message, which includes the address of the root node of the P2MP tree and a first identifier, the first identifier indicating that the first request message is for connectivity discovery. The transmitting unit 902 is configured to send a first response message to the root node based on the address of the root node.

[0247] In one implementation, the first identifier is: First request message This is to identify that it is an OAM (Operations and Maintenance Management) packet.

[0248] In one implementation, the first identifier is the User Datagram Protocol UDP port number.

[0249] In one implementation, the leaf node further includes a processing unit. The processing unit is configured to verify the validity of the first request message based on a second identifier before sending a first response message to the root node and after receiving the first request message. The transmitting unit 902 is further configured to send a first response message to the root node in response to the successful validity verification against the second identifier.

[0250] In possible implementations, a leaf node verifying the validity of a first request message based on a second identifier includes the leaf node verifying the validity of the first request message based on the second identifier carried in the first request message. Successful validity verification for the second identifier includes the leaf node determining that information about the control plane corresponding to the P2MP tree matches the second identifier. The validity of the first request message can be verified by linking information about the control plane corresponding to the P2MP tree with the second identifier on the transport plane.

[0251] In one implementation, the second identifier is either the address of the root node of the P2MP tree or a single integer value. In one example, the integer value is the Replication-ID of the replication segment. For example, different P2MP trees with the same root node and different P2MP trees with different root nodes may be identified by a globally unique Replication-ID. In another example, the value is the Tree identifier (Tree ID) of the P2MP tree, and the P2MP tree is identified together by the address of the root node and the Tree ID. For example, the first P2MP tree whose root node is A is:<Root=A,Tree ID=1> The second P2MP tree, identified by and with root node B, is<Root=B,Tree ID=1> It is identified by the Tree ID and the root node. A single P2MP tree is identified together by the Tree ID and the root node. A second identifier may be used by the leaf nodes to verify the validity of the first request message.

[0252] Figure 10 is a schematic diagram of the hardware structure of a first node 1000 according to one embodiment of the present application. The first node 1000 shown in Figure 10 can perform the corresponding steps performed by the first node, root node, or intermediate replica node in the method shown in Figures 1 to 7A and 7B of the above embodiment. For example, the first node 1000This can perform the method steps carried out by the first node described in the embodiments of steps 401 and 402 in Figure 4. 10 As shown, the first node 1000 includes a processor 1001, an interface 1002, and a bus 1003. The processor 1001 is connected to the interface 1002 via the bus 1003.

[0253] In one implementation form, the interface 1102 This includes a transmitter and a receiver configured to receive and transmit packets between a first node 1000 and another node in the P2MP tree, as an example. 1002 The processor is configured to support steps 402 in Figure 4, steps 602, 604, 605, 607, and 608 in Figure 6, and steps 702, 706, 708, 709, 715, 717, 718, 721, and 722 in Figures 7A and 7B. 1001 It is configured to perform processing performed by the first node, root node, or intermediate replication node in the embodiments described above, and / or to perform another process of the technology described herein. For example, processor 1001 is configured to determine information about the next hop node of the first node based on replication branch information. For example, processor 1001 is configured to support step 401 in Figure 4, steps 601, 603, and 606 in Figure 6, and steps 701, 703, 705, 707, 710, 711, 714, and 716 in Figures 7A and 7B.

[0254] In one implementation, the first node 1000 may further include memory. The memory may be configured to store a program, code, or instruction. When a program, code, or instruction is executed, the processor or hardware device performs the first method embodiment nodeThe processing processes related to the first node 1000 can be completed. Optionally, the memory may include read-only memory (ROM) and random access memory (RAM). The ROM includes a basic input / output system (BIOS) or an embedded system, and the RAM includes an application program and action system. When the first node 1000 needs to be executed, the bootloader in the embedded system, embedded in the BIOS or ROM, is used to start the system and bring the first node 1000 into a normal running state. After entering a normal running state, the first node 1000 executes the application program and action system in RAM to complete the processing processes related to the first node, root node, or intermediate replica node in the method embodiment. It will be understood that Figure 10 shows only a simplified design of the first node 1000. In actual use, the first node may include any number of interfaces, processors, or memory.

[0255] The processor may be a Central Processing Unit (CPU), another general-purpose processor, a digital signal processing (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), another programmable logic device, individual gate or transistor logic devices, individual hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Note that the processor may also be a processor supporting an advanced reduced instruction set computing (RISC) machine (ARM) architecture.

[0256] Further, in an optional embodiment, the memory may include a read-only memory and a random access memory and supply instructions and data to the processor. The memory may further include a non-volatile random access memory. For example, the memory may further store information on the device type.

[0257] The memory may be volatile memory or non-volatile memory, or may include both volatile memory and non-volatile memory. The non-volatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM) used as an external cache. By way of example and not limitation, many forms of RAM may be used, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0258] FIG. 11 is a schematic diagram of the hardware structure of the leaf node 1100 according to an embodiment of the present application. The leaf node 1100 shown in FIG. 11 can execute the corresponding steps executed by the leaf node in the method of the foregoing embodiment. As shown in FIG. 11, the leaf node 1100 includes an interface 1101 and a bus 1102. In one implementation, the leaf node may further include a processor. The processor 1103 and the interface 1101 are connected through the bus 1102.

[0259] In one implementation, the interface 1101 includes a transmitter and a receiver configured to receive and transmit packets between the leaf node 1100 and another node in the P2MP tree in the foregoing embodiment. As an example, the interface 1101 is configured to support steps 609 to 611 of FIG. 6, and steps 709, 713, 719, 721, 722, 725, and 726 of FIGS. 7A and 7B.

[0260] In one implementation, the processor 1103 is configured to execute the processing executed by the leaf node in the foregoing embodiment and / or to execute another process of the technology described herein. As an example, the processor 1103 is configured to analyze and identify the packets received by the interface 1101. As an example, the processor 1103 is configured to support steps 711, 723, and 724 of FIGS. 7A and 7B.

[0261] In one implementation, the leaf node 1100 may further include memory. The memory may be configured to store programs, code, or instructions. When a program, code, or instruction is executed, the processor or hardware device can complete the processing process associated with the first device in the method embodiment. Optionally, the memory may include ROM and RAM. The ROM includes a BIOS or embedded system, and the RAM includes an application program and action system. When the leaf node 1100 needs to be executed, a bootloader in the embedded system embedded in the BIOS or ROM is used to start the system and bring the leaf node 1100 into a normal running state. After entering the normal running state, the leaf node 1100 executes the application program and action system in RAM to complete the processing process associated with the leaf node in the method embodiment. It will be understood that Figure 11 shows only a simplified design of the leaf node 1100. In actual use, the leaf node may include any number of interfaces, processors, or memory.

[0262] It should be understood that the processor may be a CPU, or it may be another general-purpose processor, DSP, ASIC, FPGA, or another programmable logic device, individual gate or transistor logic devices, individual hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. It should also be noted that the processor may be a processor that supports the ARM architecture.

[0263] Furthermore, in an optional embodiment, the memory may include read-only memory and random-access memory to supply instructions and data to the processor. The memory may further include non-volatile random-access memory. For example, the memory may further store device type information.

[0264] The memory may be volatile memory or non-volatile memory, or it may include both volatile and non-volatile memory. Non-volatile memory may be ROM, PROM, EPROM, EEPROM, or flash memory. Volatile memory may be RAM used as an external cache. Many forms of RAM, such as SRAM, DRAM, SDRAM, DDR SDRAM, ESDRAM, SLDRAM, and DR RAM, may be used, but are not limited to examples.

[0265] Figure 12 is a schematic diagram of the structure of a P2MP tree connectivity detection system according to one embodiment of the present application. System 1200 is configured to implement the P2MP tree connectivity detection method of the method embodiment described above, and the P2MP tree is located in a segment routing SR domain. System 1200 includes a first node for implementing the aforementioned implementation and leaf nodes for implementing the aforementioned implementation. The first node is the root node in Figure 12. 1201 Alternatively, it may be an intermediate replication node 1202, and the leaf node is the leaf node 1203 in Figure 12. For example, the first node may be configured to perform the method steps of the first node or intermediate replication node in Figures 1 to 7A and 7B and have the corresponding functions. The leaf node is configured to perform the steps performed by the leaf node described in the embodiments of Figures 1 to 7A and 7B and has the corresponding functions.

[0266] In one implementation, the first node is configured to determine its next hop node based on replication branch information and to send a first request message to the next hop node. The first request message includes the SID of the next hop node. The first request message includes a first identifier. The first identifier indicates that the first request message is for connectivity detection. The leaf node is configured to receive the first request message, which includes the address of the root node of the P2MP tree, and to send a first response message to the root node based on the address of the root node.

[0267] In one implementation, the system includes a root node 1201, an intermediate replication node 1202, and a leaf node 1203 of a P2MP tree. The root node 1201 is configured to determine, based on replication branch information, that the next hop node of the root node is the intermediate replication node, send a first request message to the intermediate replication node, receive a first response message sent by the leaf node, and determine, based on the first response message, that the path from the root node to the leaf node is connected. The first request message includes the SID of the first next hop node. The first request message includes a first identifier. The first identifier indicates that the first request message is for connectivity detection. The intermediate replication node 1202 is configured to receive the first request message, determine, based on replication branch information, that the next hop node is a leaf node, and send a first request message to the leaf node. The leaf node 1203 is configured to receive the first request message and send a first response message to the root node.

[0268] One embodiment of the present application further provides a computer-readable storage medium comprising at least one instruction, program, or code. When the instruction, program, or code is executed on a computer, the computer is enabled to perform one of the steps of the aforementioned method to determine the bandwidth for transmitting a service flow. For example, a corresponding step of the method embodiment performed by a first node, root node, intermediate replica node, or leaf node in the embodiments of Figures 1 to 7A and 7B may be performed.

[0269] One embodiment of this application provides a computer program product comprising at least one instruction, program, or code. When the instruction, program, or code is loaded onto a computer and executed, the computer is enabled to perform the corresponding method steps of a method embodiment performed by a first node, root node, intermediate replica node, or leaf node in the embodiments of Figures 1 to 7A and 7B.

[0270] It should be noted that the embodiments of the apparatus described above are merely examples. Units described as separate parts may or may not be physically separate, and parts shown as units may or may not be physical units, i.e., they may be located in one place or distributed across multiple network units. Some or all modules may be selected according to the actual needs in order to achieve the objectives of the solutions of the embodiments. In addition, in the accompanying drawings of the first network node or controller embodiment provided in this application, the connection relationships between modules indicate that there are communication connections between modules, and the communication connections may be specifically implemented as one or more communication buses or signal cables. Those skilled in the art will be able to understand and implement embodiments of the present invention without creative effort.

[0271] All or part of the embodiments described above may be implemented using software, hardware, firmware, or any combination thereof. When an embodiment is implemented using software, all or part of the embodiment may be implemented in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded into a computer and executed, all or part of the procedures or functions according to the embodiments of the present invention are generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium and may be transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted by wired (e.g., coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless (e.g., infrared, radio, or microwave) from one website, computer, server, or data center to another website, computer, server, or data center. The computer-readable storage medium may be any available medium accessible to a computer or data storage device, for example, a server or data center incorporating one or more available media. Usable media include magnetic media (e.g., floppy disks, hard disks, or magnetic tapes), optical media (e.g., DVDs), and semiconductor media (e.g., solid state drives). Drive (SSD)) or similar may also be acceptable.

[0272] Those skilled in the art should understand that in one or more of the above examples, the functions described in the embodiments of this application can be implemented by hardware, software, firmware, or any combination thereof. When the functions are implemented by software, the aforementioned functions may be stored in a computer-readable medium or transmitted as one or more instructions or codes in a computer-readable medium. The computer-readable medium includes computer storage media and communication media, and the communication media includes any medium that enables a computer program to be transmitted from one place to another. The storage media may be any available media accessible to a general-purpose or dedicated computer.

[0273] In the above specific implementation forms, the objectives, technical solutions, and beneficial effects of this application are further described in detail. It should be understood that the above description is merely a specific implementation form of this application and is not intended to limit the protection scope of this application. Modifications, equivalent replacements, improvements, etc. made based on the technical solutions of this application shall be included within the protection scope of this application.

Description of Reference Signs

[0274] 800 First Node 801 Processing Unit 802 Transmission Unit 900 Leaf Node 901 Reception Unit 902 Transmission Unit 1000 First Node 1001 Processor 1002 Interface 1003 Bus 1100 Leaf Node 1101 Interface 1102 Bus 1103 Processor 1200 System 1201 Root Node 1202 Intermediate Replica Node 1203 Leaf Node

Claims

1. A point-to-multipoint (P2MP) tree connectivity detection method, wherein the method is applied to a segment routing (SR) domain, the SR domain includes a P2MP tree, the P2MP tree includes a first node, the first node is the root node or intermediate replica node of the P2MP tree, and the method is The first node determines the first next hop node of the first node based on the replication branch information, The first node sends a first request message to the first next-hop node, wherein the first request message includes the segment identifier (SID) of the first next-hop node, and the first request message includes a first identifier, the first identifier indicating that the first request message is for connectivity detection. When the first next-hop node is an intermediate replication node of the P2MP tree, the first next-hop node, in response to receiving the first request message, sends the first request message to the next-hop node of the first next-hop node based on the replication branch information, without sending a response message to the root node. When the first next-hop node is a leaf node of the P2MP tree, the first next-hop node, in response to receiving the first request message, sends a response message to the root node. Methods that include...

2. A point-to-multipoint (P2MP) tree connectivity detection method, the method being applied to a segment routing (SR) domain, the SR domain comprising a P2MP tree, the P2MP tree comprising a first node, the first node being the root node or intermediate replica node of the P2MP tree, and the method The first node determines the first next hop node of the first node based on the replication branch information, The first node sends a first request message to the first next-hop node, wherein the first request message includes the segment identifier (SID) of the first next-hop node, the first request message includes a first identifier, the first identifier indicates that the first request message is for connectivity detection, and the first request message includes a natural number time to live (TTL), the TTL being initialized to an initial value by the root node. When the first next-hop node is an intermediate replication node of the P2MP tree, in response to the first next-hop node receiving the first request message, if the TTL is 1, the first next-hop node sends a response message to the root node; if the TTL is greater than 1, the first next-hop node subtracts 1 from the TTL and, without sending a response message to the root node, sends the first request message to the next-hop node of the first next-hop node based on the replication branch information. When the first next-hop node is a leaf node of the P2MP tree, the first next-hop node, in response to receiving the first request message, sends a response message to the root node. Methods that include...

3. The first node is the root node of the P2MP tree, the first next hop node is a leaf node of the P2MP tree, and the method is A step in which the first node determines that a path is established from the first node to the first next hop node in response to the first node receiving a first response message transmitted by the first next hop node, wherein the first response message is the response message to the root node in response to the first request message, or The method according to claim 1 or 2, further comprising the step of the first node determining that the path from the first node to the first next hop node is broken in response that the first node has not received the response message which is sent to the root node by the first next hop node in response to the first request message.

4. The first node is the root node of the P2MP tree, the first next-hop node is an intermediate replication node of the P2MP tree, and the method is A step in which the first node determines that the path from the first node to the leaf node is connected, in response to the first node receiving a second response message transmitted by a leaf node on a path through the first next hop node, wherein the second response message is the response message to the root node in response to the first request message, or The method according to claim 1 or 2, further comprising the step of the first node determining that the path from the first node to the leaf node is broken in response that the first node has not received the response message to the root node which is transmitted by the leaf node on a path through the first next hop node and is in response to the first request message.

5. The replication branch information includes a path from the first node to a downstream node, and the first next-hop node is a node on the path. The step of determining the first next hop node of the first node based on the replication branch information by the first node is: The method according to claim 1 or 2, further comprising the step of determining the first next hop node based on the path identifier using the first node.

6. The replication branch information includes the segment identifier SID of the downstream node of the first node, and the SID of the downstream node includes the SID of the next hop node of the first node. The step of determining the first next hop node of the first node based on the replication branch information by the first node is: The method according to claim 1 or 2, comprising the step of determining the SID of the first next-hop node based on the SID of the downstream node using the first node.

7. The method according to claim 6, wherein when the SID within the SID is a segment identifier for segment routing over Internet Protocol version 6 IPv6 (SRv6 SID), the SID of the first next-hop node includes the IPv6 address of the first next-hop node.

8. The aforementioned method, The first node determines the second next hop node of the first node based on the replication branch information, The method according to claim 1 or 2, further comprising the step of the first node sending a second request message to the second next-hop node, wherein the second request message includes the SID of the second next-hop node and the second request message includes the first identifier.

9. The method according to claim 1 or 2, wherein the first request message includes a second identifier, the second identifier being for identifying the P2MP tree.

10. The method according to claim 9, wherein the second identifier is one or more of the address of the root node of the P2MP tree, the replication identifier of the replication segment, and the tree identifier of the P2MP tree.

11. A point-to-multipoint (P2MP) tree connectivity detection system, wherein the system includes a P2MP tree, the P2MP tree is located within a segment routing (SR) domain, and the system comprises a root node, intermediate replication nodes, and leaf nodes of the P2MP tree. The root node is configured to determine, based on first replication branch information, that the next hop node of the root node is the intermediate replication node, to send a first request message to the intermediate replication node, and to determine, in response to receiving a first response message sent by the leaf node, that the path from the root node to the leaf node is connected, wherein the first request message includes the segment identifier (SID) of the intermediate replication node, and the first request message includes a first identifier, the first identifier indicating that the first request message is for connectivity detection, The intermediate replication node is configured to, in response to receiving the first request message, send the first request message to the next hop node based on the second replication branch information, without sending a response message to the root node. The system is configured such that the leaf node, in response to receiving the first request message, sends the first response message to the root node.

12. A computer-readable storage medium containing a computer program, wherein when the computer program is executed on the computer, the computer is enabled to perform the method according to any one of claims 1 to 10.

Images