Method, device, and system for connectivity detection of p2MP tree

The P2MP tree connectivity detection method addresses the lack of connectivity detection in SR domains by using OAM packets to verify node connections, enhancing network reliability and efficiency.

JP2025113275APending Publication Date: 2025-08-01HUAWEI TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025077577
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2020-09-27
Filing Date
2025-05-07
Publication Date
2025-08-01

AI Technical Summary

Technical Problem

There is currently no method for detecting the connectivity of a point-to-multipoint (P2MP) tree within a Segment Routing (SR) domain, making it impossible to perform connectivity detection on the P2MP tree and the replicated segment paths associated with it.

Method used

A P2MP tree connectivity detection method is provided, where nodes within the SR domain determine next-hop nodes based on replication branch information and send request messages with identifiers to verify connectivity, using Operation, Administration, and Maintenance (OAM) packets to detect faults and verify the validity of messages.

Benefits of technology

Enables effective connectivity detection and fault location within P2MP trees, improving network reliability and efficiency by ensuring that connectivity issues are promptly identified and addressed.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025113275000001_ABST
    Figure 2025113275000001_ABST
Patent Text Reader

Abstract

To provide a P2MP tree connectivity detection method, a device, and a system.SOLUTION: 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: Determining, by the first node, a first next-hop node of the first node based on replication branch information; and sending, by the first node, 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.SELECTED DRAWING: Figure 6
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application claims the priority of 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 the priority of 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 above-mentioned 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 concatenating replication segments on nodes within a segment routing domain. An ingress node serving as the root node of the P2MP tree replicates a packet so that point-to-multipoint transmission of the packet can be carried out by the P2MP tree within the SR domain, and sends the packet to an egress node through one or more intermediate replication nodes. Different from the conventional Internet Protocol (IP) multicast technology, this technology does not need to use a multicast group address as the destination address of the packet 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 the network load and improve the packet transfer efficiency.

[0004] However, currently, there is no method for detecting the connectivity of the P2MP tree within the SR domain, and it is impossible to perform connectivity detection on the P2MP tree and the replicated segment paths associated with the P2MP tree. SUMMARY OF THE INVENTION 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 replicated segment paths associated with the P2MP tree.

[0006] According to a first aspect, this 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 a first node. The first node is the root node or an intermediate replicated node of the P2MP tree. The method includes the first node determining a first next-hop node of the first node based on replicated branch information. The first node sends 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. Alternatively, it may be understood that the first identifier indicates that the first request message is for P2MP tree fault detection or 2PMP tree connectivity verification.

[0007] In the foregoing method, a first request message for connectivity detection is sent on the P2MP tree within the SR domain so as to provide for the implementation of connectivity detection on the P2MP tree and the replicated segment paths associated with the P2MP tree for performing fault detection.

[0008] In a possible implementation form, when the first node is the root node of the P2MP tree and the first next-hop node is the leaf node of the P2MP tree, in some cases, in response to the first node receiving the 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, or in other cases, in response to the first node not receiving a response message that responds to the first request message, the first node determines that the path from the first node to the first next-hop node is disconnected.

[0009] It should be understood that if there is an obstacle 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 disconnected. If the path within the P2MP tree is connected and there is no obstacle, the first request message is transferred 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 that the path to the leaf node is connected based on the received response message.

[0010] In a possible implementation form, when the first node is the root node of a P2MP tree and the first next-hop node is an intermediate replication node of the P2MP tree, in some cases, in response to the first node receiving a second response message sent by a leaf node on the path passing through the first next-hop node, the first node determines that the path from the first node to the leaf node passing through the first next-hop node is connected, and the second response message is a response message to the first request message, or in another case, in response to the first node not receiving a response message sent by a leaf node on the path passing through the first next-hop node and responding to the first request message, the first node determines that the path from the first node to the leaf node is disconnected.

[0011] In a possible implementation form, 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 first node determining the first next-hop node of the first node based on the replication branch information includes the first node determining the first next-hop node based on the identifier of the path.

[0012] In the foregoing method, the explicit path from the first node to the downstream node is specified by 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 the 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 a possible implementation form, 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 first next-hop node. For the first node to determine the first next-hop node of the first 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, the downstream node of the first node can be represented not only by the Node SID of the node, but also by the adjacent SID or by the SID list.

[0014] In the foregoing method, 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 first next-hop node. It should be understood that the first node determines the SID of the first next-hop node based on the SID of the downstream node.

[0015] In a possible implementation form, when the SID within the SID is the segment identifier for segment routing over Internet Protocol version 6 (IPv6) (Segment Routing over IPv6 Segment Identifier, SRv6 SID), the SID of the first next-hop node includes the IPv6 address of the first next-hop node.

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

[0017] The foregoing method can be applied to a scenario where the next-hop node of the first node is a plurality of intermediate replication nodes or a plurality of leaf nodes.

[0018] In a possible implementation form, the first identifier is for identifying that the first request message is an operation, administration and maintenance (OAM) packet. For example, the first message is an Echo Request packet.

[0019] In a possible implementation form, 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 a possible implementation form, the first request message further includes the address of the root node of the P2MP tree, and the address of the root node is for indicating the leaf nodes of the P2MP tree for sending a response message in response to the first request message based on the address of the root node.

[0021] In a possible implementation form, the first request message includes a second identifier, and the second identifier is for identifying the P2MP tree.

[0022] In a possible implementation form, the second identifier may be the address of the root node of the P2MP tree or an integer value, or the second identifier may be a combination of the address of the root node of the P2MP tree and an integer value. In one example, the integer value may be the Replication-ID of the replication segment. Different P2MP trees of the same root node and different P2MP trees of different root nodes can be identified by a globally unique Replication-ID. For example, the values of the global Replication-IDs corresponding to two P2MP trees whose root nodes are A are 1 and 2 respectively, and the values of the global Replication-IDs corresponding to three P2MP trees whose root nodes are 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 identified by <Root=A, Tree ID=1>, and the second P2MP tree whose root node is B is identified by <Root=B, Tree ID=1>. It should be understood that one P2MP tree is identified together by the Tree ID and the root node. The second identifier can be further used by the leaf node to verify the validity of the first request message.

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

