Method and device for packet statistics

Abstract

The application provides a message statistics method, which comprises the following steps: a first network device receives a first multicast message; the first network device counts the characteristics of the first multicast message in a first time interval to obtain first statistics information; the first network device counts the characteristics of the first multicast message in a second time interval to obtain second statistics information; the first device judges the first statistics information and the second statistics information; when the deviation of the first statistics information and the second statistics information is greater than a first preset threshold, it is determined that the first network device has a transmission fault in the second time interval; when the first network device determines that the deviation of the first statistics information and the second statistics information is less than the first preset threshold, it is determined that the first network device has no transmission fault in the second time interval. The technical scheme provided by the application can improve the efficiency of fault positioning.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of network communication, and more particularly, to a message statistics method and device. BACKGROUND

[0002] Internet protocol (IP) multicast technology realizes efficient data transmission from a point to multiple points in an IP network, and can effectively save network bandwidth and reduce network load. After the statistics of multicast messages, the failure analysis of a device can be performed based on the statistical results, for example, to determine whether the device has a packet loss failure. In related technical solutions, the statistical result of the multicast message is the cumulative value since the multicast table item corresponding to the multicast message is established.

[0003] Therefore, in the related technical solutions, the increase of the multicast message cannot be obtained according to the cumulative message statistics result, which makes the failure analysis efficiency low. SUMMARY

[0004] The present application provides a message statistics method and a first network device, which can improve the efficiency of fault positioning.

[0005] In a first aspect, a message statistics method is provided, which includes: a first network device receiving a first multicast message; the first network device performing statistics on a feature of the first multicast message in a first time interval to obtain first statistical information; the first network device performing statistics on the feature of the first multicast message in a second time interval to obtain second statistical information; the first network device judging the first statistical information and the second statistical information; when the deviation of the first statistical information and the second statistical information is greater than a first preset threshold, determining that the first network device has a transmission failure in the second time interval; and when the deviation of the first statistical information and the second statistical information is less than the first preset threshold, determining that the first network device has no transmission failure in the second time interval.

[0006] In the above technical solution, the first network device can perform failure judgment based on at least two message features that are statistically obtained at different time intervals, and determine the time when the first network device has a failure, thereby improving the efficiency and accuracy of fault positioning.

[0007] In a possible implementation, the first statistical information includes a statistical time period and a feature of a message corresponding to the statistical time period; and the second statistical information includes a statistical time period and a feature of a message corresponding to the statistical time period.

[0008] In another possible implementation, the method further includes: receiving, by the first network device, third statistical information sent by a second network device, wherein the third statistical information is statistics of the second network device on the characteristics of the first multicast message in the first time interval; and determining, by the first network device, that the second network device or a link between the first network device and the second network device has a transmission failure in the first time interval, according to a deviation between the first statistical information and the third statistical information being greater than a second preset threshold.

[0009] In the technical solution described above, the first network device can further determine a time when the transmission failure between the first network device and the second network device occurs according to the message characteristics on the first network device and the message characteristics on the second network device in the same time interval, thereby improving the efficiency of fault location.

[0010] In another possible implementation, the first network device can determine that the first multicast message is transmitted normally and that the second network device or the link between the first network device and the second network device has no transmission failure in the first time interval, according to the deviation between the first statistical information and the third statistical information being less than the second preset threshold.

[0011] In another possible implementation, the method further includes: receiving, by the first network device, fourth statistical information sent by a second network device, wherein the fourth statistical information is statistics of the second network device on the characteristics of the first multicast message in the second time interval; and determining, by the first network device, that the second network device or a link between the first network device and the second network device has a transmission failure in the second time interval, according to a deviation between the second statistical information and the fourth statistical information being greater than a third preset threshold.

[0012] In another possible implementation, the first network device can determine that the first multicast message is transmitted normally and that the second network device or the link between the first network device and the second network device has no transmission failure in the second time interval, according to the deviation between the second statistical information and the fourth statistical information being less than the third preset threshold.

[0013] In another possible implementation, an error between a start time of obtaining the first statistical information and a start time of obtaining the third statistical information is less than a fourth preset threshold.

[0014] In the technical solution described above, the start time of obtaining the statistical information on the device can be time-synchronized, so that the statistical information obtained by each device on the multicast forwarding path is more comparable.

[0015] In a possible implementation, an error between a start time of the second statistical information acquisition and a start time of the fourth statistical information acquisition is less than a fifth preset threshold.

[0016] In a possible implementation, the feature of the packet includes any one of the following information or a combination of multiple information: a number of the packet, a byte number of the packet, a rate of the packet, and a bit rate of the packet.

[0017] In a possible implementation, the first network device is a device that forwards the first multicast packet in a protocol independent multicast (PIM).

[0018] In a possible implementation, the first network device is a device that forwards the first multicast packet in a border gateway protocol-multicast virtual private network (BGP-MVPN).

[0019] In a possible implementation, the first network device is a device that forwards the first multicast packet in a next generation-multicast virtual private network (NG-MVPN).

[0020] In a possible implementation, a tunnel in the NG-MVPN is established through a multipoint label distribution protocol (MLDP) protocol, the first multicast packet includes a point-to-multipoint (P2MP) label, a multicast source S, and a multicast group G,

[0021] The method further includes that the first network device determines the first multicast packet according to the P2MP label, the S, and the G.

[0022] In a possible implementation, a tunnel in the NG-MVPN is established through a bit index explicit replication (BIER) or a bit index explicit replication based on Internet Protocol version 6 (BIERv6), the first multicast packet includes a bit index forwarding table identifier (BIFT-ID) field, a multicast source S, and a multicast group G,

[0023] The method further includes that the first network device determines the first multicast packet according to the BIFT-ID field, the S, and the G.

[0024] In a possible implementation, a tunnel in the NG-MVPN is established through a BIER or a BIERv6, and the first multicast packet includes a bit index forwarding table identifier (BIFT-ID) field and an entropy field.

[0025] The method further includes that the first network device determines the first multicast packet according to the BIFT-ID field and the entropy field.

[0026] In a second aspect, a first network device is provided, comprising: a receiving module, a counting module, a determining module,

[0027] The receiving module is configured to receive a first multicast message.

[0028] The counting module is configured to count a feature of the first multicast message in a first time interval to obtain first counting information.

[0029] The counting module is further configured to count the feature of the first multicast message in a second time interval to obtain second counting information.

[0030] The determining module is configured to determine the first counting information and the second counting information.

[0031] The determining module is specifically configured to determine that the first network device has a transmission failure in the second time interval when it is determined that a deviation between the first counting information and the second counting information is greater than a first preset threshold; or

[0032] The determining module is specifically configured to determine that the first network device has no transmission failure in the second time interval when it is determined that the deviation between the first counting information and the second counting information is less than the first preset threshold.

[0033] In a possible implementation, the first counting information comprises a counted time period and a feature of a message corresponding to the counted time period.

[0034] The second counting information comprises a counted time period and a feature of a message corresponding to the counted time period.

[0035] In another possible implementation, the receiving module is further configured to receive third counting information sent by a second network device, wherein the third counting information is counting information of the first multicast message counted by the second network device in the first time interval.

[0036] The determining module is specifically configured to determine that the second network device or a link between the first network device and the second network device has a transmission failure in the first time interval according to a deviation between the first counting information and the third counting information being greater than a second preset threshold.

[0037] In another possible implementation, the determining module is specifically configured to determine that the first multicast message is transmitted normally and the second network device or the link between the first network device and the second network device has no transmission failure in the first time interval according to the deviation between the first counting information and the third counting information being less than the second preset threshold.

[0038] In another possible implementation, the receiving module is further configured to receive fourth statistical information sent by the second network device, wherein the fourth statistical information is statistical information of the second network device on the characteristic of the first multicast message in the second time interval.

[0039] The determining module is specifically configured to determine that the second network device or the link between the first network device and the second network device has a transmission failure in the second time interval, according to the deviation between the second statistical information and the fourth statistical information being greater than a third preset threshold.

[0040] In another possible implementation, the determining module is specifically configured to determine that the first multicast message is transmitted normally and the second network device or the link between the first network device and the second network device has no transmission failure in the second time interval, according to the deviation between the second statistical information and the fourth statistical information being less than the third preset threshold.

[0041] In another possible implementation, an error between a start time of obtaining the first statistical information and a start time of obtaining the third statistical information is less than a fourth preset threshold.

[0042] In another possible implementation, an error between a start time of obtaining the second statistical information and a start time of obtaining the fourth statistical information is less than a fifth preset threshold.

[0043] In another possible implementation, the characteristic of the message includes any one information or a combination of multiple information of the following: the number of messages, the number of bytes of messages, the rate of messages, and the bit rate of messages.

[0044] In another possible implementation, the first network device is a device for forwarding the first multicast message in a protocol-independent multicast (PIM).

[0045] In another possible implementation, the first network device is a device for forwarding the first multicast message in a border gateway protocol-multicast virtual private network (BGP-MVPN) or a next generation-multicast virtual private network (NG-MVPN).

[0046] In another possible implementation, a tunnel in the NG-MVPN is established through a multipoint label distribution protocol (MLDP) protocol, the first multicast message includes a point-to-multipoint (P2MP) label, a multicast source S, and a multicast group G,

[0047] The determining module is further configured to determine the first multicast message according to the P2MP label, the S, and the G by the first network device.

[0048] In another possible implementation, the tunnel in the NG-MVPN is established by Bit-Index Explicit Replication (BIER) or BIER version 6 (BIERv6), the first multicast packet comprises a Bit-Index Forwarding Table Identifier (BIFT-ID) field, S, and G,

[0049] The determining module is further configured to determine the first multicast packet according to the BIFT-ID field, S, and G.

[0050] In another possible implementation, the tunnel in the NG-MVPN is established by BIER or BIERv6, the first multicast packet comprises a Bit-Index Forwarding Table Identifier (BIFT-ID) field, an entropy field,

