Method for detecting multicast service flow and related device

Abstract

The embodiment of the present application provides a multicast service flow detection method, which comprises the following steps: a first node receives a multicast service flow sent by a multicast source; the first node encapsulates an IFIT extension header for the data packet of the multicast service flow; wherein the IFIT extension header comprises a first detection identifier, and the first detection identifier is used for identifying the multicast service flow to be detected; the first node copies the data packet encapsulated with the IFIT extension header according to the number of second nodes of next hops of the first node; and the first node sends the data packet encapsulated with the IFIT extension header to each second node of the next hops. The first node is a head node in a multicast detection domain. The scheme can apply the IFIT technology to the field of multicast service flow detection, and provides a performance detection mode for the multicast service.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method and related apparatus for detecting multicast service flows. Background Technology

[0002] Network performance testing technology is a common research hotspot in the Internet and telecommunications fields. Various performance testing technologies monitor, measure, and collect network performance data to analyze, evaluate, control, and adjust the network operating status in order to provide long-term stable and reliable network services, which is the foundation of network operation.

[0003] Currently, the method of network performance testing by encapsulating the IFIT extension header in the service packets being tested is limited to the field of unicast service testing. Testing multicast services is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a method and related apparatus for detecting multicast service flows, which can detect multicast service flows through flow detection technology.

[0005] In a first aspect, embodiments of this application provide a method for detecting multicast service flows, comprising: a first node receiving a multicast service flow sent by a multicast source; the first node encapsulating a flow detection technology (IFIT) extension header in the data packets of the multicast service flow; wherein the IFIT extension header includes a first detection identifier, the first detection identifier being used to identify the multicast service flow being detected; the first node copying the data packets encapsulated with the IFIT extension header according to the number of second nodes in the next hop of the first node; and the first node sending the data packets encapsulated with the IFIT extension header to each second node in the next hop.

[0006] In this embodiment, the first node is the head node in the multicast detection domain. The first node encapsulates the received multicast service stream data packets with an IFIT extension header, thus allowing the IFIT header to be inserted into the multicast service stream. Then, the first node copies the data packets encapsulated with the IFIT header and sends them to the next-hop node. In this way, the data packets encapsulated with the IFIT header can be forwarded in the detection domain along with the multicast service stream, enabling performance testing of multicast services through the IFIT header.

[0007] In one possible implementation of the first aspect, the detection identifier in the copied IFIT extension header is the same as the first detection identifier.

[0008] In one possible implementation of the first aspect, the copied IFIT extension header includes a second detection identifier, which is different from the first detection identifier and contains the first detection identifier.

[0009] In one possible implementation of the first aspect, the first node receives configuration information indicating the replication mode. It can be seen that the first node can perform corresponding operations on the replication of the first detection identifier based on the configuration information.

[0010] In one possible implementation of the first aspect, the method further includes: a first node collecting first quantity information and first time information, wherein the first quantity information is the number of data packets in the multicast service stream received within a preset period, and the first time information is the timestamp of the data packets in the multicast service stream received at a time point within the preset period; sending first detection information to a control node, wherein the first detection information includes one or more of the first quantity information, the first time information, the entry identifier of the first node, and the first detection identifier; the first detection information is used by the control node to perform packet loss detection or latency detection on the multicast service stream.

[0011] In one possible implementation of the first aspect, before the first node sends the first detection information packet to the control node, the method further includes: parsing the multicast source address and multicast group address from the data packets of the multicast service stream; the first detection information also includes the multicast source address and multicast group address.

[0012] The multicast source address and multicast group address are used to inform the control node of the true information of the multicast service flow being detected, and to prove the authenticity of the multicast service flow being detected.

[0013] In one possible implementation of the first aspect, the method further includes: a first node obtaining second quantity information and second time information, wherein the second quantity information is the number of data packets encapsulated with IFIT extension headers in the multicast service stream sent within a preset period, and the second time information is the timestamp of sending the data packets encapsulated with IFIT extension headers in the multicast service stream at a time point within the preset period; sending second detection information to a control node, wherein the second detection information includes one or more of the second quantity information, second time information, first detection identifier, and exit identifier of the first node; the second detection information is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0014] Before performing performance testing on the multicast service stream, the control node can pre-obtain the topology of the detection domain. Therefore, the control node is aware of the ingress and egress identifiers of the first node. In this embodiment, the first detection identifier is used by the control node to identify the multicast service stream being tested. The first quantity information and the second quantity information can be used by the control node to perform packet loss detection on the first node of the multicast service stream. The first time information and the second time information can be used by the control node to perform latency detection on the first node of the multicast service stream. The ingress and egress identifiers of the first node are used by the control node to clarify the positional relationship of the first node.

[0015] Secondly, embodiments of this application provide a method for detecting multicast service flows, comprising: a second node receiving a data packet encapsulated with an IFIT extension header sent by a first node of the previous hop; the IFIT extension header includes a first detection identifier, which is used to identify the multicast service flow to which the data packet belongs; the first node is the head node in the multicast group; the second node copies the data packet encapsulated with the IFIT extension header according to the number of third nodes in the next hop of the second node; and the second node sends the data packet encapsulated with the IFIT extension header to each node in the next hop.

[0016] In this embodiment, the second node is an intermediate node in the multicast detection domain. The second node copies the data packets encapsulated with the IFIT extension header received from the previous hop node and then sends them to the next hop node. Therefore, data packets encapsulated with the IFIT extension header can be forwarded in the detection domain, and multicast service performance can be detected through IFIT.

[0017] In one possible implementation of the second aspect, the detection identifier in the copied IFIT extension header is the same as the first detection identifier.

[0018] In one possible implementation of the second aspect, the copied IFIT extension header includes a second detection identifier, which is different from the first detection identifier, and the second detection identifier contains the first detection identifier.

[0019] In one possible implementation of the second aspect, the first node receives configuration information indicating the replication mode. It can be seen that the first node can perform corresponding operations on the replication of the first detection identifier based on the configuration information.

[0020] In one possible implementation of the second aspect, the method further includes: the second node obtaining third quantity information and third time information, wherein the third quantity information is the number of data packets encapsulated with IFIT extension headers in the multicast service stream received within a preset period, and the third time information is the timestamp of the data packets encapsulated with IFIT extension headers in the multicast service stream received at a time point in the preset period; sending third detection information to the control node, wherein the third detection information includes one or more of the third quantity information, third time information, first detection identifier, and entry identifier of the second node; the first detection information is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0021] In one possible implementation of the second aspect, the method further includes: the second node obtaining fourth quantity information and fourth time information, wherein the fourth quantity information is the number of data packets encapsulated with IFIT extension headers in the multicast service stream sent within a preset period, and the fourth time information is the timestamp of sending the data packets encapsulated with IFIT extension headers in the multicast service stream at a time point in the preset period; sending fourth detection information to the control node, wherein the fourth detection information includes one or more of the fourth quantity information, fourth time information, first detection identifier, and second node's exit identifier; the fourth detection information is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0022] Before performing performance testing on the multicast service flow, the control node can pre-obtain the topology of the detection domain. Therefore, the control node is aware of the ingress and egress identifiers of the second node. In this embodiment, the first detection identifier is used by the control node to identify the multicast service flow; the third and fourth quantity information can be used by the control node to perform packet loss detection on the second node of the multicast service flow; the third and fourth time information can be used by the control node to perform latency detection on the second node of the multicast service flow; and the ingress and egress identifiers of the second node are used by the control node to determine the positional relationship of the second node. Furthermore, the control node can combine the detection information sent by the first and second nodes to perform packet loss and latency detection on the multicast service flow link.

[0023] Thirdly, embodiments of this application provide a multicast service flow detection apparatus, comprising: a receiving unit for receiving a multicast service flow sent by a multicast source; an encapsulation unit for encapsulating a flow-following detection technology (IFIT) extension header into the data packets of the multicast service flow; wherein the IFIT extension header includes a first detection identifier, the first detection identifier being used to identify the multicast service flow being detected; a copying unit for copying the data packets encapsulated with the IFIT extension header according to the number of second nodes in the next hop of the first node; and a sending unit for sending the data packets encapsulated with the IFIT extension header to each second node in the next hop.

[0024] In one possible implementation of the third aspect, the detection identifier in the copied IFIT extension header is the same as the first detection identifier.

[0025] In one possible implementation of the third aspect, the copied IFIT extension header includes a second detection identifier, which is different from the first detection identifier and contains the first detection identifier.

[0026] In one possible implementation of the third aspect, the receiving unit is further configured to: receive configuration information, the configuration information being used to indicate the replication mode.

[0027] In one possible implementation of the third aspect, it further includes: a first obtaining unit, configured to obtain first quantity information and first time information, wherein the first quantity information is the number of data packets in the multicast service stream received within a preset period, and the first time information is the timestamp of the data packets in the multicast service stream received at a time point in the preset period; a first sending unit, configured to send first detection information to the control node, wherein the first detection information includes one or more of the first quantity information, the first time information, the entry identifier of the first node, and the first detection identifier; the first detection information packet is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0028] In one possible implementation of the third aspect, before the sending unit sends the first detection information to the control node, it further includes: a parsing unit, used to parse the multicast source address and multicast group address from the data packets of the multicast service stream; the first detection information also includes the multicast source address and multicast group address.

[0029] In one possible implementation of the third aspect, it further includes: a second obtaining unit, configured to obtain second quantity information and second time information, wherein the second quantity information is the number of data packets encapsulated with IFIT extension headers in the multicast service stream sent within a preset period, and the second time information is the timestamp of sending the data packets encapsulated with IFIT extension headers in the multicast service stream at a time point in the preset period; a second sending unit, configured to send second detection information to the control node, wherein the second detection information includes one or more of the second quantity information, second time information, first detection identifier, and exit identifier of the first node; the second detection information is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0030] Fourthly, embodiments of this application provide a multicast service flow detection apparatus, comprising: a receiving unit, configured to receive a data packet encapsulated with an IFIT extension header sent by a first node of the previous hop; the IFIT extension header includes a first detection identifier, the first detection identifier being used to identify the multicast service flow to which the data packet belongs; the first node being the head node in a multicast group; a copying unit, configured to copy the data packet encapsulated with the IFIT extension header according to the number of third nodes in the next hop of the second node; and a sending unit, configured to send the data packet encapsulated with the IFIT extension header to each node in the next hop.

