Method and apparatus for multicast traffic flow detection

Abstract

The embodiment of the present application provides a multicast service flow detection method and device, relates to the technical field of communication, and the method comprises the following steps: a first node receives a multicast service flow sent by a multicast source, and encapsulates a packet header for a data packet in the multicast service flow; wherein the packet header comprises a detection identifier, a first field, a second field and a third field, the detection identifier is used for identifying that the multicast service flow is a multicast service flow detected along with a flow, the first field is used for indicating a detection period of the multicast service flow, the second field is used for indicating whether a packet loss detection dye mark exists in the data packet, and the third field is used for indicating whether the data packet participates in delay detection; and the data packet encapsulated with the packet header is sent to a second node of a next hop. The embodiment of the present application indicates the parameters of flow detection by using the existing fields in the packet header, does not need to add or expand the fields in the packet header, and can realize the detection of the multicast service flow.

Description

Technical Field

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

[0002] With the implementation of Internet Protocol Version 6 (IPv6), major operators are upgrading their existing networks to IPv6, from applications (APPs), terminals, management systems, and business systems to metropolitan area networks and backbone networks. While upgrading unicast networks, multicast upgrades are being completed simultaneously. The newly defined multicast protocol must adapt to the IPv6 evolution trend, and the new multicast also requires flow detection technology.

[0003] Multicast, also known as multi-target broadcast, is a method of communication between a sender and multiple receivers in a network. Bit-indexed explicit replication (BIER) is a novel multicast forwarding technology architecture specifically used to construct multicast forwarding paths. This technology proposes a multicast architecture for building a multicast distribution tree, which satisfies the ever-increasing multicast traffic while reducing operating costs.

[0004] The Internet Engineering Task Force (IETF) draft "Draft IETF-BIER-PMMM-OAM" proposes a novel multicast quality inspection scheme that adds a BIER header to IPv6 packets to enable the transmission of BIER multicast packets in IPv6 networks. However, the draft does not specify how to implement the inspection of BIER multicast traffic, thus failing to guarantee the reliability of BIER multicast traffic transmission. Summary of the Invention

[0005] This application provides a method and device for detecting multicast service streams, which can detect BIER multicast streams.

[0006] In a first aspect, embodiments of this application provide a multicast service flow detection method, applied to a first node, the method comprising:

[0007] Receive a multicast service stream sent by a multicast source, wherein the multicast service stream includes at least one data packet;

[0008] Encapsulate the data packet with a header; wherein the header includes a detection identifier, a first field, a second field, and a third field, the detection identifier is used to identify the multicast service flow as a multicast service flow subject to flow-following detection, the first field is used to indicate the detection period of the multicast service flow, the second field is used to indicate whether the data packet has a packet loss detection coloring mark, and the third field is used to indicate whether the data packet participates in latency detection;

[0009] A data packet containing the aforementioned header is sent to a second node, which is the next-hop node of the first node.

[0010] In some implementations, the second field and the third field belong to the Operations, Administration, and Maintenance (OAM) field in the message header.

[0011] In some implementations, the header further includes a fourth field that indicates whether the data packet is subject to flow detection.

[0012] In some implementations, the header further includes a fifth field, which indicates the detection mode of the multicast service flow; the detection mode includes a segment-by-segment detection mode and an end-to-end detection mode.

[0013] In some implementations, the detection identifier includes the service flow identifier information corresponding to the multicast service flow and the node information of the first node.

[0014] In some embodiments, the method further includes:

[0015] The analyzer sends first detection information and second detection information of the first node; the first detection information includes the detection identifier, the entry identifier of the first node, and the number and timestamp of the data packets received by the first node within the detection period; the second detection information includes the detection identifier, the exit identifier of the first node, and the number and timestamp of the data packets encapsulated with the packet header sent by the first node within the detection period.

[0016] This allows the analyzer to perform packet loss detection and / or latency detection on the multicast service stream based on the first detection information and the second detection information.

[0017] Secondly, embodiments of this application provide a multicast service flow detection method, applied to a second node, the method comprising:

[0018] The system receives a data packet with a header encapsulated by a first node. The first node is the previous hop node of the second node. The header includes a detection identifier, a first field, a second field, and a third field. The detection identifier is used to identify that the multicast service flow is a multicast service flow subject to flow-following detection. The first field is used to indicate the detection period of the multicast service flow. The second field is used to indicate whether the data packet has a packet loss detection coloring mark. The third field is used to indicate whether the data packet participates in latency detection.

[0019] Send a data packet containing the header to a third node, wherein the third node is the next-hop node of the second node.

[0020] In some implementations, the second field and the third field belong to the OAM field in the message header.

[0021] In some implementations, the header further includes a fourth field that indicates whether the data packet is subject to flow detection.

[0022] In some implementations, the header further includes a fifth field, which indicates the detection mode of the multicast service flow; the detection mode includes a segment-by-segment detection mode and an end-to-end detection mode.

[0023] In some implementations, the detection identifier includes the service flow identifier information corresponding to the multicast service flow and the node information of the first node.

[0024] In some embodiments, the method further includes:

[0025] The analyzer sends the first detection information and the second detection information of the second node; the first detection information includes the detection identifier, the entry identifier of the second node, and the number and timestamp of the data packets received by the second node within the detection period; the second detection information includes the detection identifier, the exit identifier of the second node, and the number and timestamp of the data packets encapsulated with the packet header sent by the second node within the detection period.