[0051] The determining module is further configured to determine the first multicast packet according to the BIFT-ID field and the entropy field.

[0052] The beneficial effects of the second aspect and any one of the possible implementation manners of the second aspect are corresponding to those of the first aspect and any one of the possible implementation manners of the first aspect, and thus will not be described here.

[0053] In a third aspect, a first network device is provided, which has a function of implementing the behavior of the first network device in the first aspect or any possible implementation manner of the first aspect. The function can be implemented based on hardware, or corresponding software is executed based on hardware. The hardware or software comprises one or more modules corresponding to the above functions.

[0054] In a possible design, the first network device comprises a processor and an interface. The processor is configured to support the first network device to perform the corresponding functions in the above method. The interface is configured to support the first network device to receive the first multicast packet. The first network device can further comprise a memory configured to be coupled to the processor, which stores the necessary program instructions and data of the first network device.

[0055] In another possible design, the first network device includes a processor, a transmitter, a receiver, a random access memory, a read-only memory, and a bus. The processor is coupled to the transmitter, the receiver, the random access memory, and the read-only memory via the bus, respectively. When the first network device needs to be run, the system is started by a basic input / output system or a bootloader in an embedded system solidified in the read-only memory, and the first network device is guided to a normal operation state. After the first network device enters the normal operation state, an application program and an operating system are run in the random access memory, so that the processor executes the method in the first aspect or any possible implementation of the first aspect.

[0056] In a fourth aspect, a first network device is provided, which includes a main board and an interface board, and further includes a switching network board. The first network device is configured to execute the method in the first aspect or any possible implementation of the first aspect. Specifically, the first network device includes modules configured to execute the method in the first aspect or any possible implementation of the first aspect.

[0057] It can be understood that, in actual applications, the first network device can include any number of interfaces, processors, or memories.

[0058] In a fifth aspect, a computer program product is provided, which includes computer program code, and when the computer program code is run on a computer, the computer is caused to execute the method in the first aspect or any possible implementation of the first aspect.

[0059] In a sixth aspect, a computer readable medium is provided, which stores program code, and when the computer program code is run on a computer, the computer is caused to execute the method in the first aspect or any possible implementation of the first aspect. The computer readable medium includes, but is not limited to, one or more of a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), a Flash memory, an electrically EPROM (EEPROM), and a hard drive.

[0060] In a seventh aspect, a chip is provided, which includes a processor and a data interface, wherein the processor reads instructions stored on a memory through the data interface to execute the method in the first aspect or any possible implementation manner of the first aspect. In a specific implementation process, the chip can be implemented in the form of a central processing unit (CPU), a micro controller unit (MCU), a micro processing unit (MPU), a digital signal processing (DSP), a system on chip (SoC), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or a programmable logic device (PLD). BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 is a possible application scenario suitable for the present application.

[0062] Figure 2 is a schematic networking diagram of a BIER technology provided by an embodiment of the present application.

[0063] Figure 3 is a schematic diagram of a possible BIER header format provided by an embodiment of the present application.

[0064] Figure 4 is a schematic block diagram of another possible BIER header format.

[0065] Figure 5 is a process of establishing a BIER forwarding table and performing BIER packet forwarding based on the BIER technology.

[0066] Figure 6 is a schematic flowchart of a packet statistics method provided by an embodiment of the present application.

[0067] Figure 7 is a schematic flowchart of another packet statistics method provided by an embodiment of the present application.

[0068] Figure 8 is a schematic flowchart of a method for determining a multicast fault point provided by an embodiment of the present application.

[0069] Figure 9is a schematic flowchart of another method for determining a multicast fault point provided by an embodiment of the present application.

[0070] Figure 10 is a schematic structural diagram of a first network device 1000 provided by an embodiment of the present application.

[0071] Figure 11 is a schematic hardware structure diagram of a first network device 2000 of an embodiment of the present application.

[0072] Figure 12 is another schematic hardware structure diagram of a first network device 2100 of an embodiment of the present application. DETAILED DESCRIPTION

[0073] The technical solutions in the present application will be described below with reference to the drawings.

[0074] The present application will present various aspects, embodiments or features around a system including a plurality of devices, components, modules, etc. It should be understood and appreciated that each system can include additional devices, components, modules, etc., and / or can not include all the devices, components, modules, etc. discussed in connection with the drawings. In addition, combinations of these solutions can also be used.

[0075] In addition, in the embodiments of the present application, the words "example", "for example", etc. are used to mean by way of example, illustration or description. Any embodiment or design solution described as "example" in the present application should not be interpreted as more preferred or more advantageous than other embodiments or design solutions. Rather, the word "example" is intended to present the concept in a specific manner.

[0076] In the embodiments of the present application, "corresponding" and "relevant" can be used interchangeably at times. It should be pointed out that when the distinction is not emphasized, the meanings expressed are consistent.

[0077] The network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art can know that as the network architecture evolves and new business scenarios appear, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0078] Reference within this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearance of the phrases "in one embodiment" or "in some embodiments" within this specification, generally means that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. The following terms are defined as follows: The terms "including" and / or "comprising," as well as other variants such as "include", "includes," "comprise," "comprises," and / or "comprising" mean "including but not limited to," or "comprising but not limited to," and are thus meant to be open-ended terms. The term "consisting of" means "including and limited to."

[0079] In this application, "at least one" means one or more, and "multiple" means two or more. The term "and / or" describes associating objects and means that there can be three kinds of relations, for example, A and / or B can mean that it includes the case of A alone, the case of A and B together, and the case of B alone, where A and B can be singular or plural. The character " / " generally means that the associated objects before and after are in an "or" relationship. "At least one of the following" or similar expressions means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, and c can be single or multiple.

[0080] Multicast is a data transmission method that uses a multicast address to transmit data to multiple receivers on a transmission control protocol (TCP) / internet protocol (IP) network at the same time in an efficient manner. A multicast source sends a multicast stream to multicast group members in a multicast group via links in a network, and each of the multicast group members in the multicast group can receive the multicast stream. The multicast transmission method implements a point-to-multipoint data connection between the multicast source and the multicast group members. Since the multicast stream only needs to be transmitted once on each network link, and the multicast is only copied when a branch occurs in the link, the multicast transmission method improves data transmission efficiency and reduces the possibility of congestion in the backbone network.

[0081] Internet protocol (IP) multicast technology realizes efficient data transmission from point to multipoint in IP network, and can effectively save network bandwidth and reduce network load. Therefore, the IP multicast technology has wide application in real-time data transmission, multimedia conference, data copying, Internet protocol television (IPTV), game and simulation, etc.

[0082] First, the application scenario applicable to the embodiments of the present application is described in detail. Figure 1 The application scenario applicable to the embodiments of the present application is described in detail.

[0083] Figure 1 is a possible multicast scenario applicable to the embodiments of the present application. Referring to Figure 1 , as an example, the scenario can include: a multicast source (SRC), a first hop router (FHR), a router R1, a router R2, a router R3, a last hop router 1 (LHR1), an LHR2, a multicast receiver 1 (RCV1), and an RCV2.

[0084] It should be understood that the number of routers (R) connected with the SRC can be multiple, and the embodiments of the present application do not make specific limitation thereon. For the convenience of description, Figure 1 is taken as an example for description.

[0085] The embodiments of the present application do not make specific limitation on the multicast routing protocol between the routers shown in Figure 1 . For example, the multicast routing protocol can be a protocol independent multicast (PIM). For another example, the multicast routing protocol can also be a border gateway protocol (BGP).

[0086] As an example, the multicast routing protocol is taken as PIM for description.

[0087] Taking RCV1 as an example, RCV1 can send a multicast join (S1, G1) message to LHR1 connected thereto, where S represents an address of a multicast source, and G represents an address of a multicast group. LHR1 looks up a routing next hop of S1, and sends the multicast join (S1, G1) message to the routing next hop. When the routing next hop receives the multicast join (S1, G1) message, it continues to send the multicast join (S1, G1) message to the routing next hop of S1. Until the multicast join (S1, G1) message reaches FHR, thereby establishing a multicast tree from FHR to LHR1. Finally, FHR sends a multicast join (S1, G1) message to SRC. Similarly, RCV2 can also send a multicast join (S1, G2) message to SRC according to the above method, and establish a multicast tree from FHR to LHR2.

[0088] It should be understood that the above multicast join (S1, G1) message sent by the embodiment of the present application is not specifically limited. It can be an internet group management protocol (IGMP) message, or can be a multicast listener discovery (MLD) message, or can be a protocol independent multicast (PIM) message.

[0089] After receiving the multicast join (S1, G1) message, SRC sends a multicast packet corresponding to (S1, G1) to RCV1. As an example, SRC can send the multicast packet to FHR, which forwards the multicast packet to LHR1 along the multicast tree forwarding path from FHR to LHR1, and LHR1 sends the multicast packet corresponding to (S1, G1) to RCV1.

[0090] As an example, in PIM multicast, the format of the multicast packet can include: an IP header, a user datagram protocol (UDP) header, and multicast data (payload). Among them, the IP header can include: <S, G, proto = UDP>, and the UDP header includes: a source port (sport) field and a destination port (dport) field.

[0091] It should be understood that the multicast packet in each multicast stream can be identified by (S, G) in the multicast packet.

[0092] Another example, the following takes the multicast routing protocol as BGP as an example for description.

[0093] The multicast routing protocol is implemented through BGP, that is, BGP-multicast virtual private network (BGP-MVPN) or next generation MVPN (NG-MVPN).

[0094] It should be understood that in this implementation, a point to multipoint (P2MP) tunnel needs to be established between the FHR and the LHR. In the tunnel between the FHR and the LHR, the FHR and the LHR can be boundary nodes (provider edge, PE) of a service provider network. Meanwhile, the FHR and the LHR can be an ingress node and an egress node respectively. The RCV and the SRC can be customer network devices (customer edge, CE).