[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 where the failure occurs.

[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, the first identifier is for identifying that the first request packet is an operation, administration, and maintenance (OAM) packet. For example, the first response message is an Echo Request packet.

[0028] In a possible implementation, 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 after verifying the validity of the first request message, the leaf node sends a response message to the root node in order to improve the reliability and security of the verification.

[0031] In a possible implementation form, the second identifier is the address of the root node of the P2MP tree and / or an 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 an integer value. In still another example, the second identifier is a combination of the address of the root node of the P2MP tree and an integer value. For example, the integer value is the Replication-ID of the replication segment. Different P2MP trees of the same root node and different P2MP trees of different root nodes can be identified by a globally unique Replication-ID. For example, the values of the global Replication-IDs corresponding to two P2MP trees whose root node is A are 1 and 2 respectively, and the values of the global Replication-IDs 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 identified by <Root=A, Tree ID=1>, and the second P2MP tree whose root node is B is identified by <Root=B, Tree ID=1>. It should be understood that one P2MP tree can be identified together by the Tree ID and the root node. The second identifier can be used by the leaf node to verify the validity of the first request message.

[0032] In a possible implementation form, the leaf node verifying the validity of the first request message based on the 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. The success of the validity verification for the second identifier includes the leaf node determining that the information regarding the control plane corresponding to the P2MP tree matches the second identifier.

[0033] In the foregoing method, the validity of the first request message can be verified by associating information regarding the control plane corresponding to the P2MP tree with a second identifier on the transfer plane.

[0034] In a possible implementation form, the address of the root node is an IPv6 address.

[0035] In a possible implementation form, the first request message includes a time to live TTL or a hop limit HL, and the values of the 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. The SR domain includes a P2MP tree. It will be understood that the P2MP tree is constructed by concatenating replicated segments on nodes within the SR domain. The 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 replicated branch information, where the first request message includes the SID of the next-hop node. In response to the first node receiving the 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 the first response message is a response message to the first request message, or in response to the first node not receiving a response packet for responding to the first request message, the first node determines that the path from the first node to the leaf node is disconnected.

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

[0038] In a possible implementation form, the replication branch information includes the segment identifier SID of the downstream node of the first node in the P2MP tree. The first node determines the SID of the next-hop node based on the SID of the downstream node until the first request message is sent to the first leaf node of the P2MP tree. For example, the downstream node of the first node can be represented not only by the Node SID of the node, but also by the adjacent SID or by a list of SIDs.

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

[0040] In a possible implementation form, the first request message carries a first identifier. The first identifier is for identifying that the first request message is an OAM packet. For example, the first message is an Echo Request packet.

[0041] In a possible implementation form, 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 a possible implementation form, the first request message further includes the address of the root node of the P2MP tree, and the address of the root node is for indicating the leaf node of the P2MP tree for sending a response message in response to the first request message based on the address of the root node.

[0043] In a possible implementation form, the first request message includes a second identifier, and the second identifier is for identifying the P2MP tree.

[0044] In a possible implementation form, the second identifier is the address of the root node of the P2MP tree and / or an 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 an integer value. In yet another example, the second identifier is a combination of the address of the root node of the P2MP tree and an integer value. For example, the integer value is the Replication-ID of the replication segment. Different P2MP trees of the same root node and different P2MP trees of different root nodes can be identified by a globally unique Replication-ID. For example, the values of the global Replication-IDs corresponding to two P2MP trees with their root node being A are 1 and 2 respectively, and the values of the global Replication-IDs corresponding to three P2MP trees with their root node being 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 with its root node being A is identified by <Root=A,Tree ID=1>, and the second P2MP tree with its root node being B is identified by <Root=B,Tree ID=1>. It should be understood that one P2MP tree can be identified together by the Tree ID and the root node. The second identifier can be used by the leaf node to verify the validity of the first request message.

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

[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. The SR domain includes a P2MP tree. It will be understood that the P2MP tree is constructed by concatenating replicated segments on nodes within the SR domain. The second node is an intermediate replicated 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 of the second node based on the replication branch information. The second node sends the first request message to the next-hop node.

[0047] In a possible implementation form, the replication branch information includes a path from the second node to downstream nodes of the P2MP tree. The second node determines the next-hop node based on the identifier of the path.

[0048] In a possible implementation form, the replication branch information includes the segment identifier SID of downstream nodes of the second node of the P2MP tree. The second node determines the SID of the next-hop node based on the SID of the downstream node. For example, downstream nodes of the first node can be represented not only by the Node SID of the node, but also by the adjacent SID or by a list of SIDs.

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

[0050] In a possible implementation form, the first request message carries a first identifier. The first identifier is for identifying that the first request message is an OAM packet. For example, the first message is an Echo Request packet.

[0051] In a possible implementation form, 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 a possible implementation form, the first request message further includes the address of the root node of the P2MP tree, and the address of the root node is for indicating the leaf nodes of the P2MP tree for sending a response message in response to the first request message based on the address of the root node.

[0053] In a possible implementation form, the first request message includes a second identifier, and the second identifier is for identifying the P2MP tree.

[0054] In a possible implementation form, the second identifier is the address of the root node of the P2MP tree and / or an 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 an integer value. In still another example, the second identifier is a combination of the address of the root node of the P2MP tree and an integer value. For example, the integer value is the Replication-ID of the replication segment. Different P2MP trees of the same root node and different P2MP trees of different root nodes can be identified by a globally unique Replication-ID. For example, the values of the global Replication-IDs corresponding to two P2MP trees with the root node A are 1 and 2 respectively, and the values of the global Replication-IDs corresponding to three P2MP trees with the root node 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 with the root node A is identified by <Root=A,Tree ID=1>, and the second P2MP tree with the root node B is identified by <Root=B,Tree ID=1>. It should be understood that one P2MP tree can be identified together by the Tree ID and the root node. The second identifier can be used by the leaf node to verify the validity of the first request message.

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

[0056] According to the fifth aspect, a first node is provided and configured to execute the method according to any one of the first aspect or possible implementation forms of the first aspect. Specifically, the first node includes a unit configured to execute the method according to any one of the first aspect or possible implementation forms of the first aspect.

[0057] According to the sixth aspect, a leaf node is provided and configured to execute the method according to any one of the second aspect or possible implementation forms of the second aspect. Specifically, the leaf node includes a unit configured to execute the method according to any one of the second aspect or possible implementation forms of the second aspect.

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

[0059] According to the eighth aspect, a second node is provided and configured to execute the method according to any one of the fourth aspect or possible implementation forms of the fourth aspect. Specifically, the second node includes a unit configured to execute the method according to any one of the fourth aspect or possible implementation forms 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 a 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 call a program or code in the memory to execute the method in any one of the first aspect or possible implementation forms of the first aspect. For details, please refer to the detailed description in the example of the method. The details will not be described again here.

[0061] According to the tenth aspect, a leaf node is provided. The leaf node includes a processor, a communication interface, and a 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 call a program or code in the memory to execute the method in any one of the second aspect or a possible implementation form of the second aspect. For details, refer to the detailed description in the example of the method. Details will not be described again here.

[0062] According to the eleventh aspect, a first node is provided. The first node includes a processor, a communication interface, and a 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 call a program or code in the memory to execute the method in any one of the third aspect or a possible implementation form of the third aspect. For details, refer to the detailed description in the example of the method. Details will not be described again here.

[0063] According to the twelfth aspect, a second node is provided. The first node includes a processor, a communication interface, and a 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 call a program or code in the memory to execute the method in any one of the fourth aspect or a possible implementation form of the fourth aspect. For details, refer to the detailed description in the example of the method. Details will not be described again here.

[0064] According to a 13th aspect, a P2MP tree connectivity detection system is provided. The system includes a first node configured to execute the method of any one of the first aspect or a possible implementation form of the first aspect, and a leaf node configured to execute the method of any one of the second aspect or a possible implementation form of the second aspect. For example, the first node is configured to determine a first next-hop node of the first node based on replicated branch information and 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, the first request message includes the address of the root node of the P2MP tree, and based on the address of the root node, send a first response message to the root node.

[0065] According to a 14th aspect, a P2MP tree connectivity detection system is provided. The P2MP tree is within an SR domain. The system includes a root node, an intermediate replication node, and a leaf node of the P2MP tree. The root node is configured to determine, based on replicated 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 the first response message sent by the leaf node, and based on the first response message, determine that the 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. The first identifier 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 replicated branch information, that the next-hop node is the leaf node, and send the first request message to the leaf node. The leaf node is configured to receive the first request message and send a first response message to the root node.

[0066] According to a 15th aspect, the system includes a first node configured to execute any one method of a 3rd aspect or a possible implementation form of the 3rd aspect, and a second node configured to execute any one method of a 4th aspect or a possible implementation form of the 4th aspect.

[0067] According to a 16th aspect, a computer-readable medium including instructions is provided. When the instructions are executed on a computer, the computer is enabled to execute any one method of a 1st aspect or a possible implementation form of the 1st aspect, any one method of a 2nd aspect or a possible implementation form of the 2nd aspect, any one method of a 3rd aspect or a possible implementation form of the 3rd aspect, or any one method of a 4th aspect or a possible implementation form of the 4th aspect.

[0068] According to a 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 any one method of a 1st aspect or a possible implementation form of the 1st aspect, any one method of a 2nd aspect or a possible implementation form of the 2nd aspect, any one method of a 3rd aspect or a possible implementation form of the 3rd aspect, or any one method of a 4th aspect or a possible implementation form of the 4th aspect.

Brief Description of the Drawings

[0069]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7A

Figure 7B

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Embodiments for Carrying Out the Invention

[0070] The replication segment provides a way for a node to replicate packets to a group of other nodes within a Segment Routing Domain. In an SR domain, the replication segment is a logical segment that connects the replicating node to a group of downstream nodes. The replication segment is a local segment instantiated by the replicating node. The replication segment can be configured locally on the node or programmed by a path computation element (PCE). The replication segment is identified using a 2-tuple <Replication-IDentifier (Replication-ID), Node identifier (Node-ID)>. The Replication-ID is for identifying 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 that instantiates the replication segment and may be, for example, the IPv6 address of the replicating node. The content of the replication segment includes a Replication Segment Identifier (Replication SID), a Downstream Node, and a Replication State. The downstream node and the replication state of the replication segment can change over time. The replication state is a list of replication branches indicating the downstream nodes, and the list of replication branches may also be referred to as replication branch information. Each replication branch can be abstracted as <Downstream Node, DownstreamReplication SID>. The Replication SID is a Segment Routing - Multiprotocol Label Switching (SR-MPLS) label or an SRv6 SID for identifying the replication segment on the forwarding plane.It should be understood that the replication branches reaching a particular downstream node can be represented by the node SID or the adjacent SIDs of the node. Simply, the downstream node may be represented by a SID-list or an SR policy. The SR policy specifies an explicit path from the replication node to the downstream node. It should be understood that the replication node duplicates the packet and sends the packet to the downstream node based on the replication branch information. If the downstream node is an egress node, in other words, if the downstream node does not need to continue duplicating the packet, for example, the operation NEXT is executed. For details of the replication segment, refer to the description of draft-voyer-spring-sr-replication-segment-04.

[0071] The replication segment provides a building module for P2MP services. For example, the replication segments on the ingress node (which may also be called the root node of the P2MP tree), the intermediate node, and the egress node (which may also be called the leaf node of the P2MP tree) are connected together to construct a P2MP tree. The ingress node, as the root node of the P2MP tree, duplicates the packet and sends the packet to the egress node through one or more intermediate replication nodes. Therefore, different from the conventional IP multicast technology, this technology can reduce the network load and improve the packet transfer efficiency, so that the point-to-multipoint transmission of packets can be implemented by the P2MP tree within the SR domain. This technology uses the multicast group address as the destination address of the packet and does not need to use Protocol Independent Multicast (PIM) to establish a multicast transfer tree and multicast transfer entries. The SR P2MP policy can be distributed by the PCE to instantiate the P2MP tree. The SR P2MP policy is identified by a 2-tuple <Root, Tree-identifier (Tree-ID)>. Root is the address of the root node of the instantiated P2MP tree within the SR P2MP policy, for example, the IPv6 address of the root node. Tree-ID is used to uniquely identify Root. In one implementation form, the P2MP tree can be established using a control device, for example, using a path computation element (PCE). For the process of creating P2MP, please refer to the relevant description in draft-voyer-pim-sr-p2mp-policy-02. The details will not be described again here.

[0072] However, currently, there is no method for detecting the connectivity of an SR P2MP tree constructed using replication segments, and it is impossible to perform connectivity detection on the P2MP tree and the replication segment paths associated with the P2MP tree. To address the aforementioned technical problem, the present application provides a P2MP tree connectivity detection method, and according to the method, connectivity detection on the P2MP tree and the replication segment paths associated with the P2MP tree is performed.

[0073] Before the P2MP tree connectivity detection method is described, for the sake of facilitating the understanding of the P2MP tree connectivity detection method, a method for forwarding packets in a P2MP tree within an SR domain is described using an example.

[0074] FIG. 1 is a schematic diagram of an application scenario for transferring packets within a P2MP tree. The P2MP tree is constructed using replication segments within an SR domain. In FIG. 1, R1 is the root node of the P2MP tree and is connected to the intermediate replication node R3. The intermediate replication node R3 is connected to the intermediate replication node R5 and the leaf node R6. The intermediate replication node R5 is connected to the leaf nodes R6, R7, and R8. In one implementation, when one 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 value of the assigned Replication-ID is 1. The control device distributes a node replication branch list to each node within the P2MP tree. The list may also be referred to as replication branch information. The replication branch information of a node includes information about one or more downstream nodes. For example, each of the replication branch information may be abstracted as one <Downstream Node,Replication SID>. 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 an egress node of the P2MP tree, and the node needs to decapsulate the received packet and then transfer the inner layer data packet. For example, the replication branch information of the leaf node may be represented by Decap.

[0075] In FIG. 1, the nodes R1, R3, R5, R6, R7, and R8 have Node-IDs and Replication SIDs corresponding to R1, R3, R5, R6, R7, and R8 respectively. The examples are as follows.

[0076] For 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 obtain Node ID, Replication-ID, and replication branch information. The following uses an example where the SID is an SRv6 SID to explain the method for forwarding packets in a P2MP tree. The value of the Replication SID of each node may be the IPv6 address of each node. In this case, it should be understood that the replication branch information of each node includes a list of downstream node IPv6 addresses, and the replication branch information can 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 ingress node (the root node of the P2MP tree) R1 imports the packet into the corresponding P2MP tree based on the content of Table 2 below. In other words, the ingress node encapsulates the P2MP tunnel header into the packet.

[0085]

Table 2

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

[0087]

Table 3

[0088] For example, when the interface belonging to the instance virtual routing forwarding (VRF) 1 on the ingress node R1 receives a packet having a multicast address (S1,G1), the ingress node R1 encapsulates the IPv6 address of R1 into the P2MP tunnel header of the packet based on the forwarding entries shown in Table 3, and the source address is R1 (or it may be any IP address on R1). The ingress node R1 searches for the forwarding entry with DA = R1_1 in Table 1 and knows, based on the replication branch information, that the packet needs to be replicated to R3_1. The ingress node encapsulates the destination address of the packet as R3_1 and replicates the packet to the R3 node. After receiving the packet, the R3 node searches for the forwarding entry with DA = R3_1 shown in Table 1 and knows, based on the replication branch information, that the packet needs to be replicated to the downstream nodes R5_1 and R6_1. R3 replicates the packet and sends the packet to the nodes R5 and R6. The packet is finally sent to each leaf node of the P2MP tree, and each leaf node decapsulates the packet to obtain the data in the packet.

[0089] Similarly, when it is necessary to establish a P2MP multicast tree identified by the dashed line shown in FIG. 1, 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 transfer entries that are of the P2MP type identified by the dashed line and are generated on the node based on the information in Table 4 are shown in Table 5 below.

[0092]

Table 5

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

[0094]

Table 6

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

[0096]

Table 7

[0097] The ingress node R1 searches for replication branch information based on the forwarding entries shown in Table 5 to determine the next-hop node, and duplicates the packet to the next-hop node. The packets are sequentially sent to each leaf node based on the forwarding entries in Table 5, and each leaf node decapsulates the packet to obtain the data inside the packet.

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

[0099] In one implementation, when a plurality of P2MP trees whose root is R1 are established, different IPv6 addresses are 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 the branch information of the P2MP tree to each node. Nodes R1, R3, R5, R6, R7, and R8 are each composed of SIDs as packet destination addresses. The SID identifies the node and identifies [Dst-Src search and forwarding]. When the packet destination address received by the node is the SID of the node, the node performs Dst-Src search and forwarding on the packet. The SIDs assigned to nodes R1, R3, R5, R6, R7, and R8 to indicate [Dst-Src search and forwarding] are R1_0, R3_0, R5_0, R6_0, R7_0, and R8_0, respectively.

[0100] Table 8 below is information regarding the P2MP tree identified by the solid line. The P2MP tree uses R1 as the root node, and the tree is for identifying the root node R1. For example, the address R1_1 of R1 may be for identifying the root node R1. In another implementation, alternatively, the tree may 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, which are identified by the solid line and include the replicated branch information branch_IP of the nodes.

[0103]

Table 9

[0104] Table 10 shows the configuration for importing the multicast flow (vrf1, S1, G1) into the P2MP tree identified by the solid line on the ingress node (or what is called the root node of the P2MP tree).

[0105] [Table 10]

[0106] The configuration shown in Table 2 is distributed on the ingress node (or what is called the 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, the ingress node R1 receives a multicast data packet (S1,G1) from an interface belonging to vrf1, and based on the forwarding entry in Table 11, encapsulates the external IPv6 address of the multicast data packet as R1_1 and the destination address of the multicast data packet as R1_0, and obtains the encapsulated packet. The ingress node R1 further searches for a forwarding entry with DA = R1_0, obtains the [Dst-Src Search and Forwarding] instruction information, and based on the forwarding entry shown in Table 9, determines that the replication branch information includes that the next hop is R3_0. The ingress node R1 changes the destination address of the packet to R3_0 and sends the packet to the R3 node. The node R3 receives the packet, searches for a forwarding entry based on DA = R3_0, obtains the [Dst-Src Search and Forwarding] instruction information, and based on the replication branch information in the forwarding entry of Table 9, determines that the next hops are R5_0 and R6_0 respectively. Therefore, the node R3 replicates the packet to the nodes R5 and R6. The node R5 receives the packet, searches for a forwarding entry based on DA = R5_0, obtains the [Dst-Src Search and Forwarding] instruction information, and based on the replication branch information in the forwarding entry shown in Table 9, determines that the next hops are R7_0 and R8_0. The node R5 replicates the packet and sends the packet to the nodes R7 and R8. The node R6 receives the packet, searches for the forwarding table based on DA = R6_0, obtains the [Dst-Src Search and Forwarding] instruction information, and based on the replication branch information in the forwarding entry of Table 9, determines that the node R6 is a leaf node of the P2MP tree and has no next hop. The node R6 decapsulates the packet to obtain the multicast data packet. Similarly, the nodes R7 and R8 receive the packet and based on the replication branch information in Table 9, determine that there is no next hop node. This indicates that the nodes R7 and R8 are leaf nodes of the P2MP tree. The nodes R7 and R8 decapsulate the packet to obtain the multicast data packet.

[0109] In one implementation form, when its route is R1, the P2MP multicast tree identified by the dashed line and shown in FIG. 2 needs to be established, the controller assigns the IP address R1_2 to R1, and the controller distributes the replication branch information to each node of the P2MP tree separately. Table 12 shows information regarding the P2MP tree identified by the dashed line and includes the address of the root node and the replication branch information of each node.

[0110]

Table 12

[0111] Table 13 shows the forwarding entries generated by nodes R1, R3, R5, R6, R7, and R8, which are identified by the solid line and include the replication branch information branch_IP of the nodes.

[0112]

Table 13

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

[0114]

Table 14

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

[0116]

Table 15

[0117] For example, in FIG. 2, the process in which an ingress node imports a multicast data packet into a P2MP tunnel identified by a dashed line and the multicast data packet is transferred through the P2MP tunnel identified by the dashed line is as follows. The ingress node R1 receives a multicast data packet (S2, G2) from an interface belonging to vrf2, encapsulates the external IPv6 address of the multicast data packet as R1_2 and the destination address of the multicast data packet as R1_0 based on the forwarding entry in Table 15, and obtains the packet. The ingress node R1 further searches for a forwarding entry with DA = R1_0, obtains [Dst-Src search and forwarding] instruction information, and determines based on the forwarding entry in Table 13 that the replication and branching information includes that the next hop is R3_0. The ingress node R1 changes the destination address of the packet to R3_0 and sends the packet to node R3. Node R3 receives the packet, searches for a forwarding entry based on DA = R3_0, obtains [Dst-Src search and forwarding] instruction information, and determines based on the forwarding entry shown in Table 13 that the replication and branching information includes that the next hops are R5_0 and R6_0 respectively. Node R3 sends the replicated packets to node R5 and node R6. Node R5 receives the packet, searches the forwarding table based on DA = R5_0, obtains [Dst-Src search and forwarding] instruction information, and determines based on the forwarding entry shown in Table 13 that the next-hop nodes included in the replication and branching information are node 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 [Dst-Src search and forwarding] instruction information, and determines based on the replication and branching information in the forwarding entry of Table 13 that node R6 is a leaf node of the P2MP tree and has no next hop. Node R6 decapsulates the packet to obtain the multicast data packet. Similarly, nodes R7 and R8 receive the packet and determine based on the replication and branching information in Table 13 that there is no next-hop node.This indicates that nodes R7 and R8 are leaf nodes of the P2MP tree. Nodes R7 and R8 decapsulate the packets in order to obtain the multicast data packets.

[0118] It should be understood that the description of packet transfer in the P2MP trees of FIGS. 1 and 2 is helpful for understanding the P2MP tree connectivity detection method. FIG. 3 is a schematic diagram of an application scenario of P2MP tree connectivity detection. FIG. 4 is a schematic flowchart of the P2MP tree connectivity detection method. The following describes the P2MP tree connectivity detection method with reference to FIGS. 3 and 4. The method includes the following steps.

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

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

[0121] Based on the descriptions of FIGS. 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 a SID list (SID-list) or an SR policy. For example, the downstream nodes of the first node can be represented not only by the Node SID of the node, but also by an adjacent SID or a SID list. In one implementation, together with the information about the downstream nodes represented by the SR policy, the replication branch information includes a path from the first node to the downstream nodes, and the first next-hop node is a node on the 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. In another implementation, the replication branch information includes the SIDs of the downstream nodes of the first node, and the SID includes the SID of the first next-hop node. It should 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 of the first node, the downstream nodes may be represented by a SID list. 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 within the SID is a segment routing SRv6 SID via 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 the replication branch information. For example, it determines 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 the replication branch 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 the replication branch information.

[0123] Step 402: The first node sends a 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. It can also be understood that the first identifier indicates that the first request message is for fault detection on the data plane of the P2MP tree or for connectivity check for the 2PMP tree. In one implementation, the first identifier is for identifying 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 address of the root node is for indicating a leaf node for sending a response message in response to the first request message based on the address of the root node.

[0125] In one implementation form, the first request message may further include a second identifier, and the second identifier is for identifying a P2MP tree. The second identifier includes the address of the root node of the P2MP tree and / or an 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 one example, the second identifier is the address of the root node, the second identifier may be the Replication-ID, or the second identifier may be the Tree ID. In another example, the second identifier is a combination of the address of the root node and the Replication-ID. In yet another example, the second identifier is a combination of the address of the root node 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 values of the global Replication-IDs corresponding to two P2MP trees with root node A are 1 and 2 respectively, and the values of the global Replication-IDs corresponding to three P2MP trees with root node 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 with root node A is identified by <Root=A, Tree ID=1>, and the second P2MP tree with root node B is identified by <Root=B, Tree ID=1>. It should be understood that one P2MP tree is identified together by the Tree ID and the root node. The second identifier may be further used by the leaf node to verify the validity of the first request message.

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

[0127] In one implementation form, the first node is the root node of a P2MP tree. In this case, the first node generates a 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 FIG. 1 or FIG. 2.

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

[0129] In one implementation form, FIG. 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 encapsulation 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 (for example, 0:0:0:0:0:FFFF:7F00:1). The UDP port number is for identifying that the request message is a connectivity detection packet. For example, the UDP port number 12345 is used to identify that the request message is an OAM packet. The external IPv6 header is encapsulated on the outer layer of the request message, and it should be understood that the external IPv6 header is for transferring the request message in the P2MP tree. For example, the root node R1 sends the first request message to the intermediate replication node R3, and the first request message reaches the leaf nodes R6, R7, and R8 through the P2MP transfer path. The leaf nodes R6, R7, and R8, as the P2MP egress nodes, decapsulate the external IPv6 header of the first request message, determine based on the UDP port number that the first request message is OAM for connectivity detection, and send a response message to the root node R1.

[0130] In one implementation form, the first request message may carry the address of the root node of the P2MP tree, and the address of the root node is for instructing the leaf nodes to use the address as the destination address of the response message. The address of the root node may be different from or the same as the source address of the external IPv6 header of the first request message.

[0131] In one implementation form, 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 the verification, and the leaf node, based on the verification success result, sends a response message in response to the first request message in order to perform the verification of the data plane by the control plane. In another implementation form, the first request message may further carry the address of the root node of the P2MP tree, that is, the address located within the external IPv6 header. In other words, the external IPv6 header of the first request message has one address of the root node that identifies the P2MP tree, and the inner layer of the first request message also includes the same IPv6 address. When the internal IPv6 address within the first request message is the same as the source address within the external IPv6 header, this indicates that the first request message has passed the verification, and the leaf node sends a response message in response to the first request message based on the verification success result.

[0132] It should be understood that the nodes within the P2MP tree transfer the first request message from the root node to the leaf node based on the replication branch information. The following further describes how the leaf node receives the first request message and sends the first response message to the root node based on the address of the root node within the first request message.

[0133] In one implementation, when the first node in FIG. 4 is the root node of the P2MP tree and the first next-hop node is the leaf node of the P2MP tree, the method shown in FIG. 4 responds to the first node receiving the first response message sent by the first next-hop node by determining that the path from the first node to the first next-hop node is connected, and further including that 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 FIG. 4 is the root node of the P2MP tree and the first next-hop node is the intermediate replication node of the P2MP tree, the method shown in FIG. 4 responds to the first node receiving the second response message sent by the leaf node on the path through the first next-hop node by determining that the path from the first node to the leaf node that passes through the first next-hop node is connected, and further including that 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 the leaf node on the path through the first next-hop node and responding to the first request message, the first node determines that the path from the first node to the leaf node that passes through the first next-hop node is disconnected.

[0135] For example, both the first request packet and the first response message are OAM packets, and the first request message is an Echo Request packet. As shown in FIG. 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 packet 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 to the root node R1 separately. The root node R1 determines that all the paths from the root node R1 to the leaf nodes R6, R7, and R8 in the P2MP tree are connected based on the Echo Reply packets sent and received by the leaf nodes R6, R7, and R8. It should be understood that if there is a failure in the link between the intermediate replication node R5 and the leaf node R8, the leaf node R8 cannot receive the Echo Request packet sent by the root node R1, and the root node R1 cannot receive the Echo Reply packet 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 disconnected.

[0136] In one implementation form, the first response message includes an IPv6 header, a UDP header, and an OAM header. It should be understood that the first response message includes the address of the root node of the P2MP tree, and the first response message is transmitted based on the address of the root node. Therefore, the first response message may not be encapsulated by an external IPv6 header as a P2MP tunnel header. For example, the destination address of 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 transmitting 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 may be the same as the destination port of the first request packet, and the UDP destination port number of the first response message may be the same as the source port number of the first request packet.

[0137] In one implementation form, before the leaf node transmits the first response message to the root node of the P2MP tree and after the leaf node receives the first request message, the leaf node verifies the validity of the first request message based on a second identifier. In response to the successful verification of the validity of the second identifier by the leaf node, the leaf node transmits the 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 can send an Internet Control Message Protocol (ICMP) echo request packet to a target node and wait for the target host to return an ICMP echo response packet. If the local device receives a response from the target node within a specific 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 specific period, this indicates that the path from the local device to the target node is disconnected and the connection cannot be established. Traceroute is another important method for checking whether a network path is connected. Traceroute can send UDP data packets and set an unreachable port in the UDP data packets. Depending on whether the returned ICMP packet times out or the port is unreachable, it is determined whether the Traceroute program ends. Referring to FIGS. 6, 7A, and 7B, the following describes P2MP tree connectivity detection by using two implementation forms of Ping and Traceroute.

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

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

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

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

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

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

[0145] In one implementation form, 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 an 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 one example, the second identifier may be the address of the root node, the second identifier may be the Replication-ID, or the second identifier may be the Tree ID. In another example, the second identifier is a combination of the address of the root node and the Replication-ID. In yet another example, the second identifier is a combination of the address of the root node 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 values of the global Replication-IDs corresponding to two P2MP trees with root node A are 1 and 2 respectively, and the values of the global Replication-IDs corresponding to three P2MP trees with root node 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 with root node A is identified by <Root=A, Tree ID=1>, and the second P2MP tree with root node B is identified by <Root=B, Tree ID=1>. It should be understood that one P2MP tree is identified together by the Tree ID and the root node.

[0146] In one implementation form, in order to verify the validity of an Echo Request packet, a Replication-ID can be used by nodes in a P2MP tree. The value of the Replication-ID may be carried in the OAM header of the Echo Request packet. In another implementation form, 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 within the IPv6 header of the Echo Request or within the OAM header of the Echo Request.

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

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

[0149] Step 604: Intermediate replication node R3 replicates the Echo Request packet to intermediate replication node R6.

[0150] Intermediate replication node R3 replicates the packet to intermediate replication node R6.

[0151] Step 605: Intermediate replication node R3 replicates the Echo Request packet to leaf node R5.

[0152] Intermediate replication node R3 replicates the packet to leaf node R5.

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

[0154] The 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, in accordance with the method of forwarding packets in the SR P2MP tree described in FIG. 1, FIG. 2, or FIG. 3.

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

[0156] The intermediate replication node R5 replicates the Echo Request packet to the leaf node R8.

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

[0158] The intermediate replication node R5 replicates the Echo Request packet to the leaf node R7.

[0159] Step 609: The leaf node R6 sends the Echo Reply packet to the root node R1.

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

[0161] In one implementation form, before sending the Echo packet to R1, leaf node R6 verifies the validity of the Echo Request packet and sends an Echo Reply packet after the verification is successful. The leaf nodes of the P2MP tree receive the Echo Request packet and verify the Echo Request packet. When 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 the verification. Based on the verification success result, the leaf node sends a response message in response to the first request message to perform the verification of the data plane by the control plane. Alternatively, the leaf node of the P2MP tree receives the Echo Request packet and checks whether the IPv6 address carried in the Echo Request packet for verification is the same as the source address of 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 of the external IPv6 header of the Echo Request packet, the verification is successful.

[0162] In one implementation form, before leaf node R6 sends the Echo Reply packet to 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 the "reply packet address", the source address of the external IPv6 header is indicated as the destination address for sending the Echo Reply packet.

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

[0164] For a specific implementation of sending an Echo Reply packet from leaf node R8 to root node R1, refer to the implementation of step 609.

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

[0166] For a specific implementation of sending an Echo Reply packet from leaf node R7 to root node R1, refer to the implementation of 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 the Echo Reply packets sent by leaf nodes R6, R7, and R8. If the path from the root node to leaf node R7 is disconnected, the leaf node will not receive the Echo Request packet sent by root node R1, and leaf node R7 will not feedback the Echo Reply packet to the root node. Based on the fact that root node R1 does not receive the Echo Reply packet sent by leaf node R7, root node R1 can determine that the path from root node R1 to leaf node R7 or R8 is disconnected.

[0168] Figures 7A and 7B are schematic flowcharts of another P2MP tree connectivity detection method according to the present application. The method is described with reference to the scenario example diagram shown in Figure 3. In the method, not only can the connectivity detection of the P2MP tree be performed, but also the failure location can be further detected. The method includes the following steps.

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

[0170] Step 701: Root node R1 determines that the next hop is R3 based on the replicated branch information.

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

[0172] Step 702: The root node R1 sends the Echo Request packet to the 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 into the packet, and sets the value of the Hop Limit (HL) or time to live (TTL) 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 of the internal IPv6 header is an address within the address segment 0:0:0:0:0:FFFF:7F00:0 / 104. The port number of the UDP header may be for identifying the OAM header. In one example, the method of encapsulating the external IPv6 header of the Echo Request packet is an encapsulation method corresponding to a P2MP tunnel based on an IPv6 unicast address, the source address is R1, and the destination address is R3.

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

[0175] In one implementation form, the Echo Request packet may further include an identifier for identifying the P2MP tree. The identifier is, for example, the address of the root node of the P2MP tree and / or an 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 one example, the second identifier may be the address of the root node, the second identifier may be the Replication-ID, or the second identifier may be the Tree ID. In another example, the second identifier is a combination of the address of the root node and the Replication-ID. In yet another example, the second identifier is a combination of the address of the root node and the Tree ID. For example, the integer value may be the Replication-ID of the replication segment. Different P2MP trees of the same root node and different P2MP trees of different root nodes can be identified by a globally unique Replication-ID. For example, the values of the global Replication-IDs corresponding to two P2MP trees with root node A are 1 and 2 respectively, and the values of the global Replication-IDs corresponding to three P2MP trees with root node 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 with root node A is identified by <Root=A,Tree ID=1>, and the second P2MP tree with root node B is identified by <Root=B,Tree ID=1>. It should be understood that one P2MP tree is identified together by the Tree ID and the root node.

[0176] In one implementation form, the Echo Request packet may further include a Replication-ID. To verify the validity of the Echo Request packet, the Replication-ID is used by nodes in the P2MP tree. The value of the Replication-ID may be carried in the OAM header of the Echo Request packet. In another implementation form, 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.

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

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

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

[0180] In one implementation form, the first request message may further include a second identifier. The second identifier is for identifying a P2MP tree. The second identifier includes the address of the root node of the P2MP tree and / or an 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 one example, the second identifier is the address of the root node, the second identifier may be the Replication-ID, or the second identifier may be the Tree ID. In another example, the second identifier is a combination of the address of the root node and the Replication-ID. In yet another example, the second identifier is a combination of the address of the root node and the Tree ID. For example, the integer value may be the Replication-ID of the replication segment. Different P2MP trees of the same root node and different P2MP trees of different root nodes can be identified by a globally unique Replication-ID. For example, the values of the global Replication-IDs corresponding to two P2MP trees with root node A are 1 and 2 respectively, and the values of the global Replication-IDs corresponding to three P2MP trees with root node 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 with root node A is identified by <Root=A, Tree ID=1>, and the second P2MP tree with root node B is identified by <Root=B, Tree ID=1>. It should be understood that one P2MP tree is identified together by the Tree ID and the root node.

[0181] In one implementation form, the Echo Request packet further includes a "reply packet address". The address may be the IPv6 address of the root node R1, may be carried in the source address field of the IPv6 header of the Echo Request packet, or may be carried in a field of the OAM header. The "reply packet address" is used by the leaf nodes of the P2MP tree to feedback 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 the Echo Reply packet sent by the intermediate replication node R3 in the first round of detection, the path from the root node R1 to the intermediate replication node R3 is connected and it can be determined that there is no fault.

[0183] 2. Steps 705 to 713 are the second round of detection of 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 forms, refer to the description of step 701.

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

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

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

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

[0190] The 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 according to the method of forwarding packets in the SR P2MP tree described in FIG. 1, FIG. 2, or FIG. 3.

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

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

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

[0194] Based on TTL = 1 in the Echo Request packet, the intermediate replication node R5 determines that the Echo Request packet does not need to be forwarded to the downstream node. The intermediate replication node R5 analyzes the Echo Request packet, identifies that the internal packet is the Echo Request packet, and sends an Echo Reply packet to the root node R1. In one example, the 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: The leaf node R6 identifies TTL = 1 in the Echo Request packet.

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

[0197] Step 712: The intermediate replication node R5 copies the Echo Reply packet to the root node R1.

[0198] For the implementation form, refer to the description of step 704.

[0199] Step 713: The leaf node R6 sends the Echo Reply packet to the root node R1.

[0200] For the implementation form, refer to the description of step 704.

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

[0202] 3. Steps 714 to 704 are the third round of detection of the root node R1.

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

[0204] For specific implementation forms, refer to the description of Step 701.

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

[0206] For specific implementation forms, refer to the description of Step 702. The difference is that the TTL value in the Echo Request packet is set to 3.

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

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

[0209] The 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 in accordance with the method of forwarding packets in the SR P2MP tree described in FIG. 1, FIG. 2, or FIG. 3.

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

[0211] Step 718: The root node R3 sends an Echo Request packet to the 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 an Echo Request packet and decides to decapsulate the Echo Request packet based on the outer IPv6 header and the replication branch information. After decapsulating the Echo Request packet, R6 identifies that the inner layer of the Echo Request packet is an IPv6 packet and 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 that the next hops are R7 and R8 based on the replication branch information.

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

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

[0217] Step 722: Intermediate replication node replicates the Echo Request packet to 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] The intermediate replication node R7 determines, based on TTL = 1 in the Echo Request packet, that the Echo Request packet does not need to be transferred to the downstream node. The intermediate replication node R7 analyzes the Echo Request packet, identifies that the internal packet is the Echo Request packet, and sends an Echo Reply packet to the root node R1.

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

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

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

[0223] For the specific implementation form, please refer to the description of step 704.

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

[0225] For the specific implementation form, please refer to the description of step 704.

[0226] It should be understood that the third round of detection is completed and all leaf nodes return Echo Reply messages. Therefore, the paths from the root node R1 to each leaf node are connected and there are no faults.

[0227] Referring to FIGS. 1 to 8, the above describes in detail the P2MP tree connectivity detection method provided in the embodiments of the present application. Referring to FIGS. 8 to 12, the following details the embodiments of the apparatus and system of the present application. It should be understood 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 foregoing method embodiments.

[0228] FIG. 8 is a schematic diagram of the structure of a first node 800 according to an embodiment of the present application. The first node 800 shown in FIG. 8 can execute the corresponding steps executed by the first node, root node, or intermediate replication node in the methods shown in FIGS. 1 to 7A and 7B of the foregoing embodiments. For example, the first node 800 can execute the method steps executed by the first node described in the embodiments of steps 401 and 402 of FIG. 4. As shown in FIG. 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 the replication branch information. The transmission unit 802 is configured to transmit 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, and the first identifier indicates that the first request message is for connectivity detection.

[0229] In one implementation form, the first node is the root node of the P2MP tree, the first next-hop node is the 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 transmitted by the first next-hop node.

[0231] In response to the reception unit receiving the first response message, the processing unit 801 is further configured to determine that the path from the first node to the first next-hop node is connected, and that the first response message is a response message to the first request message.

[0232] In one implementation form, 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 reception unit.

[0233] In response to the reception unit not receiving a response message in response to the first request message, the processing unit 801 is further configured to determine that the path from the first node to the first next-hop node is disconnected.

[0234] In one implementation form, 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 reception unit.

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

[0236] In response to the reception unit receiving the second response message, the processing unit 801 is further configured to determine that the path from the first node to the leaf node is connected, and that the second response message is a response message to the first request message.

[0237] In one implementation form, 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 reception 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 disconnected in response to the receiving unit not receiving a response message in response to the first request message.

[0239] In one implementation form, the processing unit 801 is further configured to determine a second next-hop node of the first node based on the replicated branch information.

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

[0241] In one implementation form, the first identifier is for identifying that the first request message is an operation, administration, and maintenance OAM packet.

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

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

[0244] In one implementation form, the first request message includes a second identifier, and the second identifier is for identifying the P2MP tree.

[0245] In one implementation form, the second identifier may be the address of the root node of the P2MP tree or an integer value, or the second identifier may be a combination of the address of the root node of the P2MP tree and an integer value. In one example, the integer value may be the Replication-ID of the replication segment. Different P2MP trees of the same root node and different P2MP trees of different root nodes can be identified by a globally unique Replication-ID. For example, the values of the global Replication-ID corresponding to two P2MP trees whose root node is A are 1 and 2 respectively, and the values of the global Replication-ID 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 identified by <Root=A,Tree ID=1>, and the second P2MP tree whose root node is B is identified by <Root=B,Tree ID=1>. It should be understood that one P2MP tree is identified together by the Tree ID and the root node. The second identifier can be used by the leaf node to verify the validity of the first request message.

[0246] The first node 900 shown in FIG. 9 can execute the corresponding steps executed by the leaf node in the method of the foregoing embodiment. For example, the leaf node 900 can execute the steps executed by the leaf nodes in FIGS. 1 to 4, FIG. 6, and FIGS. 7A and 7B. As shown in FIG. 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 within a segment routing SR domain. The receiving unit 901 is configured to receive 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 transmitting unit 902 is configured to transmit a first response message to the root node based on the address of the root node.

[0247] In one implementation form, the first identifier is for identifying that the first request packet is an operation, administration, and maintenance OAM packet.

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

[0249] In one implementation form, 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 transmitting the first response message to the root node and after receiving the first request message. The transmitting unit 902 is further configured to transmit the first response message to the root node in response to a successful validity verification for the second identifier.

[0250] In a possible implementation form, the leaf node verifying the validity of the first request message based on the 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. The successful verification of the validity of the second identifier includes the leaf node determining that the information regarding the control plane corresponding to the P2MP tree matches the second identifier. The validity of the first request message can be verified by associating the information regarding the control plane corresponding to the P2MP tree with the second identifier on the transfer plane.

[0251] In one implementation form, the second identifier is the address of the root node of the P2MP tree or an integer value. In an example, the integer value is the Replication-ID of the replication segment. For example, different P2MP trees of the same root node and different P2MP trees of different root nodes can 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 with the root node being A is identified by <Root=A,Tree ID=1>, and the second P2MP tree with the root node being B is identified by <Root=B,Tree ID=1>. It should be understood that one P2MP tree is identified together by the Tree ID and the root node. The second identifier can be used by the leaf node to verify the validity of the first request message.

[0252] FIG. 10 is a schematic diagram of the hardware structure of the first node 1000 according to an embodiment of the present application. The first node 1000 shown in FIG. 10 can execute the corresponding steps executed by the first node, the root node, or the intermediate replication node in the methods shown in FIGS. 1 to 7A and 7B of the foregoing embodiments. For example, the first node 800 can execute the method steps executed by the first node described in the embodiments of steps 401 and 402 of FIG. 4. As shown in FIG. 11, the first node 1000 includes a processor 1001, an interface 1002, and a bus 1003. The processor 1001 is connected to the interface 1002 through the bus 1003.

[0253] In one implementation, the interface 1103 includes a transmitter and a receiver configured to receive and transmit packets between the first node 1000 and another node within the P2MP tree in the foregoing embodiments. As an example, the interface 1003 is configured to support steps 402 of FIG. 4, steps 602, 604, 605, 607, and 608 of FIG. 6, and steps 702, 706, 708, 709, 715, 717, 718, 721, and 722 of FIGS. 7A and 7B. The processor 1101 is configured to execute the processing executed by the first node, the root node, or the intermediate replication node in the foregoing embodiments and / or is configured to execute another process of the technology described herein. As an example, the processor 1001 is configured to determine information regarding the next-hop node of the first node based on the replication branch information. As an example, the processor 1001 is configured to support steps 401 of FIG. 4, steps 601, 603, and 606 of FIG. 6, and steps 701, 703, 705, 707, 710, 711, 714, and 716 of FIGS. 7A and 7B.

[0254] In one implementation form, the first node 1000 may further include a memory. The memory may be configured to store a program, code, or instructions. When the program, code, or instructions are executed, a processor or a hardware device can complete the processing process related to the first device of the method embodiment. Optionally, the memory may include a read-only memory (ROM) and a 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 an action system. When the first node 1000 needs to be executed, the bootloader in the BIOS or the embedded system embedded in the ROM is used to start the system and make the first node 1000 enter the normal execution state. After entering the normal execution state, the first node 1000 executes the application program and the action system in the RAM to complete the processing process related to the first node, the root node, or the intermediate replication node in the method embodiment. It should be understood that FIG. 10 only shows a simplified design of the first node 1000. In actual applications, the first node can include any number of interfaces, processors, or memories.

[0255] The processor may be a central processing unit (CPU), or it may be another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. It should be noted that the processor may also be a processor that supports the advanced RISC machines (ARM) architecture.

[0256] Furthermore, in an optional embodiment, the memory may include a read-only memory and a random access memory and may 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 about the device type.

[0257] The memory may be volatile memory, non-volatile memory, or may include both volatile memory and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), or flash memory. The volatile memory may be 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 a 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 by 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 form, interface 1101 includes a transmitter and a receiver configured to receive and transmit packets between the leaf node 1100 in the P2MP tree and another node in the foregoing embodiments. As an example, 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 form, processor 1103 is configured to execute the processing performed by the leaf node in the foregoing embodiments and / or to execute another process of the technology described herein. As an example, processor 1103 is configured to analyze and identify the packets received by interface 1101. As an example, processor 1101 is configured to support steps 711, 723, and 724 of FIGS. 7A and 7B.

[0261] In one implementation form, the leaf node 1100 may further include a memory. The memory may be configured to store programs, codes, or instructions. When the programs, codes, or instructions are executed, the processor or the hardware device can complete the processing process related to the first device of the method embodiment. Optionally, the memory may include a ROM and a RAM. The ROM includes a BIOS or an embedded system, and the RAM includes an application program and an action system. When the leaf node 1100 needs to be executed, the bootloader in the BIOS or the embedded system embedded in the ROM is used to start the system and make the leaf node 1100 enter the normal execution state. After entering the normal execution state, the leaf node 1100 executes the application program and the action system in the RAM to complete the processing process related to the leaf node in the method embodiment. It should be understood that FIG. 11 shows only a simplified design of the leaf node 1100. In actual applications, the leaf node can include any number of interfaces, processors, or memories.

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

[0263] Furthermore, in an optional embodiment, the memory includes a read-only memory and a random access memory, and may 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 about the device type.

[0264] The memory may be a volatile memory or a non-volatile memory, or may include both a volatile memory and a non-volatile memory. The non-volatile memory may be a ROM, PROM, EPROM, EEPROM, or flash memory. The volatile memory may be a RAM used as an external cache. By way of example and not limitation, many forms of RAM, such as SRAM, DRAM, SDRAM, DDR SDRAM, ESDRAM, SLDRAM, and DR RAM may be used.

[0265] FIG. 12 is a schematic diagram of the structure of a P2MP tree connectivity detection system according to an embodiment of the present application. The system 1200 is configured to implement the P2MP tree connectivity detection method of the foregoing method embodiment, and the P2MP tree is within a segment routing SR domain. The system 1200 includes a first node for executing the foregoing implementation form and a leaf node for executing the foregoing implementation form. The first node may be the root node 1202 or the intermediate replication node 1202 of FIG. 12, and the leaf node is the leaf node 1203 of FIG. 12. For example, the first node may be configured to execute the method steps of the first node or the intermediate replication node of FIGS. 1 to 7A and 7B and have corresponding functions. The leaf node is configured to execute the steps executed by the leaf node described in the embodiments of FIGS. 1 to 7A and 7B and have corresponding functions.

[0266] In one implementation form, the first node is configured to determine the next-hop node of the first node based on the replicated branch information and send the 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, the first request message includes the address of the root node of the P2MP tree, and based on the address of the root node, send the first response message to the root node.

[0267] In one implementation form, the system includes a root node 1201 of a P2MP tree, an intermediate replication node 1202, and a leaf node 1203. The root node 1201 determines, based on the replication branch information, that the next-hop node of the root node is the intermediate replication node, sends a first request message to the intermediate replication node, receives a first response message sent by the leaf node, and determines, 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 the replication branch information, that the next-hop node is the leaf node, and send the 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 including at least one instruction, program, or code. When the instruction, program, or code is executed on a computer, the computer is enabled to execute any one of the steps of the foregoing methods to determine the bandwidth for transmitting a service flow. For example, the corresponding method steps of the method embodiments executed by the first node, the root node, the intermediate replication node, or the leaf node in the embodiments of FIGS. 1 to 7A and 7B may be executed.

[0269] One embodiment of the present application provides a computer program product including at least one instruction, program, or code. When the instruction, program, or code is loaded and executed on a computer, the computer is enabled to execute corresponding method steps of the method embodiments executed by the first node, root node, intermediate replication node, or leaf node in the embodiments of FIGS. 1 to 7A and 7B.

[0270] It should be noted that the above-described device embodiments are merely examples. The units described as separate parts may or may not be physically separate, and the parts shown as units may or may not be physical units, that is, they may be arranged in one place or distributed among a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment. In addition, in the accompanying drawings of the embodiments of the first network node or controller provided in the present application, the connection relationship between the modules indicates that there is a communication connection between the modules, and the communication connection may be specifically implemented as one or more communication buses or signal cables. A person skilled in the art can understand and implement the embodiments of the present invention without creative efforts.

[0271] All or part of the foregoing embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implementing the embodiments using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and run on a computer, 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 devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by means of wired (such as coaxial cable, optical fiber, or digital subscriber line (DSL)) or wireless (such as infrared, wireless, or microwave) methods. The computer-readable storage medium may be any available medium accessible to a computer or a data storage device, such as a server or a data center incorporating one or more available media. The available media may be a magnetic medium (such as a floppy disk, a hard disk, or a magnetic tape), an optical medium (such as a DVD), a semiconductor medium (such as a solid state disk (SSD)), and the like.

[0272] Those skilled in the art should understand that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented by hardware, software, firmware, or any combination thereof. When the function is implemented by software, the foregoing function 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 a computer storage medium and a communication medium, and the communication medium includes any medium that enables a computer program to be transmitted from one place to another. The storage medium may be any available medium accessible to a general-purpose or dedicated computer.

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

Description of Reference Numerals

[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 Replication Node 1203 Leaf Node

Claims

1. A method for detecting point-to-multipoint P2MP tree connectivity, the method being applicable to a segment routing SR domain, the SR domain including a P2MP tree, the P2MP tree including a first node, the first node being a root node or an intermediate replication node of the P2MP tree, the method comprising: Determining, by the first node, a first next-hop node of the first node based on replication branch information; Sending, by the first node, a first request message to the first next-hop node, the first request message including a 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.

2. The first node is a root node of the P2MP tree, the first next-hop node is a leaf node of the P2MP tree, and the method comprises: Determining, by the first node, that a path from the first node to the first next-hop node is connected in response to receiving a first response message sent by the first next-hop node by the first node, the first response message being a response message to the first request message; or Further comprising, by the first node, determining that a path from the first node to the first next-hop node is disconnected in response to not receiving a response message sent by the first next-hop node and responding to the first request message by the first node, the method according to claim 1.

3. The first node is a root node of the P2MP tree, the first next-hop node is an intermediate replication node of the P2MP tree, and the method comprises: 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, the step of determining that the path from the first node to the leaf node is connected, wherein the second response message is a response message to the first request message, or The method according to claim 1, further comprising the step of, in response to the first node not receiving a response message transmitted by a leaf node on a path through the first next-hop node and responding to the first request message, determining that the path from the first node to the leaf node is disconnected.

4. The replicated 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 the first node determining a first next-hop node of the first node based on the replicated branch information is The method according to any one of claims 1 to 3, comprising the step of the first node determining the first next-hop node based on an identifier of the path.

5. The replicated branch information includes a segment identifier SID of a downstream node of the first node, and the SID of the downstream node includes the SID of the first next-hop node, The step of the first node determining a next-hop node of the first node based on the replicated branch information is The method according to any one of claims 1 to 3, comprising the step of the first node determining the SID of the first next-hop node based on the SID of the downstream node.

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

7. The method is The step of the first node determining a second next-hop node of the first node based on the replicated branch information, and A step of transmitting, by the first node, 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, the method according to any one of claims 1 to 6, further comprising the step.

8. The method according to any one of claims 1 to 7, wherein the first identifier is for identifying that the first request message is an operation and maintenance management OAM packet.

9. The method according to claim 8, wherein the first identifier is a User Datagram Protocol UDP port number.

10. The method according to any one of claims 1 to 9, wherein the first request message further includes the address of the root node of the P2MP tree, and the address of the root node is for indicating the leaf node of the P2MP tree for transmitting the response message in response to the first request message based on the address of the root node.

11. The method according to any one of claims 1 to 10, wherein the first request message includes a second identifier, and the second identifier is for identifying the P2MP tree.

12. The method according to claim 11, wherein the second identifier is any one or more of the address of the root node of the P2MP tree, a replication identifier Replication-ID of a replication segment, and a tree identifier Tree ID of the P2MP tree.

13. The method according to any one of claims 1 to 12, wherein the first request message includes a time to live TTL or a hop limit HL, and the values of the TTL and the HL are natural numbers.

14. 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 leaf nodes, and the method includes: A step of receiving, by the leaf node, a first request message, wherein the first request message includes the address of the root node of the P2MP tree and a first identifier, and the first identifier indicates that the first request message is for connectivity detection. A method including the step of transmitting, by the leaf node, a first response message to the root node based on the address of the root node.

15. The method according to claim 14, wherein the first identifier is for identifying that the first request message is an operation, administration, and maintenance (OAM) packet.

16. The method according to claim 15, wherein the first identifier is a User Datagram Protocol (UDP) port number.

17. Before the step of transmitting, by the leaf node, the first response message to the root node and after the step of receiving, by the leaf node, the first request message, the method further includes: the step of verifying, by the leaf node, the validity of the first request message based on a second identifier; and the step of transmitting, by the leaf node, the first response message to the root node in response to successful verification of the validity against the second identifier. The method according to any one of claims 14 to 16.

18. The method according to claim 17, wherein the second identifier includes the address of the root node and / or a third identifier for identifying the P2MP tree.

19. The method according to claim 18, wherein the third identifier includes a replication identifier (Replication-ID) of a replication segment or a tree identifier (Tree ID) of the P2MP tree.

20. The step of verifying, by the leaf node, the validity of the first request message based on a second identifier includes: the step of verifying, by the leaf node, the validity of the first request message based on the second identifier carried in the first request message; and Success in verifying the validity against the second identifier includes the step of determining, by the leaf node, that information regarding a control plane corresponding to the P2MP tree matches the second identifier. The method according to any one of claims 17 to 19.

21. The method according to any one of claims 14 to 20, wherein the address of the root node is an Internet Protocol version 6 (IPv6) address.

22. The method according to any one of claims 14 to 20, wherein the first request message includes a time to live TTL or a hop limit HL, and the values of the TTL and the HL are natural numbers.

23. A first node, wherein the first node is a root node of an intermediate replication node of a point-to-multipoint P2MP tree, the P2MP tree is within a segment routing SR domain, and the first node A processing unit configured to determine a first next-hop node of the first node based on replication branch information, A transmission unit configured to transmit a first request message to the first next-hop node, wherein the first request message includes a segment identifier SID of the first next-hop node, the first request message includes a first identifier, and the first identifier indicates that the first request message is for connectivity detection. A first node comprising a transmission unit.

24. The first node is a root node of the P2MP tree, the first next-hop node is a leaf node of the P2MP tree, and the first node further comprises a receiving unit, The receiving unit is configured to receive a first response message transmitted by the first next-hop node, The processing unit is further configured to determine that a path from the first node to the first next-hop node is connected in response to the receiving unit receiving the first response message, and the first response message is a response message to the first request message. The first node according to claim 23.

25. The first node is a root node of the P2MP tree, the first next-hop node is a leaf node of the P2MP tree, and the first node further comprises a receiving unit, The processing unit is further configured to determine that a path from the first node to the first next-hop node is disconnected in response to the receiving unit not receiving a response message in response to the first request message. The first node according to claim 23.

26. 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. The receiving unit is configured to receive a second response message transmitted by the first next-hop node. The processing unit is further configured to determine that a path from the first node to a leaf node is connected in response to the receiving unit receiving the second response message, and the second response message is a response message to the first request message. The first node according to claim 23.

27. 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. The processing unit is further configured to determine that a path from the first node to the first next-hop node is disconnected in response to the receiving unit not receiving a response message in response to the first request message. The first node according to claim 23.

28. The processing unit is further configured to determine a second next-hop node of the first node based on the replication branch information. The transmitting unit is further configured to transmit a second request message to the second next-hop node, the second request message includes the SID of the second next-hop node, and the second request message includes the first identifier. The first node according to any one of claims 23 to 27.

29. The first identifier is for identifying that the first request message is an operation, administration, and maintenance OAM packet. The first node according to any one of claims 23 to 28.

30. The first identifier is a User Datagram Protocol UDP port number. The first node according to any one of claims 23 to 29.

31. The first request message further includes the address of the root node, and the address of the root node is for indicating a leaf node of the P2MP tree for transmitting the response message in response to the first request message based on the address of the root node. The first node according to any one of claims 23 to 30.

32. The first request message includes a second identifier, and the second identifier is for identifying the P2MP tree. The first node according to any one of claims 23 to 31.

33. The second identifier is any one or more of the address of the root node of the P2MP tree, a replication identifier Replication-ID of a replication segment, and a tree identifier Tree ID of the P2MP tree. The first node according to claim 32.

34. A leaf node, wherein the leaf node is a leaf node of a point-to-multipoint P2MP tree, the P2MP tree is within a segment routing SR domain, and the leaf node A receiving unit configured to receive a first request message, the first request message including an address of a root node of the P2MP tree and a first identifier, the first identifier indicating that the first request message is for connectivity detection. A receiving unit, A leaf node comprising a transmitting unit configured to transmit a first response message to the root node based on the address of the root node.

35. The first identifier is for identifying that the first request message is an operation, administration, and maintenance OAM packet. The leaf node according to claim 33.

36. The first identifier is a User Datagram Protocol UDP port number. The leaf node according to claim 34.

37. The leaf node further comprises a processing unit, The processing unit is configured to verify the validity of the first request message based on a second identifier before transmitting the first response message to the root node and after receiving the first request message. The leaf node according to any one of claims 33 to 35, wherein the transmission unit is further configured to transmit the first response message to the root node in response to successful verification of the validity of the second identifier.

38. The leaf node according to claim 37, wherein the second identifier includes the address of the root node and / or a third identifier for identifying the P2MP tree.

39. The leaf node according to claim 38, wherein the third identifier includes a replication identifier Replication-ID of a replication segment or a tree identifier Tree ID of the P2MP tree.

40. A point-to-multipoint P2MP tree connectivity detection system, the system including a P2MP tree, the P2MP tree being within a segment routing SR domain, the system comprising a root node, an intermediate replication node, and a leaf node of the P2MP tree, The root node determines, based on first replication branch information, that the next-hop node of the root node is the intermediate replication node, transmits a first request message to the intermediate replication node, and in response to receiving the first response message transmitted by the leaf node, determines that the path from the root node to the leaf node is connected. The first request message includes a segment identifier SID of the intermediate replication node, the first request message includes a first identifier, and the first identifier indicates that the first request message is for connectivity detection. The intermediate replication node is configured to receive the first request message and determine, based on second replication branch information, that the next-hop node is the leaf node, and transmit the first request message to the leaf node. The leaf node is configured to receive the first request message and transmit the first response message to the root node.

41. A computer-readable storage medium including a computer program, wherein when the computer program is executed on a computer, the computer is enabled to execute the method according to any one of claims 1 to 22.