[0026] This allows the analyzer to perform packet loss detection and / or latency detection on the multicast service stream based on the first detection information and the second detection information.

[0027] Thirdly, embodiments of this application provide a multicast service flow detection device, applied to a first node, the device comprising:

[0028] A receiving module is used to receive a multicast service stream sent by a multicast source, wherein the multicast service stream includes at least one data packet;

[0029] An encapsulation module is used to encapsulate a header for the data packet; wherein the header includes a detection identifier, a first field, a second field, and a third field, the detection identifier is used to identify the multicast service flow as a multicast service flow subject to flow-following detection, the first field is used to indicate the detection period of the multicast service flow, the second field is used to indicate whether the data packet has a packet loss detection coloring mark, and the third field is used to indicate whether the data packet participates in latency detection;

[0030] The sending module is used to send a data packet encapsulated with the packet header to a second node, where the second node is the next-hop node of the first node.

[0031] In some implementations, the second field and the third field belong to the OAM field in the message header.

[0032] In some implementations, the header further includes a fourth field that indicates whether the data packet is subject to flow detection.

[0033] In some implementations, the header further includes a fifth field, which indicates the detection mode of the multicast service flow; the detection mode includes a segment-by-segment detection mode and an end-to-end detection mode.

[0034] In some implementations, the detection identifier includes the service flow identifier information corresponding to the multicast service flow and the node information of the first node.

[0035] In some implementations, the sending module is further configured to:

[0036] The analyzer sends first detection information and second detection information of the first node; the first detection information includes the detection identifier, the entry identifier of the first node, and the number and timestamp of the data packets received by the first node within the detection period; the second detection information includes the detection identifier, the exit identifier of the first node, and the number and timestamp of the data packets encapsulated with the packet header sent by the first node within the detection period.

[0037] This allows the analyzer to perform packet loss detection and / or latency detection on the multicast service stream based on the first detection information and the second detection information.

[0038] Fourthly, embodiments of this application provide a multicast service flow detection device, applied to a second node, the device comprising:

[0039] A receiving module is used to receive a data packet encapsulated with a message header sent by a first node; the first node is the previous hop node of the second node; the message header includes a detection identifier, a first field, a second field, and a third field; the detection identifier is used to identify that the multicast service flow is a multicast service flow subject to flow-following detection; the first field is used to indicate the detection period of the multicast service flow; the second field is used to indicate whether the data packet has a packet loss detection coloring mark; and the third field is used to indicate whether the data packet participates in latency detection.

[0040] The sending module is used to send a data packet encapsulated with the packet header to a third node, wherein the third node is the next-hop node of the second node.

[0041] In some implementations, the second field and the third field belong to the OAM field in the message header.

[0042] In some implementations, the header further includes a fourth field that indicates whether the data packet is subject to flow detection.

[0043] In some implementations, the header further includes a fifth field, which indicates the detection mode of the multicast service flow; the detection mode includes a segment-by-segment detection mode and an end-to-end detection mode.

[0044] In some implementations, the detection identifier includes the service flow identifier information corresponding to the multicast service flow and the node information of the first node.

[0045] In some implementations, the sending module is further configured to:

[0046] The analyzer sends the first detection information and the second detection information of the second node; the first detection information includes the detection identifier, the entry identifier of the second node, and the number and timestamp of the data packets received by the second node within the detection period; the second detection information includes the detection identifier, the exit identifier of the second node, and the number and timestamp of the data packets encapsulated with the packet header sent by the second node within the detection period.

[0047] This allows the analyzer to perform packet loss detection and / or latency detection on the multicast service stream based on the first detection information and the second detection information.

[0048] Fifthly, embodiments of this application provide a communication device, including a processor and an interface circuit, wherein the processor is communicatively connected to the interface circuit;

[0049] The interface circuit is used to communicate with other communication devices;

[0050] The processor is configured to implement the multicast service flow detection method as provided in the first aspect, or the multicast service flow detection method as provided in the second aspect.

[0051] Sixthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the multicast service flow detection method provided in the first aspect, or the multicast service flow detection method provided in the second aspect.

[0052] The multicast service flow detection method and device provided in this application embodiment can detect multicast service flows by using existing fields in the packet header to indicate the parameters for flow detection, without adding or expanding the fields in the packet header. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a schematic diagram of the format of a data packet provided in an embodiment of this application;

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

[0056] Figure 3 A flowchart illustrating a multicast service flow detection method provided in an embodiment of this application;

[0057] Figure 4 This is a schematic diagram of the coloring identifier distribution of data packets in the embodiments of this application;

[0058] Figure 5 This is a schematic diagram of another data packet format provided in the embodiments of this application;

[0059] Figure 6 This is a schematic diagram of a segment-by-segment detection mode provided in the embodiments of this application;

[0060] Figure 7 This is a schematic diagram of an end-to-end detection mode provided in an embodiment of this application;

[0061] Figure 8 A schematic diagram of a program module for a multicast service flow detection device provided in this application embodiment. Figure 1 ;

[0062] Figure 9 A schematic diagram of a program module for a multicast service flow detection device provided in this application embodiment. Figure 2 ;