[0031] In one possible implementation of the fourth aspect, the detection identifier in the copied IFIT extension header is the same as the first detection identifier.

[0032] In one possible implementation of the fourth aspect, the copied IFIT extension header includes a second detection identifier, which is different from the first detection identifier and contains the first detection identifier.

[0033] In one possible implementation of the fourth aspect, the receiving unit is further configured to: receive configuration information, the configuration information being used to indicate the mode of the replication.

[0034] In one possible implementation of the fourth aspect, it further includes: a first obtaining unit, configured to obtain third quantity information and third time information, wherein the third quantity information is the number of data packets encapsulated with IFIT extension headers in the multicast service stream received within a preset period, and the third time information is the timestamp of the data packets encapsulated with IFIT extension headers in the multicast service stream received at a time point in the preset period; a first sending unit, configured to send third detection information to the control node, wherein the third detection information includes one or more of the third quantity information, third time information, first detection identifier, and entry identifier of the second node; the third detection information is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0035] In one possible implementation of the fourth aspect, it further includes: a second obtaining unit, configured to obtain fourth quantity information and fourth time information, wherein the fourth quantity information is the number of data packets encapsulated with IFIT extension headers in the multicast service stream sent within a preset period, and the fourth time information is the timestamp of sending the data packets encapsulated with IFIT extension headers in the multicast service stream at a time point in the preset period; a second sending unit, configured to send fourth detection information to the control node, wherein the fourth detection information includes one or more of the fourth quantity information, fourth time information, first detection identifier, and exit identifier of the second node; the fourth detection information is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0036] Fifthly, embodiments of this application provide a multicast service flow detection apparatus, comprising: a receiving unit, configured to receive a data packet encapsulated with an IFIT extension header sent by a second node of the previous hop; wherein the IFIT extension header includes a first detection identifier, the first detection identifier being used to uniquely identify the multicast service flow to which the data packet belongs; the first node being the head node in the multicast group; a decapsulation unit, configured to decapsulate the data packet from the data packet encapsulated with the IFIT extension header; a copying unit, configured to copy the data packet according to the number of receivers of the next hop of the third node; and a sending unit, configured to send the data packet to each receiver of the next hop.

[0037] In one possible implementation of the fifth aspect, it further includes: a first obtaining unit, configured to obtain fifth quantity information and fifth time information, wherein the fifth quantity information is the number of data packets encapsulated with IFIT extension headers in the multicast service stream received within a preset period, and the fifth time information is the timestamp of the data packets encapsulated with IFIT extension headers in the multicast service stream received within the preset period; a first sending unit, configured to send fifth detection information to the control node, wherein the fifth detection information includes one or more of the fifth quantity information, fifth time information, first detection identifier, and entry identifier of the third node; the fifth detection information packet is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0038] In one possible implementation of the fifth aspect, it further includes: a second obtaining unit, configured to obtain sixth quantity information and sixth time information, wherein the sixth quantity information is the number of data packets sent within a preset period, and the sixth time information is the timestamp of the data packets sent within the preset period;

[0039] The second sending unit is used to send the sixth detection information to the control node. The sixth detection information includes one or more of the sixth quantity information, the sixth time information, the first detection identifier, and the exit identifier of the third node. The sixth detection information packet is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0040] Sixthly, embodiments of this application provide a multicast service flow detection device, the detection device including at least one processor and a communication interface, the communication interface being used to send and / or receive data, and at least one processor being used to call a computer program stored in at least one memory, so that the detection device implements the method described in the first aspect or any possible implementation of the first aspect, or the second aspect or any possible implementation of the second aspect, or the third aspect or any possible implementation of the third aspect.

[0041] In a seventh aspect, embodiments of this application provide a multicast service flow detection system, which includes a first node, a second node, and a third node, wherein the first node is the apparatus described in the third aspect or any possible implementation of the third aspect; the second node is the apparatus described in the fourth aspect or any possible implementation of the fourth aspect; and the third node is the apparatus described in the fifth aspect or any possible implementation of the fifth aspect.

[0042] Eighthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on one or more processors, performs the method described in the first aspect or any possible implementation thereof.

[0043] Ninthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on one or more processors, performs the method described in the second aspect or any possible implementation thereof.

[0044] In a tenth aspect, embodiments of this application provide a computer program product that, when run on one or more processors, performs the method described in the first aspect or any possible implementation thereof.

[0045] In the eleventh aspect, embodiments of this application provide a computer program product that, when run on one or more processors, performs the method described in the second aspect or any possible implementation thereof.

[0046] In a twelfth aspect, embodiments of this application provide a chip system including at least one processor, a memory, and an interface circuit. The interface circuit is used to provide information input / output to the at least one processor. The memory stores a computer program that, when run on one or more processors, executes the method described in the first aspect or any possible implementation of the first aspect.

[0047] In a thirteenth aspect, embodiments of this application provide a chip system including at least one processor, a memory, and an interface circuit. The interface circuit is used to provide information input / output to the at least one processor. The memory stores a computer program that, when run on one or more processors, performs the methods described in the second aspect or any possible implementation of the second aspect. Attached Figure Description

[0048] The accompanying drawings used in the embodiments of this application are described below.

[0049] Figure 1 This is a schematic diagram of the encapsulation format of an IFIT extension header provided in an embodiment of this application;

[0050] Figure 2A This is a schematic diagram illustrating a scenario of a multicast service flow detection method provided in an embodiment of this application;

[0051] Figure 2B This is a schematic diagram of the structure of a node provided in an embodiment of this application;

[0052] Figure 3A This is a schematic diagram of a system architecture for a multicast detection domain provided in an embodiment of this application;

[0053] Figure 3B This is a schematic diagram of a multicast service stream transmission path provided in an embodiment of this application;

[0054] Figure 4 This is a flowchart illustrating a method for detecting multicast service flows provided in an embodiment of this application;

[0055] Figure 5 This is a schematic diagram of the structure of a multicast service flow detection device provided in an embodiment of this application;

[0056] Figure 6 This is a schematic diagram of another multicast service flow detection device provided in an embodiment of this application;

[0057] Figure 7 This is a schematic diagram of the structure of a multicast service flow detection device provided in an embodiment of this application. Detailed Implementation

[0058] The technical solutions in the embodiments of this application will now be described clearly and in detail with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the "or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0059] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0060] The following is a brief introduction to the relevant technologies and technical terms involved in this application to facilitate understanding.

[0061] In-situ Flow Information Telemetry (IFIT)

[0062] IFIT detection technology is based on RFC 8321 (Alternate-Marking Method for Passive and Hybrid Performance Monitoring). It is a flow detection technology that specially marks (colors) the actual business flow and performs packet loss and latency detection on the feature fields.

[0063] IFIT is based on flow-following inspection, requiring the inclusion of IFIT header information in actual service packets. Flow-following nodes then perform performance measurements based on the IFIT extended header. For example... Figure 1 The diagram shows the encapsulation format of the core part of the IFIT extension header. The Flow ID (bits 0-19) identifies a service flow carrying this first detection identifier. The Flow ID must be unique across the entire network within the detection domain. IP-based radio access network (IPRAN) elements can identify flows based on the Flow ID. L Flag: Loss Flag, a packet loss measurement marker; D Flag: Delay Flag, a delay measurement marker, where 1 indicates that delay needs to be measured, and 0 indicates that delay does not need to be measured.

[0064] One embodiment of this application (referred to as Scheme 1) is as follows: Figure 2A As shown, from Figure 2A It can be seen that head node 201 receives data packets from the multicast service stream sent by the multicast source. Ingress 1 of head node 201 identifies the data packets and generates a first detection identifier 100 based on the data packets. The first detection identifier 100 is then encapsulated into an IFIT extension header, and the IFIT extension header is further encapsulated into the data packets. It should be noted that a multicast service stream includes one or more multicast packets, each of which encapsulates an IFIT extension header. The first detection identifier 100 is used to identify the multicast service stream carrying this first detection identifier.

[0065] Downlink from head node 201 requires multicast replication of data packets encapsulated with the IFIT extension header. Generally, the replication amount depends on the number of next-hop nodes in head node 201. Figure 2AAs can be seen, the next-hop nodes of head node 201 are intermediate nodes 202A and 2020B. Therefore, head node 201 needs to copy two data packets encapsulated with the IFIT extension header. For the first detection identifier 100 encapsulated in the data packet, a second detection identifier 100:100 and a second detection identifier 100:200 are generated respectively. Then, the second detection identifier 100:100 and the second detection identifier 100:200 replace the first detection identifier 100 inserted into the data packet, respectively. Finally, the updated data packets are forwarded by exit points 2 and 3 of head node 201.

[0066] Header node 201's ingress 1 sends the multicast service detection result + first detection identifier 100 to the control node (not shown in the figure). Header node 201's egress 2 sends the multicast service detection result + second detection identifier 100:100 to the control node (not shown in the figure). Header node 201's egress 3 sends the data packet detection result + second detection identifier 100:200 to the control node (not shown in the figure). The detection result sent by header node's ingress 1 can be the number of data packets received according to a preset period and their timestamps. The detection result sent by header node's egress 2 can be the number of data packets encapsulated with second detection identifier 100:100 sent according to a preset period and their timestamps. The detection result sent by header node's egress 3 can be the number of data packets encapsulated with second detection identifier 100:200 sent according to a preset period and their timestamps. The control node (not shown in the figure) receives the information sent by the head node 201. Since the sent information contains the first detection identifier 100, the control node (not shown in the figure) can identify that the reported information is a multicast service flow carrying the same first detection identifier 100. It can then perform hop-by-hop packet loss detection on the multicast service flow = {detection result of entry 1 - detection result of entry 2 or detection result of entry 1 - detection result of entry 3}.

[0067] Intermediate and tail nodes replicate, update, and forward received data packets in the same manner, and also send the detection result plus the first detection identifier to the control node (not shown in the diagram). All information sent to the control node includes the first detection identifier 100. The control node can assume that the detection results reported by the head, intermediate, and tail nodes belong to the service flow carrying the same first detection identifier 100. Therefore, link packet loss detection can be performed on multicast service flows carrying this first detection identifier 100.