[0095] It should also be understood that the interface through which the FHR receives the multicast packet can be a public network interface, or can also be an interface bound with a virtual private network (VPN), which can also be referred to as a private network interface.

[0096] There are various specific implementation manners for establishing the P2MP tunnel between the FHR and the LHR in the embodiments of the present application, and the possible implementation manners are described in detail as follows.

[0097] For example, in the NG-MVPN, the P2MP tunnel between the FHR and the LHR can be established through a multipoint label distribution protocol (MLDP) protocol.

[0098] Specifically, taking the establishment of the P2MP tunnel between the FHR and the LHR1 as an example. The FHR as an ingress PE node sends a BGP MVPN routing message to the LHR1 as an egress PE node. The routing message carries (S1, G1) information and an MLDP forwarding equal class (FEC) identifier, which indicates that the FHR will send the multicast traffic of (S1, G1) through the P2MP tunnel identified by the FEC. The FEC will carry the IP address of the FHR router. After the LHR1 receives the message, it can join the multicast (S1, G1) and send an LDPMapping message to the FHR hop by hop through the FEC and carry an MPLS label, thereby establishing a P2MP tunnel with the FHR as the root and the LHR1 as the leaf.

[0099] In the P2MP tunnel established using the MLDP, the multicast message needs to be encapsulated when being forwarded in the tunnel. The format of the encapsulated multicast message can include: P2MP label, IP header, UDP header and multicast data (payload). Among them, the IP header can include:, the UDP header includes: source port (source port, sport) field, destination port (destination port, dport) field.

[0100] It should be understood that in the above message format, each multicast flow can be identified by (P2MP label, S, G) in the message.

[0101] For example, in the NG-MVPN, a P2MP tunnel between the FHR and the LHR can also be established by the bit index explicit replication (BIER) technology or the internet protocol version 6 based BIER (BIERv6).

[0102] For ease of understanding, the related technologies of BIER will be described first.

[0103] It should be understood that BIER is a new technology for constructing a multicast data forwarding path, which proposes a multicast technology architecture without constructing a multicast distribution tree. As shown in Figure 2 The router supporting the BIER technology is called a bit forwarding router (BFR), which can receive and forward BIER messages. A multicast forwarding domain composed of one or more BFRs is called a BIER domain. At the entrance of the BIER domain, the BFR that encapsulates the original multicast data message is called a bit forwarding ingress router (BFIR). At the exit of the BIER domain, the BFR that decapsulates the original multicast data message from the BIER message is called a bit forwarding egress router (BFER). It should be understood that the BFIR and the BFER in the BIER domain can be referred to as edge BFRs in the BIER domain.

[0104] In the BIER domain, the edge BFRs described above can be configured with a globally unique bit position identifier in the entire BIER sub-domain (SD). As an example, a value is configured for each edge BFR as a BFR identifier (BFR ID), for example, the BFR ID can be a number between 1 and 256. All BFR IDs in the BIER domain form a bit string.

[0105] In the embodiments of the present application, when the original multicast data packet needs to be transmitted in the BIER domain, an additional specific BIER header needs to be encapsulated. The BIER header marks all destination devices of the original multicast data packet through a bit string. The BFRs in the BIER domain can perform forwarding according to the bit index forwarding table (BIFT) and the bit string carried in the BIER header, so as to ensure that the original multicast data packet can be sent to all destination addresses.

[0106] The embodiments of the present application do not make specific limitations on the BIER header format, as long as the bit string field is included in the BIER header. The following will describe in detail two possible BIER header formats. Figures 3-4

[0107] Figure 3 is a schematic block diagram of a possible BIER header format. As shown in Figure 3 The BIER header can include but is not limited to: a bit index forwarding table identifier (BIFT ID) with a length of 20 bits, a bit string length (BSL), 64 bits (8 bytes) of other fields, for example, traffic class (TC) of the original multicast data packet behind the BIER header, stack (S), time to live (TTL) field, entropy field, version (Ver) field, nibble field, protocol (proto) field, operation administration and maintenance (OAM) field, reserve (Rsv) field, differential service code points (DSCP) field, etc. ​

[0108] The fields in the BIER header are described in detail below.

[0109] (1)BIFT ID field

[0110] Under the BIER-multi protocol label switching (MPLS) encapsulation is an MPLS label (label, L). This MPLS label can be called a BIER label, and the subsequent TC / S / TTL fields are standard label encoding formats.

[0111] The BIFT ID may be a BIFT-id, which may include a combination of sub-domain (SD) / bit string length (BSL) / set identifier (SI), and different BIFT IDs may correspond to different SD / BSL / SI combinations.

[0112] It should be understood that different BIFT IDs can map to different SD / BSL / SI combinations. Figure 3 The BIER header format shown does not directly contain the SD / BSL / SI fields. SD / BSL / SI are three implicit fields, and the SD / BSL / SI values ​​need to be mapped according to the BIFT ID field.

[0113] BSL is the length of the bit string included in the BIER header. There can be multiple BSLs, and the embodiments of the present application do not specifically limit this. The minimum BSL is 64 bits, and the BSL can also be 128 bits, 256 bits, 512 bits, 1024 bits, 2048 bits, and the maximum BSL is 4096 bits. Specifically, it is identified by 4 bits in the message. For example, when the BSL is 64 bits, it is identified by 0001 in the message. When the BSL is 128 bits, it is identified by 0010 in the message. When the BSL is 512 bits, it is identified by 0100 in the message. When the BSL is 1024 bits, it is identified by 0101 in the message, and so on.

[0114] If the number of BFER devices in the network is greater than 256, in order to accommodate this situation, the BIER package contains not only a BitString but also a set identifier (SI). The role of the SI is to divide the BIER device number into multiple different intervals, thereby supporting larger-scale network addressing.

[0115] (2) Bit string field

[0116] Each bit in the bit string is used to identify the edge BFR. For example, the low-order (rightmost) bit of the bit string is used to identify the BFER with BFR-ID=1. The second bit from right to left in the bit string is used to identify the BFER with BFR-ID=2. The forwarding table entries based on which the forwarding plane forwards the message determine which BFERs the message will be sent to based on the bit string in the message. When the BFR in the BIER domain receives a message header containing a BIER, it forwards the BIER message based on the bit string and BIFT ID carried in the BIER header.

[0117] It should be noted that a bit value of 1 indicates that the message is to be sent to the BFER device represented by the BFR-ID, and a bit value of 0 indicates that the message does not need to be sent to the BFER device represented by the BFR-ID.

[0118] Figure 4 This is a schematic diagram of another possible BIER header format. Figure 3 As shown in the BIER header format, Figure 4 The BIER header format shown does not contain the BIFT-ID field, but contains the SD / BSL / SI fields. In other words, Figure 3 The BIER header format shown directly contains the three fields SD / BSL / SI, without the need to map the SD / BSL / SI values ​​from the BIFT ID field.

[0119] Below Figure 5 Taking BIER as an example, the process of establishing a BIER forwarding table and forwarding BIER messages based on BIER technology is described in detail.

[0120] like Figure 5 The BIER domain shown can include devices A to F, where devices A, D, E, and F belong to the edge BFR within the BIER domain, and devices B and C belong to the BIER intermediate forwarding devices. Specifically, device A is located at the entrance of the BIER domain and is responsible for BIER encapsulation of the original multicast data message, corresponding to Figure 1 Device D, device E, and device F are located at the exit of the BIER domain and are responsible for decapsulating the original multicast data packets from the BIER packets, corresponding to Figure 1 BFER in.

[0121] In the embodiment of the present application, a unique BFR-ID can be assigned to each edge BFR in the BIER domain, for example, Figure 5In the middle, the BFR-ID configured for device A, device D, device E, device F is 4, 1, 3, 2 respectively. The intermediate forwarding BFR, for example, device B, device C, does not assign BFR-ID.

[0122] It should be noted that in the embodiments of the present application, "ID" and "id" can be mixed sometimes. It should be pointed out that when the distinction is not emphasized, the meanings expressed are consistent. In the present application, BFR-ID can refer to Figure 5 id in the middle.

[0123] The bit string encapsulated in the BIER header of the data flow marks all the destination devices of the flow. For example, the bit string corresponding to device D with BFR-ID 1 is 0001, the bit string corresponding to device F with BFR-ID 2 is 0010, the bit string corresponding to device E with BFR-ID 3 is 0100, and the bit string corresponding to device A with BFR-ID 4 is 1000.

[0124] It should be understood that the BFR-ID value assigned to each edge BFR in the BIER domain can be flooded to other BFRs in the BIER domain through a routing protocol. The flooded BIER information also includes the IP address of the edge BFR and encapsulation information. For example, the flooded BIER information of device A carries the IP address of device A and the BIFT-id. The BFR (for example, device F in the middle) in the BIER domain can establish a BIFT entry according to the flooded BIER information, so as to facilitate Figure 4 device F in the middle) in the BIER domain can establish a BIFT entry according to the flooded BIER information, so as to facilitate Figure 5 After device F in the middle receives the BIER packet, it completes the forwarding of the BIER packet to the destination device according to the established BIFT entry.

[0125] For device A, if it needs to send a BIER packet to BFRs with BFR-ID 1, 2, and 3, the BIER packet needs to be sent to the neighbor (device B) of device A first. The edge BFR with BFR-ID 4 is itself, therefore, the BIFT entry established by device A is as follows:

[0126] Forwarding entry 1: neighbor (Nbr) = B, forwarding bit mask (FBM) = 0111;

[0127] Forwarding entry 2: Nbr* = A, FBM = 1000.

[0128] The forwarding table entry 1 is used to indicate that when the bit string of a BIER packet has any one of the first bit, the second bit, and the third bit from right to left as 1, the BIER packet is sent to the neighbor (device B) of device A, and Nbr=B indicates that the neighbor of device A is device B.