[0063] Figure 10 This is a schematic diagram of the hardware structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0065] The terms "first," "second," etc., used in this application specification, claims, and accompanying drawings are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms can be used interchangeably where appropriate, for example, to implement embodiments in a sequence other than those given in the illustrations or description of this application.

[0066] The term "module" as used in the embodiments of this application refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and software code capable of performing the functions associated with that element.

[0067] Multicast, also known as multi-target broadcast, is a method of communication between a sender and multiple receivers in a network. A multicast source sends a message to a specific multicast address. Unlike unicast addresses, multicast addresses do not belong to a single host but to a group of hosts. A multicast address represents a group, and hosts that need to receive multicast messages join this group. Multicast technology can be applied to both point-to-multipoint applications, such as media broadcasting, event notification, status monitoring, data collection, and online auctions, and multipoint-to-multipoint applications, such as multipoint conferencing and database synchronization.

[0068] The following explains some of the terms used in the embodiments of this application:

[0069] OAM: Operations, Administration, and Maintenance. Based on the actual needs of network operation, network management work is typically divided into three main categories: Operation, Administration, and Maintenance, abbreviated as OAM. Operation mainly involves the analysis, forecasting, planning, and configuration of daily network and services; Maintenance mainly involves routine operational activities such as testing and fault management of the network and its services.

[0070] In-situ Flow Information Telemetry (IFIT) is a technology that uses special marking (coloring) to detect packet loss and latency in actual service flows. IFIT does not require external probes; it carries OAM instructions in the packet header and obtains link performance based on the latency and bit errors experienced by the colored bits. The measurement results are embedded in designated fields of the packet header, and processing nodes collect and report data based on the OAM instruction information in the header.

[0071] BFIR: Bit Forwarding Ingress Router, a node that handles multicast data traffic entering the BIER domain and is responsible for BIER encapsulation of packets entering the BIER network.

[0072] BFR: Bit Forwarding Router, an intermediate node in the BIER domain for forwarding multicast data traffic, responsible for forwarding BIER packets.

[0073] BFER: Bit Forwarding Egress Router, the node that handles multicast data traffic leaving the BIER domain. It is responsible for decapsulating BIER packets and forwarding them to multicast receivers.

[0074] MSR: Multicast Segment Routing.

[0075] MSR6: Multicast Segment Routing Over IPv6.

[0076] BE: Best Effort mode.

[0077] BIER is a new type of multicast forwarding technology architecture. By encapsulating the set of destination nodes to be reached by the multicast message in the message header as a bit string (BS), the intermediate nodes in the network do not need to be aware of the multicast service or maintain the multicast stream state. It can better solve the problems of traditional IP multicast technology and provide good multicast service scalability.

[0078] In BIER networks, multicast packet forwarding relies on the BitIndex Forwarding Table (BIFT) established by the BFR using BIER technology, enabling multicast packets to be copied and forwarded simply based on the bit string. The Internet Engineering Task Force (IETF) draft "Draft-IETF-BIER-PMMM-OAM" proposes a novel multicast quality inspection scheme that adds a BIER header to IPv6 packets to enable the transmission of BIER multicast packets in IPv6 networks. However, this draft does not specify how to implement the inspection of BIER multicast traffic, thus failing to guarantee the reliability of BIER multicast traffic transmission.

[0079] In some implementations, the OAM field is considered when defining the BIER header and the MSR BE header, see reference. Figure 1 , Figure 1 This is a schematic diagram illustrating the format of a data packet provided in an embodiment of this application. The meanings of each field in the data packet are as follows:

[0080] Version: 4 bits, version number.

[0081] Traffic Class: 8 bits, transmission class.

[0082] Flow Label: Flow label.

[0083] Payload Length: 16 bits.

[0084] Hop Limit: 8 bits, limit on the number of hops.

[0085] Source Address: 32 bits, used as the IPv6 source address.

[0086] Destination Address: 32 bits, used as the IPv6 destination address.

[0087] Next Header: 8 bits, used to identify the type of the next message header.

[0088] Hdr Ext Len: 8 bits, indicating the length of the IPv6 extension header.

[0089] OT: Option Type, 8 bits. OT = (BIER) indicates that the option type is BIER.

[0090] Option Length: 8 bits, the length of the option.

[0091] Resv: Reserved field.

[0092] TTL: 8 bits, which has the same meaning as TTL in IP packets and can be used to prevent loops.

[0093] Ver: 4 bits, version number.

[0094] BSL: 4 bits, with values ​​from 1 to 7 representing different bit string lengths.

[0095] Entropy: 20 bits, used to select a path when an equivalent path exists.

[0096] OAM: 2 bits, default value is 0, can be used for OAM function.

[0097] DSCP: 7 bits, the priority level of the message itself, which determines the priority of message transmission.

[0098] Bit String: A string of bits or bytes.

[0099] In related technologies, the OAM field is only used for alternating coloring and cannot be used to detect BIER multicast service flows.

[0100] To address the aforementioned technical problems, this application provides a multicast service flow detection method. By utilizing existing fields in the packet header to indicate the parameters for flow detection, multicast service flows can be detected without adding or expanding fields in the packet header. Please refer to the following embodiments of this application for details.