[0068] Please see Figure 2B , Figure 2B This is a schematic diagram of the node structure provided in an embodiment of this application. From... Figure 2BIt can be seen that the node includes a network processor (NP) chip and a traffic management (TM) chip. Typically, the operation of generating a first detection identifier for data packets in a multicast traffic flow and encapsulating this identifier in an IFIT header requires a high-performance processing chip, usually the NP chip; while the operation of copying data packets encapsulated with the IFIT header is performed by the TM chip. However, for... Figure 2A In the scenario diagram shown, the TM chip needs to edit the IFIT header for the packets it copies. That is, the TM chip edits the first detection identifier in the IFIT header encapsulated in the copied data packet, generating an identifier different from the original first detection identifier. Due to the limited processing power of the TM chip, re-editing the first detection identifier is quite difficult. Therefore, Figure 2A The proposed method for detecting multicast service flows is currently difficult to implement.

[0069] Another embodiment of this application (referred to as Scheme Two) proposes a method and related apparatus for detecting multicast service flows. The method includes:

[0070] The first node receives the multicast service stream sent by the multicast source. The first node encapsulates the data packets of the multicast service stream with an IFIT (In-Flow Detection) extension header. For example, before encapsulating the data packets with the IFIT extension header, the first node identifies the multicast service stream (e.g., by identifying the multicast stream through (S-multicast source, G-multicast group) in the multicast packet) and generates a first detection identifier. Then, the first detection identifier is inserted into the IFIT extension header. The first detection identifier is used to uniquely identify the multicast service stream being detected, which contains one or more data packets. That is, the first detection identifier identifies a multicast stream in the multicast detection domain. The first node copies the data packets encapsulated with the IFIT extension header according to the number of second nodes in the next hop. The detection identifier in the copied IFIT extension header is the same as the first detection identifier. Then, the first node sends the data packets encapsulated with the IFIT extension header to each second node in the next hop. The first node is the head node in the multicast detection domain. In this embodiment, the first node in the multicast detection domain to receive the service stream to be tested sent by the multicast source is defined as the head node.

[0071] The second node receives a data packet encapsulated with an IFIT header from the first node of the previous hop. The second node then copies the data packet encapsulated with the IFIT header according to the number of third nodes in its next-hop nodes, and sends the data packet encapsulated with the IFIT header to each next-hop node. The second node is an intermediate node in the multicast detection domain.

[0072] The third node receives a data packet with an IFIT header from the second node of the previous hop, and decapsulates the data packet from the IFIT header. The third node then copies the data packet according to the number of receivers in the next hop, and sends the data packet to each receiver in the next hop. The third node is the tail node in the multicast detection domain.

[0073] In this embodiment, the first detection identifier is the same before and after each replication. For example, the first detection identifier in the IFIT extension header encapsulated by the first node is 100, and the first detection identifier in the data packet encapsulated with the IFIT extension header replicated by the first node is still 100. Similarly, the first detection identifier in the data packet encapsulated with the IFIT extension header replicated by the second node is also 100.

[0074] Nodes in the multicast detection domain also send detection information to the control node. The detection information sent by the node's ingress to the control node includes the ingress identifier, the first detection identifier, the number of data packets received within a preset period, and the timestamps of the data packets received within the preset period. The detection information sent by the node's egress to the control node includes the egress identifier, the first detection identifier, the number of data packets sent within a preset period, and the timestamps of the data packets sent within the preset period.

[0075] The control node receives detection information sent by nodes in the multicast detection domain, all of which have the same first detection identifier. This indicates that the detection information is from the same service flow, and packet loss detection or latency detection can be performed based on the detection information.

[0076] Compared to Figure 2A In the scheme described in this application embodiment, the TM does not need to edit the first detection identifier in the IFIT extension header of the copied message, thereby making the technical solution of this application embodiment easy to implement on existing TMs.

[0077] The two schemes mentioned above describe two replication modes. Scheme 1 uses the same detection identifier in the copied IFIT extension header as the original IFIT extension header. Scheme 2 uses a different detection identifier in the copied IFIT extension header than the original IFIT extension header. In implementation, the device (head node or intermediate node) can be configured to run in either Scheme 1 or Scheme 2 mode during runtime, or its replication mode can be fixed at the factory.

[0078] The system architecture provided in the embodiments of this application is described below. It should be noted that the system architecture described in this application is for the purpose of more clearly illustrating the technical solution of this application, and does not constitute a limitation on the technical solution provided in this application. As those skilled in the art will know, with the evolution of system architecture, the counting scheme provided in this application is also applicable to similar technical problems.

[0079] Please see Figure 3A , Figure 3A This is a schematic diagram of a system architecture for a multicast detection domain provided in an embodiment of this application. The system architecture of the multicast detection domain includes a server 301, a control node 302, a multicast source 303, a head node 304A, an intermediate node 304B, a tail node 304C, and a receiver 305.

[0080] Server 301 serves as the physical device for deploying control node 302. Also known as a server, it's a device that provides computing services. Because servers need to respond to service requests and process those requests, they generally possess the capability to undertake and guarantee services. For example, the server analyzes and processes the business information received by the control node to obtain packet loss and latency data for the multicast detection domain.

[0081] The 301 server consists of a processor, hard disk, memory, system bus, etc., similar to a general computer architecture. However, due to the need to provide reliable services, it has high requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0082] Generally speaking, a server 301 can refer to an x86 server, also known as a Complex Instruction Set Computing (CISC) architecture server, or PC server. It is a server based on the PC architecture, using Intel or other processor chips compatible with the x86 instruction set and the Windows operating system. x86 servers are characterized by their low price, good compatibility, relatively poor stability, and lower security, and are mainly used in small and medium-sized enterprises and non-critical business applications.

[0083] Control node 302, with functions such as network management, service control, and network analysis, is the core enabling system for realizing network resource pooling, automated network connection, and automated operation and maintenance. It is primarily used to collect data and perform performance testing on service packets along the transmission paths between nodes in the multicast detection domain. Performance testing includes packet loss detection and latency detection. Control node 302 can determine the control domain, obtain the topology diagram of the multicast detection domain within the control domain, and determine the entry and exit identifiers of the head node, intermediate nodes, and tail node of the transmission path to be detected based on the topology diagram.

[0084] Multicast source 303 is a node used to send multicast service flows to multicast groups within the multicast detection domain. In the multicast detection domain, the multicast source sends information only once. Nodes in the multicast detection domain establish routes for the multicast service flows using multicast routing protocols. The transmitted information is replicated and distributed only at the furthest possible branch point. All node members in the multicast group can receive the multicast service flow data packets. The multicast group consists of a head node 304A, intermediate nodes 304B, and a tail node 304C. It's important to note that a multicast source is not necessarily a member of the multicast group; it sends data to the multicast group but is not necessarily a receiver itself. Multiple multicast sources can send messages to a single multicast group simultaneously. Figure 3A Only one multicast source is shown in the image.

[0085] It should be noted that, although Figure 3A The diagram only shows one head node 304A, one intermediate node 304B, and one tail node 304C, but the nodes in a multicast group can consist of multiple head nodes, multiple intermediate nodes, and multiple tail nodes.

[0086] Header node 304A is the first node in the multicast detection domain to receive data packets from multicast service flows. It receives data packets sent by multicast source 303, generates a first detection identifier based on the data packets, encapsulates the first detection identifier into an IFIT extension header, then encapsulates the IFIT extension header into the data packets, copies and forwards the copied data packets encapsulated with the IFIT extension header. The detection identifier in the copied IFIT extension header is the same as the first detection identifier. It is also used to collect detection information from incoming service flows and upload the detection information to control node 302.

[0087] Intermediate node 304B is used to receive data packets encapsulated with IFIT extension headers sent by the head node, copy the data packets, and forward them. The detection identifier in the copied IFIT extension header is the same as the first detection identifier. It is also used to count the detection information of incoming multicast service flows and upload the detection information to control node 302.

[0088] Tail node 304C is used to receive data packets encapsulated with IFIT extension headers sent by intermediate nodes, copy the data packets, and decapsulate the data packets from the data packets encapsulated with IFIT extension headers. It is also used to collect detection information of incoming service flows and upload the detection information to control node 302.

[0089] It should be noted that the detection information collected by the head node, intermediate node, and tail node includes one or more of the following: the entry and exit identifiers of each node, the number and timestamps of data packets received and sent by each node, the first detection identifier, the multicast source address, the multicast group address, the multicast source port, the receiving port, and the multicast protocol number.

[0090] The receiver 305 is used to receive data packets sent by the tail node 304C. It should be noted that the receiver 305 can also join a multicast group composed of the head node 304A, the intermediate node 304B, and the tail node 304C.

[0091] It should be noted that in multicast mode, the sender of the information is called the "multicast source", and the receiver of the information is called the "multicast group" of the information.

[0092] It should be noted that the nodes mentioned in the embodiments of this application are electronic devices with data transmission and reception functions. In specific implementation, the head node 304A, the intermediate node 304B, and the tail node 304C can be data relay devices, such as routers, repeaters, bridges, or switches. The receiving end 305 can be a terminal device, such as various types of user equipment (UE), mobile phones, tablets, desktop computers, headphones, speakers, televisions, etc.

[0093] Please see Figure 3B , Figure 3B This is a schematic diagram of a multicast service stream transmission path provided in an embodiment of this application. The diagram includes a control node and multiple network nodes. These network nodes are connected via communication links for transmitting the multicast service stream. Figure 3B As shown, the multicast source, head node, intermediate node 1, intermediate node 2, tail node, and multicast group are connected sequentially via communication links. The multicast group consists of receiver 1, receiver 2, and receiver 3. Multicast service streams can travel from the multicast source through the head node, intermediate node 1, and tail node to the multicast group, and any receiver in the multicast group can receive the multicast service stream.

[0094] The control node can collect information and perform transmission path performance testing on data packets along the transmission path between the aforementioned multiple network nodes. Performance testing includes packet loss detection and latency detection. Packet loss detection includes end-to-end (E2E) packet loss detection and hop-by-hop packet loss detection; latency detection includes E2E latency detection and hop-by-hop packet loss detection. In this embodiment, the transmission path may include the path traversed by multicast service flows.

[0095] The control node can determine a detection domain, which is the detection range defined by the control node. In one possible implementation, the network engineer sends device information of the transmission path to be detected to the control node through a network management device or user equipment. This device information includes the identifiers of the head node and tail node of the data path to be detected. For example, the network engineer requests to detect the transmission path between a first network device and a second network device. The network engineer sends the device identifiers of the first and second network devices to the control node through the network management device or user equipment. After receiving the device identifiers of the first and second network devices, the control node designates the first network device as the head node of the transmission path to be detected and the second network device as the tail node, thereby determining the detection domain. The control node can receive the device information through, for example, a northbound interface (NBI).