[0129] The forwarding table entry 2 is used to indicate that when the bit string of a BIER packet has the fourth bit from right to left as 1, the BIER packet is sent to device A. Since device A is itself, device A will strip the BIER header and forward according to the information in the original multicast data packet. It should be noted that the * in the above forwarding table entry 2 is used to indicate that the Nbr is itself, for example, for device A, Nbr=A indicates that the neighbor of device A is itself. Similarly, Figure 4 Other devices in the network can also establish BIFT table entries according to their own neighbor devices. The BIFT table entries established by other devices are described in detail in the following table, and will not be described here again. Figure 5

[0130] ​When the device A receives the original multicast data packet as a BFIR of the BIER domain entrance, a BIER header is encapsulated in front of the original multicast data packet. It should be understood that, for the convenience of description, the following is referred to as entrance device A. As an example, the entrance device A can learn the destination device of the original multicast data packet according to the BFR-ID flooded by the Border Gateway Protocol (BGP) message after receiving the original multicast data packet. For example, the receiver of the original multicast data packet is the destination device E with BFR-ID 3, the destination device F with BFR-ID 2, and the destination device D with BFR-ID 1. The entrance device A encapsulates the bit string of the BIER header as 0111, and forwards the encapsulated BIER packet to the neighbor device B according to the forwarding table item 1 described above. After the device B receives the BIER packet, it determines that the BIER packet needs to be sent to the devices C and E according to the bit string 0111 and the BIFT table item. When the device B sends the BIER packet to the device C, it can perform an AND operation on the bit string (0111) of the BIER header and the FBM field corresponding to Nbr=C in the BIFT table item. In the embodiment of the present application, the result of the AND operation is 0011, so the device B can modify the bit string of the BIER header to 0011 and send it to the device C. Similarly, the device B can modify the bit string of the BIER header to 0100 when sending the BIER packet to the device E. After the device E receives the BIER packet, it determines that the BIER packet needs to be sent to the neighbor device E according to the bit string 0100. Since the device E determines that the neighbor device E is itself according to the identification in the forwarding table, the device E as a BFER of the BIER domain exit can decapsulate the original multicast data packet from the BIER packet and forward it according to the information in the original multicast data packet in the inner layer.

[0131] In the BIER-MPLS encapsulation, the first 32 bits of the BIER header is an MPLS label encoding, wherein the first 20 bits in the first 32 bits is an MPLS label value. The MPLS label value will change in the process of forwarding, for example, the device A needs to encapsulate the MPLS label value of the device B when sending the packet to the device B, and the device B needs to encapsulate the MPLS label value of the device C when sending the packet to the device C. In the embodiment of the present application, the MPLS label values allocated by the devices A / B / B / C / D / E / F are 100 / 200 / 300 / 400 / 500 / 600 respectively. These MPLS label values need to be carried in the BIER encapsulation information described above and flooded to other BFRs in the BIER domain through a routing protocol, so that the device A can learn the MPLS label value of the device B. This MPLS label identifying BIER information is also called BIER label.

[0132] In the BIER tunnel established using BIER or BIERv6, the multicast message needs to be encapsulated when forwarding in the tunnel. The format of the encapsulated multicast message can include: BIER header, IP header, UDP header and multicast data (payload). Among them, the IP header can include: <S, G, proto=UDP>, and the UDP header includes: source port (source port, sport) field and destination port (destination port, dport) field.

[0133] It should be understood that in BIER, a corresponding multicast flow can also be determined according to the multicast message. There are many specific implementation manners. For example, the multicast flow can be determined according to the (S, G) of the IP header behind the BIER header and the BIFT-ID field of the BIER header. Another example is that the (S, G) of the IP header of the multicast flow can be mapped to the Entropy field of the BIER header, and then the multicast flow is determined according to the Entropy field and the BIFT-ID field together. For specific description of the BIER header, please refer to the description in the foregoing, which will not be repeated here.

[0134] The above various scenarios can perform flow statistics on the multicast message, and perform fault analysis on the device based on the statistical result, for example, determine whether the device has a packet loss fault. In the related technical solution, the statistical result of the multicast message is the cumulative value since the multicast table corresponding to the multicast message is established. In the related technical solution, the cumulative message statistical result cannot obtain the increase of the multicast message, so that the efficiency of fault analysis is low.

[0135] Therefore, the embodiments of the present application provide a message statistical method, which can improve the efficiency of fault positioning.

[0136] Figure 6 is a schematic flow chart of a message statistical method provided by the embodiments of the present application. As shown in Figure 6 The method can include steps 610-640, which will be described in detail below.

[0137] Step 610: The first network device receives a first multicast message.

[0138] It should be understood that the first network device is a device in PIM that forwards the first multicast message. Alternatively, it can also be a device in BGP-MVPN that forwards the first multicast message. Alternatively, it can also be a device in NG-MVPN that forwards the first multicast message. The present application does not make specific limitation on this.

[0139] Step 620: The first network device counts the features of the first multicast message in the first time interval to obtain first statistical information.

[0140] It should be understood that the first statistical information can include a counted time period and the features of the message corresponding to the counted time period.

[0141] In the embodiments of the present application, the features of the message can include any one of the following information or a combination of multiple information: the number of messages, the number of bytes of messages, the rate of messages, and the bit rate of messages.

[0142] Step 630: The first network device counts the features of the first multicast message in the second time interval to obtain second statistical information.

[0143] It should be understood that the second statistical information can include a counted time period and the features of the message corresponding to the counted time period.

[0144] Step 640: The first network device judges the first statistical information and the second statistical information.

[0145] Specifically, the first network device can determine whether the first network device fails in the second time interval according to whether the deviation of the first statistical information and the second statistical information is less than a first preset threshold.

[0146] As an example, if the deviation of the first statistical information and the second statistical information is greater than the first preset threshold, it can be determined that the first network device fails in the second time interval. As another example, if the deviation of the first statistical information and the second statistical information is less than the first preset threshold, it can be determined that the first network device does not fail in the second time interval, and the first multicast message is transmitted normally.

[0147] The deviation of the first statistical information and the second statistical information can be understood as the difference between the count of a certain message feature in the first statistical information and the count of the message feature in the second statistical information, or can also be understood as the deviation rate of the count of a certain message feature in the first statistical information and the count of the message feature in the second statistical information.

[0148] It should be understood that the deviation rate can be (the count of a certain message feature in the first statistical information - the count of the message feature in the second statistical information) / the count of a certain message feature in the first statistical information.

[0149] In the above technical solution, the first network device can determine the time when the first network device fails based on at least two message features counted by itself at different time intervals, thereby improving the efficiency of fault positioning.

[0150] Optionally, the first network device can further receive third statistical information and fourth statistical information sent by the second network device, wherein the third statistical information is statistics of the second network device on the characteristic of the first multicast message in the first time interval, and the fourth statistical information is statistics of the second network device on the characteristic of the first multicast message in the second time interval. The first network device can determine the fault between the first network device and the second network device based on the above information.

[0151] For example, the first network device determines whether the second network device has a fault in the first time interval or whether a link between the first network device and the second network device has a transmission fault in the first time interval according to whether a deviation of the first statistical information and the third statistical information is less than a second preset threshold.

[0152] If the first network device determines that the deviation of the first statistical information and the third statistical information is greater than the second preset threshold, it can be determined that the second network device has a fault in the first time interval or that the link between the first network device and the second network device has a transmission fault in the first time interval.

[0153] If the first network device determines that the deviation of the first statistical information and the third statistical information is less than the second preset threshold, it can be determined that the first multicast message is transmitted normally, the second network device has no fault in the first time interval, or the link between the first network device and the second network device has no transmission fault in the first time interval.

[0154] For another example, the first network device determines whether the second network device has a fault in the second time interval or whether a link between the first network device and the second network device has a fault in the second time interval according to whether a deviation of the second statistical information and the fourth statistical information is less than a third preset threshold.

[0155] If the first network device determines that the deviation of the second statistical information and the fourth statistical information is greater than the third preset threshold, it can be determined that the second network device has a fault in the second time interval or that the link between the first network device and the second network device has a transmission fault in the second time interval.

[0156] If the first network device determines that the deviation of the second statistical information and the fourth statistical information is less than the third preset threshold, it can be determined that the first multicast message is transmitted normally, the second network device has no fault in the second time interval, or the link between the first network device and the second network device has no transmission fault in the second time interval.

[0157] The following is an example ofFigure 1 As an example, combining the following scenario Figure 7 A possible implementation process of the method for providing message statistics in the embodiment of the present application is described in detail with a specific example. It should be understood that Figure 7 The examples are only intended to help those skilled in the art understand the embodiments of the present application, and are not intended to limit the embodiments of the present application to Figure 7 Those skilled in the art can obviously make various equivalent modifications or changes based on the examples given, and such modifications and changes also fall within the scope of the embodiments of the present application.

[0158] Figure 7 This is a schematic flow chart of another method for packet statistics provided by an embodiment of the present application. Figure 7 As shown, the method may include steps 710-720, and steps 710-720 are described in detail below.

[0159] Step 710: Each device on the multicast forwarding path creates a table entry.

[0160] Each device on the multicast forwarding path (e.g., FHR, LHR, R1, R2, R3) can establish a table entry. It should be understood that for ease of description, the following is based on Figure 1 The FHR shown is used as an example for explanation.

[0161] For example, the FHR counts the number of packets and bytes accumulated for each multicast stream. For example, the total packet count can be used to represent the total number of packets for each multicast stream, while the total byte count can be used to represent the total number of bytes accumulated for each multicast stream. After the above table entries are established, each time a packet is received, the FHR adds the number of packets to the total packet count and the number of bytes in the packet to the total byte count.

[0162] For another example, the FHR also maintains a last packet count and a last byte count for each multicast flow.

[0163] As another example, FHR maintains multiple arrays for each multicast stream. For example, to record statistics for five messages, FHR can maintain five arrays, Array[0]-Array[4], for each multicast stream. The statistical information in each array can include: the number of messages and the number of message bytes. Optionally, each array can also include: the message rate and the message bit rate.