[0101] Reference Figure 2 , Figure 2 This is a schematic diagram of the system architecture of a multicast detection domain provided in the embodiments of this application. The system architecture of the multicast detection domain includes an analyzer 101, a multicast source 102, a head node A, a normal IPv6 node B, an intermediate node C, a tail node D, a tail node E, and receivers 103a and 103b.

[0102] In some embodiments, the analyzer 101 may have functions such as network management, service control, and network analysis, and is a core enabling system for realizing network resource pooling, network connection automation, and operation and maintenance automation. It is mainly used to collect data and perform performance testing on service packets along the transmission path between nodes in the multicast detection domain. Performance testing includes packet loss detection and latency detection. The analyzer 101 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, the entry and exit identifiers of the intermediate nodes, and the entry and exit identifiers of the tail node of the transmission path to be detected based on the topology diagram.

[0103] In some embodiments, multicast source 102 can be used to send multicast service flows to nodes in a multicast group within a 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 fork in the road. All node members in the multicast group can receive the data packets of the multicast service flow. A multicast group consists of a head node, intermediate nodes, and a tail node. It is important to note that a multicast source is not necessarily a member of a multicast group; it sends data to the multicast group but is not necessarily a receiver itself. Multiple multicast sources can simultaneously send messages to a single multicast group. Figure 2 Only one multicast source is shown in the image.

[0104] It should be noted that, although Figure 2 The diagram only shows one head node A, one intermediate node C, and two tail nodes D and E, but a multicast group can consist of multiple head nodes, multiple intermediate nodes, and multiple tail nodes. Additionally, a regular IPv6 node B may or may not exist.

[0105] In some embodiments, head node A is the first node in the multicast detection domain to receive data packets of multicast service streams. It is used to receive data packets sent by multicast source 102, as well as to collect detection information of incoming and outgoing service streams, and to upload the detection information to analyzer 101.

[0106] In some embodiments, intermediate node C is used to receive data packets sent by head node, as well as detection information of incoming and outgoing multicast service flows, and upload the detection information to analyzer 101.

[0107] Tail nodes D and E are used to receive data packets sent by intermediate node C, as well as detection information of incoming and outgoing business flows, and upload the detection information to analyzer 101.

[0108] It should be noted that the detection information statistically analyzed by the head node, intermediate node, and tail node above 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, multicast source address, multicast group address, multicast source port, receiver port, and multicast protocol number.

[0109] Receivers 103a and 103b are used to receive data packets sent by the tail node.

[0110] 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.

[0111] 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 A, intermediate node C, and tail nodes D and E can be data relay devices, such as routers, repeaters, bridges, or switches. The receiving ends 103a and 103b can be terminal devices, such as various types of user equipment (UE), mobile phones, tablets, desktop computers, headphones, speakers, televisions, etc.

[0112] In some embodiments, the head node A can be BFIR; the middle node C can be BFR; and the tail nodes D and E can be BFER.

[0113] Reference Figure 3 , Figure 3 This is a flowchart illustrating a multicast service flow detection method provided in an embodiment of this application. The multicast service flow detection method includes:

[0114] S301, The first node receives configuration information.

[0115] The first node mentioned above is the head node in the multicast detection domain. In this embodiment of the application, 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.

[0116] In some embodiments of this application, the above configuration information includes any one or more of the following: service flow identification information, detection period, detection mode, and latency detection enable information corresponding to the multicast service flow.

[0117] In some embodiments, the flow detection function of the head node, intermediate node, and tail node can be enabled in advance, and detection parameters can be configured on the head node in advance. These detection parameters include: specifying the flow characteristics of the detection packets, such as configuring the detection of a certain multicast VPN traffic; specifying the detection period as 30 seconds; specifying the detection type as segment-by-segment detection; and enabling latency detection.

[0118] S302, The first node receives a multicast service stream sent by a multicast source, the multicast service stream including at least one data packet.

[0119] S303, the first node encapsulates a header for the aforementioned data packet; wherein, the header includes a detection identifier, a first field, a second field, and a third field, the detection identifier is used to identify the aforementioned multicast service flow as a multicast service flow subject to flow-following detection, the first field is used to indicate the detection period of the aforementioned multicast service flow, the second field is used to indicate whether the aforementioned data packet has a packet loss detection coloring mark, and the third field is used to indicate whether the aforementioned data packet participates in latency detection.

[0120] In some embodiments, the first node may encapsulate a header for the data packet based on the received configuration information.

[0121] In some implementations, the data packets can be encapsulated with a header according to the header encapsulation format of the MSR BE message, based on the received configuration information. The MSR BE message is a multicast segmented routing message using best-effort delivery mode.

[0122] In some implementations, the data packets can also be encapsulated with a header according to the MSR6 BE message header encapsulation format based on the received configuration information. The MSR6 BE message is an IPv6-based multicast segmented routing message using best-effort delivery mode.

[0123] In some embodiments, the multicast service flow corresponding to the above detection identifier is unique across the entire network within the detection domain.

[0124] In some embodiments, after receiving a multicast service stream sent by a multicast source, the first node determines whether the VPN to which the multicast service stream belongs is consistent with the following flow detection configuration. If they are consistent, the node modifies the relevant fields in the header of the data packets in the multicast service stream.