[0096] In another possible implementation, the control node determines the head node device identifier and tail node device identifier of the transmission path to be detected according to a predetermined multicast policy. The control node can acquire the topology of multiple network nodes in the multicast detection domain, and thus determine the head node device identifier and tail node device identifier of the transmission path to be detected based on the topology of these multiple network nodes. For example, the preset multicast policy is to collect detection information and perform performance testing on the transmission paths between forwarding nodes within a data center (DC). The control node determines the head node device identifier and tail node device identifier of the transmission path to be detected based on the topology of the DC.

[0097] In another possible implementation, the controller node can determine the detection head node device based on the multicast source address of the multicast service stream's data packets, and determine the detection tail node device based on the destination address of the data packets, thereby determining the detection domain.

[0098] In the transmission path within the detection domain, the next-hop node of the head node can be an intermediate node, and the previous-hop node of the tail node can also be an intermediate node. For example... Figure 3B The intermediate node 1 and intermediate node 2 in the diagram.

[0099] The control node sends information carrying the head node identifier to the head node determined by the control node. The head node identifier can be identified by the head node's device identifier or IP address, etc. After receiving the head node identifier, the head node can determine that it is the head node based on the head node identifier. Therefore, when the head node receives a multicast service stream, it can identify the multicast service stream, generate a first detection identifier 100 for the multicast service stream, insert the first detection identifier 100 into the IFIT extension header, and encapsulate the IFIT extension header for the multicast service stream's data packets.

[0100] The control node sends information carrying the tail node's identifier to the tail node it has identified. The tail node identifier can be identified using the tail node's device identifier or IP address, etc. Upon receiving the tail node identifier, the tail node can determine itself as the tail node based on this identifier. Therefore, after receiving a multicast service stream, the tail receiver can decapsulate the data packets from the data packets encapsulated with the IFIT extension header.

[0101] Figure 3B In the detection domain shown, the head node's egress B, intermediate node 1's ingress D, intermediate node 1's egress E, and tail node 1's ingress G communicate through a single transmission path; and the head node's egress B, intermediate node 1's ingress D, intermediate node 1's egress F, and tail node 2's ingress K communicate through another transmission path. When the head node receives a multicast service stream, it copies two data packets encapsulated with IFIT extension headers. The detection identifier in the copied IFIT extension header is the same as the first detection identifier 100. One data packet is sent from the head node's egress B to the intermediate node 1's ingress D, and the other data packet is sent from the head node's egress C to the intermediate node 2's ingress L. After receiving the data packet encapsulated with an IFIT extension header sent by the head node's egress B, intermediate node 1 copies it to obtain two data packets encapsulated with IFIT extension headers. The detection identifier in the copied IFIT extension header is the same as the first detection identifier. One copy is sent from the intermediate node's egress E to the tail node 1's ingress G, and the other copy is sent from the intermediate node's egress F to the tail node 2's ingress K. After receiving a data packet encapsulated with an IFIT extension header, the tail node decapsulates the data packet from the IFIT header, copies it to obtain three data packets, and sends the data packet from tail node 1's egress H to node 1 in the multicast group, from tail node 1's egress I to node 2 in the multicast group, and from tail node 1's egress J to node 3 in the multicast group. It should be noted that... Figure 3B The topology of multiple nodes in the detection domain shown is an example, and the embodiments of this application do not impose any limitations.

[0102] Each network node in the detection domain can send detection information to the control node. The detection information sent by the ingress node of each node includes its ingress identifier, first detection identifier, the number of data packets received in the multicast service stream within a preset period, and a timestamp. The detection information sent by the egress node of each node includes its egress identifier, first detection identifier, the number of data packets sent in the multicast service stream within a preset period, and a timestamp. The detection information may also include the multicast source address and multicast group address parsed from the data packets by the nodes in the detection domain. The multicast source address and multicast group address are used by the control node to determine the true information of the detected service stream.

[0103] It should be noted that in the embodiments of this application, devices and nodes can be used interchangeably. For example, a control node can be called a control device, a head node can be called a head device, an intermediate node can be called an intermediate device, and a tail node can be called a tail device.

[0104] It should be noted that, in this embodiment of the application, there is at least one data packet in the multicast service stream, and each data packet in the multicast service stream is encapsulated with an IFIT extension header, which includes a first detection identifier. That is, the first detection identifier can be carried in each replicated data packet.

[0105] Please see Figure 4 , Figure 4 This is a flowchart illustrating a multicast service flow detection method provided in an embodiment of this application. The method includes, but is not limited to, the following steps:

[0106] Step S401: The first node receives the multicast service stream sent by the multicast source.

[0107] Specifically, multicast refers to sending data packets to a specific set of nodes (i.e., a multicast group) in a best-effort delivery manner within a multicast detection domain. The basic idea of ​​multicast provided in this application embodiment is that in a multicast environment, the multicast source sends only one multicast service stream. The destination address of the multicast service stream it generates is not single, but a group, thus forming a group address. All receivers in the multicast group can receive the same data packets copied from the data packets in the multicast service stream. The multicast service stream sent by the multicast source can be a video stream.

[0108] The protocols involved in the multicast detection domain mainly include multicast group management protocols and multicast routing protocols. The multicast group management protocol currently used is the Internet Multicast Management Protocol (IGMP), which serves as the basic signaling protocol for IP multicast. IGMP primarily operates between nodes in the multicast group and the multicast detection domain, enabling network nodes to determine whether there are multicast group members on their network segment. Multicast routing protocols operate between multicast nodes, establishing and maintaining multicast routes to ensure the correct and efficient forwarding of multicast service flows. Currently used multicast routing protocols include PIM-SM, PIM-DM, and MSDP.

[0109] Multicast routing protocols can establish a loop-free data transmission path from a multicast source to multiple receivers in a multicast group, such as... Figure 3B The diagram shown is a schematic of the multicast service stream transmission path provided in an embodiment of this application. The first node receives the multicast service stream sent by the multicast source through the established transmission path.

[0110] It should be noted that the first node is the head node in the multicast detection domain. In this embodiment, the node that is the first to receive the service stream to be tested sent by the multicast source in the multicast detection domain is defined as the head node. It can be understood that the first node to receive the service stream is not necessarily the first node in the multicast detection domain, but can be any node in the multicast detection domain.

[0111] Step S402: The first node encapsulates the data packets of the multicast service flow with the IFIT extension header for flow detection technology.

[0112] Specifically, after receiving a multicast service stream, the first node encapsulates an IFIT extension header into the data packets of the multicast service stream. The IFIT extension header includes a first detection identifier, which is a sequence number generated by the first node after matching the multicast service stream (e.g., by identifying the multicast stream through (S-multicast source, G-multicast group) in the multicast packet). The first detection identifier is used to identify a service stream and can be unique across the entire network within the detection domain. It should be noted that because the multicast service stream to be detected includes one or more data packets, an IFIT extension header is encapsulated in each data packet of the multicast service stream. For example, the first detection identifier corresponds to... Figure 1 In the Flow ID field, if the multicast service flow received by the first node is the first one in the network, the first node can determine that the Flow ID value of the service flow is 1. Therefore, the Flow ID value of 1 is used to uniquely identify the multicast service flow. If there are 100 other multicast service flows in the network before the first node receives the multicast service flow, the first node can determine that the Flow ID value of the multicast service flow is 101. Therefore, the Flow ID value of 101 is used to uniquely identify the multicast service flow.

[0113] Step S403: The first node sends the first detection information to the control node.

[0114] Specifically, after the first node encapsulates the data packets of the multicast service flow with an IFIT extension header, it needs to count the first quantity information and the first time information of the multicast service flow. The first quantity information is the number of data packets received by the first node in the multicast service flow within a preset period. For example, the marker field of the detected flow (multicast service flow) is alternately colored according to the preset period, and then the number of colored packets in this period is counted as the first quantity. The first time information is the timestamp of the data packets in the multicast service flow received at the time point of the preset period. For example, in each measurement period, one data packet of the detected multicast service flow received at the start time point, end time point, or intermediate time point of this period is time-delayed colored, and the entry timestamp of the data packet is recorded. If the measurement period is 10 seconds, the time-delayed colored data packet can be performed on the data packet received in the first second of the first 10 seconds, or the data packet received in the 10th second of the first 10 seconds.

[0115] The entry point of the first node sends first detection information to the control node according to a preset period. The first detection information carries a first identifier, which can be composed of the entry point of the first node and the value of the first detection identifier. For example, if the entry point of the first node is A and the value of the first detection identifier is 1, then the first identifier can be A1. The first detection information specifically includes first quantity information, first time information, the entry identifier of the first node, and the first detection identifier.

[0116] When the first node parses the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number from the data packets of the multicast service stream, the first detection information may also include the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number.

[0117] It should be noted that the first node can encapsulate one or more of the following: first quantity information, first time information, first node entry identifier, first detection identifier, multicast source address and multicast group address, as well as multicast source port, receiving port and multicast protocol number, into first detection information, and then send the first detection information to the control node.

[0118] Step S404: The first node copies the data packet encapsulated with the IFIT extension header according to the number of second nodes.

[0119] Specifically, the control node can pre-obtain the topology map of the multicast detection domain. From the topology map, the transmission path from the multicast source to the multicast group can be determined, thus determining the number of data packets copied by each node along the transmission path. This information is then sent to each node. For the first node, the control node can obtain the number of its next-hop nodes from the topology map and send this number to the first node. The first node can then copy data packets encapsulated with an IFIT extension header based on the number of its next-hop nodes. The detection identifier in the copied IFIT extension header is the same as the first detection identifier. For example, if the first detection identifier in the IFIT extension header encapsulated by the first node is 100, the detection identifier in the copied data packet encapsulated with the IFIT extension header will also be 100.

[0120] For example, the first node may have three exits, but only two of them need to forward data packets. So when a data packet in a multicast service stream is transmitted to the first node, the first node knows that it will only forward the data packet through two of the exits, so it copies the data packet twice.

[0121] Step S405: The first node sends a data packet encapsulated with an IFIT extension header to the second node.