[0164] Wherein, the packet number is determined according to the value of total packet count minus the value of last packet count. The packet byte number is determined according to the value of total byte count minus the value of last byte count.

[0165] Optionally, the packet rate is determined according to the value of packet number divided by the time length. The packet bit rate is determined according to the value of packet byte number multiplied by 8 and then divided by the time length.

[0166] Optionally, the FHR can also maintain a last time. The FHR can also check the current time at any time.

[0167] It should be noted that the above time length can be an approximate value of 60 (i.e. 60 seconds), or can also be determined according to the difference between the value of current time and the value of last time.

[0168] In the embodiment of the application, in order to record the statistical results of multiple packets, the FHR also maintains a count, which represents the number of moving the index of the circular array backward. Taking the recording of the statistical results of 5 packets as an example, count = (count + 1) % 5.

[0169] For example, when the first timer expires, the counts in Array[0] are filled, count = 1, which represents moving the index of the circular array backward by 1 bit, and the counts in Array[1] start to be counted. For another example, when the second timer expires, the counts in Array[1] are filled, count = 2, which represents moving the index of the circular array backward by 2 bits, and the counts in Array[3] start to be counted. For another example, when the third timer expires, the counts in Array[2] are filled, count = 3, which represents moving the index of the circular array backward by 3 bits, and the counts in Array[4] start to be counted. For another example, when the fourth timer expires, the counts in Array[3] are filled, count = 4, which represents moving the index of the circular array backward by 4 bits, and the counts in Array[4] start to be counted. For another example, when the fifth timer expires, the counts in Array[4] are filled, count = 0, which represents moving the index of the circular array backward by 5 bits, and returns to Array[0] of the circular queue, and the counts in Array[0] start to be counted.

[0170] Initially, current = 0, each member of the Array array is 0, the last packet count and the last byte count are 0, and the total packet count and the total byte count are also 0. The last time stamp can take the time when the entry is established as the initial value.

[0171] Step 720: Each device on the multicast forwarding path performs statistics on each received multicast stream.

[0172] For ease of description, the following will take the FHR shown in FIG. 1 as an example for illustration. Figure 1

[0173] It should be understood that the FHR needs to identify each group of multicast streams and perform packet statistics on each group of multicast streams before performing statistics on each received multicast stream. The method of identifying each group of multicast streams is different in different application scenarios, and the following will be described in combination with several possible application scenarios.

[0174] Taking PIM as an example, the format of the multicast message can include: IP header, user datagram protocol (UDP) header and multicast data (Payload). Among them, the IP header can include: <S, G, proto = UDP>, the UDP header includes: source port (source port, sport) field, destination port (destination port, dport) field. The FHR can identify different multicast streams according to (S, G) in the multicast message.

[0175] Taking BGP as an example, different tunnels identify each group of multicast streams in different ways.

[0176] In one possible implementation, in the P2MP tunnel established using MLDP, the format of the encapsulated multicast message can include: P2MP label, IP header, UDP header and multicast data (Payload). Among them, the IP header can include: <S, G, proto = UDP>, the UDP header includes: source port (source port, sport) field, destination port (destination port, dport) field. The FHR can identify different multicast streams according to (P2MP label, S, G) in the multicast message.

[0177] ​In another possible implementation, in a P2MP tunnel established using BIER or BIERv6, the format of the encapsulated multicast packet can include: a BIER header, an IP header, a UDP header, and multicast data (payload). The IP header can include: <S, G, proto=UDP>, and the UDP header can include: a source port (sport) field and a destination port (dport) field. In one example, the FHR can determine a multicast flow according to the (S, G) in the IP header behind the BIER header and the BIFT-ID field in the BIER header. In another example, the FHR can also map the (S, G) in the IP header of the multicast flow to the Entropy field in the BIER header, and determine a multicast flow according to the Entropy field and the BIFT-ID field together.

[0178] The following describes in detail the specific implementation process of the FHR for counting each received multicast flow.

[0179] The FHR can start a timer, and when the timer expires, the FHR counts the number of packets. For example, the time length (or time interval) is 60 seconds, and the time of the timer is 60 seconds.

[0180] In one possible implementation, when the first timer expires, count = 1, and the multiple counts included in Array[0] are filled.

[0181] For example, the FHR subtracts the value of the last packet count from the value of the total packet count to obtain a calculation result, denoted as the increased packet count (delta packet count). The FHR takes the increased packet count (delta packet count) as the packet number of Array[0].

[0182] For example, the FHR subtracts the value of the last byte count from the value of the total byte count to obtain a calculation result, denoted as the increased byte count (delta byte count). The FHR takes the increased byte count (delta byte count) as the byte number of Array[0].

[0183] Optionally, the FHR can also divide the increased packet count (delta packet count) by the time length to obtain a calculation result, and take the calculation result as the packet rate of Array[0].

[0184] Optionally, the FHR can also use the increased byte count (delta byte count) multiplied by 8 and divided by the time length to obtain a calculation result, and take the calculation result as the packet bit rate of Array[0].

[0185] After the counts in Array[0] are filled, the total packet count (total packet count) can be assigned to the last packet count (last packet count), i.e., last packet count = total packet count. The total byte count (total byte count) can also be assigned to the last byte count (last byte count), i.e., last byte count = total packet count.

[0186] Similarly, by analogy, when the second timer expires, the counts in Array[1] are filled. For specific determination methods, please refer to the description in the foregoing, which will not be described here again.

[0187] The following takes the information counted in each array as an example, including the packet count, byte count, packet rate, and packet bit rate, the time length is 60 seconds, and 5 packet statistics records are recorded, to exemplarily illustrate the packet information counted by the FHR.

[0188] Table 1: Packet information counted by the FHR

[0189] Serial number Number of messages Number of bytes Message rate Message bit rate Corresponding time period 0 1004 1413000 16 188400 (10:06:00-10:07:00) 1 1013 1413000 16 188400 (10:07:00-10:08:00) 2 1020 1413000 16 188400 (10:08:00-10:09:00) 3 1010 1416000 16 188800 (10:09:00-10:10:00) 4 1015 1417000 16 188933 (10:10:00-10:11:00)

[0190] Among them, the packet rate can also be expressed as the network throughput rate, i.e., package per second (pps), indicating the number of data packets that can be forwarded by the network device per second. The packet bit rate is bit per second (bps), indicating how many bits of information are transmitted per second.

[0191] On the FHR, the command line can display "record one packet statistics per minute, and record a total of 5 packet statistics records". Optionally, the command line can also display the packet rate and bit rate. The following is a specific command line example.

[0192]

[0193] Wherein, "Last 5 statistic records (60 seconds each except the latest one)" means that one packet statistic is recorded every minute, and totally 5 packet statistic records are recorded. "1004 packets (16 pps), 1413000 bytes (188400 bps)" means that the number of packets is 1004, the packet rate is 16 pps, the number of bytes is 1413000, and the packet bit rate is 188400 bps.

[0194] Similarly, other devices on the multicast forwarding path (for example, R1, R2, R3, LHR) can also perform packet statistics on each multicast stream received according to the above method. For example, one packet statistic is recorded every minute, and totally 5 packet statistic records are recorded. For example, for multicast stream 1, there is one packet statistic containing 5 statistic counts in the last 5 minutes, with each minute as a time period. For another example, for multicast stream 2, there is one packet statistic containing 5 statistic counts in the last 5 minutes, with each minute as a time period.

[0195] Optionally, the timer started by the FHR can also be "corrected" to the time point of the whole minute. For example, the time of the table entry establishment is 10:06:05, the first timeout time of the timer started by the FHR is set to 55 seconds, and the second timeout time is set to 60 seconds.

[0196] For another example, as time goes on, the timeout time point of the timer deviates from the time of the whole minute, and if the deviation is greater than 1 second, the correction can be continued on the FHR. In this way, it can be ensured that the packet count array of the FHR is taken from the time point of the whole minute.

[0197] Other devices on the multicast forwarding path can also correct the packet statistic count to the time point of the whole minute. In addition, the devices on the multicast forwarding path can be time-synchronized through a time synchronization protocol, for example, a network time protocol (NTP), so that the packet statistics performed by the devices on the multicast forwarding path are more comparable.

[0198] Taking the example of recording one packet statistic every minute and totally recording 5 packet statistic records, if the devices on the multicast forwarding path are time-synchronized, the time periods of the 5 packet statistics recorded by each device are the same. For example, the FHR, the LHR, R1, R2, and R3 can record their respective 5 packet statistics for a certain multicast stream, for example, multicast stream (S1, G1), in the same time period.

[0199] In the embodiments of the present application, the fault point of multicast forwarding can also be quickly located according to the multicast message statistical data obtained by each device on the multicast forwarding path. There are various specific implementation manners, in one possible implementation manner, a certain forwarding device on the multicast forwarding path for forwarding multicast messages can quickly locate the fault point of multicast forwarding based on the multicast message statistical data obtained by each device. In another possible implementation manner, a separate control device can also quickly locate the fault point of multicast forwarding based on the multicast message statistical data obtained by each device on the multicast forwarding path. The following will be described in detail in combination with two different implementation manners respectively. Figures 8-9 The two different implementation manners will be described in detail.

[0200] It should be understood that Figures 8-9 The examples are only used to help those skilled in the art to understand the embodiments of the present application, and are not intended to limit the embodiments of the present application to the specific values or specific scenarios shown. Those skilled in the art can obviously make various equivalent modifications or changes according to the examples given below, and such modifications and changes also fall within the scope of the embodiments of the present application. Figures 8-9 The examples are only used to help those skilled in the art to understand the embodiments of the present application, and are not intended to limit the embodiments of the present application to the specific values or specific scenarios shown. Those skilled in the art can obviously make various equivalent modifications or changes according to the examples given below, and such modifications and changes also fall within the scope of the embodiments of the present application.