[0125] In some embodiments, the first field can be 2 bits, which can be used to indicate four different detection periods. For example, when the first field is 00, it indicates that the detection period of the multicast service stream is 10s; when the first field is 01, it indicates that the detection period of the multicast service stream is 30s; when the first field is 10, it indicates that the detection period of the multicast service stream is 60s; and when the first field is 11, it indicates that the detection period of the multicast service stream is 300s.

[0126] In some embodiments, both the second and third fields mentioned above belong to the OAM field in the above message header.

[0127] The second field is the L field in the OAM field, used to indicate whether the data packet has a packet loss detection coloring mark. For example, an L field value of 1 indicates that the data packet has a packet loss detection coloring mark, and an L field value of 0 indicates that the data packet does not have a packet loss detection coloring mark. The third field is the D field in the OAM field, used to indicate whether the data packet has a latency detection coloring mark. For example, a D field value of 1 indicates that latency detection is required, and a D field value of 0 indicates that latency detection is not required.

[0128] In some embodiments, the first node may color the received data packets according to the detection period indicated by the first field.

[0129] Reference Figure 4 , Figure 4 This is a schematic diagram of the coloring identifier distribution of data packets in the embodiments of this application.

[0130] exist Figure 4 During the process, the coloring is switched at the beginning of the cycle, with odd-numbered cycles having a coloring value of 1 and even-numbered cycles having a coloring value of 0.

[0131] In some embodiments, the D field in the first data packet of each cycle can be marked as 1, and the D field in the remaining data packets can be marked as 0; this indicates that the first data packet of each cycle needs to be delayed.

[0132] In some embodiments of this application, the above-mentioned header further includes a fourth field, which is used to indicate whether the above-mentioned data packet is subject to flow detection.

[0133] In this process, after the BFIR node identifies the multicast service flow to be detected by the flow, it sets the field to 1, indicating that the multicast packet is being detected by the flow. The BFR and BFER nodes use this field to determine whether to perform flow learning and detection.

[0134] In some embodiments, the above-mentioned header further includes a fifth field, which is used to indicate the detection mode of the above-mentioned multicast service flow.

[0135] In some embodiments, the first field, the fourth field, and the fifth field are all reserved fields in the above-mentioned message header.

[0136] In some embodiments, the detection identifier includes the service flow identifier information corresponding to the multicast service flow and the node information of the first node.

[0137] Optionally, the aforementioned detection identifier is carried in the source address corresponding to the aforementioned data packet. For example, the opcode of the source IP address: src.dt can be used as the flow identifier information flow-id corresponding to the aforementioned multicast service flow; and the Locator of the source IP address can be used as the node information Node-ID of the aforementioned first node.

[0138] Understandably, in an MSR BE network, each node supporting MSR has a unique locator route, so the locator can be used to identify a unique node in the network. Since the opcode is the traffic that identifies a multicast VPN under the locator of a certain node, it is used to represent a specific detection flow in that node. Therefore, the locator + opcode can uniquely identify a specific detection flow in the entire network.

[0139] To better understand the embodiments of this application, please refer to... Figure 5 , Figure 5 This is a schematic diagram of another data packet format provided in the embodiments of this application.

[0140] Among them, the first field mentioned above is Figure 5 The P field shown above, the second field mentioned above is Figure 5 The L field shown above, the third field mentioned above is Figure 5 The fourth field mentioned above is the D field shown. Figure 5 The F field shown above, the fifth field is Figure 5 The E field shown above indicates that the detection identifier is carried in the source address corresponding to the above data packet.

[0141] In some embodiments, the detection modes of the multicast service streams described above include segment-by-segment detection mode and end-to-end detection mode.

[0142] Reference Figure 6 , Figure 6 This is a schematic diagram of a segment-by-segment detection mode provided in the embodiments of this application.

[0143] The segment-by-segment detection requires detecting each node of BFIR, BFR, and BFER.

[0144] Reference Figure 7 , Figure 7 This is a schematic diagram of an end-to-end detection mode provided in an embodiment of this application.

[0145] The end-to-end detection mode only performs detection at the BFIR inlet and the BFER outlet.

[0146] In some embodiments, when the fifth field E is 0, it indicates that the detection mode of the multicast service stream is a segment-by-segment detection mode; when the fifth field E is 1, it indicates that the detection mode of the multicast service stream is an end-to-end detection mode.

[0147] S304. The first node sends a data packet encapsulated with the above-mentioned header to the second node, and the second node is the next-hop node of the first node.

[0148] S305. The second node sends a data packet encapsulated with the above-mentioned header to the third node, where the third node is the next-hop node of the second node.

[0149] The second node is an intermediate node in the multicast detection domain. It can be understood that there can be at least one intermediate node on the transmission path.

[0150] In some embodiments, after receiving a data packet with a header from the first node, the second node can forward the received data packet to the third node.

[0151] S306. The third node sends a data packet to the receiving end.

[0152] In some embodiments, after receiving the data packet with a header encapsulated by the second node, the third node may continue to send the received data packet to the receiving end.

[0153] Optionally, the number of receivers mentioned above can be one or more.

[0154] In some embodiments, the first node repeatedly colors and decolorizes data packets in the multicast service flow in the inbound direction according to a detection period, and counts the packets and records the timestamps. After each period, it reports the first detection information of the service flow to the analyzer. In some embodiments, the first detection information includes the detection identifier, the inbound identifier of the first node, and the number and timestamps of the data packets received by the first node within the detection period.