[0122] Specifically, the control node can know in advance which exits of the first node will send data packets. Therefore, the control node can send the relevant exit information to the first node, which can be the exit identifier of the first node. So when the first node obtains the data packet encapsulated with the IFIT extension header, it can send it to the second node through the pre-determined exits of the first node.

[0123] For example, the egress identifiers for the data packets to be forwarded in the first node are denoted as B and C, respectively. The port numbers of the ingress nodes connecting egress B and egress C are denoted as D and L, respectively. When a data packet in a multicast service stream is transmitted to the first node, the first node knows that the data packet needs to enter the next node through its two egress points, so it copies the data packet twice. One copy of the data packet is forwarded from egress B to the ingress D of the next hop node; the other copy is forwarded from egress C to the ingress L of the next hop node.

[0124] Step S406: The first node sends a second detection message to the control node.

[0125] Specifically, after the first node sends a data packet encapsulated with an IFIT extension header to each next-hop second node, it needs to statistically analyze the second quantity information and the second time information of the multicast service flow. The second quantity information is the number of data packets in the multicast service flow sent by the first node within a preset period. For example, according to the preset period statistically analyzed by the first node's ingress end, the number of colored packets sent within the preset period is counted as the first quantity. The first time information is the timestamp of the data packets in the multicast service flow sent within the preset period. For example, according to the preset period statistically analyzed by the first node's ingress end, the exit timestamp of the delayed colored data packets in the detected multicast service flow in each period is recorded.

[0126] The first node's output sends second detection information to the control node at a preset period. This second detection information carries a second identifier, which can be composed of the first node's output and the value of a first detection identifier. For example, if the first node's output is B and the first detection identifier's value is 1, then the second identifier could be B1. Specifically, the second detection information includes one or more of the following: second quantity information, second time information, the first node's output identifier, and the first detection identifier.

[0127] Optionally, after the first node parses one or more of the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number from the data packets of the multicast service flow, the second detection information may also include one or more of the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number.

[0128] It should be noted that the first node can encapsulate one or more of the following: second quantity information, second time information, first node's exit identifier, first detection identifier, multicast source address and multicast group address, multicast source port, receiving port, and multicast protocol number, into second detection information, and then send the second detection information to the control node.

[0129] It should be noted that when data packets need to be sent to the first hop node of the first node through several exits of the first node, several sets of detection information about the exits of the first interface need to be sent. For example, if a data packet is sent through exit B of the first node, the detection information of exit B needs to be sent to the control node; and if a data packet is sent through exit C of the first node, the detection information of exit C needs to be sent to the control node.

[0130] Step S407: The second node receives the data packet encapsulated with the IFIT extension header sent by the first node.

[0131] Specifically, the control node can predetermine the multicast detection domain, thereby identifying the head node and tail node. On the transmission path within the detection domain, the intermediate node is located between the head node and the tail node. The second node is an intermediate node within the multicast detection domain. It is understood that at least one intermediate node can exist on the transmission path, but only one node can receive the data packet encapsulated with the IFIT extension header sent by the first node.

[0132] Step S408: The second node sends the third detection information to the control node.

[0133] Specifically, after receiving a data packet encapsulated with an IFIT extension header from the first node, the second node needs to collect third quantity information and third time information for the multicast service stream. The third quantity information is the number of data packets received by the second node in the multicast service stream within a preset period. For example, based on the preset period counted by the first node's ingress end, the number of colored packets received by the second node within the preset period is counted as the third quantity. The third time information is the timestamp of the data packets received by the second node in the multicast service stream within the preset period. For example, based on the preset period counted by the first node's ingress end, the second node records the ingress timestamp of the delayed colored data packets in the detected multicast service stream for each period.

[0134] The second node sends third detection information to the control node at a preset period. This third detection information carries a third identifier, which can be composed of the second node's entry identifier and the value of the first detection identifier. For example, if the second node's entry identifier is D and the first detection identifier is 1, then the second identifier could be D1. The third detection information specifically includes one or more of the following: third quantity information, third time information, the second node's entry identifier, and the first detection identifier.

[0135] Optionally, after the second node parses the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number from the data packets of the multicast service flow, the third detection information may also include the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number.

[0136] It should be noted that the second node can encapsulate one or more of the following: third quantity information, third time information, second node entry identifier, first detection identifier, multicast source address and multicast group address, multicast source port, receiving port, and multicast protocol number, into third detection information, and then send the third detection information to the control node.

[0137] Step S409: The second node copies the data packet encapsulated with the IFIT extension header according to the number of third nodes.

[0138] Specifically, because the control node can pre-obtain the topology of the multicast detection domain, it can determine the transmission path from the multicast source to the multicast group from the topology. Therefore, it can determine the number of data packets copied by each node along the transmission path and then distribute this information to each node. For the second node, the control node can obtain the number of next-hop nodes from the topology and then send this number to the second node. The second node can then copy data packets encapsulated with an IFIT extension header based on the number of its next-hop third nodes. The detection identifier in the copied IFIT extension header is the same as the first detection identifier. For example, the detection identifier in the copied data packet encapsulated with an IFIT extension header is also 100. For instance, a second node may have four exit points, but only two of them need to forward data packets. Therefore, when data packets in a multicast service flow are transmitted to the second node, the second node knows to forward the data packets only through the two exit points and thus copies the data packets twice.

[0139] Step S410: The second node sends a data packet encapsulated with an IFIT extension header to the third node.

[0140] Specifically, the control node can know in advance which exit points of the second node will send data packets to the third node. Therefore, the control node can send the relevant exit information to the second node, which can be the exit identifier of the second node. So when the second node obtains the data packet encapsulated with the IFIT extension header, it can send it to the third node through the pre-determined exit points of the second node.

[0141] It is understandable that at least one intermediate node can exist on a multicast transmission path. When there is one intermediate node, the second node sending data packets to the third node can also be the second node receiving data packets sent by the first node. When there are two intermediate nodes, the second node sending data packets to the third node is not the same node as the second node receiving data packets sent by the first node. For example, second node 1 could receive data packets sent by the first node, then send the data packets to second node 2, and second node 2 could then send the data packets to the third node.

[0142] For example, the egress identifiers for the data packets to be forwarded in the second node are represented by E and F, respectively, and the port numbers of the ingress nodes connected to the next-hop nodes of egress E and F are represented by G and K, respectively. When a data packet in a multicast service stream is transmitted to the first node, the first node knows that the data packet needs to enter the next node through its two egress points, so it copies the data packet twice. One copy of the data packet is forwarded from egress E to the ingress G of the next-hop node; the other copy is forwarded from egress F to the ingress K of the next-hop node.

[0143] Step S411: The second node sends the fourth detection message to the control node.

[0144] Specifically, after the second node sends a data packet encapsulated with an IFIT extension header to each next-hop third node, it needs to count the fourth quantity information and the fourth time information of the multicast service flow. The fourth quantity information is the number of data packets in the multicast service flow sent by the second node within a preset period. For example, according to the preset period counted by the first node's ingress end, the number of colored packets sent in the preset period is counted as the fourth quantity. The fourth time information is the timestamp of the data packets in the multicast service flow sent within the preset period. For example, according to the preset period counted by the first node's ingress end, the exit timestamp of the delayed colored data packets in the detected multicast service flow in each period is recorded.

[0145] The second node's output sends fourth detection information to the control node at a preset cycle. This fourth detection information carries a fourth identifier, which can be composed of the second node's output and the value of the first detection identifier. For example, if the second node's output is E and the first detection identifier is 1, then the second identifier could be E1. Specifically, the fourth detection information includes one or more of the following: fourth quantity information, fourth time information, the second node's output identifier, and the first detection identifier.

[0146] Optionally, after the second node parses one or more of the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number from the data packets of the multicast service flow, the second detection information may also include one or more of the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number.

[0147] It should be noted that the second node can encapsulate one or more of the following: fourth quantity information, fourth time information, second node's exit identifier, first detection identifier, multicast source address and multicast group address, multicast source port, receiving port, and multicast protocol number, into fourth detection information, and then send the fourth detection information to the control node.

[0148] Step S412: The third node receives the data packet encapsulated with the IFIT extension header sent by the second node.

[0149] Specifically, the control node can predetermine the multicast detection domain, thereby obtaining the topology map of that detection domain. The third node is the tail node in the multicast detection domain, serving as the node that sends data packets from the multicast service flow to the receiving end within the multicast detection domain.

[0150] It is understandable that, regardless of how many intermediate nodes may exist on the multicast transmission path, the third node receives the data packet encapsulated with the IFIT extension header sent by the second node of the previous hop.

[0151] Step S413: The third node sends the fifth detection information to the control node.

[0152] Specifically, after the third node receives a data packet encapsulated with an IFIT extension header from the second node of the previous hop, it needs to count the fifth quantity information and the fifth time information of the multicast service flow. The fifth quantity information is the number of data packets received by the third node in the multicast service flow within a preset period. For example, according to the preset period counted by the first node's entry point, the number of colored packets received in the preset period is counted as the fifth quantity. The fifth time information is the timestamp of the data packets received in the multicast service flow within the preset period. For example, according to the preset period counted by the third node's entry point, the entry timestamp of the delayed colored data packets in the detected multicast service flow in each period is recorded.

[0153] The third node's entry point sends fifth detection information to the control node according to a preset cycle. This fifth detection information carries a fifth identifier, which can be composed of the third node's entry point and the value of the first detection identifier. For example, if the third node's entry point is G and the first detection identifier is 1, then the fifth identifier could be G1. Specifically, the fifth detection information includes one or more of the following: fifth quantity information, fifth time information, the third node's entry identifier, and the first detection identifier.

[0154] Optionally, after the third node parses one or more of the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number from the data packets of the multicast service stream, the fifth detection information may also include one or more of the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number.

[0155] It should be noted that the third node can encapsulate one or more of the following: fifth quantity information, fifth time information, third node entry identifier, first detection identifier, multicast source address and multicast group address, multicast source port, receiving port, and multicast protocol number, into fifth detection information, and then send the fifth detection information to the control node.

[0156] Step S414: The third node decapsulates the data packet from the data packet encapsulated with the IFIT extension header.

[0157] Specifically, since the main purpose of the IFIT extension header is to perform performance testing such as packet loss and latency on multicast service flows, when the multicast service flow propagates to the tail node of the detection domain, the tail node needs to decapsulate the data packet encapsulated with the IFIT extension header to extract the data packet, which is the data that the receiver in the multicast group is interested in.