[0201] Figure 8 is a schematic flowchart of a method for determining a multicast fault point provided by the embodiments of the present application. As shown in Figure 8 The method can include steps 810-830, which will be described in detail below respectively.

[0202] It should be understood that each device on the multicast forwarding path can implement quick location of the fault point of multicast forwarding based on the multicast message statistical data recorded by each device. In order to facilitate description, Figure 8 In the embodiments of the present application, LHR1 is taken as an example for description.

[0203] It should also be understood that the embodiments of the present application do not make specific limitation on the application scenarios of the method shown in Figure 8 As shown in the above description, the application scenarios of the method can be scenarios in which the multicast routing protocol is PIM, or can also be scenarios in which the multicast routing protocol is BGP. For the description of various scenarios, please refer to the description in the above, which will not be described here.

[0204] Step 810: LHR1 sends a request message to each device on the multicast forwarding path.

[0205] LHR1 can send a request message to R3, R2, R1 and FHR, and the request message is used to request message statistical information on each device (for example, R3, R2, R1 and FHR) on the multicast forwarding path. As an example, the request message can be an MTRACE message.

[0206] Step 820: Each device on the multicast forwarding path feeds back the packet statistical information to LHR1 through a reply message.

[0207] As an example, each device on the multicast forwarding path (e.g., R3, R2, R1, FHR) can carry the packet statistical information through an MTRACE message. For example, each device in the network can record the packet statistical information according to the following method. Figure 7 The method shown in the table is used to perform packet statistics on each group of multicast flows.

[0208] Specifically, taking the time length of the packet statistics of each device on the multicast forwarding path (e.g., R3, R2, R1, FHR) as 60 seconds, and taking 5 packet statistical results as an example, each packet statistical result includes the number of packets and the number of bytes, the statistical information fed back by each device (e.g., R3, R2, R1, FHR) on the multicast forwarding path to LHR1 through an MTRACE message is shown in the following table.

[0209]

[0210] For "Response1", "input interface (IIF) = to SRC, output interface (OIF) = to R1" indicates that the input interface is SRC and the output interface is R1, so it can be determined that the Response1 is sent by R1. "stastics <1004, 1413000; 1013, 1413000; 1020, 1413000; 1010, 1416000; 1015, <1417000>" indicates the packet information on R1. Specifically, in the first time period, the number of packets is 1004 and the number of bytes is 1413000; in the second time period, the number of packets is 1013 and the number of bytes is 1413000; in the third time period, the number of packets is 1020 and the number of bytes is 1413000; in the fourth time period, the number of packets is 1010 and the number of bytes is 1416000; in the fifth time period, the number of packets is 1015 and the number of bytes is 1417000.

[0211] Similarly, for "Response2", the input interface is Rl and the output interface is R3, thus it can be determined that the Response2 is sent by R2. "stastics <1004, 1413000; 1013, 1413000; 1020, 1413000; 1010, 1416000; 1015, <1417000>" represents the message information on R2. Specifically, in the first time period, the number of messages is 1004 and the number of bytes is 1413000; in the second time period, the number of messages is 1013 and the number of bytes is 1413000; in the third time period, the number of messages is 1020 and the number of bytes is 1413000; in the fourth time period, the number of messages is 1010 and the number of bytes is 1416000; in the fifth time period, the number of messages is 1015 and the number of bytes is 1417000.

[0212] For "Response3", the input interface is R2 and the output interface is LHRl, thus it can be determined that the Response3 is sent by R3. "stastics <1004, 1413000; 1013, 1413000; 1020, 1413000; 810, 916000; 0, 0>" represents the message information on R3. Specifically, in the first time period, the number of messages is 1004 and the number of bytes is 1413000; in the second time period, the number of messages is 1013 and the number of bytes is 1413000; in the third time period, the number of messages is 1020 and the number of bytes is 1413000; in the fourth time period, the number of messages is 810 and the number of bytes is 91600; in the fifth time period, the number of messages is 0 and the number of bytes is 0.

[0213] For "Response4", "input interface (IIF) = to R3, output interface (OIF) = to RCV" indicates that the input interface is R3 and the output interface is RCV1, and thus it can be determined that the Response4 is sent by LHR1. "stastics <1004, 1413000; 1013, 1413000; 1020, 1413000; 810, 916000; 0, 0>" indicates the packet information on LHR1. Specifically, in the first time period, the number of packets is 1004 and the number of bytes is 1413000; in the second time period, the number of packets is 1013 and the number of bytes is 1413000; in the third time period, the number of packets is 1020 and the number of bytes is 1413000; in the fourth time period, the number of packets is 810 and the number of bytes is 916000; and in the fifth time period, the number of packets is 0 and the number of bytes is 0.

[0214] Step 830: LHR1 determines the multicast fault point according to the packet statistical information on each device (e.g., R3, R2, R1, FHR) on the multicast forwarding path.

[0215] As an example, LHR1 can determine the device that causes packet loss and flow interruption according to the number of packets and the number of bytes in the packet statistical information recorded by each device (e.g., R3, R2, R1, FHR) on the multicast forwarding path, so as to more accurately detect the fault device on the multicast forwarding path and improve the efficiency and accuracy of fault detection.

[0216] Specifically, in one possible implementation, taking the statistical information received by LHR1 in step 820 as an example. The information recorded on R2 (i.e., IIF = to R1, OIF = to R3), such as the number of packets and the number of bytes, is consistent with that recorded on R1 (i.e., IIF = to FHR, OIF = to R2), and the information recorded on R3 (i.e., IIF = to R2, OIF = to LHR1), such as the number of packets and the number of bytes, is inconsistent with that recorded on R2 (i.e., IIF = to R1, OIF = to R3). For example, in the fourth time period, the number of packets recorded on R2 (i.e., IIF = to R1, OIF = to R3) is 1010 and the number of bytes is 1416000. In the fourth time period, the number of packets recorded on R3 (i.e., IIF = to R2, OIF = to LHR1) is 810 and the number of bytes is 91600. Compared with R2, the number of packets and the number of bytes recorded on R3 in the fourth time period are significantly less (e.g., the degree of reduction exceeds 5%), and thus LHR1 can determine that packet loss and flow interruption occur when R2 sends to R3.

[0217] Figure 9 is a schematic flowchart of another method for determining a multicast fault point provided by an embodiment of the present application. As shown in Figure 9 , the method can include steps 910-920, which are described in detail below respectively.

[0218] It should be understood that the application scenarios of the method shown in Figure 9 are not specifically limited by the embodiments of the present application, and can be scenarios in which the multicast routing protocol is PIM, or scenarios in which the multicast routing protocol is BGP. For specific descriptions of various scenarios, please refer to the descriptions in the foregoing text, which will not be described here again.

[0219] Step 910: The controller obtains the packet statistical information of the multicast stream recorded by each device on the multicast forwarding path.

[0220] There are various specific implementation manners. In one possible implementation manner, each device on the multicast forwarding path can actively report the packet statistical information of the multicast stream recorded by itself to the controller. In another possible implementation manner, each device on the multicast forwarding path can passively report the packet statistical information of the multicast stream recorded by itself to the controller.

[0221] Taking the case in which each device on the multicast forwarding path actively reports the packet statistical information of the multicast stream recorded by itself to the controller as an example, each device (for example, LHR, R3, R2, R1, FHR) on the multicast forwarding path can actively report the packet statistical information of the multicast stream recorded by itself to the controller at every other time interval. This active reporting can enable the controller to obtain the service running status in a longer time period by storing more traffic statistical data, for example, the controller can save the traffic statistical data of each multicast stream per 1 minute within 24 hours.

[0222] Taking the case in which each device on the multicast forwarding path passively reports the packet statistical information of the multicast stream recorded by itself to the controller as an example. For example, the controller sends a request for reporting packet statistical information to each device on the multicast forwarding path when it needs to diagnose a fault. Each device on the multicast forwarding path reports the packet statistical information of the multicast stream recorded by itself to the controller after receiving the request sent by the controller.

[0223] It should be understood that the request can be a single request, or can be multiple requests. Taking the case of a single request as an example, the controller requests each device on the multicast forwarding path once, and each device correspondingly reports the packet statistical information of the multicast stream to the controller. Taking the case of multiple requests as an example, the controller requests each device once every interval, and each device reports the packet statistical information of the multicast stream to the controller each time when it is requested.

[0224] Optionally, before step 910, the controller can also issue configuration information to each device on the multicast forwarding path, which is used to instruct the each device to perform packet statistics on the multicast stream. For example, the configuration information indicates that the time length of statistics performed by each device on the multicast forwarding path is 60 seconds, and 5 pieces of packet statistics results are recorded. The statistics results can include but are not limited to: the number of packets, the number of bytes of packets. Optionally, the statistics results also include: packet rate, packet bit rate. For details, see the description in Figure 7 , which will not be repeated here.

[0225] Specifically, taking the number of packets, the number of bytes of packets in each piece of packet statistics result as an example, the time length of statistics performed by each device on the multicast forwarding path is 60 seconds, and 5 pieces of packet statistics results are recorded. The statistics information fed back by each device on the multicast forwarding path obtained by the controller is shown as follows.

[0226]

[0227] For details of the explanation of each of the above command lines, see the description in step 810, which will not be repeated here.

[0228] Step 920: The controller determines the multicast fault point according to the packet statistics information on each device on the multicast forwarding path.

[0229] The method of determining the multicast fault point by LHR1 according to the packet statistics information in step 830 is the same. For details, see the description in step 830, which will not be repeated here.

[0230] The method of packet statistics provided by the embodiments of the present application is described in detail above in Figures 1 to 9 , and the embodiments of the device of the present application will be described in detail below in Figures 10 to 12 . It should be understood that the description of the method embodiments and the description of the device embodiments correspond to each other, and therefore, the parts not described in detail can be referred to the foregoing method embodiments.