[0155] In some implementations, in addition to encapsulating packet headers for the data packets of the multicast service stream, the first node also needs to statistically analyze the detection information of the multicast service stream according to the detection period. This detection information includes quantity information and time information. The quantity information is the number of data packets received by the first node from the multicast service stream within the detection period. For example, the first node alternately colors the marker field of the detected stream (multicast service stream) according to the detection period, and then counts the number of colored packets in this detection period as the first quantity. The time information is the timestamp of the data packets received in the multicast service stream at the time point of the detection period. For example, one data packet of the detected multicast service stream received at the start time point, end time point, or intermediate time point within each detection period is time-delayed colored, and the entry timestamp of the data packet is recorded. If the detection period is 10 seconds, the data packet received in the first second of the first 10 seconds can be time-delayed colored, or the data packet received in the 10th second of the first 10 seconds can be time-delayed colored.

[0156] In some implementations, during the process of the first node sending a data packet encapsulated with the above-mentioned message header to the second node, it is also necessary to send the second detection information of the first node to the analyzer according to the detection cycle.

[0157] In some embodiments, the second detection information includes the detection identifier, the egress identifier of the first node, and the number and timestamp of data packets encapsulated with the above-mentioned header sent by the first node within the detection period. Based on the first and second detection information, the analyzer can perform packet loss detection and / or latency detection on the multicast service flow.

[0158] Understandably, after the analyzer receives the first detection information and the second detection information sent by the first node, since both the first and second detection information contain a detection identifier, the analyzer can identify that the reported detection information is a multicast service flow carrying the same detection identifier. Therefore, the analyzer can perform packet loss detection and / or latency detection on the multicast service flow.

[0159] The packet loss detection result is calculated as {first detection information - second detection information}.

[0160] In some implementations, during the process of receiving the data packet with a header encapsulated by the first node, the second node also needs to send the second node's first detection information to the analyzer according to the detection cycle.

[0161] The first detection information of the second node includes the detection identifier, the entry identifier of the second node, and the number and timestamp of the data packets received by the second node during the detection period.

[0162] In some implementations, during the process of sending a data packet encapsulated with the aforementioned header to the third node, the second node also needs to send second detection information to the analyzer according to the detection cycle.

[0163] The second detection information of the second node includes the detection identifier, the exit identifier of the second node, and the number and timestamp of the data packets encapsulated with the above message header sent by the second node during the detection period.

[0164] In some implementations, during the process of receiving the data packet with a header encapsulated by the second node, the third node also needs to send the third node's first detection information to the analyzer according to the detection cycle.

[0165] The first detection information of the third node includes the detection identifier, the entry identifier of the third node, and the number and timestamp of the data packets received by the third node during the detection period.

[0166] In some implementations, during the process of sending data packets to the receiving end, the third node also needs to send the third node's second detection information to the analyzer according to the detection cycle.

[0167] The second detection information of the third node includes the detection identifier, the exit identifier of the third node, and the number and timestamp of data packets encapsulated with the above message header sent by the third node during the detection period.

[0168] In some implementations, after receiving the detection information sent by the aforementioned nodes, the analyzer performs packet loss detection and / or latency detection on the multicast service stream.

[0169] In some embodiments, the analyzer can subscribe to detection data from the head node, intermediate nodes, and tail node through the Telemetry system. Telemetry is a closed-loop automated operation and maintenance system, also known as an intelligent operation and maintenance system, composed of network devices, collectors, analyzers, and controllers.

[0170] In some embodiments, the analyzer can determine a detection domain, which is a detection range determined by the analyzer. In one possible implementation, a network engineer sends device information of the transmission path to be detected to the analyzer via a network management device or a user equipment. The 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 network device and the second network device to the analyzer via a network management device or a user equipment. After receiving the device identifiers of the first and second network devices, the analyzer identifies the first network device as the head node device of the transmission path to be detected and the second network device as the tail node of the transmission path to be detected, thereby determining the detection domain.

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

[0172] Understandably, each network node in the detection domain can send detection information to the analyzer. The detection information sent by the ingress of each node in the detection domain includes the ingress identifier, detection identifier, number of data packets in the multicast service stream received within the detection period, and timestamp; the detection information sent by the egress of each node in the detection domain includes the egress identifier, detection identifier, number of data packets in the multicast service stream sent within the detection period, and timestamp.

[0173] For example, after receiving the aforementioned data packet, the second node matches the traffic based on the information in the flow detection header in the inbound direction and generates detection information according to the detection cycle, reporting it to the analyzer. Simultaneously, in the outbound direction, it needs to generate detection information for each interface and report it to the analyzer according to the detection cycle. Similarly, after receiving the aforementioned data packet, the third node performs packet statistics based on the flow detection header in the inbound direction and generates detection information according to the detection cycle, reporting it to the analyzer. Simultaneously, it also performs packet statistics based on the interface in the outbound direction and reports the detection results to the analyzer according to the detection cycle. Finally, the packet header is stripped, and the packet is forwarded to the receiving device.

[0174] The multicast service flow detection method provided in this application embodiment can detect multicast service flows by using existing fields in the packet header to indicate the parameters for flow detection, without adding or expanding fields in the packet header.