[0158] Step S415: The third node copies the data packets according to the number of receivers.

[0159] Specifically, because the control node can pre-obtain the topology of the multicast detection domain, it can determine the transmission path from the multicast source to the multicast group from the topology. Therefore, it can determine the number of data packets copied by each node along the transmission path and then distribute this information to each node. For the third node, the control node can obtain the number of receivers in the multicast group through the topology and then send this number to the third node. The third node can then copy data packets encapsulated with the IFIT extension header based on the number of receivers. It should be noted that the receiver can be considered the next-hop node of the third node.

[0160] For example, a third node may have five exits, but only three of them need to forward data packets. So when a data packet in a multicast service stream is transmitted to the third node, the third node knows to forward the data packet only through the three exits, so it copies the data packet three times.

[0161] Step S416: The third node sends a data packet to the receiving end.

[0162] Specifically, the control node can know in advance which exit points of the third node will send data packets to the receiving end. Therefore, the control node can send the relevant exit information to the third node, which can be the exit identifier of the third node. So when the third node obtains the data packet encapsulated with the IFIT extension header, it can send it to the receiving end through the predetermined exit points of the third node.

[0163] For example, the exit identifiers for data packets that need to be forwarded in the third node are represented by H, I, and J, respectively. The next-hop nodes connected to exits H, I, and J are receiver 1, receiver 2, and receiver 3, respectively. When a data packet in a multicast service stream is transmitted to the third node, the third node knows that the data packet needs to enter the next node through its three exits, so it copies the data packet three times. One copy of the data packet is forwarded from exit H to receiver 1; another copy is forwarded from exit I to receiver 2; and the last copy is forwarded from exit J to receiver 3.

[0164] Step S417: The third node sends the sixth detection message to the control node.

[0165] Specifically, after the third node sends a data packet to the receiving end, it needs to collect the sixth quantity information and the sixth time information of the multicast service stream. The sixth quantity information is the number of data packets in the multicast service stream sent by the third node within a preset period. For example, according to the preset period counted by the first node's ingress end, the third node counts the number of colored packets sent within the preset period as the sixth quantity. The sixth time information is the timestamp of the data packets in the multicast service stream sent within the preset period. For example, according to the preset period counted by the first node's ingress end, the third node records the exit timestamp of the delayed colored data packets in the detected multicast service stream in each period.

[0166] The third node's output sends a sixth detection message to the control node at a preset cycle. This sixth detection message carries a sixth identifier, which can be composed of the third node's output and the value of the first detection identifier. For example, if the sixth node's output is H and the first detection identifier is 1, then the second identifier could be H1. Specifically, the sixth detection message includes one or more of the following: sixth quantity information, sixth time information, the third node's output identifier, and the first detection identifier.

[0167] Optionally, after the third node parses one or more of the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number from the data packets of the multicast service flow, the sixth detection information may also include one or more of the multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number.

[0168] It should be noted that the third node can encapsulate one or more of the following: sixth quantity information, sixth time information, third node's exit identifier, first detection identifier, multicast source address and multicast group address, multicast source port, receiving port, and multicast protocol number, into sixth detection information, and then send the sixth detection information to the control node.

[0169] It should be noted that when data packets need to be sent to the receiving end through several exits of the third node, several sets of detection information about the exits need to be sent. For example, if a data packet is sent to the receiving end 1 through exit I of the third node, the detection information of exit I needs to be sent to the control node.

[0170] Step S418: The control node performs performance testing on the multicast service stream.

[0171] Specifically, because the control node can receive detection information sent by various nodes in the detection domain, and the first detection identifier in the detection information is the same, the control node can consider the detection information to be the detection information of the same multicast service flow, and can perform performance detection on the multicast service flow based on the detection information.

[0172] For E2E packet loss detection and latency detection, E2E packet loss detection and latency detection are performed based on the first detection information sent by the head node (ingress A) and the sixth detection information sent by the tail node. For example, assuming that data packets are sent to the receiving end through the three exits (exit H, exit I, and exit J) of the tail node, the sixth detection information sent by the tail node to the control node can include node information about these three exits. Then, the following steps are taken to determine whether there is packet loss in the data transmission path between the head node and the tail node: {number of data packets received by the head node's ingress A - data packets sent by the tail node's exit H}, {number of data packets received by the head node's ingress A - data packets sent by the tail node's exit I}, and {number of data packets received by the head node's ingress A - data packets sent by the tail node's exit J}.

[0173] For hop-by-hop packet loss detection and latency detection, packet loss and latency detection can be performed on the head node based on the first and second detection information sent by the head node; packet loss and latency detection can be performed on the intermediate nodes based on the third and fourth detection information sent by the intermediate nodes; and packet loss and latency detection can be performed on the tail node based on the fifth and sixth detection information sent by the tail node. Furthermore, packet loss and latency detection can be performed on the path between the head node and the intermediate nodes using the second detection information sent by the head node and the third detection information sent by the intermediate nodes.

[0174] It should be noted that the process steps of the multicast service flow detection method provided in this application embodiment are not limited to [specific steps]. Figure 4The process steps are shown. For example, the order of steps S402, S403, and S404 can be such that step S403 is performed first, followed by steps S402 and S404. Similarly, the order of steps S408 and S409 can be such that step 409 is performed first, followed by step 408. This application's embodiments do not impose any limitations.

[0175] The methods of the embodiments of this application have been described in detail above, and the apparatus of the embodiments of this application is provided below.

[0176] Please see Figure 5 , Figure 5 This is a schematic diagram of a multicast service flow detection device 50 provided in an embodiment of this application. The detection device 50 can be a node or a device within a node, such as a chip or integrated circuit. The detection device 50 may include a receiving unit 501, an encapsulation unit 502, a replication unit 503, and a sending unit 504. This detection device 50 is used to implement the aforementioned multicast service flow detection method, for example... Figure 3A , Figure 3B or Figure 4 The multicast service flow detection method of any of the embodiments shown.

[0177] It is understood that in the various device embodiments of this application, the division of multiple units or modules is only a logical division based on function and is not intended to limit the specific structure of the device. In specific implementations, some functional modules may be subdivided into more smaller functional modules, and some functional modules may be combined into a single functional module. However, regardless of whether these functional modules are subdivided or combined, the general process executed by the detection device 50 in detecting multicast service flows is the same. For example, the receiving unit 501, encapsulation unit 502, copying unit 503, and sending unit 504 in the detection device 50 can also be combined into a communication unit. Typically, each unit corresponds to its own program code (or program instructions). When the program code corresponding to each unit runs on the processor, it causes the unit to execute the corresponding process to achieve the corresponding function.

[0178] In some possible implementations, the detection device 50 can be Figure 3A , Figure 3B or Figure 4 The first node in the illustrated embodiment is described as follows:

[0179] The receiving unit 501 is used to receive the multicast service stream sent by the multicast source;

[0180] The encapsulation unit 502 is used to encapsulate the data packets of the multicast service flow with the IFIT extension header of the flow detection technology; wherein, the IFIT extension header includes a first detection identifier, which is used to identify the multicast service flow being detected;

[0181] The replication unit 503 is used to replicate the data packet encapsulated with the IFIT extension header according to the number of second nodes that are the next hop of the first node;

[0182] The sending unit 504 is used to send a data packet encapsulated with an IFIT extension header to the second node of each next hop.

[0183] In one possible implementation, the detection identifier in the copied IFIT extension header is the same as the first detection identifier.

[0184] In one possible implementation, the copied IFIT extension header includes a second detection identifier, which is different from the first detection identifier, but contains the first detection identifier.

[0185] In one possible implementation, the receiving unit 501 is further configured to:

[0186] Receive configuration information, which indicates the replication mode.

[0187] In one possible implementation, the device 50 further includes:

[0188] The first obtaining unit 5011 is used to obtain first quantity information and first time information, wherein the first quantity information is the number of data packets in the multicast service stream received within a preset period, and the first time information is the timestamp of the data packets in the multicast service stream received at a time point in the preset period.

[0189] The first sending unit 5012 is used to send first detection information to the control node. The first detection information includes one or more of the following: first quantity information, first time information, entry identifier of the first node, and first detection identifier. The first detection information packet is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0190] In one possible implementation, before sending the first detection information to the control node, the sending unit 504 further includes:

[0191] The parsing unit 5013 is used to parse the multicast source address and multicast group address from the data packets of the multicast service stream; the first detection information also includes the multicast source address and multicast group address.

[0192] In one possible implementation, the device 50 further includes:

[0193] The second obtaining unit 5014 is used to obtain second quantity information and second time information, wherein the second quantity information is the number of data packets encapsulated with IFIT extension headers in the multicast service stream sent within a preset period, and the second time information is the timestamp of the data packets encapsulated with IFIT extension headers in the multicast service stream sent within the preset period.

[0194] The second sending unit 5015 is used to send second detection information to the control node. The second detection information includes one or more of the following: second quantity information, second time information, first detection identifier, and exit identifier of the first node. The second detection information is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0195] It should be noted that the implementation of each unit can also be referenced accordingly. Figure 3A , Figure 3B , Figure 4 A corresponding description of one embodiment is shown.

[0196] Please see Figure 6 , Figure 6 This is a schematic diagram of a multicast service flow detection device 60 provided in an embodiment of this application. The device 60 can be a node or a component within a node, such as a chip or integrated circuit. The detection device 60 may include a receiving unit 601, a copying unit 602, and a sending unit 603. This detection device 60 is used to implement the aforementioned multicast service flow detection method, for example... Figure 3A , Figure 3B or Figure 4 The multicast service flow detection method of any of the embodiments shown.

[0197] It is understood that in the various device embodiments of this application, the division of multiple units or modules is only a logical division based on function and is not intended to limit the specific structure of the device. In specific implementations, some functional modules may be subdivided into more smaller functional modules, and some functional modules may be combined into a single functional module. However, regardless of whether these functional modules are subdivided or combined, the general process executed by device 60 in detecting multicast service flows is the same. For example, the receiving unit 601 and the sending unit 603 in the aforementioned device 60 can also be combined into a communication unit. Typically, each unit corresponds to its own program code (or program instructions). When the program code corresponding to each unit runs on the processor, it causes the unit to execute the corresponding process to achieve the corresponding function.