[0231] Figure 10 is a schematic structural diagram of a first network device 1000 provided by an embodiment of the present application. Figure 10 The first network device 1000 shown can perform the corresponding steps performed by the first network device in the method of the above-described embodiments. As shown in Figure 10 , the first network device 1000 includes: a receiving module 1010, a statistics module 1020, and a determining module 1030.

[0232] It should be understood that the first network device 1000 can perform the corresponding steps performed by the first network device in the method of the above-described embodiments, for example Figure 6The first network device in the method performs corresponding steps. Specifically, the receiving module 410 can implement Figure 6 The method flow in step 610 is used for receiving the first multicast message; the statistical module 1020 can implement Figure 6 The method flow in step 620 is used for counting the features of the first multicast message in the first time interval to obtain the first statistical information; the statistical module 1020 can also implement Figure 6 The method flow in step 630 is used for counting the features of the first multicast message in the second time interval to obtain the second statistical information; the determining module 1030 can implement Figure 6 The method flow in step 640 is used for judging the first statistical information and the second statistical information, determining that the first network device has a transmission failure in the second time interval when the deviation of the first statistical information and the second statistical information is greater than a first preset threshold, or determining that the first network device has no transmission failure in the second time interval when the deviation of the first statistical information and the second statistical information is less than the first preset threshold.

[0233] Optionally, the first statistical information includes a counted time period and features of the message corresponding to the counted time period.

[0234] The second statistical information includes a counted time period and features of the message corresponding to the counted time period.

[0235] Optionally, the receiving module 1010 is further used for receiving third statistical information sent by a second network device, where the third statistical information is a count of the features of the first multicast message in the first time interval by the second network device.

[0236] The determining module 1030 is specifically used for determining that the second network device or a link between the first network device and the second network device has a transmission failure in the first time interval according to the deviation of the first statistical information and the third statistical information being greater than a second preset threshold.

[0237] Optionally, the receiving module 1010 is further used for receiving fourth statistical information sent by a second network device, where the fourth statistical information is a count of the features of the first multicast message in the second time interval by the second network device.

[0238] The determining module 1030 is specifically used for determining that the second network device or a link between the first network device and the second network device has a transmission failure in the second time interval according to the deviation of the second statistical information and the fourth statistical information being greater than a third preset threshold.

[0239] Optionally, an error between the start time of the first statistical information acquisition and the start time of the third statistical information acquisition is less than a fourth preset threshold.

[0240] Optionally, an error between the start time of the second statistical information acquisition and the start time of the fourth statistical information acquisition is less than a fifth preset threshold.

[0241] Optionally, the feature of the packet includes any one of the following information or a combination of multiple information: the number of packets, the number of bytes of the packet, the rate of the packet, and the bit rate of the packet.

[0242] Optionally, the first network device is a device for forwarding the first multicast packet in a protocol-independent multicast (PIM).

[0243] Optionally, the first network device is a device for forwarding the first multicast packet in a border gateway protocol-multicast virtual private network (BGP-MVPN) or next generation-multicast virtual private network (NG-MVPN).

[0244] Optionally, the tunnel in the NG-MVPN is established through a multipoint label distribution protocol (MLDP) protocol, the first multicast packet includes a point-to-multipoint (P2MP) label, a multicast source S, and a multicast group G,

[0245] The determining module 1030 is further configured to determine the first multicast packet according to the P2MP label, the S, and the G.

[0246] Optionally, the tunnel in the NG-MVPN is established through a bit index explicit replication (BIER) or a bit index explicit replication based on Internet Protocol version 6 (BIERv6), the first multicast packet includes a bit index forwarding table identifier (BIFT-ID) field, the S, and the G,

[0247] The determining module 1030 is further configured to determine the first multicast packet according to the BIFT-ID field, the S, and the G.

[0248] Optionally, the tunnel in the NG-MVPN is established through a BIER or a BIERv6, and the first multicast packet includes a BIFT-ID field and an entropy field.

[0249] The determining module 1030 is further configured to determine the first multicast packet according to the BIFT-ID field and the entropy field.

[0250] Figure 11 FIG. 1 is a schematic diagram of a hardware structure of a first network device 2000 according to an embodiment of the present application. Figure 11The first network device 2000 shown can execute the corresponding steps executed by the first network device in the method of the above embodiment.

[0251] like Figure 11 As shown, the first network device 2000 includes a processor 2001, a memory 2002, an interface 2003, and a bus 2004. The interface 2003 can be implemented wirelessly or wired, and can be a network card. The processor 2001, the memory 2002, and the interface 2003 are connected via the bus 2004.

[0252] It should be understood that the first network device 2000 can execute the corresponding steps executed by the first network device in the method of the above embodiment, for example, Figure 6 The corresponding steps are performed by the first network device in the method.

[0253] As an example, processor 2001 is used to: receive a first multicast message; perform statistics on the characteristics of the first multicast message within a first time interval to obtain first statistical information; perform statistics on the characteristics of the first multicast message within a second time interval to obtain second statistical information; judge the first statistical information and the second statistical information, and when it is determined that the deviation between the first statistical information and the second statistical information is greater than a first preset threshold, determine that a transmission failure occurs in the first network device within the second time interval; or when it is determined that the deviation between the first statistical information and the second statistical information is less than a first preset threshold, determine that no transmission failure occurs in the first network device within the second time interval.

[0254] Specifically, the interface 2003 in the first network device 2000 can implement Figure 6 The method flow of step 610 in the first network device 2000 is used to receive the first multicast message; the processor 2001 in the first network device 2000 can implement Figure 6 The method flow of steps 620 and 630 in the first network device 2000 is used to perform statistics on the characteristics of the first multicast message in a first time interval to obtain first statistical information; perform statistics on the characteristics of the first multicast message in a second time interval to obtain second statistical information; the processor 2001 in the first network device 2000 can also implement Figure 6 The method flow of step 640 is used to judge the first statistical information and the second statistical information. When it is determined that the deviation between the first statistical information and the second statistical information is greater than a first preset threshold, it is determined that a transmission failure occurs in the first network device within the second time interval; or when it is determined that the deviation between the first statistical information and the second statistical information is less than a first preset threshold, it is determined that no transmission failure occurs in the first network device within the second time interval.

[0255] The interface 2003 can include a transmitter and a receiver, for the first network device to implement the above-mentioned receiving and transmitting. For example, the interface 2003 is configured to receive the first multicast packet.

[0256] The processor 2001 is configured to perform the processing performed by the first network device in the above-mentioned embodiments. For example, the processor 2001 is configured to support steps 620-640 in the method 600. Figure 6 The memory 2002 includes an operating system 20021 and an application 20022, and is configured to store programs, codes or instructions, which can complete the processing process related to the first network device in the method embodiments when the processor or the hardware device executes the programs, codes or instructions. Optionally, the memory 2002 can include a read-only memory (ROM) and a random access memory (RAM). The ROM includes a basic input / output system (BIOS) or an embedded system, and the RAM includes an application and an operating system. When the first network device 2000 needs to be run, the system is started by the BIOS or the bootloader in the embedded system solidified in the ROM, and the first network device 2000 is guided to a normal operation state. After the first network device 2000 enters the normal operation state, the application and the operating system running in the RAM are executed, so that the processing process related to the first network device 2000 in the method embodiments is completed.

[0257] It can be understood that, Figure 11 Only a simplified design of the first network device 2000 is shown. In actual applications, the first network device can include any number of interfaces, processors or memories.

[0258] Figure 12 A hardware structure diagram of another first network device 2100 of the embodiments of the present application is shown. Figure 12 The first network device 2100 shown can perform the corresponding steps performed by the first network device in the method of the above-mentioned embodiments.

[0259] As Figure 12The first network device 2100 includes a main control board 2110, an interface board 2130, a switching network board 2120, and an interface board 2140. The main control board 2110, the interface boards 2130 and 2140, and the switching network board 2120 are connected to a system backboard through a system bus to realize intercommunication. The main control board 2110 is configured to complete system management, device maintenance, protocol processing, and the like. The switching network board 2120 is configured to complete data exchange between the interface boards (the interface boards are also referred to as line cards or service boards). The interface boards 2130 and 2140 are configured to provide various service interfaces (for example, a POS interface, a GE interface, an ATM interface, and the like) and implement data packet forwarding.

[0260] It should be understood that the first network device 2100 can perform the corresponding steps performed by the first network device in the methods of the above-described embodiments, for example, Figure 6 the corresponding steps performed by the first network device in the methods.

[0261] Specifically, the interface board 2130 can implement the method flow of step 610 in Figure 6 to receive the first multicast message; the main control board 2110 can implement the method flow of steps 620 and 630 in Figure 6 to perform statistics on the characteristics of the first multicast message in a first time interval to obtain first statistical information, and perform statistics on the characteristics of the first multicast message in a second time interval to obtain second statistical information; the main control board 2110 can implement the method flow of step 640 in Figure 6 to determine whether the first network device has a transmission failure in the second time interval when it is determined that the deviation between the first statistical information and the second statistical information is greater than a first preset threshold, or determine that the first network device has no transmission failure in the second time interval when it is determined that the deviation between the first statistical information and the second statistical information is less than the first preset threshold.

[0262] The interface board 2130 can include a central processor 2131, a forwarding table item storage 2134, a physical interface card 2133, and a network processor 2132. The central processor 2131 is configured to control and manage the interface board and communicate with the central processor on the main control board. The forwarding table item storage 2134 is configured to save table items. The physical interface card 2133 is configured to complete traffic reception and transmission.

[0263] It should be understood that the operations on the interface board 2140 in the embodiments of the present application are consistent with the operations of the interface board 2130, and for the sake of brevity, will not be described again. It should be understood that the first network device 2100 of the present embodiment can correspond to the functions and / or various steps implemented in the above-described method embodiments, and will not be described again here.