[0175] Based on the content described in the above embodiments, referring to Figure 8 , Figure 8A schematic diagram of a program module for a multicast service flow detection device provided in this application embodiment. Figure 1 It is applied to the first node. In this embodiment, the multicast service flow detection device 80 includes:

[0176] The receiving module 801 is used to receive a multicast service stream sent by a multicast source, wherein the multicast service stream includes at least one data packet.

[0177] The encapsulation module 802 is used to encapsulate a header for the data packet; wherein the header includes a detection identifier, a first field, a second field, and a third field, the detection identifier is used to identify that the multicast service flow is a multicast service flow subject to flow-following detection, the first field is used to indicate the detection period of the multicast service flow, the second field is used to indicate whether the data packet has a packet loss detection coloring mark, and the third field is used to indicate whether the data packet participates in latency detection.

[0178] The sending module 803 is used to send a data packet encapsulated with the message header to a second node, the second node being the next-hop node of the first node.

[0179] In some implementations, the second field and the third field belong to the OAM field in the message header.

[0180] In some implementations, the header further includes a fourth field that indicates whether the data packet is subject to flow detection.

[0181] In some implementations, the header further includes a fifth field, which indicates the detection mode of the multicast service flow; the detection mode includes a segment-by-segment detection mode and an end-to-end detection mode.

[0182] In some implementations, the detection identifier includes the service flow identifier information corresponding to the multicast service flow and the node information of the first node.

[0183] In some implementations, the sending module 803 is further configured to:

[0184] The analyzer sends first detection information and second detection information of the first node; the first detection information includes the detection identifier, the entry identifier of the first node, and the number and timestamp of the data packets received by the first node within the detection period; the second detection information includes the detection identifier, the exit identifier of the first node, and the number and timestamp of the data packets encapsulated with the packet header sent by the first node within the detection period; so that the analyzer can perform packet loss detection and / or latency detection on the multicast service flow based on the first detection information and the second detection information.

[0185] It is understood that the implementation principle and method of the multicast service flow detection device 80 described above are the same as the implementation principle and method of the multicast service flow detection method described in the above embodiments. Therefore, the description of each embodiment in the above multicast service flow detection method can be referred to, and will not be repeated here.

[0186] Based on the content described in the above embodiments, referring to Figure 9 , Figure 9 A schematic diagram of a program module for a multicast service flow detection device provided in this application embodiment. Figure 2 It is applied to the second node. In this embodiment, the multicast service flow detection device 90 includes:

[0187] The receiving module 901 is used to receive a data packet with a packet header sent by a first node; the first node is the previous hop node of the second node, and the packet header includes a detection identifier, a first field, a second field, and a third field. The detection identifier is used to identify that the multicast service flow is a multicast service flow subject to flow-following detection, the first field is used to indicate the detection period of the multicast service flow, the second field is used to indicate whether the data packet has a packet loss detection coloring mark, and the third field is used to indicate whether the data packet participates in latency detection.

[0188] The sending module 902 is used to send a data packet encapsulated with the packet header to a third node, wherein the third node is the next-hop node of the second node.

[0189] In some implementations, the second field and the third field belong to the OAM field in the message header.

[0190] In some implementations, the header further includes a fourth field that indicates whether the data packet is subject to flow detection.

[0191] In some implementations, the header further includes a fifth field, which indicates the detection mode of the multicast service flow; the detection mode includes a segment-by-segment detection mode and an end-to-end detection mode.

[0192] In some implementations, the detection identifier includes the service flow identifier information corresponding to the multicast service flow and the node information of the first node.

[0193] In some implementations, the sending module 902 is further configured to:

[0194] The analyzer sends first detection information and second detection information of the second node; the first detection information includes the detection identifier, the entry identifier of the second node, and the number and timestamp of the data packets received by the second node within the detection period; the second detection information includes the detection identifier, the exit identifier of the second node, and the number and timestamp of the data packets encapsulated with the packet header sent by the second node within the detection period; so that the analyzer can perform packet loss detection and / or latency detection on the multicast service flow based on the first detection information and the second detection information.

[0195] It is understood that the implementation principle and method of the multicast service flow detection device 90 described above are the same as the implementation principle and method of the multicast service flow detection method described in the above embodiments. Therefore, the description of each embodiment in the above multicast service flow detection method can be referred to, and will not be repeated here.

[0196] Furthermore, based on the content described in the above embodiments, this application also provides a communication device, including a processor and an interface circuit, wherein the processor is communicatively connected to the interface circuit.

[0197] In some embodiments, the interface circuit is used to communicate with other communication devices; the processor is used to implement the content described in the embodiments of the multicast service flow detection method above.

[0198] To better understand the embodiments of this application, please refer to... Figure 10 , Figure 10 This is a schematic diagram of the hardware structure of a communication device provided in an embodiment of this application.

[0199] like Figure 10 As shown, the communication device 100 includes a processor 1010 and an interface circuit 1020. The processor 1010 and the interface circuit 1020 are communicatively connected. It is understood that the interface circuit 1020 can be a transceiver or an input / output interface. Optionally, the communication device 100 may further include a memory 1030 for storing instructions executed by the processor 1010, or storing input data required by the processor 1010 to execute instructions, or storing data generated after the processor 1010 executes instructions.

[0200] This application provides a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the various steps of the multicast service flow detection method described in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments.