[0198] In some possible implementations, the device 60 can be Figure 3A , Figure 3B or Figure 4The second node in the illustrated embodiment is described as follows:

[0199] The receiving unit 601 is used to receive a data packet encapsulated with an IFIT extension header sent by the first node of the previous hop; the IFIT extension header includes a first detection identifier, which is used to identify the multicast service flow to which the data packet belongs; the first node is the head node in the multicast group.

[0200] The replication unit 602 is used to replicate data packets encapsulated with IFIT extension headers according to the number of third nodes that are the next hop of the second node.

[0201] The sending unit 603 is used to send a data packet encapsulated with an IFIT extension header to each next-hop node.

[0202] In one possible implementation, the detection identifier in the copied IFIT extension header is the same as the first detection identifier.

[0203] In one possible implementation, the copied IFIT extension header includes a second detection identifier, which is different from the first detection identifier, but contains the first detection identifier.

[0204] In one possible implementation, the receiving unit 601 is further configured to:

[0205] Receive configuration information, which indicates the replication mode.

[0206] In one possible implementation, device 60 further includes:

[0207] The first statistical unit 6011 is used to count the third quantity information and the third time information. The third quantity information is the number of data packets with IFIT extension headers encapsulated in the multicast service stream received within a preset period, and the third time information is the timestamp of the data packets with IFIT extension headers encapsulated in the multicast service stream received within the preset period.

[0208] The first sending unit 6012 is used to send third detection information to the control node. The third detection information includes one or more of the following: third quantity information, third time information, first detection identifier, and second node entry identifier. The third detection information is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0209] In one possible implementation, device 60 further includes:

[0210] The second statistical unit 6013 is used to count the fourth quantity information and the fourth time information. The fourth quantity information is the number of data packets with IFIT extension headers encapsulated in the multicast service stream sent within a preset period. The fourth time information is the timestamp of the data packets with IFIT extension headers encapsulated in the multicast service stream sent within the preset period.

[0211] The second sending unit 6014 is used to send fourth detection information to the control node. The fourth detection information includes one or more of the following: fourth quantity information, fourth time information, first detection identifier, and second node exit identifier. The fourth detection information is used by the control node to perform packet loss detection or delay detection on the multicast service stream.

[0212] It should be noted that the implementation of each unit can also be referenced accordingly. Figure 3A , Figure 3B , Figure 4 A corresponding description of one embodiment is shown.

[0213] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a multicast service flow detection device 70 provided in an embodiment of this application. The detection device 70 can be a node or a device within a node, such as a chip or integrated circuit. The device 70 may include at least one memory 701 and at least one processor 702. Optionally, it may also include a bus 703. Further optionally, it may also include a communication interface 704, wherein the memory 701, processor 702, and communication interface 704 are connected via the bus 703.

[0214] The memory 701 provides storage space, which can store data such as the operating system and computer programs. The memory 701 can be one or a combination of several of the following: random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM).

[0215] Processor 702 is a module that performs arithmetic and / or logical operations. Specifically, it can be one or a combination of processing modules such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor unit (MPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and a complex programmable logic device (CPLD).

[0216] The communication interface 704 is used to receive and / or transmit data to external sources. It can be a wired link interface, such as an Ethernet cable, or a wireless link interface (Wi-Fi, Bluetooth, general wireless transmission, etc.). Optionally, the communication interface 704 may also include a transmitter (such as a radio frequency transmitter, antenna, etc.) or a receiver coupled to the interface.

[0217] The processor 702 in the detection device 70 is used to read the computer program stored in the memory 701 to execute the aforementioned Bluetooth pairing method, for example... Figure 3A , Figure 3B or Figure 4 The method for detecting the performance of multicast service streams as described in any embodiment.

[0218] In some possible implementations, the multicast service stream performance testing device 70 can be... Figure 3A , Figure 3B or Figure 4 In the first node of the illustrated embodiment, the processor 702 in the detection device 70 is used to read the computer program stored in the memory 701 and to perform the following operations:

[0219] Receive multicast service streams sent by multicast sources;

[0220] The data packets of multicast service flows are encapsulated with the IFIT extension header for in-stream detection technology; wherein, the IFIT extension header includes a first detection identifier, which is used to identify the multicast service flow being detected;

[0221] The data packet encapsulated with the IFIT extension header is copied based on the number of second nodes that are the next hops of the first node;

[0222] Send a data packet encapsulated with an IFIT extension header to the second node of each next hop.

[0223] In one possible implementation, the detection identifier in the copied IFIT extension header is the same as the first detection identifier.

[0224] In one possible implementation, the copied IFIT extension header includes a second detection identifier, which is different from the first detection identifier, but contains the first detection identifier.

[0225] In one possible implementation, processor 702 is further configured to:

[0226] Receive configuration information, which indicates the replication mode.

[0227] In one possible implementation, the processor 702 is further configured to:

[0228] The first quantity information and the first time information are statistically analyzed. The first quantity information is the number of data packets in the multicast service stream received within a preset period, and the first time information is the timestamp of the data packets in the multicast service stream received within the preset period.

[0229] Send first detection information to the control node, wherein the first detection information includes one or more of the following: first quantity information, first time information, entry identifier of the first node, and first detection identifier; the first detection information is used by the control node to perform packet loss detection or latency detection on the multicast service stream.

[0230] In one possible implementation, before sending the first detection information packet to the control node, the processor 702 is also used to:

[0231] The multicast source address and multicast group address are obtained by parsing the data packets of the multicast service stream; the first detection information also includes the multicast source address and multicast group address.

[0232] In one possible implementation, the processor 702 is further configured to:

[0233] The second quantity information and the second time information are statistically analyzed. The second quantity information is the number of data packets with IFIT extension headers encapsulated in the multicast service stream sent within a preset period. The second time information is the timestamp of the data packets with IFIT extension headers encapsulated in the multicast service stream sent within the preset period.

[0234] Send second detection information to the control node, wherein the second detection information includes one or more of the following: second quantity information, second time information, first detection identifier, and first node's exit identifier; the second detection information is used by the control node to perform packet loss detection or latency detection on the multicast service stream.

[0235] It should be noted that the implementation of each unit can also be referenced accordingly. Figure 3A , Figure 3B , Figure 4 A corresponding description of one embodiment is shown.

[0236] In some possible implementations, the detection device 70 for inspecting the multicast service stream can be... Figure 3A , Figure 3B , Figure 4 In the second node of the illustrated embodiment, the processor 702 in the detection device 70 is used to read the computer program stored in the memory 701 and to perform the following operations:

[0237] Receive a data packet encapsulated with an IFIT extension header sent by the first node of the previous hop; the IFIT extension header includes a first detection identifier, which is used to identify the multicast service flow to which the data packet belongs; the first node is the head node in the multicast group;

[0238] The data packet encapsulated with the IFIT extension header is copied based on the number of third nodes in the next hop of the second node;

[0239] Send a data packet encapsulated with an IFIT extension header to each next-hop node.

[0240] In one possible implementation, the detection identifier in the copied IFIT extension header is the same as the first detection identifier.

[0241] In one possible implementation, the copied IFIT extension header includes a second detection identifier, which is different from the first detection identifier, but contains the first detection identifier.

[0242] In one possible implementation, processor 702 is further configured to:

[0243] Receive configuration information, which indicates the replication mode. In one possible implementation, the processor 702 is further configured to:

[0244] The third quantity information and the third time information are statistically analyzed. The third quantity information is the number of data packets with IFIT extension headers encapsulated in the multicast service stream received within a preset period, and the third time information is the timestamp of the data packets with IFIT extension headers encapsulated in the multicast service stream received within the preset period.

[0245] Send third detection information to the control node, wherein the third detection information includes one or more of the following: third quantity information, third time information, first detection identifier, and second node entry identifier; the first detection information is used by the control node to perform packet loss detection or latency detection on the multicast service stream.

[0246] In one possible implementation, the processor 702 is further configured to:

[0247] The fourth quantity information and the fourth time information are statistically analyzed. The fourth quantity information is the number of data packets with IFIT extension headers encapsulated in the multicast service stream sent within a preset period. The fourth time information is the timestamp of the data packets with IFIT extension headers encapsulated in the multicast service stream sent within the preset period.

[0248] Send fourth detection information to the control node, wherein the fourth detection information includes one or more of the following: fourth quantity information, fourth time information, first detection identifier, and second node exit identifier; the fourth detection information is used by the control node to perform packet loss detection or latency detection on multicast service streams.

[0249] This application also provides a computer-readable storage medium storing a computer program that, when executed on one or more processors, performs... Figure 3A , Figure 3B , Figure 4 The method for detecting multicast service flows as shown in any of the embodiments.

[0250] This application embodiment also provides a chip system, which includes at least one processor, a memory, and an interface circuit. The interface circuit is used to provide information input / output to the at least one processor. The at least one memory stores a computer program, which executes when the computer program is run on one or more processors. Figure 3A , Figure 3B , Figure 4 The method for detecting multicast service flows as shown in any of the embodiments.

[0251] This application also provides a computer program product that, when run on one or more processors, can execute the following: Figure 3A , Figure 3B , Figure 4 The method for detecting multicast service flows described in any of the embodiments shown.

[0252] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented entirely or partially in the form of a computer instruction product. When the computer instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application can be implemented entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0253] The steps in the method embodiments of this application can be adjusted, combined, or deleted according to actual needs.

[0254] The modules in the device embodiments of this application can be merged, divided, and deleted according to actual needs.

Claims

1. A method for detecting multicast service flows, characterized in that, The method, applied to a first node and at least one second node, wherein the first node is the head node in the multicast detection domain and the second node is an intermediate node in the multicast detection domain, includes: The first node receives the multicast service stream sent by the multicast source; The first node is the IFIT extension header for encapsulating data packets of the multicast service stream; The data packets encapsulated with the IFIT extension header are multiple, and the IFIT extension header includes a first detection identifier Flow ID, which is used to identify the multicast service flow being detected. The first node sends a data packet encapsulated with the IFIT extension header to each of the next-hop second nodes according to the number of the next-hop second nodes of the first node, and each of the data packets encapsulated with the IFIT extension header includes the data packet of the multicast service flow. The at least one second node receives the data packet encapsulated with the IFIT extension header and performs network performance measurements based on the IFIT extension header.

2. The method according to claim 1, characterized in that, The detection identifier in each data packet encapsulated with the IFIT extension header is the same as the first detection identifier, Flow ID.