[0264] In addition, it should be noted that the master board can have one or more, and when there are multiple, it can include a master master board and a standby master board. The interface board can have one or more, and the stronger the data processing capability of the first network device, the more interface boards it provides. The physical interface card on the interface board can also have one or more. The switching network board can have none or one or more, and when there are multiple, they can collectively implement load sharing and redundancy. Under the centralized forwarding architecture, the first network device can not need a switching network board, and the interface board assumes the entire system's business data processing function. Under the distributed forwarding architecture, the first network device can have at least one switching network board, and data exchange between multiple interface boards is implemented through the switching network board to provide large-capacity data exchange and processing capability. Therefore, the data access and processing capability of the first network device of the distributed architecture is greater than that of the centralized architecture. Which architecture to use depends on the specific network deployment scenario, and no limitation is made here.

[0265] The embodiments of the present application also provide a computer readable medium storing program codes, which, when executed on a computer, cause the computer to perform the method in the above aspects. The computer readable storage includes, but is not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), Flash memory, electrically EPROM (EEPROM), and hard drive.

[0266] The embodiments of the present application also provide a computer program product applied in the first network device, which includes computer program codes, which, when executed on a computer, cause the computer to perform the method in any possible implementation manner of any aspect.

[0267] The embodiments of the present application also provide a chip system applied in the first network device, which includes at least one processor, at least one memory and an interface circuit, the interface circuit is responsible for information interaction between the chip system and the outside world, the at least one memory, the interface circuit and the at least one processor are interconnected through a circuit, and the at least one memory stores instructions; the instructions are executed by the at least one processor to perform the operation of the first network device in the method of the above aspects.

[0268] In the implementation process, the chip can be realized in the form of a central processing unit (CPU), a micro controller unit (MCU), a micro processing unit (MPU), a digital signal processing (DSP), a system on chip (SoC), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or a programmable logic device (PLD).

[0269] The embodiments of the present application also provide a computer program product applied to a first network device, the computer program product comprising a series of instructions, when the instructions are executed, the operations of the first network device in the methods of the various aspects described above are performed.

[0270] It should be understood that the size of the sequence number of the processes described above in various embodiments of the present application does not mean the order of execution, the execution order of the processes should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0271] Those skilled in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0272] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the system, device and unit described above can refer to the corresponding processes in the foregoing method embodiments, which will not be described here.

[0273] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic. The division of the units is merely logical function division. There can be other division manners in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, devices or units, and can be in electrical, mechanical or other forms.

[0274] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0275] In addition, each functional unit in the various embodiments of the present application can be integrated into a processing unit, or each unit can be a physically separate unit, or two or more units can be integrated into one unit.

[0276] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application can be embodied in the form of a software product, and the computer software product is stored in a storage medium, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program code storage media.

[0277] The above is merely specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method of packet statistics, characterized by, The method comprises: The first network device receives a first multicast message; The first network device performs statistics on a feature of the first multicast message in a first time interval to obtain first statistical information; The first network device performs statistics on the feature of the first multicast message in a second time interval to obtain second statistical information; The first network device judges the first statistical information and the second statistical information; When the first network device determines that a deviation of the first statistical information and the second statistical information is greater than or equal to a first preset threshold, the first network device determines that the first network device has a transmission fault in the second time interval; When the first network device determines that the deviation of the first statistical information and the second statistical information is less than the first preset threshold, the first network device determines that the first network device has no transmission fault in the second time interval; The first network device receives third statistical information sent by a second network device, wherein the third statistical information is statistics performed by the second network device on the feature of the first multicast message in the first time interval; The first network device determines that the second network device or a link between the first network device and the second network device has a transmission fault in the first time interval according to a deviation of the first statistical information and the third statistical information being greater than a second preset threshold.

2. The method of claim 1, wherein, The first statistical information comprises a statistical time period of the first statistical information and a feature of a message corresponding to the statistical time period; The second statistical information comprises a statistical time period of the second statistical information and a feature of a message corresponding to the statistical time period.

3. The method of claim 1, wherein, The method further comprises: The first network device receives fourth statistical information sent by a second network device, wherein the fourth statistical information is statistics performed by the second network device on the feature of the first multicast message in the second time interval; The first network device determines that the second network device or a link between the first network device and the second network device has a transmission fault in the second time interval according to a deviation of the second statistical information and the fourth statistical information being greater than a third preset threshold.

4. The method of claim 1, wherein, An error between a starting time of the first statistical information and a starting time of the third statistical information is less than a fourth preset threshold.

5. The method of claim 3, wherein, An error between a starting time of the second statistical information and a starting time of the fourth statistical information is less than a fifth preset threshold.

6. The method according to any one of claims 1 to 5, characterized in that, The feature of the message comprises any one information or a combination of multiple information of the following: a number of messages, a byte number of messages, a rate of messages, a bit rate of messages.

7. The method according to any one of claims 1 to 5, characterized in that, The first network device is a device for forwarding the first multicast message in a protocol-independent multicast (PIM).

8. The method according to any one of claims 1 to 5, characterized in that, The first network device is a device for forwarding the first multicast message in a border gateway protocol-multicast virtual private network (BGP-MVPN) or a next-generation-multicast virtual private network (NG-MVPN).

9. The method of claim 8, wherein, The tunnel in the NG-MVPN is established by a multi-point label distribution protocol (MLDP) protocol, the first multicast message includes a point-to-multipoint (P2MP) label, a multicast source S, and a multicast group G, The method further includes: The first network device determines the first multicast message according to the P2MP label, the multicast source S, and the multicast group G.

10. The method of claim 8, wherein, The tunnel in the NG-MVPN is established by bit index explicit replication (BIER) or BIER version 6 (BIERv6), the first multicast message includes a bit index forwarding table (BIFT) identifier (ID) field, a multicast source S, and a multicast group G, The method further includes: The first network device determines the first multicast message according to the BIFT-ID field, the multicast source S, and the multicast group G.

11. The method of claim 8, wherein, The tunnel in the NG-MVPN is established by BIER or BIERv6, the first multicast message includes a BIFT-ID field and an entropy field, The method further includes: The first network device determines the first multicast message according to the BIFT-ID field and the entropy field.

12. A first network device, comprising: It includes: A receiving module is configured to receive a first multicast message; A statistical module is configured to perform statistics on a feature of the first multicast message in a first time interval to obtain first statistical information; The statistical module is further configured to perform statistics on the feature of the first multicast message in a second time interval to obtain second statistical information; A determining module is configured to determine the first statistical information and the second statistical information; The determining module is specifically configured to determine that the first network device has a transmission fault in the second time interval when it is determined that a deviation between the first statistical information and the second statistical information is greater than a first preset threshold; or The determining module is specifically configured to determine that the first network device has no transmission fault in the second time interval when it is determined that the deviation between the first statistical information and the second statistical information is less than the first preset threshold. The receiving module is further configured to: Receive third statistical information sent by a second network device, wherein the third statistical information is statistics performed by the second network device on the feature of the first multicast message in the first time interval; The determining module is specifically configured to: Determine that the second network device or a link between the first network device and the second network device has a transmission fault in the first time interval according to the deviation between the first statistical information and the third statistical information being greater than a second preset threshold.

13. The first network device of claim 12, wherein, The first statistical information includes a time period of the statistics of the first statistical information and a feature of a message corresponding to the time period of the statistics; The second statistical information includes a time period of the statistics of the second statistical information and a feature of a message corresponding to the time period of the statistics.

14. The first network device of claim 12, wherein, The receiving module is further configured to: Receive fourth statistical information sent by a second network device, wherein the fourth statistical information is statistics performed by the second network device on the feature of the first multicast message in the second time interval; The determining module is specifically configured to: determine that a link between the second network device or the first network device and the second network device has a transmission failure in the second time interval according to the deviation between the second statistical information and the fourth statistical information being greater than a third preset threshold.

15. The first network device of claim 12, wherein, An error between a starting time of acquisition of the first statistical information and a starting time of acquisition of the third statistical information is less than a fourth preset threshold.

16. The first network device of claim 14, wherein, An error between a starting time of acquisition of the second statistical information and a starting time of acquisition of the fourth statistical information is less than a fifth preset threshold.

17. The first network device according to any of claims 12 to 16, wherein, The features of the packet include any one information or a combination of multiple information of the following: a number of packets, a byte number of the packet, a rate of the packet, and a bit rate of the packet.

18. The first network device according to any one of claims 12 to 16, wherein, The first network device is a device for forwarding the first multicast packet in a protocol-independent multicast (PIM).

19. The first network device according to any one of claims 12 to 16, wherein, The first network device is a device for forwarding the first multicast packet in a border gateway protocol-multicast virtual private network (BGP-MVPN) or next-generation-multicast virtual private network (NG-MVPN).

20. The first network device of claim 19, wherein, The tunnel in the NG-MVPN is established through a multipoint label distribution protocol (MLDP) protocol, the first multicast packet includes a point-to-multipoint (P2MP) label, a multicast source S, and a multicast group G, The determining module is further configured to determine the first multicast packet according to the P2MP label, the multicast source S, and the multicast group G by the first network device.

21. The first network device of claim 19, wherein, The tunnel in the NG-MVPN is established through bit index explicit replication (BIER) or bit index explicit replication version 6 (BIERv6), the first multicast packet includes a bit index forwarding table identifier (BIFT-ID) field, a multicast source S, and a multicast group G, The determining module is further configured to determine the first multicast packet according to the BIFT-ID field, the multicast source S, and the multicast group G.

22. The first network device of claim 19, wherein, The tunnel in the NG-MVPN is established through BIER or BIERv6, the first multicast packet includes a BIFT-ID field and an entropy field, The determining module is further configured to determine the first multicast packet according to the BIFT-ID field and the entropy field.

23. A first network device, comprising: comprising: a processor and a memory, the memory being configured to store a program or code, and the processor being configured to call and run the program from the memory to execute the method in any one of claims 1 to 11.

24. A computer-readable storage medium, characterized in that, comprising a computer program or code, when the computer program or code is run on a computer, causing the computer to execute the method in any one of claims 1 to 11.

Images