[0201] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0202] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0203] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0204] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0205] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for multicast traffic detection, the method comprising: Applied to the first node, the method includes: Receive a multicast service stream sent by a multicast source, wherein the multicast service stream includes at least one data packet; Encapsulate the data packet with a header; wherein the header includes a detection identifier, a first field, a second field, and a third field, the detection identifier is used to identify the multicast service flow as a multicast service flow subject to flow-following detection, the first field is used to indicate the detection period of the multicast service flow, the second field is used to indicate whether the data packet has a packet loss detection coloring mark, and the third field is used to indicate whether the data packet participates in latency detection; A data packet containing the aforementioned header is sent to a second node, which is the next-hop node of the first node; wherein the second field and the third field belong to the Operation, Maintenance and Management (OAM) field in the header.

2. The method of claim 1, wherein, The header also includes a fourth field, which indicates whether the data packet is subject to flow detection.

3. The method of claim 1, wherein, The message header also includes a fifth field, which is used to indicate the detection mode of the multicast service flow; the detection mode includes a segment-by-segment detection mode and an end-to-end detection mode.

4. The method of claim 1, wherein, The detection identifier includes the service flow identifier information corresponding to the multicast service flow and the node information of the first node.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The analyzer sends first detection information and second detection information of the first node; the first detection information includes the detection identifier, the entry identifier of the first node, and the number and timestamp of the data packets received by the first node within the detection period; the second detection information includes the detection identifier, the exit identifier of the first node, and the number and timestamp of the data packets encapsulated with the packet header sent by the first node within the detection period. This allows the analyzer to perform packet loss detection and / or latency detection on the multicast service stream based on the first detection information and the second detection information.

6. A method for multicast traffic detection, the method comprising: Applied to the second node, the method includes: The system receives a data packet with a header encapsulated by a first node. The first node is the previous hop node of the second node. The header includes a detection identifier, a first field, a second field, and a third field. The detection identifier is used to identify that the multicast service flow is a multicast service flow subject to flow-following detection. The first field is used to indicate the detection period of the multicast service flow. The second field is used to indicate whether the data packet has a packet loss detection coloring mark. The third field is used to indicate whether the data packet participates in latency detection. A data packet containing the aforementioned header is sent to a third node, which is the next-hop node of the second node; wherein the second field and the third field belong to the Operation, Maintenance and Management (OAM) field in the header.

7. The method of claim 6, wherein, The header also includes a fourth field, which indicates whether the data packet is subject to flow detection.

8. The method of claim 6, wherein, The message header also includes a fifth field, which is used to indicate the detection mode of the multicast service flow; the detection mode includes a segment-by-segment detection mode and an end-to-end detection mode.

9. The method of claim 6, wherein, The detection identifier includes the service flow identifier information corresponding to the multicast service flow and the node information of the first node.

10. The method according to any one of claims 6 to 9, characterized in that, The method further includes: The analyzer sends the first detection information and the second detection information of the second node; the first detection information includes the detection identifier, the entry identifier of the second node, and the number and timestamp of the data packets received by the second node within the detection period; the second detection information includes the detection identifier, the exit identifier of the second node, and the number and timestamp of the data packets encapsulated with the packet header sent by the second node within the detection period. This allows the analyzer to perform packet loss detection and / or latency detection on the multicast service stream based on the first detection information and the second detection information.

11. A multicast service flow detection apparatus, characterized by comprising: Applied to the first node, the device includes: A receiving module is used to receive a multicast service stream sent by a multicast source, wherein the multicast service stream includes at least one data packet; An encapsulation module is used to encapsulate a header for the data packet; wherein the header includes a detection identifier, a first field, a second field, and a third field, the detection identifier is used to identify the multicast service flow as a multicast service flow subject to flow-following detection, the first field is used to indicate the detection period of the multicast service flow, the second field is used to indicate whether the data packet has a packet loss detection coloring mark, and the third field is used to indicate whether the data packet participates in latency detection; The sending module is used to send a data packet encapsulated with the packet header to a second node, where the second node is the next-hop node of the first node; The second field and the third field belong to the Operation, Maintenance and Management (OAM) field in the message header.

12. A multicast service flow detection apparatus, characterized by comprising: Applied to the second node, the device includes: A receiving module is used to receive a data packet encapsulated with a message header sent by a first node; the first node is the previous hop node of the second node; the message header includes a detection identifier, a first field, a second field, and a third field; the detection identifier is used to identify that the multicast service flow is a multicast service flow subject to flow-following detection; the first field is used to indicate the detection period of the multicast service flow; the second field is used to indicate whether the data packet has a packet loss detection coloring mark; and the third field is used to indicate whether the data packet participates in latency detection. The sending module is used to send a data packet encapsulated with the packet header to a third node, wherein the third node is the next-hop node of the second node; The second field and the third field belong to the Operation, Maintenance and Management (OAM) field in the message header.

13. A communications device, characterized by It includes a processor and an interface circuit, wherein the processor is communicatively connected to the interface circuit; The interface circuit is used to communicate with other communication devices; The processor is configured to implement the multicast service flow detection method as described in any one of claims 1 to 5, or to implement the multicast service flow detection method as described in any one of claims 6 to 10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by the processor, implement the multicast service flow detection method as described in any one of claims 1 to 5, or the multicast service flow detection method as described in any one of claims 6 to 10.

Images