3. The method according to claim 1, characterized in that, Each data packet encapsulated with the IFIT extension header includes a second detection identifier, which is different from the first detection identifier Flow ID, but contains the first detection identifier Flow ID.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: The first node replicates the data packet based on the number of second nodes that are the next hops of the first node.

5. The method according to claim 4, characterized in that, The method further includes: The first node receives configuration information, which is used to indicate the replication mode.

6. The method according to any one of claims 1-3 or 5, characterized in that, The method further includes: The first node obtains first quantity information and first time information, wherein the first quantity information is the number of data packets in the multicast service stream received within a preset period, and the first time information is the timestamp of the data packets in the multicast service stream received at a time point in the preset period. The first node sends first detection information to the control node, wherein the first detection information includes one or more of the first quantity information, the first time information, the entry identifier of the first node, and the first detection identifier Flow ID; the first detection information is used by the control node to perform packet loss detection or latency detection on the multicast service flow.

7. The method according to claim 6, characterized in that, Before the first node sends the first detection information to the control node, the method further includes: The first node parses the multicast source address and multicast group address from the data packets of the multicast service stream; the first detection information also includes the multicast source address and the multicast group address.

8. The method according to any one of claims 1-3, 5 or 7, characterized in that, The method further includes: The first node obtains second quantity information and second time information, wherein the second quantity information is the number of data packets encapsulated with the IFIT extension header in the multicast service stream sent within a preset period, and the second time information is the timestamp of sending the data packets encapsulated with the IFIT extension header in the multicast service stream at a time point in the preset period. The first node sends second detection information to the control node, wherein the second detection information includes one or more of the following: the second quantity information, the second time information, the first detection identifier Flow ID, and the first node's egress identifier; the second detection information is used by the control node to perform packet loss detection or latency detection on the multicast service flow.

9. A method for detecting multicast service flows, characterized in that, The method, applied to a second node and at least one third node, wherein the second node is an intermediate node in the multicast detection domain and the at least one third node is the next-hop node of the second node, includes: The second node receives a data packet encapsulated with an IFIT extension header sent by the first node of the previous hop; The data packets encapsulated with the IFIT extension header are multiple, and the IFIT extension header includes a first detection identifier Flow ID, which is used to identify the multicast service flow to which the data packet belongs; the first node is the head node in the multicast detection domain; The second node sends the data packet encapsulated with the IFIT extension header to each of the next-hop third nodes according to the number of the next-hop third nodes of the second node, and each of the data packets encapsulated with the IFIT extension header includes the data packet of the multicast service flow. The at least one third node receives the data packet encapsulated with the IFIT extension header and performs network performance measurements based on the IFIT extension header.

10. The method according to claim 9, characterized in that, The detection identifier in each data packet encapsulated with the IFIT extension header is the same as the first detection identifier, Flow ID.

11. The method according to claim 9, characterized in that, Each data packet encapsulated with the IFIT extension header includes a second detection identifier, which is different from the first detection identifier Flow ID, but contains the first detection identifier Flow ID.

12. The method according to any one of claims 9-11, characterized in that, The method further includes: The second node replicates the data packet encapsulated with the IFIT extension header based on the number of third nodes that are the next hops of the second node.

13. The method according to claim 12, characterized in that, The method further includes: The second node receives configuration information, which indicates the replication mode.

14. The method according to any one of claims 9-11 or 13, characterized in that, The method further includes: The second node collects third quantity information and third time information, wherein the third quantity information is the number of data packets encapsulated with the IFIT extension header in the multicast service stream received within a preset period, and the third time information is the timestamp of the data packets encapsulated with the IFIT extension header in the multicast service stream received at a time point in the preset period. The second node sends third detection information to the control node, wherein the third detection information includes one or more of the third quantity information, the third time information, the first detection identifier Flow ID, and the entry identifier of the second node; the third detection information is used by the control node to perform packet loss detection or latency detection on the multicast service flow.

15. The method according to claim 14, characterized in that, The method further includes: The second node collects fourth quantity information and fourth time information, wherein the fourth quantity information is the number of data packets encapsulated with the IFIT extension header in the multicast service stream sent within a preset period, and the fourth time information is the timestamp of the data packets encapsulated with the IFIT extension header sent in the multicast service stream at a time point in the preset period. Send fourth detection information to the control node, wherein the fourth detection information includes one or more of the fourth quantity information, the fourth time information, the first detection identifier Flow ID, and the exit identifier of the second node; the fourth detection information is used by the control node to perform packet loss detection or latency detection on the multicast service flow.

16. A multicast service flow detection system, comprising a first node and at least one second node, wherein the first node is a head node in the multicast detection domain and the second node is an intermediate node in the multicast detection domain; The first node is used to receive multicast service streams sent by the multicast source; The first node is also used to encapsulate the data packets of the multicast service stream with the IFIT extension header for flow detection technology; in, The data packets encapsulated with the IFIT extension header are multiple, and the IFIT extension header includes a first detection identifier Flow ID, which is used to identify the multicast service flow being detected; The first node is further configured to send a data packet encapsulated with the IFIT extension header to each of the next-hop second nodes according to the number of the next-hop second nodes of the first node, and each of the data packets encapsulated with the IFIT extension header includes the data packet of the multicast service flow. The at least one second node is used to receive the data packet encapsulated with the IFIT extension header and to perform network performance measurements based on the IFIT extension header.

17. The system according to claim 16, characterized in that, The detection identifier in each data packet encapsulated with the IFIT extension header is the same as the first detection identifier, Flow ID.

18. The system according to claim 16, characterized in that, Each data packet encapsulated with the IFIT extension header includes a second detection identifier, which is different from the first detection identifier Flow ID, but contains the first detection identifier Flow ID.

19. The system according to any one of claims 16-18, characterized in that, The first node is also used to replicate the data packet according to the number of second nodes that are the next hops of the first node.

20. The system according to claim 19, characterized in that, The first node is also configured to receive configuration information, which indicates the replication mode.

21. The system according to any one of claims 16-18 or 20, characterized in that, The system also includes a control node; The first node is also used for: Obtain first quantity information and first time information, wherein the first quantity information is the number of data packets in the multicast service stream received within a preset period, and the first time information is the timestamp of the data packets in the multicast service stream received at a time point in the preset period; Send first detection information to the control node, wherein the first detection information includes one or more of the first quantity information, the first time information, the entry identifier of the first node, and the first detection identifier Flow ID; the first detection information is used by the control node to perform packet loss detection or latency detection on the multicast service flow.

22. The system according to claim 21, characterized in that, The first node is also used for: The multicast source address and multicast group address are obtained by parsing the data packets of the multicast service stream; the first detection information also includes the multicast source address and the multicast group address.

23. The system according to any one of claims 16-18, 20, and 22, characterized in that, The system also includes a control node; The first node is also used for: Obtain second quantity information and second time information, wherein the second quantity information is the number of data packets encapsulated with the IFIT extension header in the multicast service stream sent within a preset period, and the second time information is the timestamp of sending the data packets encapsulated with the IFIT extension header in the multicast service stream at a time point in the preset period. Send second detection information to the control node, wherein the second detection information includes one or more of the following: the second quantity information, the second time information, the first detection identifier Flow ID, and the exit identifier of the first node; the second detection information is used by the control node to perform packet loss detection or latency detection on the multicast service flow.

24. A multicast service flow detection system, comprising a second node and at least one third node, wherein the second node is an intermediate node in a multicast detection domain, and the at least one third node is the next-hop node of the second node; The second node is used to receive data packets encapsulated with IFIT extension headers sent by the first node of the previous hop; in, The data packets encapsulated with the IFIT extension header are multiple, and the IFIT extension header includes a first detection identifier Flow ID, which is used to identify the multicast service flow to which the data packet belongs; the first node is the head node in the multicast detection domain; The second node is further configured to send the data packet encapsulated with the IFIT extension header to each third node of the next hop according to the number of third nodes of the second node, and each data packet encapsulated with the IFIT extension header includes the data packet of the multicast service flow. The at least one third node is used to receive the data packet encapsulated with the IFIT extension header and to perform network performance measurements based on the IFIT extension header.

25. The system according to claim 24, characterized in that, The detection identifier in each data packet encapsulated with the IFIT extension header is the same as the first detection identifier, Flow ID.

26. The system according to claim 24, characterized in that, Each data packet encapsulated with the IFIT extension header includes a second detection identifier, which is different from the first detection identifier Flow ID, but contains the first detection identifier Flow ID.

27. The system according to any one of claims 24-25, characterized in that, The second node is also used to replicate the data packet encapsulated with the IFIT extension header according to the number of third nodes that are the next hops of the second node.

28. The system according to claim 27, characterized in that, The second node is also used to receive configuration information, which indicates the replication mode.

29. The system according to any one of claims 24-26, 28, characterized in that, The system also includes a control node; The second node is also used for: The third quantity information and the third time information are statistically analyzed. The third quantity information is the number of data packets encapsulated with the IFIT extension header in the multicast service stream received within a preset period. The third time information is the timestamp of the data packets encapsulated with the IFIT extension header in the multicast service stream received at a time point in the preset period. The control node sends third detection information, wherein the third detection information includes one or more of the third quantity information, the third time information, the first detection identifier Flow ID, and the entry identifier of the second node; the third detection information is used by the control node to perform packet loss detection or latency detection on the multicast service flow.

30. The system according to claim 29, characterized in that, The system also includes a control node; The second node is also used for: The second node collects fourth quantity information and fourth time information, wherein the fourth quantity information is the number of data packets encapsulated with the IFIT extension header in the multicast service stream sent within a preset period, and the fourth time information is the timestamp of the data packets encapsulated with the IFIT extension header sent in the multicast service stream at a time point in the preset period. Send fourth detection information to the control node, wherein the fourth detection information includes one or more of the fourth quantity information, the fourth time information, the first detection identifier Flow ID, and the exit identifier of the second node; the fourth detection information is used by the control node to perform packet loss detection or latency detection on the multicast service flow.

31. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on one or more processors, performs the method as described in any one of claims 1-8, or performs the method as described in any one of claims 9-15.

32. A computer program product, characterized in that, The computer program product includes a computer program that, when run on one or more processors, causes the method of any one of claims 1-8 to be implemented, or the method of any one of claims 9-15 to be implemented.

Images