Statistical Method, Device and System for BIER Multicast Traffic

Abstract

The present application provides a method, device, and system for statistically analyzing BIER multicast traffic. The method includes: a first network device obtains a first BIER packet; the first network device performs traffic statistics on the first BIER packet according to multicast flow information, and obtains a traffic statistics result of the first BIER packet, where the multicast flow information is used to identify the multicast flow to which the first BIER packet belongs; the first network device sends the multicast flow information and the traffic statistics result of the first BIER packet to a controller. The technical solution provided by the present application can perform statistics on BIER multicast traffic.

Description

[0001] This application claims the priority of a Chinese patent application with the application number 202010511126.0 and the invention title "A Multicast Traffic Statistics Method, Device and System", which was filed with the Chinese Patent Office on June 5, 2020. The entire content of the Chinese patent application is incorporated herein by reference. Technical Field

[0002] This application relates to the field of network communication, and more particularly, to a method, device, and system for counting BIER multicast traffic. Background Art

[0003] The Internet Protocol (IP) multicast technology realizes efficient data transmission from a point to multiple points in the IP network, which can effectively save network bandwidth and reduce network load. For this reason, the industry has proposed a new technology for constructing a multicast data forwarding path, called the Bit Indexed Explicit Replication (BIER) technology, which proposes a new multicast technology architecture that does not require the construction of a multicast distribution tree.

[0004] The BIER technology performs multiple unicast forwards based on the bitstring in the BIER packet step by step on different devices in the network according to the bit identifier to achieve the purpose of replicating to multiple receivers. The bit index forwarding table (BIFT) entry of the network device in the BIER domain provides forwarding guidance for any multicast flow using BIER forwarding, without distinguishing between multicast flows. Therefore, this BIER-based forwarding makes it difficult for network devices in the BIER domain to count multicast flows.

[0005] Therefore, how network devices in the BIER domain perform BIER multicast traffic has become a technical problem that urgently needs to be solved. Summary of the Invention

[0006] This application provides a method, device, and system for counting Bit Indexed Explicit Replication (BIER) multicast traffic, which can count BIER multicast traffic.

[0007] In a first aspect, a method for statistically analyzing explicit copy BIER multicast traffic based on bit indexing is provided, including: a first network device obtains a first BIER packet; the first network device performs traffic statistics on the first BIER packet according to multicast flow information, and obtains a traffic statistics result of the first BIER packet, where the multicast flow information is used to identify the multicast flow to which the first BIER packet belongs; the first network device sends the multicast flow information and the traffic statistics result of the first BIER packet to a controller.

[0008] In the above technical solution, the first network device can perform statistics on BIER multicast traffic, which can solve the problem that BIER multicast service traffic cannot be statistically analyzed, and the controller can effectively locate lost or interrupted data packets based on the multicast traffic statistics data.

[0009] In a possible implementation manner, the first network device is an ingress device of a BIER domain. Before the first network device obtains the first BIER packet, the method further includes: the first network device performs BIER encapsulation on the first multicast data according to a traffic statistics instruction, and obtains the first BIER packet. The traffic statistics instruction includes a multicast source group (S, G) of the first multicast data, and the traffic statistics instruction is used to indicate traffic statistics on the first multicast data including the multicast source group (S, G).

[0010] It should be understood that the above traffic statistics instruction may be sent by the controller to the first network device, or may also be directly configured on the first network device according to a command line.

[0011] In another possible implementation manner, the method further includes: the first network device generates a first correspondence, where the first correspondence is a correspondence between the multicast source group (S, G) of the first multicast data and the multicast flow information; the first network device sends the first correspondence to the controller.

[0012] In the above technical solution, the controller can map the first BIER packet to the multicast source group (S, G) of the first multicast data based on the first correspondence, the multicast flow information sent by the first network device, and the traffic statistics result of the first BIER packet, and perform traffic statistics on the multicast source group (S, G) of the first multicast data based on the traffic statistics result.

[0013] In another possible implementation manner, the first network device is an intermediate forwarding device or an egress device of a BIER domain. Before the first network device performs traffic statistics on the first BIER packet, the method further includes: the first network device determines to perform traffic statistics on the first BIER packet.

[0014] In another possible implementation, the first network device receives first indication information sent by the controller, where the first indication information includes the multicast flow information, and the first indication information is used to indicate traffic statistics on the first BIER packet; the first network device determines to perform traffic statistics on the first BIER packet according to the first indication information.

[0015] In the above technical solution, the first network device can directly perform traffic statistics on the first BIER packet according to the first indication information sent by the controller.

[0016] In another possible implementation, the multicast flow information includes any one of the following:

[0017] The bit forwarding ingress router identifier BFIR-ID and the entropy label in the BIER header of the first BIER packet;

[0018] The source address SA and the flow label in the outer Internet Protocol version 6 IPv6 header of the first BIER packet;

[0019] The multicast source group (S, G) of the first multicast data in the inner layer of the first BIER packet;

[0020] The virtual private network multicast source group (VPN, S, G) of the first multicast data in the inner layer of the first BIER packet.

[0021] In another possible implementation, a traffic statistics identifier is carried in the first BIER packet, and the traffic statistics identifier is used to indicate traffic statistics on the first BIER packet, and the first network device determines to perform traffic statistics on the first BIER packet according to the traffic statistics identifier.

[0022] In the above technical solution, the first controller does not need to send indication information to the intermediate forwarding device or the egress device in the BIER domain. The intermediate forwarding device or the egress device in the BIER domain can determine whether to perform traffic statistics on the first BIER packet based on whether the traffic statistics identifier is carried in the first BIER packet. In this way, the configuration complexity can be reduced.

[0023] In another possible implementation, the traffic statistics identifier is carried in the first field of the first BIER packet.

[0024] In another possible implementation, the first field is an operation, administration, and maintenance OAM field, a reserved Rsv field, or a field in the BIER extension header.

[0025] In another possible implementation, the first BIER packet further includes a second field, where the second field indicates that the traffic statistics identifier is carried in the first field, and the method further includes: the first network device obtaining the traffic statistics identifier in the first field according to the second field.

[0026] In another possible implementation, the method further includes: the first network device obtaining interface information of the first BIER packet; the first network device sending the interface information of the first BIER packet to the controller.

[0027] In the above technical solution, the controller can also restore the service path based on the interface information of the first BIER packet, and restore the traffic statistics result of the source group (S, G) of the first multicast data corresponding to the first BIER packet to the service path. The controller can judge whether there is packet loss or disconnection of the multicast flow according to the traffic analysis of the multicast flow on the service path. If there are such fault conditions, it can assist the user to delimit and locate the fault point. For example, it can assist the user to delimit and locate the fault point by means of alarming and comparing with upstream and downstream devices.

[0028] In a second aspect, a method for statistically analyzing explicit replication BIER multicast traffic based on bit index is provided, including: the controller receiving multicast flow information sent by a first network device in a BIER domain and the traffic statistics result of a first BIER packet, where the multicast flow information is used to identify the multicast flow to which the first BIER packet belongs; the controller performing traffic analysis on the first BIER packet according to the multicast flow information and the traffic statistics result of the first BIER packet.

[0029] In a possible implementation, the first network device is an ingress device in the BIER domain. Before the controller receives the multicast flow information and the traffic statistics result of the first BIER packet sent by the first network device, the method further includes: the controller sending a traffic statistics instruction to the first network device, where the traffic statistics instruction includes the source group (S, G) of the first multicast data, and the traffic statistics instruction is used to instruct the first network device to perform traffic statistics on the first BIER packet including the source group (S, G).

[0030] In another possible implementation, before the controller receives the multicast flow information and the traffic statistics result of the first BIER packet sent by the first network device, the method further includes: the controller receiving a first correspondence relationship sent by the first network device, where the first correspondence relationship is the correspondence relationship between the source group (S, G) of the first multicast data and the multicast flow information.

[0031] In another possible implementation, the multicast flow information includes any one of the following:

[0032] The bit forwarding ingress router identifier BFIR-ID and the entropy label in the BIER header of the first BIER packet;

[0033] The source address SA and the flow label in the outer Internet Protocol version 6 IPv6 header of the first BIER packet;

[0034] The multicast source group (S, G) of the first multicast data in the inner layer of the first BIER packet;

[0035] The virtual private network multicast source group (VPN, S, G) of the first multicast data in the inner layer of the first BIER packet.

[0036] In another possible implementation, the first network device is an intermediate forwarding device or an egress device in the BIER domain, and the method further includes: the controller sends first indication information to the first network device, the first indication information includes the multicast flow information, and the first indication information is used to instruct the first network device to perform traffic statistics on the first BIER packet.

[0037] In another possible implementation, the method further includes: the controller receives the interface information of the first BIER packet sent by the first network device; the controller determines the transmission path of the first BIER packet according to the interface information of the first BIER packet and the physical topology information.

[0038] The beneficial effects of the second aspect and any possible implementation of the second aspect correspond to those of the first aspect and any possible implementation of the first aspect, and thus will not be elaborated herein.

[0039] In a third aspect, a first network device is provided, including:

[0040] A processing module, configured to obtain a first BIER packet;

[0041] The processing module is further configured to perform traffic statistics on the first BIER packet according to the multicast flow information to obtain a traffic statistics result of the first BIER packet, where the multicast flow information is used to identify the multicast flow to which the first BIER packet belongs;

[0042] A sending module, configured to send the multicast flow information and the traffic statistics result of the first BIER packet to a controller.

[0043] In a possible implementation, the first network device is an ingress device of the BIER domain,

[0044] The processing module is further configured to perform BIER encapsulation on the first multicast data according to a traffic statistics instruction, to obtain the first BIER packet. The traffic statistics instruction includes a multicast source group (S, G) of the first multicast data, and the traffic statistics instruction is used to indicate traffic statistics on the first multicast data including the multicast source group (S, G).

[0045] In another possible implementation, the first network device further includes: a processing module, further configured to generate a first correspondence, where the first correspondence is a correspondence between the multicast source group (S, G) of the first multicast data and the multicast flow information;

[0046] The sending module is further configured to: send the first correspondence to the controller.

[0047] In another possible implementation, the first network device is an intermediate forwarding device or an egress device in a BIER domain, and the processing module is further configured to determine traffic statistics on the first BIER packet.

[0048] In another possible implementation, the first network device further includes:

[0049] a receiving module, configured to receive first indication information sent by the controller, where the first indication information includes the multicast flow information, and the first indication information is used to indicate traffic statistics on the first BIER packet;

[0050] The processing module is specifically configured to: determine traffic statistics on the first BIER packet according to the first indication information.

[0051] In another possible implementation, the multicast flow information includes any one of the following:

[0052] a bit forwarding ingress router identifier BFIR-ID and an entropy label in the BIER header of the first BIER packet;

[0053] a source address SA and a flow label in the outer Internet Protocol version 6 (IPv6) header of the first BIER packet;

[0054] the multicast source group (S, G) of the first multicast data in the inner layer of the first BIER packet;

[0055] the virtual private network multicast source group (VPN, S, G) of the first multicast data in the inner layer of the first BIER packet.

[0056] In another possible implementation, a traffic statistics identifier is carried in the first BIER packet, and the traffic statistics identifier is used to indicate traffic statistics for the first BIER packet. Specifically, the processing module is configured to: determine to perform traffic statistics on the first BIER packet according to the traffic statistics identifier.

[0057] In another possible implementation, the traffic statistics identifier is carried in a first field of the first BIER packet.

[0058] In another possible implementation, the first field is an operation, administration, and maintenance (OAM) field, a reserved (Rsv) field, or a field in a BIER extension header.

[0059] In another possible implementation, the first BIER packet further includes a second field, and the second field indicates that the traffic statistics identifier is carried in the first field. The processing module is further configured to obtain the traffic statistics identifier in the first field according to the second field.

[0060] In another possible implementation, the processing module is further configured to obtain interface information of the first BIER packet; the sending module is further configured to: send the interface information of the first BIER packet to the controller.

[0061] Fourthly, a controller is provided, including:

[0062] a receiving module, configured to receive multicast flow information sent by a first network device in a BIER domain and a traffic statistics result of a first BIER packet, where the multicast flow information is used to identify a multicast flow to which the first BIER packet belongs;

[0063] a processing module, configured to perform traffic analysis on the first BIER packet according to the multicast flow information and the traffic statistics result of the first BIER packet.

[0064] In a possible implementation, the first network device is an ingress device in the BIER domain, and the controller further includes: a sending module, configured to send a traffic statistics instruction to the first network device, where the traffic statistics instruction includes a source group (S, G) of a first multicast data, and the traffic statistics instruction is used to instruct the first network device to perform traffic statistics on the first BIER packet including the source group (S, G).

[0065] In another possible implementation, the receiving module is further configured to: receive a first correspondence sent by the first network device, where the first correspondence is a correspondence between the source group (S, G) of the first multicast data and the multicast flow information

[0066] In another possible implementation, the multicast flow information includes any one of the following:

[0067] The bit forwarding ingress router identifier BFIR-ID and the entropy label in the BIER header of the first BIER packet;

[0068] The source address SA and the flow label in the outer Internet Protocol version 6 IPv6 header of the first BIER packet;

[0069] The multicast source group (S, G) of the first multicast data in the inner layer of the first BIER packet;

[0070] The virtual private network multicast source group (VPN, S, G) of the first multicast data in the inner layer of the first BIER packet.

[0071] In another possible implementation, the first network device is an intermediate forwarding device or an egress device in the BIER domain, and the controller further includes: a sending module, configured to send first indication information to the first network device, where the first indication information includes the multicast flow information, and the first indication information is used to instruct the first network device to perform traffic statistics on the first BIER packet.

[0072] In another possible implementation, the receiving module is further configured to: receive the interface information of the first BIER packet sent by the first network device;

[0073] The processing module is further configured to determine the transmission path of the first BIER packet according to the interface information of the first BIER packet and the physical topology information.

[0074] In a fifth aspect, a first network device is provided, and the first network device has a function of implementing the behavior of the first network device in the above method. The function can be implemented based on hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0075] In a possible design, the structure of the first network device includes a processor and an interface, and the processor is configured to support the first network device to execute the corresponding functions in the above method. The interface is used to support the first network device to receive the first BIER packet, or to support sending the multicast flow information and the traffic statistics result of the first BIER packet to the controller.

[0076] The first network device may further include a memory, and the memory is used to be coupled with the processor and store necessary program instructions and data of the first network device.

[0077] 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 respectively coupled to the transmitter, the receiver, the random access memory, and the read-only memory through the bus. When the first network device needs to be run, it is started by the basic input / output system solidified in the read-only memory or the bootloader boot system in the embedded system to guide the first network device into a normal operating state. After the first network device enters the normal operating state, the application program and the 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.

[0078] In a sixth aspect, a first network device is provided, the first network device comprising: a main control board and an interface board, and further, a switching network board. The first network device is used to execute the method in the first aspect or any possible implementation of the first aspect. Specifically, the first network device includes a module for executing the method in the first aspect or any possible implementation of the first aspect.

[0079] In the seventh aspect, a first network device is provided, the first network device includes a control module and a first forwarding sub-device. The first forwarding sub-device includes: an interface board, and further, may also include a switching network board. The first forwarding sub-device is used to perform the function of the interface board in the sixth aspect, and further, may also perform the function of the switching network board in the sixth aspect. The control module includes a receiver, a processor, a transmitter, a random access memory, a read-only memory and a bus. Among them, the processor is respectively coupled to the receiver, the transmitter, the random access memory and the read-only memory through the bus. Among them, when it is necessary to run the control module, it is started by the basic input / output system solidified in the read-only memory or the bootloader boot system in the embedded system, and the control module is guided to enter a normal operating state. After the control module enters the normal operating state, the application program and the operating system are run in the random access memory, so that the processor performs the function of the main control board in the sixth aspect.

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

[0081] In an eighth aspect, a controller is provided, wherein the controller has the function of implementing the controller behavior in the above method. The function can be implemented based on hardware, or can be implemented based on hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0082] In a possible design, the structure of the controller includes a processor and an interface. The processor is configured to support the controller in performing the corresponding functions in the above method. The interface is used to support the controller in receiving the multicast flow information and the traffic statistics result of the first BIER packet sent by the first network device in the BIER domain, or is used to support the controller in sending a traffic statistics instruction to the first network device, or is used to support the controller in receiving the first correspondence sent by the first network device.

[0083] The controller may further include a memory, which is used to be coupled with the processor and stores the necessary program instructions and data of the controller.

[0084] In another possible design, the controller includes: a processor, a transmitter, a receiver, a random access memory, a read-only memory, and a bus. Among them, the processor is respectively coupled to the transmitter, the receiver, the random access memory, and the read-only memory through the bus. Among them, when the controller needs to run, it is started through the basic input / output system solidified in the read-only memory or the bootloader in the embedded system to boot the controller into the normal running state. After the controller enters the normal running state, the application program and the operating system are run in the random access memory, so that the processor executes the method in the second aspect or any possible implementation manner of the second aspect.

[0085] It can be understood that in practical applications, the controller may include any number of interfaces, processors, or memories.

[0086] In a ninth aspect, a computer program product is provided, which includes: computer program code, when the computer program code runs on a computer, it causes the computer to execute the method in the first aspect or any possible implementation manner of the first aspect.

[0087] In a tenth aspect, a computer program product is provided, which includes: computer program code, when the computer program code runs on a computer, it causes the computer to execute the method in the second aspect or any possible implementation manner of the second aspect.

[0088] In the eleventh aspect, a computer-readable medium is provided. The computer-readable medium stores program code, which, when run on a computer, causes the computer to execute the method according to the first aspect or any possible implementation of the first aspect. These computer-readable storage media include, but are not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), Flash memory, electrically erasable PROM (EEPROM), and hard drive.

[0089] In the twelfth aspect, a computer-readable medium is provided. The computer-readable medium stores program code, which, when run on a computer, causes the computer to execute the method according to the second aspect or any possible implementation of the second aspect. These computer-readable storage media include, but are not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), Flash memory, electrically erasable PROM (EEPROM), and hard drive.

[0090] In the thirteenth aspect, a chip is provided. The chip includes a processor and a data interface. The processor reads instructions stored in a memory through the data interface to execute the method according to the first aspect or any possible implementation of the first aspect. In a specific implementation process, the chip can be implemented in the form of a central processing unit (CPU), a microcontroller unit (MCU), a microprocessing unit (MPU), a digital signal processor (DSP), a system on chip (SoC), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or a programmable logic device (PLD).

[0091] In a fourteenth aspect, a chip is provided, which includes a processor and a data interface. The processor reads instructions stored in a memory through the data interface to execute the method in the second aspect or any possible implementation manner of the second aspect. In a specific implementation process, the chip may 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).

[0092] In a fifteenth aspect, a system is provided, which includes the above-mentioned first network device and a controller. Description of the Drawings

[0093] Figure 1 It is a schematic networking diagram of a BIER technology provided by an embodiment of the present application.

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

[0095] Figure 3 It is a schematic block diagram of another possible BIER header format.

[0096] Figure 4 It is a process of establishing a BIER forwarding table and forwarding BIER packets based on the BIER technology.

[0097] Figure 5 It is a schematic diagram of the packet format of a possible BIERv6 encapsulation provided by an embodiment of the present application.

[0098] Figure 6 It is a schematic flowchart of a method for counting BIER multicast traffic provided by an embodiment of the present application.

[0099] Figure 7 It is a schematic flowchart of another method for counting BIER multicast traffic provided by an embodiment of the present application.

[0100] Figure 8It is a schematic flowchart of another method for counting BIER multicast traffic provided by an embodiment of the present application.

[0101] Figure 9 It is a schematic structural diagram of a first network device 900 provided by an embodiment of the present application.

[0102] Figure 10 It is a schematic structural diagram of a controller 1000 provided by an embodiment of the present application.

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

[0104] Figure 12 It is a schematic hardware structure diagram of another first network device 2100 according to an embodiment of the present application.

[0105] Figure 13 It is a schematic hardware structure diagram of a controller 2200 according to an embodiment of the present application. Detailed implementation manners

[0106] Next, the technical solutions in the present application will be described with reference to the accompanying drawings.

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

[0108] In addition, in the embodiments of the present application, words such as "exemplary" and "for example" are used to represent examples, illustrations or explanations. Any embodiment or design solution described as "exemplary" in the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Exactly speaking, the use of the word "exemplary" is intended to present concepts in a specific way.

[0109] In the embodiments of the present application, "corresponding" and "corresponding" can sometimes be used interchangeably. It should be noted that when the difference is not emphasized, the meanings they express are the same.

[0110] The network architecture and service scenarios described in the embodiments of the present application are for more clearly explaining 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 of ordinary skill in the art know that with the evolution of the network architecture and the emergence of new service scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

[0111] References to "one embodiment" or "some embodiments" or the like described in this specification mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, the phrases "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "comprising", "including", "having" and their variants mean "including but not limited to", unless otherwise specifically emphasized.

[0112] In this application, "at least one" means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships may exist. For example, A and / or B may represent: including the case where A exists alone, the case where A and B exist simultaneously, and the case where B exists alone, where A and B may be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after. "At least one (item)" or a similar expression thereof refers to any combination of these items, including any combination of single item (s) or plural items (s). For example, at least one (item) of a, b, or c may represent: a, b, c, a - b, a - c, b - c, or a - b - c, where a, b, and c may be single or multiple.

[0113] Multicast is a data transmission method that efficiently sends data to multiple receivers on a Transmission Control Protocol (TCP) / Internet Protocol (IP) network at the same time by using a multicast address. The multicast source sends a multicast stream to the multicast group members in the multicast group via a link in the network, and all the multicast group members in the multicast group can receive this multicast stream. The multicast transmission method realizes a point - to - multi - point 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 replicated when a branch appears on the link. Therefore, the multicast transmission method improves the data transmission efficiency and reduces the possibility of congestion in the backbone network.

[0114] Internet Protocol (IP) multicast technology enables efficient point-to-multipoint data transmission in IP networks, effectively saving network bandwidth and reducing network load. Therefore, it has extensive applications in many aspects such as real-time data transmission, multimedia conferencing, data copying, Internet Protocol Television (IPTV), gaming, and simulation. This multicast technology uses multicast protocols to construct a control plane multicast tree, and then uses the multicast tree to logically treeify the network plane to achieve multicast point-to-multipoint data forwarding. Intermediate devices with the construction of the distribution tree as the core need to maintain complex multicast forwarding information states. In the case of an increasingly large network scale and growing multicast data traffic, this multicast technology faces increasing challenges in terms of cost and operation and maintenance.

[0115] Therefore, the industry has proposed a new technology for constructing multicast data forwarding paths, called Bit Index Explicit Replication (BIER) technology, which proposes a multicast technology architecture that does not require the construction of a multicast distribution tree. As Figure 1 shown, a router that supports BIER technology is called a Bit-forwarding router (BFR), and this BFR can receive and forward BIER packets. A multicast forwarding domain composed of one or more of the above BFRs is called a BIER domain. At the entrance of the BIER domain, the BFR that performs BIER encapsulation on the original multicast data packet is called the bit forwarding ingress router (BFIR). At the exit of the BIER domain, the BFR that decapsulates the original multicast data packet from the BIER packet is called the bitforwarding egress router (BFER). It should be understood that the BFIR and BFER in the BIER domain can be called the edge BFRs in the BIER domain.

[0116] For the convenience of understanding, the following combines Figures 2 - 5 to describe the related technologies of BIER in detail first.

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

[0118] In the embodiments of this application, when the original multicast data packet needs to be transmitted in the BIER domain, a specific BIER header needs to be additionally encapsulated. All destination devices of the original multicast data packet are marked in the BIER header through the bit string. The BFR in the BIER domain can forward according to the bit index forwarding table (BIFT) and the bit string carried in the BIER header to ensure that the original multicast data packet can be sent to all destination addresses.

[0119] It should be noted that the destination devices of the original multicast data packet in this application can be a set of multiple BFERs. For the sake of easy description, the set of multiple BFERs to which the original multicast data packet needs to be sent is hereinafter referred to as the destination device.

[0120] It should be understood that the original multicast data packet following the BIER header can be an Internet Protocol Version 6 (IPv6) multicast packet, or it can also be an Internet Protocol Version 4 (IPv4) multicast packet. This application does not make specific limitations.

[0121] There can be multiple types of BIER encapsulation, and this application does not make specific limitations. As an example, the BIER packet can be encapsulated through multi-protocol label switching (MPLS), and this encapsulation can be called BIER-MPLS encapsulation. As another example, the BIER packet can be encapsulated based on Internet Protocol Version 6 (IPv6), and this encapsulation can be called BIERv6 encapsulation.

[0122] The following combines Figures 2 - 4 , and details the related technologies of BIER-MPLS encapsulation.

[0123] The embodiments of this application do not specifically limit the BIER header format, as long as the BIER header contains a bitstring field. The following will respectively combine Figures 2 - 3 to describe two possible BIER header formats in detail.

[0124] Figure 2 is a schematic block diagram of a possible BIER header format. As Figure 2 shown, the BIER header may include but is not limited to: a 20-bit bit index forwarding table identifier (BIFT ID), a bit string length (BSL), and a 64-bit (8-byte) other field. For example, the traffic class (TC), 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. of the original multicast data packet behind the BIER header.

[0125] The following will respectively describe the fields in the BIER header in detail.

[0126] (1) BIFT ID field

[0127] With a length of 20 bits, under the BIER - multi protocol label switching (MPLS) encapsulation, it is an MPLS label (L). This MPLS label can be called a BIER label, and the subsequent TC / S / TTL and other fields are in the standard label encoding format. The TC / S / TTL and other fields will be described separately below and will not be elaborated here for the time being.

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

[0129] It should be understood that different BIFT IDs can map to different SD / BSL / SI combinations. In Figure 2 the BIER header format shown, the SD / BSL / SI fields are not directly included. SD / BSL / SI are three implicit fields, and the values of SD / BSL / SI need to be mapped according to the BIFT ID field.

[0130] 1. Sub-domain (SD)

[0131] A BIER domain can be divided and configured into different sub-domains SD according to the requirements of the actual service scenario to support features such as interior gateway protocol (IGP) multi-topology. Each BIER domain must contain at least one sub-domain, that is, the default sub-domain 0. When multiple sub-domains are divided, each BFR router in the BIER domain must be configured with all sub-domains. For example, a sub-domain 0 can be configured on each BFR router in the BIER domain to use the system default topology, and then a sub-domain 1 can be configured to use the multicast topology.

[0132] Each sub-domain SD is represented by a sub-domain identifier (SD-ID). For example, the value range of SD-ID is [0 - 255], and the length is 8 bits. As an example, according to the differences in virtual private networks (VPNs), the BIER domain can be configured with different SDs, and different VPNs can be configured to use different SDs. For example, VPN 1 uses SD 0, and VPN 2 uses SD 1.

[0133] It should be noted that multiple VPNs can also use the same SD. Different SDs in the BIER domain can be in one interior gateway protocol (IGP) process or topology, or not in one IGP process or topology. The embodiments of the present application do not make specific limitations on this.

[0134] 2. Bit string length (BSL)

[0135] BSL is the length of the bit string included in the BIER header. There can be multiple BSLs, which are not specifically limited in the embodiments of this application. The minimum BSL is 64 bits, and the BSL can also be 128 bits, 256 bits, 512 bits, 1024 bits, 2048 bits in sequence, 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.

[0136] 3. Set identifier (SI)

[0137] If the number of BFER devices in the network is greater than 256, to adapt to this situation, the BIER encapsulation not only contains a BitString, but also contains a set identifier (SI). The role of SI is to divide the numbers of BIER devices into multiple different intervals, so as to support larger-scale network addressing.

[0138] SI can be understood as a set composed of multiple edge BFRs or configured BFR IDs in the network. As an example, the BSL is 256 bits, but there are more than 256 edge BFRs in the network, or there are more than 256 configured BFR IDs, then these edge BFRs or BFR IDs need to be divided into different sets. For example, 256 edge BFRs with BFR ID from 1 to 256 are set 0 (set index 0, or SI = 0), and 256 edge BFRs with BFR ID from 257 to 512 are set 1 (set index 1, or SI = 1).

[0139] After receiving the BIER message, the BFR in the BIER domain can determine which SD the BIER message belongs to, the BSL used, and the set to which the message belongs in the BSL according to the BIFT ID in the BIER header.

[0140] The following lists several possible combinations of SD / BSL / SI represented by BIFT IDs.

[0141] BIFT ID = 1: corresponding to SD 0, BSL 256, SI 0 / / equivalent to SD 0 / BSL 256 / SI0

[0142] BIFT ID = 2: corresponding to SD 0, BSL 256, SI 1 / / equivalent to SD 0 / BSL 256 / SI1

[0143] BIFT ID = 3: corresponding to SD 0, BSL 256, SI 2 / / equivalent to SD 0 / BSL 256 / SI2

[0144] BIFT ID = 4: corresponding to SD 0, BSL 256, SI 3 / / equivalent to SD 0 / BSL 256 / SI3

[0145] BIFT ID = 5: corresponding to SD 0, BSL 512, SI 0 / / equivalent to SD 0 / BSL 512 / SI0

[0146] BIFT ID = 6: corresponding to SD 0, BSL 512, SI 1 / / equivalent to SD 0 / BSL 512 / SI1

[0147] BIFT ID = 7: corresponding to SD 1, BSL 256, SI 0 / / equivalent to SD 1 / BSL 256 / SI0

[0148] BIFT ID = 8: corresponding to SD 1, BSL 256, SI 1 / / equivalent to SD 1 / BSL 256 / SI1

[0149] BIFT ID = 9: corresponding to SD 1, BSL 256, SI 2 / / equivalent to SD 1 / BSL 256 / SI2

[0150] BIFT ID = 10: corresponding to SD 1, BSL 256, SI 3 / / equivalent to SD 1 / BSL 256 / SI3

[0151] BIFT ID = 11: corresponding to SD 1, BSL 512, SI 0 / / equivalent to SD 1 / BSL 512 / SI0

[0152] BIFT ID = 12: corresponding to SD 1, BSL 512, SI 1 / / equivalent to SD 1 / BSL 512 / SI1

[0153] It should be noted that the BIFT ID field value corresponds to a triple of <SD, BSL, SI>. Through the BIFT-id field, the unique <SD, BSL, SI> information can be obtained. It has the following functions: obtaining the length of the BitString in the BIER header through BSL, so as to know the length of the entire BIER header; knowing whether the BitString represents BFR-ID from 1 to 256 or 257 to 512, etc. through BSL and SI information; finding the corresponding forwarding table through SD information.

[0154] (2) Bit string field

[0155] 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 the right to the left in the bit string is used to identify the BFER with BFR-ID = 2. The forwarding table entry based on which the forwarding plane forwards is determined by the bit string in the packet to decide which BFERs the packet should be sent to. When the BFR in the BIER domain receives a packet containing the BIER header, it forwards the BIER packet according to the bitstring carried in the BIER header and the BIFT ID.

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

[0157] Taking BIFT ID = 2 as an example, after the BFR receives the BIER packet, it can obtain that the BIER packet belongs to SD 0 according to the BIFTID in the BIER header. The BSL used in the BIER header is 256 bits and it belongs to set 1 (a set of 256 edge BFRs with BFR IDs from 257 to 512).

[0158] (3) Traffic class (TC) field

[0159] Identifies the priority of the packet.

[0160] (4) Stack (S)

[0161] S is the stack bottom marker, and the value of this marker in the BIER header is 1, that is, this MPLS label is the bottom label of the entire label stack.

[0162] (5) Version (Ver) field

[0163] It is 4 bits in length and is the IP version number. A value of 4 represents IPv4, and a value of 6 represents IPv6.

[0164] (6) Entropy field

[0165] It is used for load sharing. BIER forwarding may perform equal-cost load sharing. In this case, load sharing must select the same path for two BIER packets with the same Entropy and BitString. That is to say, the entropy of multiple packets belonging to one flow is the same, and the entropy of multiple packets of different flows is different. When a packet is forwarded, different flows can be distributed to different links according to the entropy, while multiple packets of the same flow follow the same link.

[0166] To ensure that different entropies identify different flows, when allocating entropy in a BFIR device, it is required to allocate different entropy labels based on different flows without repetition.

[0167] (7) Protocol (proto) field

[0168] It is used to identify the payload format behind the BIER packet header. For example, values 4 and 6 represent IPv4 packets and IPv6 packets respectively, and value 2 represents an MPLS packet with an upstream sub-label, which is a proto value used in multicast virtual private network (MVPN) over BIER. The reason for using an upstream label is that multicast is a point-to-multipoint transmission. The sender provider edge (PE) device can allocate a unique label and send it to the receiver PE device through the control plane. The data packet uses the label allocated by the sender PE device and is identified at the receiver PE device. For the receiver PE device, this label is not allocated by itself but by the sender PE device, which is called an upstream label.

[0169] (8) Nibble

[0170] It is a 4-bit fixed value of 0101. This field is used to distinguish the services carried by MPLS and to differentiate BIER, IPv4, and IPv6. Because in MPLS encapsulation and forwarding, sometimes the IPv4 or IPv6 header behind the label stack is checked to support ECMP.

[0171] (9) BFIR-id

[0172] The BFR-ID of BFIR. When the BFIR device uses sub-domain encapsulation to send BIER packets, the BFIR-id field needs to fill in the BFR-ID of the device under the sub-domain. The BFIR-id can identify from which BFIR the multicast flow is sent to uniquely determine a multicast flow.

[0173] (10)bit string

[0174] The destination device set string of the BIER packet.

[0175] Figure 3 It is a schematic block diagram of another possible BIER header format. Compared with Figure 2 the BIER header format shown, Figure 3 the BIER header format shown does not contain the BIFT-ID field, but shows the inclusion of three fields: SD / BSL / SI. That is to say, Figure 3 the BIER header format shown directly contains the three fields of SD / BSL / SI, without having to map the values of SD / BSL / SI from the BIFT ID field.

[0176] It should be noted that Figure 3 the fields included in the BIER header format shown are similar to the fields included in Figure 2 the BIER header format shown. For the specific descriptions of each field in Figure 3 the BIER header format shown, please refer to the description in Figure 2 and will not be elaborated here.

[0177] Next, taking Figure 4 as an example, the process of establishing a BIER forwarding table and forwarding BIER packets based on BIER technology will be described in detail.

[0178] As Figure 4 shown, the BIER domain can include devices A to F. Among them, devices A, D, E, and F belong to the edge BFRs 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 performing BIER encapsulation on the original multicast data packets, corresponding to Figure 1 the BFIR in. Devices D, E, and 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 the BFER in.

[0179] In the embodiments of the present application, a unique BFR-ID can be assigned to each edge BFR within the BIER domain. For example, in Figure 4Among them, the BFR-IDs configured for Device A, Device D, Device E, and Device F are 4, 1, 3, and 2 respectively. For intermediate forwarding BFRs, such as Device B and Device C, no BFR-ID is assigned.

[0180] It should be noted that in the embodiments of this application, "ID" and "id" can sometimes be used interchangeably. It should be pointed out that when their differences are not emphasized, their intended meanings are the same. Among them, the BFR-ID in this application can refer to Figure 4 the id in

[0181] The bit string encapsulated in the BIER header of the data traffic annotates all the destination devices of this traffic. For example, for Device D with a BFR-ID of 1, the corresponding bit string is 0001; for Device F with a BFR-ID of 2, the corresponding bit string is 0010; for Device E with a BFR-ID of 3, the corresponding bit string is 0100; for Device A with a BFR-ID of 4, the corresponding bit string is 1000.

[0182] It should be understood that the BFR-ID values assigned to the edge BFRs in each 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 and encapsulation information of the edge BFR. For example, the flooded BIER information of Device A will carry the IP address of Device A and the BIFT-id. The BFRs in the BIER domain (such as Figure 4 Device F in Figure 4 can establish BIFT entries according to the flooded BIER information, so that

[0183] After Device F in

[0184] receives a BIER packet, it can complete the forwarding of the BIER packet to the destination device according to the established BIFT entries.

[0185] For Device A, if it needs to send a BIER packet to BFERs with BFR-IDs of 1, 2, and 3 respectively, this BIER packet needs to be sent to the neighbor (Device B) of Device A first. The edge BFR with a BFR-ID of 4 is itself. Therefore, the BIFT entries established by Device A are as follows:

[0186] Forwarding entry 1: Neighbor (Nbr) = B, Forwarding bit mask (FBM) = 0111;

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

[0186] Among them, the forwarding table entry 1 is used to indicate that when any one of the 1st bit, 2nd bit, and 3rd bit from the right to the left of the bit string of the BIER packet is 1, the BIER packet will be sent to the neighbor (device B) of device A, and Nbr = B indicates that the neighbor of device A is device B.

[0187] The forwarding table entry 2 is used to indicate that when the 4th bit from the right to the left of the bit string of the BIER packet is 1, the BIER packet will be sent to device A. Since device A is itself, device A will strip off the BIER header and forward it according to the information in the original multicast data packet. It should be noted that in the above forwarding table entry 2, * is used to identify that this Nbr is itself. For example, for device A, Nbr* = A indicates that the neighbor device of device A is itself. Similarly, Figure 4 other devices in Figure 4 can also establish BIFT table entries according to their own neighbor devices. For the BIFT table entries established by other devices, please refer to

[0188] When the BFIR at the ingress of the BIER domain in Device A receives the original multicast data packet, a BIER header is encapsulated before the original multicast data packet. It should be understood that for the sake of convenience in description, it is simply referred to as the ingress device A hereinafter. As an example, after receiving the original multicast data packet, the ingress 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. For example, the receiver of the original multicast data packet is the destination device with BFR-ID 3 being E, the destination device with BFR-ID 2 being F, and the destination device with BFR-ID 1 being D. The bit string of the BIER header encapsulated by the ingress device A is 0111, and the encapsulated BIER packet is forwarded to the neighbor device B according to the above-mentioned forwarding table entry 1. After receiving the BIER packet, device B determines according to the bit string 0111 and the BIFT entry that the BIER packet needs to be sent to device C and device E respectively. When device B sends the BIER packet to 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 entry. In the embodiment of the present application, the result of the AND operation is 0011. Therefore, device B can modify the bit string of the BIER header to 0011 and send it to device C. Similarly, when device B sends the BIER packet to device E, it can modify the bit string of the BIER header to 0100. After receiving the BIER packet, device E determines according to the bit string 0100 that the BIER packet is to be sent to the neighbor device E. Since device E determines that the neighbor device E is itself according to the identifier * in the forwarding table, device E, as the BFER at the egress of the BIER domain, can de-encapsulate the original multicast data packet from the BIER packet and forward it according to the information in the inner original multicast data packet.

[0189] In the BIER-MPLS encapsulation, the first 32 bits of the BIER header are an MPLS label encoding, where the first 20 bits of these first 32 bits are the MPLS label value. This MPLS label value will change during the forwarding process. For example, when the ingress device A sends a packet to device B, it needs to encapsulate the MPLS label value of device B. When device B sends a packet to device C, it needs to encapsulate the MPLS label value of device C. In the embodiment of the present application, the MPLS label values assigned to device A / device B / device C / device D / device E / device F are 100 / 200 / 300 / 400 / 500 / 600 respectively. These MPLS label values need to be carried in the aforementioned BIER encapsulation information and flooded to other BFRs in the BIER domain through the routing protocol so that device A can learn the MPLS label value of device B. This MPLS label identifying the BIER information is also called the BIER label.

[0190] In the embodiments of the present application, the bit positions of the edge BFRs are flooded in the BIER domain in advance through the interior gateway protocol (IGP) or the border gateway protocol (BGP), so that each BFR in the BIER domain forms a bit index forwarding table (BIFT) for guiding the forwarding of the original multicast data packets in the BIER domain. The information flooded in the BIER domain along with the IGP or BGP can be referred to as BIER information. When a BFR receives a BIER packet encapsulated with a BIER header, it forwards the BIER packet to the destination device according to the BIFT entry.

[0191] In the embodiments of the present application, the interior gateway protocol IGP may include, but is not limited to, the open shortest path first (OSPF) protocol, the intermediate system to intermediate system (ISIS) protocol, etc.

[0192] It should be understood that the BIER domain refers to a network area that can flood BIER information through the IGP or BGP and establish BIFT entries. The BIER domain includes BFIR and BFER. The BIER information may include, but is not limited to, the BFR ID of each edge BFR mentioned above. As an example, an interior gateway protocol (IGP) is deployed within an autonomous system (AS) domain to flood BIER information, and this AS domain is a BIER domain.

[0193] Generally, when the network scale is large, multiple domains are divided. For example, different ASs are divided according to different administrative domains, and the boundary of the AS can be an autonomous system border router (ASBR). The IGP may be deployed within different AS domains to flood BIER information, and the BGP is deployed between multiple AS domains without flooding BIER information. Then, multiple AS domains can be multiple different BIER domains.

[0194] The following Figure 5 is used to describe in detail the related technologies of BIERv6 encapsulation.

[0195] It should be understood that the BIERv6 encapsulation is a solution formed by combining the advantages of Native IPv6 and BIER. The packet format under BIERv6 encapsulation is: IPv6 header + BIER header + original multicast data packet. Among them, the BIER header can be included in the IPv6 extension header, and the original multicast data packet serves as the payload of the outer IPv6 header.

[0196] Under this encapsulation, the IPv6 header and the IPv6 extension header containing the BIER header together form the outer packet header of the inner original multicast data packet, which can also be referred to as the BIERv6 header in the embodiments of the present application.

[0197] The embodiments of the present application do not specifically limit the IPv6 extension header containing the BIER header. For example, the IPv6 extension header can be a destination option header (DOH), or the IPv6 extension header can also be a routing header (RH).

[0198] Figure 5 is a schematic block diagram of a possible BIERv6 encapsulation. See Figure 5 , the BIER header can be located in the IPv6 extension header, for example, located in the DOH.

[0199] It should be understood that the options in the DOH are in a type length value (TLV) format. Among them, the BIER header serves as the Option data in the Option TLV of the DOH, and its format is identified by the Option type in the Option TLV, and its length is identified by the Option length in the Option TLV.

[0200] It should be noted that in the BIERv6 encapsulation, the embodiments of the present application do not specifically limit the BIER header format in the DOH, as long as the BIER header contains a bit string field. The BIER header format can be the format shown in Figure 2 , or the format shown in Figure 3 , or other formats. Under BIERv6 encapsulation, the BIER header can further delete fields such as the Proto field and the DSCP field, as long as the BIER header contains a bit string for explicit replication of bit indexing. For a detailed description of the specific BIER header format, please refer to the description in Figure 2 or Figure 3 , and details are not described here again.

[0201] The fields included in the outer IPv6 header are described in detail below.

[0202] Version number (version, Ver): The version number of the IP, where a value of 6 represents IPv6.

[0203] Traffic class (TC) field: Identifies the priority of the packet.

[0204] Flow label (FL) field: Multiple packets belonging to one traffic can be marked with the same flow label, and multiple packets of different traffic can be marked with another flow label value. When a packet is forwarded, different traffic can be distributed to different links according to the flow label, while multiple packets of the same traffic follow the same link. That is, the flow label is used to distinguish real-time traffic, and different flow labels can determine different data streams. In this way, network devices in the BIER domain can also more efficiently distinguish different data streams based on the flow label field.

[0205] Payload length (PL) field: Represents the length of the packet.

[0206] Next Header (NH) field: Represents the type of the next header of the packet. For example, it can be an IPv6 extension header.

[0207] Hop Limit (HL) field: Represents the limit on the number of packets.

[0208] Source address (SA) field: Identifies the source address of the packet.

[0209] Destination address (DA) field: Identifies the destination address of the packet.

[0210] Take Figure 4 The BIER domain shown as an example. As the ingress device of the Ipv6 network, device A encapsulates the packet after receiving the multicast data packet from the user behind the BIERv6 header, that is, after an outer Ipv6 header and an Ipv6 extension header containing the BIER header, to obtain the encapsulated BIERv6 packet. Among them, the BIER packet header contained in the Ipv6 extension header carries a bit string representing the set of destination devices.

[0211] Device A sends the encapsulated BIERv6 packet to B according to the BIER packet header and its bit string information. When sending, the destination address field in the IPv6 header can use the unicast address of B (for example, B::100). Device B sends the packet to C and E according to the BIER packet header and its bit string information. When sending, the destination address field in the IPv6 header can use the unicast address of C (for example, C::100) and the unicast address of E (for example, E::100). Similarly, device C sends the packet to D and F according to the BIER packet header and its bit string information. When sending, the destination address field in the IPv6 header can use the unicast address of D (for example, D::100) and the unicast address of F (for example, D::100).

[0212] As can be seen from the above description of BIER / BIERv6, the BIER / BIERv6 technology for carrying multicast service traffic is a stateless multicast forwarding technology. That is, a multicast forwarding tree will not be generated in the middle of the network, and there are no table entries and states based on multicast flows. The BIER technology generates a BIER forwarding and replication table BIFT on network devices based on IGP. In essence, from the perspective of forwarding, it is to perform multiple unicast forwards based on the bitstring in the BIER packet at different network devices according to the bit identifier to achieve the purpose of replicating to multiple receivers. The BIFT table entry provides forwarding guidance for any multicast flow using BIER forwarding, without distinguishing multicast flows. Therefore, this kind of forwarding based on the BIER technology makes it difficult for network devices to perform statistics on BIER multicast flows.

[0213] As an example, for a network forwarding device that forwards BIER traffic, first, it cannot distinguish between BIER forwarding flows and ordinary unicast forwarding flows. Therefore, the traffic is uniformly counted as unicast flows. Second, the network forwarding device also cannot distinguish the traffic of different multicast groups in the BIER forwarding traffic. This causes difficulties in the operation and maintenance of the BIER multicast technology. When a user cannot receive a multicast flow, it is impossible to quickly know where the traffic is interrupted. And when there are packet losses in the multicast flow received by the user, it is impossible to quickly know where the packet losses occur. To find the traffic interruption point or packet loss point, it is necessary to remove the influence of other traffic. Therefore, other services have to be interrupted, and then the forwarding table of each device and the total unicast traffic statistics of the device have to be queried one by one to analyze, troubleshoot, and locate the problem. Interrupting other services is unacceptable to other users, and it is also very difficult and inaccurate to check the tables level by level and infer the packet loss or disconnection position based on the total unicast traffic of the device.

[0214] In view of this, the present application provides a method for counting BIER multicast traffic, which can count BIER multicast traffic. The following will be combined with Figure 6, a method for BIER multicast traffic statistics provided by an embodiment of the present application will be described in detail.

[0215] Figure 6 It is a schematic flowchart of a method for BIER multicast traffic statistics provided by an embodiment of the present application. Refer to Figure 6 , this method may include steps 610 - 640, and the steps 610 - 640 will be described in detail below.

[0216] Step 610: The first network device obtains a first BIER packet.

[0217] The first network device may be an ingress device (e.g., BFIR) of the BIER domain, or may also be an intermediate forwarding device (e.g., BFR) or an egress device (e.g., BFER) of the BIER domain. The embodiments of the present application do not make specific limitations in this regard.

[0218] Optionally, when the first network device is an ingress device (e.g., BFIR) of the BIER domain, before the first network device obtains the first BIER packet, the first network device also receives a traffic statistics instruction sent by the controller, and performs BIER encapsulation on the first multicast data according to the traffic statistics instruction to obtain the above-mentioned first BIER packet.

[0219] It should be understood that the traffic statistics instruction may include the first multicast data. The traffic statistics instruction is used to indicate traffic statistics on the first multicast data.

[0220] It should be understood that in multicast, the source (S) represents the source end of the multicast data, and the group (G) represents the destination end of the multicast data. Therefore, the multicast source group can be expressed as (S, G). The first multicast data can be uniquely identified by a multicast source group (S, G). Or, according to the differences of virtual private networks (VPNs), the first multicast data can also be uniquely identified by (VPN, S, G). Therefore, the traffic statistics instruction may include (S, G) or (VPN, S, G) that identifies the first multicast data, and the traffic statistics instruction is used to indicate traffic statistics on the first multicast data identified by (S, G) or (VPN, S, G).

[0221] Step 620: The first network device performs traffic statistics on the first BIER packet according to the multicast flow information to obtain the traffic statistics result of the first BIER packet.

[0222] Among them, the multicast flow information is used to identify the multicast flow to which the first BIER packet belongs. Specifically, as an example, the multicast flow information includes any one of the following: the BFIR-ID and entropy label in the BIER header of the first BIER packet; the SA and flow label in the IPv6 header of the first BIER packet; the (S, G) of the first multicast data in the inner layer of the first BIER packet; the (VPN, S, G) of the first multicast data in the inner layer of the first BIER packet.

[0223] Optionally, the first network device is an intermediate forwarding device (e.g., BFR) or an egress device (e.g., BFER) in the BIER domain. Before the first network device performs traffic statistics on the first BIER packet, the first network device also needs to determine whether traffic statistics need to be performed on the first BIER packet.

[0224] There are multiple implementation manners for the above first network device to determine whether traffic statistics need to be performed on the first BIER packet, and the present application does not make specific limitations thereon.

[0225] In a possible implementation manner, the controller issues a statistical instruction for a specified flow to all network devices in the network, and the first network device may determine that traffic statistics need to be performed on the first BIER packet according to the statistical instruction for the specified flow. The statistical instruction for the specified flow may be, for example, a first indication message, and the first indication message includes multicast flow information, and the first indication message is used to indicate that traffic statistics need to be performed on the first BIER packet.

[0226] In another possible implementation manner, the controller only issues a statistical instruction for a specified flow to the ingress device (e.g., BFIR) in the BIER domain. The ingress device (e.g., BFIR) in the BIER domain carries the traffic statistics identifier in the first BIER packet of the specified flow based on the statistical instruction. After receiving the first BIER packet, the intermediate forwarding device (e.g., BFR) or the egress device (e.g., BFER) in the BIER domain may determine whether traffic statistics need to be performed on the first BIER packet according to whether the traffic statistics identifier is carried in the first BIER packet. In this way, the controller does not need to issue a statistical instruction for a specified flow to all network devices in the network, reducing the configuration complexity. The above two implementation manners will be described in detail in combination with specific embodiments below and will not be elaborated here for the time being.

[0227] Step 630: The first network device sends the multicast flow information and the traffic statistics result of the first BIER packet to the controller.

[0228] In the above technical solution, the first network device can perform statistics on BIER multicast traffic. On the one hand, it can solve the problem that BIER / BIERv6 multicast service traffic cannot be statistically analyzed. In the scenario where BIER / BIERv6 multicast traffic is interrupted or packets are lost, the controller can effectively locate the lost or interrupted data packets based on the multicast traffic statistics data. On the other hand, it can also improve the operation and maintenance capabilities of BIER / BIERv6 multicast.

[0229] Taking the controller's issuance of a statistical instruction for a specified flow to all network devices as an example, combined with Figure 7 a specific implementation process of the BIER multicast traffic statistical method provided in the embodiments of the present application will be described in detail.

[0230] It should be understood that Figure 7 the examples are only to help those skilled in the art understand the embodiments of the present application, rather than limiting the embodiments of the application to the specific numerical values or specific scenarios shown. Those skilled in the art can clearly make various equivalent modifications or changes according to the examples given below Figure 7 of the present application, and such modifications and changes also fall within the scope of the embodiments of the present application.

[0231] Figure 7 is a schematic flowchart of another BIER multicast traffic statistical method provided in the embodiments of the present application. As Figure 7 shown, the method may include steps 710-740, and the steps 710-740 will be described in detail below.

[0232] Step 710: The controller sends a statistical instruction based on a certain flow to the BFIR.

[0233] In the embodiments of the present application, the multicast flow forwarded in the BIER domain may be referred to as a virtual private network multicast source group (VPN source group, VPN, S, G). (VPN, S, G) may sometimes also be referred to as flow information (VPN, S, G).

[0234] Step 720: The BFIR reports the flow identifier corresponding to the flow information (VPN, S, G) to the controller.

[0235] It should be understood that the flow identifier may correspond to the multicast flow information in the above text.

[0236] An example is that in the scenario of BIER encapsulation, if BFIR can assign different entropy fields to different multicast streams, and since the BFIR-id can identify from which BFIR a multicast stream is sent to uniquely determine the multicast stream. Therefore, BFIR can uniquely represent a multicast stream through the BFIR-id field and the entropy field in the BIER header. The BFR and BFER in the BIER domain can obtain the mapping relationship 1 (BFIR-ID + entropy ←----→ multicast stream (VPN, S, G)) from BFIR and apply it to the BFR and BFER in the BIER domain, so that the BFR and BFER in the BIER domain can uniquely identify a specific multicast stream according to the above mapping relationship 1.

[0237] In the above BIER encapsulation scenario, "BFIR-ID + entropy" in the BIER header can be used as a flow identifier to identify different multicast streams. BFIR can also report the flow identifier corresponding to the flow information (VPN, S, G) to the controller.

[0238] For example, the information reported by BFIR to the controller is shown in Table 1.

[0239] Table 1

[0240]

[0241]

[0242] In this implementation method, the controller can uniquely identify a multicast stream through "BFIR-ID + entropy" and enable the BFR and BFER in the BIER domain to perform traffic statistics on the multicast stream by issuing "BFIR-ID + entropy". The BFR and BFER in the BIER domain can match the corresponding multicast stream based on "BFIR-ID + entropy" and perform traffic statistics on the matched multicast stream.

[0243] Another example is in the scenario of BIERv6 encapsulation. If the BFIR can assign different flow label (FL) fields to different multicast flows, and since the source address SA in the outer IPv6 header can identify from which BFIR the multicast flow is sent, to uniquely determine the multicast flow. Therefore, the BFIR can uniquely represent a multicast flow through the SA field and the flow label field in the outer IPv6 header. The BFR and BFER in the BIER domain can obtain the mapping relationship 2 (SA + flow label ←----→ multicast flow (VPN, S, G)) from the BFIR and apply it to the BFR and BFER in the BIER domain, so that the BFR and BFER in the BIER domain can uniquely identify a specific multicast flow according to the above mapping relationship 2.

[0244] In the above scenario of BIERv6 encapsulation, "SA + flow label" in the outer IPv6 header can be used as another flow identifier to identify different multicast flows. The BFIR can also report the flow identifier corresponding to the flow information (VPN, S, G) to the controller.

[0245] For example, the information reported by the BFIR to the controller is shown in Table 2.

[0246] Table 2

[0247]

[0248] In this implementation, the controller can uniquely identify a multicast flow through "SA + flow label" and enable the BFR and BFER in the BIER domain to perform traffic statistics on the multicast flow by issuing "SA + flow label". The BFR and BFER in the BIER domain can match the corresponding multicast flow based on "SA + flow label" and perform traffic statistics on the matched multicast flow.

[0249] Another example is in the scenario of BIER encapsulation. If the BFIR cannot assign different entropy to different multicast flows, or in the scenario of BIERv6 encapsulation, the BFIR cannot assign different flow labels to different multicast flows, the multicast flow can be directly identified by (VPN, S, G). In this case, the information reported by the BFIR to the controller is shown in Table 3.

[0250] Table 3

[0251]

[0252] In this implementation, the controller can uniquely identify a multicast flow through (VPN, S, G), and enable the BFR and BFER in the BIER domain to perform traffic statistics on the multicast flow by issuing (VPN, S, G). The BFR and BFER in the BIER domain can match the corresponding multicast flow based on (VPN, S, G) and perform traffic statistics on the matched multicast flow.

[0253] Step 730: The controller enables the BFR and BFER in the BIER domain to perform statistics on the multicast flow and report the statistical results.

[0254] When it is necessary to count the traffic of a certain multicast flow, the BFR and BFER in the BIER domain can perform traffic statistics on the multicast flow. There are various specific implementation methods, and two possible implementation methods are introduced below.

[0255] In one implementation, the controller can, according to the information reported by the BFIR, issue the key information of the flow identifier to the BFR and BFER in the BIER domain. So that the BFR and BFER in the BIER domain can match the corresponding multicast flow according to the key information of the flow identifier and perform traffic statistics on the matched multicast flow.

[0256] In another implementation, the key information of the flow identifier can be directly enabled and configured on the BFR and BFER in the BIER domain, so that the BFR and BFER in the BIER domain can match the corresponding multicast flow according to the key information of the flow identifier and perform traffic statistics on the matched multicast flow.

[0257] The process of the controller issuing the key information of the flow identifier to the BFR and BFER in the BIER domain is described below.

[0258] As an example, a multicast flow is uniquely identified by (VPN, S, G). When it is necessary to count the traffic of a certain flow, the controller configures the statistical enablement for the BFR and BFER in the BIER domain according to the (VPN, S, G) reported by the BFIR, and issues the (VPN, S, G) information to the BFR and BFER in the BIER domain. The BFR and BFER in the BIER domain generate an access control table (ACL) rule as shown in Table 3, for example, based on the (VPN, S, G) information issued by the controller, and perform statistics on the multicast flow that meets the matching conditions, and periodically report the traffic statistics data. For example, statistical resources can be applied for in the control plane and issued to the forwarding plane. The forwarding plane performs statistics on the multicast flow that meets the ACL rule and periodically reports the traffic statistics data.

[0259] It should be understood that the above traffic statistics data may include: BFR-id, (VPN, S, G), and traffic statistics information.

[0260] Optionally, in some embodiments, the BFR and BFER in the BIER domain may also periodically report traffic in-and-out interface information to the controller.

[0261] After the controller receives the traffic in-and-out interface information reported by the BFR and BFER in the BIER domain, it can correspond the traffic interface information to the existing physical topology to restore the service path of the flow.

[0262] As another example, use "BFIR-ID + entropy" as a flow identifier to uniquely identify a multicast flow. When counting the traffic of a certain flow, the controller configures the statistics enablement for the BFR and BFER in the BIER domain according to the correspondence between the "BFIR-ID + entropy" reported by BFIR and (VPN, S, G), and sends the "BFIR-ID + entropy" information to the BFR and BFER in the BIER domain. The BFR and BFE in the BIER domain generate an ACL rule as shown in Table 1, for example, and perform statistics on the multicast flow that meets the matching conditions based on the ACL rule, and periodically report the traffic statistics data. For example, statistical resources can be applied for in the control plane and sent to the forwarding plane. The forwarding plane performs statistics on the multicast flow that meets the ACL rule and periodically reports the traffic statistics data.

[0263] It should be understood that the above traffic statistics data may include: BFIR-id, entropy, and traffic statistics information.

[0264] Optionally, in some embodiments, the BFR and BFER in the BIER domain may also periodically report traffic in-and-out interface information to the controller.

[0265] After the controller receives the traffic in-and-out interface information reported by the BFR and BFER in the BIER domain, it can correspond the traffic interface information to the existing physical topology to restore the service path of the flow.

[0266] As another example, "SA + flow label" is used as a kind of flow identifier to uniquely identify a multicast flow. When it is necessary to count the traffic of a certain flow, the controller configures the statistics enabling for the BFR and BFER in the BIER domain according to the correspondence between the "SA + flow label" reported by the BFIR and (VPN, S, G), and issues the "SA + flow label" information to the BFR and BFER in the BIER domain. The BFR and BFE in the BIER domain generate ACL rules as shown in Table 2, for example, based on the "SA + flow label" information issued by the controller, and perform statistics on the multicast flows that meet the matching conditions, and periodically report the traffic statistics data. For example, statistical resources can be applied for in the control plane and issued to the forwarding plane, and the forwarding plane performs statistics on the multicast flows that meet the ACL rules and periodically reports the traffic statistics data.

[0267] It should be understood that the above traffic statistics data may include: SA, flow label, traffic statistics information.

[0268] Optionally, in some embodiments, the BFR and BFER in the BIER domain may also periodically report the traffic in-and-out interface information to the controller.

[0269] After receiving the traffic in-and-out interface information reported by the BFR and BFER in the BIER domain, the controller may correspond the traffic interface information with the existing physical topology to restore the service path of the flow.

[0270] In the above technical solution, since "SA, flow label" is in the outer IPv6 header, therefore, the method of using "SA, flow label" to identify multicast flows has high processing efficiency for the forwarding plane to parse this information.

[0271] It should be noted that in the BIER forwarding, in the scenario of forwarding across non-BFR devices, the non-BFR devices do not perform multicast traffic statistics.

[0272] Step 740: The controller analyzes according to the traffic statistics results reported by the BFR and BFER in the BIER domain.

[0273] In the embodiments of the present application, the controller may analyze according to the traffic statistics results reported by the BFR and BFER in the BIER domain. This analysis may include but is not limited to: multicast flow statistics visualization, multicast flow fault analysis.

[0274] Among them, the multicast flow statistics visualization takes the head node and the multicast flow as the key dimensions for the controller, presenting the devices through which a certain multicast flow sent by a head node passes and the traffic of each device, and presenting the entire process of multicast flow replication and traffic statistics. The multicast flow fault analysis takes the head node, the receiving end, and the multicast flow as the key dimensions, views the service path and traffic statistics during the forwarding process of the multicast flow received by the receiving end from BFIR to BFER, and analyzes the fault points and causes based on the traffic statistics.

[0275] Taking the unique identification of a multicast flow by (VPN, S, G) as an example. After the controller receives the traffic statistics data reported by BFR and BFER in the BIER domain, it can map the BFR-id, flow information (VPN, S, G), and traffic statistics data to the restored service path.

[0276] Taking "BFIR-ID + entropy" as a flow identifier to uniquely identify a multicast flow as an example. After the controller receives the traffic statistics data reported by BFR and BFER in the BIER domain, it can map the reported "BFIR-id, entropy, traffic statistics data" to the flow information (VPN, S, G). And map the corresponding flow information (VPN, S, G) and traffic statistics data to the restored service path.

[0277] Taking "SA + flow label" as a flow identifier to uniquely identify a multicast flow as an example. After the controller receives the traffic statistics data reported by BFR and BFER in the BIER domain, it can map the reported "SA, flow label, traffic statistics data" to the flow information (VPN, S, G). And map the corresponding flow information (VPN, S, G) and traffic statistics data to the restored service path.

[0278] In the above technical solution, the controller can judge whether there is packet loss or flow interruption of the multicast flow according to the traffic analysis of the multicast flow on the service path. If there are such fault conditions, it can assist the user in delimiting and locating the fault point. For example, it can assist the user in delimiting and locating the fault point by means of alarms and comparison with upstream and downstream devices.

[0279] Next, taking the example that the controller only sends statistical instructions for specified flows to BFIR, combined with Figure 8 Another specific implementation process of the BIER multicast traffic statistics method provided by the embodiments of the present application will be described in detail.

[0280] It should be understood that Figure 8 the examples are only for helping those skilled in the art to understand the embodiments of the present application, rather than limiting the embodiments of the application to the specific values or specific scenarios shown. Those skilled in the art can, according to the following Figure 8For example, various equivalent modifications or variations can obviously be made, and such modifications and variations also fall within the scope of the embodiments of the present application.

[0281] Figure 8 FIG. is a schematic flowchart of another method for statistically analyzing BIER multicast traffic provided by an embodiment of the present application. As Figure 8 shown, the method may include steps 810-860, which will be described in detail below for steps 810-860.

[0282] Step 810: The controller sends a statistical instruction based on a certain flow (VPN, S, G) to the BFIR.

[0283] When the traffic of a certain multicast flow needs to be statistically analyzed, the controller sends a statistical instruction based on a certain flow (VPN, S, G) to the BFIR.

[0284] Step 820: The BFIR may report the flow identifier corresponding to the flow information (VPN, S, G) to the controller.

[0285] Taking "BFIR-ID + entropy" as a flow identifier to uniquely identify a multicast flow as an example, the BFIR may report the correspondence between the flow information (VPN, S, G) shown in Table 1 and "BFIR-ID + entropy" to the controller. Taking "SA + flow label" as a flow identifier to uniquely identify a multicast flow as an example, the BFIR may report the correspondence between the flow information (VPN, S, G) shown in Table 2 and "SA + flow label" to the controller. Taking (VPN, S, G) to uniquely identify a multicast flow as an example. The BFIR may report the information shown in Table 3 to the controller. For specific details, please refer to the description in the above text and will not be elaborated here.

[0286] Step 830: When the BFIR performs BIER encapsulation on the multicast flow for which traffic statistics need to be performed, it carries a multicast traffic statistics identifier.

[0287] For the multicast flows for which traffic statistics need to be performed and are sent by the controller, when the BFIR performs BIER encapsulation on these multicast flows, it may carry a multicast traffic statistics identifier in the encapsulated BIER packet, so that the BFR and BFER in the BIER domain can perform traffic statistics on the BIER packet according to the multicast traffic statistics identifier carried in the BIER packet.

[0288] In the embodiments of the present application, there are various specific implementation manners for carrying the multicast traffic statistics identifier through the BIER packet. Several possible implementation manners will be described in detail below.

[0289] 1. In a possible implementation, fields in the BIER header can be used to carry multicast traffic statistics identifiers.

[0290] This application embodiment does not make specific limitations on this field. It can be a field in the BIER header used alone or the value of a field in the BIER header used alone to indicate the multicast traffic statistics identifier. Or, it can also be a field shared with other functions or the value of a field shared with other functions to indicate the multicast traffic statistics identifier.

[0291] As an example, the OAM field of the BIER header can be used to carry the BIER multicast flow statistics identifier. Specifically, the OAM field of the BIER header can be borrowed. When the OAM field is 00, it represents the default value. One of the remaining values 01, 10, and 11 is selected to indicate that this message needs to perform multicast flow statistics. For example, selecting 11 indicates that this message needs to perform multicast flow statistics.

[0292] When BFIR configures the list of multicast channels to be statistically analyzed, it sets the OAM field of the BIER header of the multicast message to be statistically analyzed to 11. In the BIER domain, BFR and BFER only configure the BIER traffic statistics enable instruction, such as bierstatistic enable based on device configuration, without configuring the channel list, which greatly reduces the configuration amount and improves efficiency. When BFR and BFER in the BIER domain receive a BIER multicast message for BIER forwarding processing, they check this OAM field. If it is 11, it indicates that multicast flow statistics need to be performed on this multicast message. Therefore, the traffic statistics result of this multicast message can be reported to the controller.

[0293] Another example, the Rsv field of the BIER header can be used to carry the multicast traffic statistics identifier. The specific implementation method is similar to the process of using the OAM field to carry the BIER multicast flow statistics identifier in the above text. For details, please refer to the description in the above text and will not be elaborated here.

[0294] 2. In another possible implementation, the BIER header extension information can also be used to identify that BIER multicast traffic statistics need to be performed, and the extension header is used to carry the BIER multicast traffic statistics flag.

[0295] Specifically, the BIER header can be extended, and a new proto field (such as 0x3F) can be defined to indicate the extension information to be carried after the BIER header. A certain field or the value of a certain field in the extension information can be used to indicate that this message needs to perform multicast flow statistics.

[0296] As an example, when BFIR configures the multicast channel list to be counted, it sets the proto field of the BIER header of the multicast packet to be counted to 0x3F, and extends the BIER header to add a traffic statistics identifier. In the BIER domain, BFR and BFER only configure the BIER traffic statistics enable instruction, such as bier statistic enable based on the device configuration, without the need to configure the channel list, which greatly reduces the configuration amount and improves efficiency.

[0297] Specifically, when BFR and BFER in the BIER domain receive a BIER multicast packet for BIER forwarding processing, they check this proto field. If it is 0x3F, they continue to check the BIER extended header information. If the extended information is identified as a traffic statistics enable flag, they perform multicast traffic statistics on the multicast packet and report the traffic statistics result to the controller.

[0298] 3. In another possible implementation, a new version of the BIER header format can also be defined, and a flag for enabling traffic statistics for the multicast stream is added to the new version header format.

[0299] Specifically, a new version of the BIER header structure can be defined, such as Ver = 1. A field for multicast traffic statistics (for example, the Stat field) is added to the new version header structure. When the value of the Stat field is, for example, 01, it means that multicast stream statistics need to be performed on the multicast packet.

[0300] As an example, when BFIR configures the multicast channel list to be counted, it sets the Stat field of the BIER header of the multicast packet to be counted to 0x01. In the BIER domain, BFR and BFER only configure the BIER traffic statistics enable instruction, such as bier statistic enable based on the device configuration, without the need to configure the channel list, which greatly reduces the configuration amount and improves efficiency.

[0301] Specifically, when BFR and BFER in the BIER domain receive a BIER multicast packet for BIER forwarding processing, they identify that it is a BIER header encapsulation with Ver = 1, check the Stat field. If it is 01, they perform traffic statistics on the multicast packet and report the traffic statistics result to the controller.

[0302] It should be noted that in this implementation method, it is required that all devices that forward BIER multicast and perform BIER multicast traffic statistics in the network support the BIER header structure of the new version (Ver = 1).

[0303] Step 840: BFIR sends a BIER packet to BFR and BFER in the BIER domain.

[0304] Step 850: The BFR and BFER in the BIER domain process the BIER packet and report the traffic statistics result.

[0305] After receiving the BIER packet sent by the BFIR, the BFR and BFER in the BIER domain determine whether the BIER packet carries a multicast traffic statistics identifier.

[0306] Taking the OAM field of the BIER header carrying the BIER multicast flow statistics identifier as an example, the BFR and BFER in the BIER domain can check this OAM field. If it is 11, it means that multicast flow statistics need to be performed on this multicast packet. Therefore, the traffic statistics data of this multicast packet can be reported to the controller. For other implementation methods, please refer to the description in step 830 above, which will not be elaborated here.

[0307] Taking the OAM field = 11 in the BIER header indicating the enabling of BIER multicast traffic statistics as an example, a specific implementation method of how the BFR and BFER in the BIER domain complete traffic statistics according to the traffic statistics enabling flag will be described in detail below.

[0308] When the BFR and BFER in the BIER domain receive the BIER multicast flow for the first time, if the device interface enables BIER multicast traffic statistics, the forwarding layer checks the BIER header and finds that OAM = 11, then this traffic is sent to the control plane for flow table learning. After the control plane learns the flow table, it notifies the forwarding plane of the ACL rule of this flow and applies for the flow statistics resource to be sent to the forwarding plane. The forwarding layer then matches the multicast flow according to the ACL and performs traffic statistics.

[0309] It should be noted that if the forwarding layer checks the BIER header and finds that OAM is not 11, the foregoing sending and flow table learning processes are not performed, and the packet is directly forwarded according to the BIER entry.

[0310] Taking (VPN, S, G) to uniquely identify a multicast flow as an example, the traffic statistics data reported by the BFR and BFER in the BIER domain may include: BFR-id, (VPN, S, G), traffic statistics information. Optionally, in some embodiments, the BFR and BFER in the BIER domain may also periodically report the traffic in and out interface information to the controller.

[0311] Taking "BFIR-ID + entropy" as a flow identifier to uniquely identify a multicast flow as an example, the traffic statistics data reported by the BFR and BFER in the BIER domain may include: BFIR-id, entropy, traffic statistics information. Optionally, in some embodiments, the BFR and BFER in the BIER domain may also periodically report the traffic in and out interface information to the controller.

[0312] Taking "SA + flow label" as a flow identifier to uniquely identify a multicast flow as an example, the traffic statistics data reported by the BFR and BFER in the BIER domain may include: SA, flow label, and traffic statistics information. Optionally, in some embodiments, the BFR and BFER in the BIER domain may also periodically report traffic in-and-out interface information to the controller.

[0313] Step 860: The controller analyzes the traffic statistics results reported by the BFR and BFER in the BIER domain.

[0314] Similar to step 740, for specific details, please refer to the description in step 740, which will not be elaborated here.

[0315] In the above technical solution, a traffic statistics flag of the BIER multicast flow can be carried in the multicast flow. In this way, only traffic statistics instructions need to be issued to the BFIR for different multicast flows, instead of issuing traffic statistics instructions based on multicast flows to a large number of BFRs and BFERs, which can simplify the deployment.

[0316] As described above in conjunction with Figures 1 - 8 , a method for statistics of BIER multicast traffic provided by an embodiment of the present application has been described in detail. Next, in conjunction with Figures 9 - 13 , embodiments of the device of the present application will be described in detail. It should be understood that the description of the method embodiments corresponds to the description of the device embodiments. Therefore, for parts not described in detail, reference can be made to the previous method embodiments.

[0317] Figure 9 FIG. 20 is a schematic structural diagram of a first network device 900 provided by an embodiment of the present application. Figure 9 The illustrated first network device 900 can perform the corresponding steps executed by the first network device in the method of the above embodiment. As Figure 9 shown, the first network device 900 includes: a processing module 910, a sending module 920,

[0318] The processing module 910 is configured to obtain a first BIER packet;

[0319] The processing module 910 is further configured to perform traffic statistics on the first BIER packet according to multicast flow information to obtain a traffic statistics result of the first BIER packet, where the multicast flow information is used to identify the multicast flow to which the first BIER packet belongs;

[0320] The sending module 920 is configured to send the multicast flow information and the traffic statistics result of the first BIER packet to the controller.

[0321] Optionally, the first network device 900 is an ingress device of the BIER domain,

[0322] The processing module 910 is further configured to perform BIER encapsulation on the first multicast data according to a traffic statistics instruction, to obtain the first BIER packet. The traffic statistics instruction includes a multicast source group (S, G) of the first multicast data, and the traffic statistics instruction is used to indicate traffic statistics on the first multicast data including the multicast source group (S, G).

[0323] Optionally, the processing module 910 is further configured to generate a first correspondence, where the first correspondence is a correspondence between the multicast source group (S, G) of the first multicast data and the multicast flow information;

[0324] The sending module 920 is further configured to: send the first correspondence to the controller.

[0325] Optionally, the first network device 900 is an intermediate forwarding device or an egress device in a BIER domain, and the processing module 910 is further configured to determine traffic statistics on the first BIER packet.

[0326] Optionally, the first network device 900 further includes:

[0327] a receiving module, configured to receive first indication information sent by the controller, where the first indication information includes the multicast flow information, and the first indication information is used to indicate traffic statistics on the first BIER packet;

[0328] The processing module 910 is specifically configured to: determine traffic statistics on the first BIER packet according to the first indication information.

[0329] Optionally, the multicast flow information includes any one of the following:

[0330] a bit forwarding ingress router identifier BFIR-ID and an entropy label in the BIER header of the first BIER packet;

[0331] a source address SA and a flow label in the outer Internet Protocol version 6 (IPv6) header of the first BIER packet;

[0332] the multicast source group (S, G) of the first multicast data in the inner layer of the first BIER packet;

[0333] the virtual private network multicast source group (VPN, S, G) of the first multicast data in the inner layer of the first BIER packet.

[0334] Optionally, a traffic statistics identifier is carried in the first BIER packet, and the traffic statistics identifier is used to indicate traffic statistics for the first BIER packet. Specifically, the processing module 910 is configured to determine to perform traffic statistics on the first BIER packet according to the traffic statistics identifier.

[0335] Optionally, the traffic statistics identifier is carried in a first field of the first BIER packet.

[0336] Optionally, the first field is an operation, administration, and maintenance (OAM) field, a reserved (Rsv) field, or a field in a BIER extension header.

[0337] Optionally, the first BIER packet further includes a second field, and the second field indicates that the traffic statistics identifier is carried in the first field. The processing module 910 is further configured to obtain the traffic statistics identifier in the first field according to the second field.

[0338] Optionally, the processing module 910 is further configured to obtain interface information of the first BIER packet. Specifically, the sending module 920 is configured to send the interface information of the first BIER packet to the controller.

[0339] Figure 10 FIG. is a schematic structural diagram of a controller 1000 provided by an embodiment of the present application. Figure 10 The illustrated controller 1000 may perform corresponding steps executed by the controller in the method of the foregoing embodiment. As Figure 10 shown, the controller 1000 includes: a receiving module 1010 and a processing module 1020.

[0340] The receiving module 1010 is configured to receive multicast flow information sent by a first network device in a BIER domain and a traffic statistics result of a first BIER packet. The multicast flow information is used to identify a multicast flow to which the first BIER packet belongs.

[0341] The processing module 1020 is configured to perform traffic analysis on the first BIER packet according to the multicast flow information and the traffic statistics result of the first BIER packet.

[0342] Optionally, the first network device is an ingress device in the BIER domain. The controller 1000 further includes: a sending module 1030, configured to send a traffic statistics instruction to the first network device. The traffic statistics instruction includes a source group (S, G) of first multicast data, and the traffic statistics instruction is used to instruct the first network device to perform traffic statistics on the first BIER packet including the source group (S, G).

[0343] Optionally, the receiving module 1010 is further configured to: receive a first correspondence sent by the first network device, where the first correspondence is a correspondence between a multicast source group (S, G) of the first multicast data and the multicast flow information

[0344] Optionally, the multicast flow information includes any one of the following:

[0345] The bit forwarding ingress router identifier BFIR-ID and the entropy label in the BIER header of the first BIER packet;

[0346] The source address SA and the flow label in the outer Internet Protocol version 6 (IPv6) header of the first BIER packet;

[0347] The multicast source group (S, G) of the first multicast data in the inner layer of the first BIER packet;

[0348] The virtual private network multicast source group (VPN, S, G) of the first multicast data in the inner layer of the first BIER packet.

[0349] Optionally, the first network device is an intermediate forwarding device or an egress device in the BIER domain. The sending module 1030 is further configured to send first indication information to the first network device, where the first indication information includes the multicast flow information, and the first indication information is used to instruct the first network device to perform traffic statistics on the first BIER packet.

[0350] Optionally, the receiving module 1010 is further configured to: receive interface information of the first BIER packet sent by the first network device;

[0351] The processing module 1020 is further configured to determine a transmission path of the first BIER packet according to the interface information of the first BIER packet and the physical topology information.

[0352] Figure 11 It is a schematic hardware structure diagram of the first network device 2000 according to an embodiment of the present application. Figure 11 The illustrated first network device 2000 may perform corresponding steps executed by the first network device in the method of the foregoing embodiment.

[0353] As Figure 11 shown, the first network device 2000 includes a processor 2001, a memory 2002, an interface 2003, and a bus 2004. The interface 2003 may be implemented in a wireless or wired manner, specifically, it may be a network card. The foregoing processor 2001, memory 2002, and interface 2003 are connected through the bus 2004.

[0354] The interface 2003 may specifically include a transmitter and a receiver, which are used by the first network device to implement the above-mentioned transmission and reception. For example, the interface 2003 is used to receive the first BIER message, or to send the multicast stream information and the traffic statistics result of the first BIER message to the controller.

[0355] The processor 2001 is used to execute the processing performed by the first network device in the above-mentioned embodiment. For example, it is used to perform traffic statistics on the first BIER message according to the multicast stream information to obtain the traffic statistics results of the first BIER message; and / or other processes for the technology described in this article. The memory 2002 includes an operating system 20021 and an application 20022, which are used to store programs, codes or instructions. When the processor or hardware device executes these programs, codes or instructions, the processing process involving the first network device in the method embodiment can be completed. Optionally, the memory 2002 may include a read-only memory (ROM) and a random access memory (RAM). Among them, the ROM includes a basic input / output system (BIOS) or an embedded system; the RAM includes an application and an operating system. When the first network device 2000 needs to be run, it is started by the BIOS solidified in the ROM or the bootloader boot system in the embedded system to guide the first network device 2000 into a normal operating state. After the first network device 2000 enters a normal operating state, the application program and the operating system in the RAM are run, thereby completing the processing process involving the first network device 2000 in the method embodiment.

[0356] Understandably, Figure 11 Only a simplified design of the first network device 2000 is shown. In practical applications, the first network device may include any number of interfaces, processors or memories.

[0357] Figure 12 A schematic diagram of the hardware structure of another first network device 2100 according to an embodiment of the present application. Figure 12 The first network device 2100 shown can execute the corresponding steps executed by the first network device in the method of the above embodiment.

[0358] like Figure 12As described above, the first network device 2100 includes: a main control board 2110, interface boards 2130 and 2140, and a switching fabric board 2120. The main control board 2110, interface boards 2130 and 2140, and the switching fabric board 2120 are interconnected through a system bus and a system backplane. Among them, the main control board 2110 is used to complete functions such as system management, device maintenance, and protocol processing. The switching fabric board 2120 is used to complete data exchange between each interface board (the interface board is also called a line card or service board). The interface boards 2130 and 2140 are used to provide various service interfaces (for example, POS interfaces, GE interfaces, ATM interfaces, etc.) and implement packet forwarding.

[0359] The interface board 2130 may include a central processing unit 2131, a forwarding table entry memory 2134, a physical interface card 2133, and a network processor 2132. Among them, the central processing unit 2131 is used to control and manage the interface board and communicate with the central processing unit 2111 on the main control board. The forwarding table entry memory 2134 is used to store table entries, for example, the BIFT mentioned above. The physical interface card 2133 is used to complete the reception and transmission of traffic.

[0360] It should be understood that the operations on the interface board 2140 in the embodiments of the present application are the same as those of the interface board 2130. For the sake of brevity, they will not be described in detail here.

[0361] It should be understood that the first network device 2100 in this embodiment may correspond to the functions and / or various steps implemented in the above method embodiments, and will not be described in detail here.

[0362] In addition, it should be noted that there may be one or more main control boards. When there are multiple main control boards, they may include an active main control board and a standby main control board. There may be one or more interface boards. The stronger the data processing ability of the first network device, the more interface boards are provided. There may also be one or more physical interface cards on the interface board. There may be no switching fabric board, or there may be one or more switching fabric boards. When there are multiple switching fabric boards, they can jointly implement load sharing and redundant backup. In a centralized forwarding architecture, the first network device may not require a switching fabric board, and the interface board undertakes the processing function of the service data of the entire system. In a distributed forwarding architecture, the first network device may have at least one switching fabric board, and data exchange between multiple interface boards is achieved through the switching fabric board, providing a large-capacity data exchange and processing ability. Therefore, the data access and processing ability of the first network device in the distributed architecture is greater than that of the device in the centralized architecture. Which architecture is specifically adopted depends on the specific networking deployment scenario, and no limitation is made here.

[0363] Figure 13 It is a schematic diagram of the hardware structure of the controller 2200 in the embodiments of the present application. Figure 13The illustrated controller 2200 may perform the corresponding steps executed by the controller in the method of the foregoing embodiments.

[0364] As Figure 13 shown, the controller 2200 includes a processor 2201, a memory 2202, an interface 2203, and a bus 2204. The interface 2203 may be implemented in a wireless or wired manner, specifically, it may be a network card. The foregoing processor 2201, memory 2202, and interface 2203 are connected via the bus 2204.

[0365] The interface 2203 may specifically include a transmitter and a receiver, and is used for the controller to perform the foregoing transceiver operations. For example, this interface is used to support receiving multicast stream information sent by a first network device in a BIER domain and traffic statistics results of a first BIER packet. For another example, this interface 2203 is used to support sending traffic statistics instructions to the first network device. For yet another example, this interface 2203 is used to support receiving a first correspondence relationship sent by the first network device.

[0366] The processor 2201 is used to perform the processing performed by the controller in the foregoing embodiments. For example, it is used to perform traffic analysis on the first BIER packet according to the multicast stream information and the traffic statistics results of the first BIER packet; and / or for other processes of the technologies described herein. The memory 2202 includes an operating system 22021 and application programs 22022, and is used to store programs, codes, or instructions. When the processor or hardware device executes these programs, codes, or instructions, the processing procedures related to the controller in the method embodiments can be completed. Optionally, the memory 2202 may include a read-only memory (ROM) and a random access memory (RAM). Among them, the ROM includes a basic input / output system (BIOS) or an embedded system; the RAM includes application programs and an operating system. When it is necessary to run the controller 2200, the system is started by the BIOS solidified in the ROM or the bootloader in the embedded system, and the controller 2200 is guided into the normal operating state. After the controller 2200 enters the normal operating state, the application programs and the operating system running in the RAM are used to complete the processing procedures related to the controller 2200 in the method embodiments.

[0367] It can be understood that Figure 13 only a simplified design of the controller 2200 is shown. In practical applications, the second network device may include any number of interfaces, processors, or memories.

[0368] An embodiment of this application also provides a computer-readable medium. The computer-readable medium stores program code. When the computer program code runs on a computer, it causes the computer to execute the method performed by the above-mentioned first network device. These computer-readable storages include, but are not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), Flash memory, electrically erasable PROM (EEPROM), and hard drive.

[0369] An embodiment of this application also provides a computer-readable medium. The computer-readable medium stores program code. When the computer program code runs on a computer, it causes the computer to execute the method performed by the above-mentioned controller. These computer-readable storages include, but are not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), Flash memory, electrically erasable PROM (EEPROM), and hard drive.

[0370] An embodiment of this application also provides a chip system, which is applied to a first network device. The chip system includes: at least one processor, at least one memory, and an interface circuit. The interface circuit is responsible for the 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 by lines. Instructions are stored in the at least one memory; the instructions are executed by the at least one processor to perform the operations of the first network device in the methods in the above various aspects.

[0371] 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 processor (DSP), a system on chip (SoC), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or a programmable logic device (PLD).

[0372] The embodiment of the present application also provides another chip system, which is applied to a controller. The chip system includes: at least one processor, at least one memory, and an interface circuit. The interface circuit is responsible for the 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 by lines. Instructions are stored in the at least one memory; the instructions are executed by the at least one processor to perform the operations of the controller in the methods in the above various aspects.

[0373] 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 processor (DSP), a system on chip (SoC), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or a programmable logic device (PLD).

[0374] The embodiment of the present application also provides a computer program product, which is applied to a first network device. The computer program product includes a series of instructions, and when the instructions are run, they perform the operations of the first network device in the methods in the above various aspects.

[0375] The embodiments of the present application also provide a computer program product, which is applied to a controller. The computer program product includes a series of instructions that, when executed, perform the operations of the controller in the methods described in the above various aspects.

[0376] It should be understood that in various embodiments of the present application, the sequence numbers of the above processes do not imply the order of execution. The execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0377] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0378] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein.

[0379] In several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be in an electrical, mechanical, or other form.

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

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

[0382] When the above-mentioned functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art or a part of this technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

[0383] As described above, the above are only specific implementation manners of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed in this application can easily think of changes or substitutions, which should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims

1. A statistical method for explicit replication BIER multicast traffic based on bit index, characterized in that, the method includes: A first network device obtains a first BIER packet; The first network device performs traffic statistics on the first BIER packet according to the multicast flow information to obtain a traffic statistics result of the first BIER packet, and the multicast flow information is used to identify the multicast flow to which the first BIER packet belongs; The first network device sends the multicast flow information and the traffic statistics result of the first BIER packet to a controller; wherein, The first network device is an intermediate forwarding device or an egress device in the BIER domain; Before the first network device performs traffic statistics on the first BIER packet, the method further includes: The first network device determines to perform traffic statistics on the first BIER packet; wherein, A traffic statistics identifier is carried in the first BIER packet, and the traffic statistics identifier is used to indicate performing traffic statistics on the first BIER packet, and the traffic statistics identifier is carried in the first BIER packet by an ingress device in the BIER domain based on a traffic statistics instruction; The first network device determines to perform traffic statistics on the first BIER packet, including: The first network device determines to perform traffic statistics on the first BIER packet according to the traffic statistics identifier; The method further includes: The first network device reports interface information of the first BIER packet to the controller, so that the controller can determine a transmission path of the first BIER packet according to the interface information and physical topology information.

2. The method according to claim 1, characterized in that, the multicast flow information includes any one of the following: The bit forwarding ingress router identifier BFIR-ID and the entropy label in the BIER header of the first BIER packet; The source address SA and the flow label in the outer Internet Protocol version 6 IPv6 header of the first BIER packet; The multicast source group of the first multicast data in the inner layer of the first BIER packet; The virtual private network multicast source group of the first multicast data in the inner layer of the first BIER packet.

3. The method according to claim 1 or 2, characterized in that, the traffic statistics identifier is carried in a first field of the first BIER packet.

4. The method according to claim 3, characterized in that, the first field is an operation, administration and maintenance OAM field or a reserved Rsv field or a field in the BIER extension header.

5. The method according to claim 3, characterized in that, the first BIER packet further includes a second field, and the second field indicates that the traffic statistics identifier is carried in the first field, the method further includes: The first network device obtains the traffic statistics identifier in the first field according to the second field.

6. The method according to claim 1 or 2, characterized in that, the method further includes: The first network device obtains interface information of the first BIER packet; The first network device sends the interface information of the first BIER packet to the controller.

7. A statistical method for bit-indexed explicit replication BIER multicast traffic, characterized in that the method includes: The controller receives the multicast flow information sent by the first network device in the BIER domain and the traffic statistics result of the first BIER packet, where the multicast flow information is used to identify the multicast flow to which the first BIER packet belongs; The controller performs traffic analysis on the first BIER packet according to the multicast flow information and the traffic statistics result of the first BIER packet; where Before the controller receives the multicast flow information sent by the first network device and the traffic statistics result of the first BIER packet, the method further includes: The controller sends a traffic statistics instruction to the first network device, where the traffic statistics instruction includes the multicast source group of the first multicast data, and the traffic statistics instruction is used to instruct the first network device to perform traffic statistics on the first BIER packet including the multicast source group; where The first network device is an ingress device in the BIER domain, and the controller only sends the traffic statistics instruction to the ingress device of the BIER domain, so that the first network device includes a traffic statistics identifier in the first BIER packet based on the traffic statistics instruction, and the traffic statistics identifier is used to indicate that traffic statistics is performed on the first BIER packet; The method further includes: The controller receives the interface information of the first BIER packet reported by the first network device; The controller determines the transmission path of the first BIER packet according to the interface information and the physical topology information.

8. The method according to claim 7, characterized in that Before the controller receives the multicast flow information sent by the first network device and the traffic statistics result of the first BIER packet, the method further includes: The controller receives the first correspondence sent by the first network device, and the first correspondence is the correspondence between the multicast source group of the first multicast data and the multicast flow information.

9. The method according to claim 7 or 8, characterized in that The multicast flow information includes any one of the following: The bit forwarding ingress router identifier BFIR-ID and the entropy label in the BIER header of the first BIER packet; The source address SA and the flow label in the outer Internet Protocol version 6 IPv6 header of the first BIER packet; The multicast source group of the first multicast data in the inner layer of the first BIER packet; The virtual private network multicast source group of the first multicast data in the inner layer of the first BIER packet.

10. The method according to claim 7 or 8, characterized in that The method further includes: The controller receives the interface information of the first BIER packet reported by the first network device; The controller determines the transmission path of the first BIER packet according to the interface information of the first BIER packet and the physical topology information.

11. A first network device, characterized in that Comprising: A processing module, configured to obtain a first BIER packet; The processing module is further configured to perform traffic statistics on the first BIER packet according to multicast flow information to obtain a traffic statistics result of the first BIER packet, where the multicast flow information is used to identify the multicast flow to which the first BIER packet belongs; A sending module, configured to send the multicast flow information and the traffic statistics result of the first BIER packet to a controller; where The first network device is an intermediate forwarding device or an egress device in a BIER domain; The processing module is further configured to determine to perform traffic statistics on the first BIER packet; where A traffic statistics identifier is carried in the first BIER packet, and the traffic statistics identifier is used to indicate that traffic statistics is to be performed on the first BIER packet, and the traffic statistics identifier is carried in the first BIER packet by an ingress device in the BIER domain based on a traffic statistics instruction; The processing module is specifically configured to: determine to perform traffic statistics on the first BIER packet according to the traffic statistics identifier; The sending module is further configured to report interface information of the first BIER packet to the controller, so that the controller can determine a transmission path of the first BIER packet according to the interface information and physical topology information.

12. The first network device according to claim 11, wherein, The multicast flow information includes any one of the following: The bit forwarding ingress router identifier BFIR-ID and the entropy label in the BIER header of the first BIER packet; The source address SA and the flow label in the outer Internet Protocol version 6 IPv6 header of the first BIER packet; The multicast source group of the first multicast data in the inner layer of the first BIER packet; The virtual private network multicast source group of the first multicast data in the inner layer of the first BIER packet.

13. The first network device according to claim 11 or 12, wherein, The traffic statistics identifier is carried in a first field of the first BIER packet.

14. The first network device according to claim 13, wherein, The first field is an operation, administration, and maintenance OAM field or a reserved Rsv field or a field in a BIER extension header.

15. The first network device according to claim 13, wherein, The first BIER packet further includes a second field, and the second field indicates that the traffic statistics identifier is carried in the first field, The processing module is further configured to obtain the traffic statistics identifier in the first field according to the second field.

16. The first network device according to claim 11 or 12, wherein, The processing module is further configured to obtain interface information of the first BIER packet; The sending module is further configured to send the interface information of the first BIER packet to the controller.

17. A controller, wherein, Comprising: A receiving module, configured to receive multicast stream information sent by a first network device in a BIER domain and traffic statistics results of a first BIER packet, where the multicast stream information is used to identify the multicast stream to which the first BIER packet belongs; A processing module, configured to perform traffic analysis on the first BIER packet according to the multicast stream information and the traffic statistics results of the first BIER packet; wherein, The controller further includes: A sending module, configured to send a traffic statistics instruction to the first network device, where the traffic statistics instruction includes a multicast source group of first multicast data, and the traffic statistics instruction is used to instruct the first network device to perform traffic statistics on the first BIER packet including the multicast source group; wherein, The first network device is an ingress device in the BIER domain, and the controller only sends the traffic statistics instruction to the ingress device of the BIER domain, so that the first network device includes a traffic statistics identifier in the first BIER packet based on the traffic statistics instruction, and the traffic statistics identifier is used to indicate that traffic statistics is performed on the first BIER packet; The receiving module is further configured to receive interface information of the first BIER packet reported by the first network device; The processing module is further configured to determine a transmission path of the first BIER packet according to the interface information and physical topology information.

18. The controller according to claim 17, wherein, The receiving module is further configured to: receive a first correspondence relationship sent by the first network device, where the first correspondence relationship is a correspondence relationship between the multicast source group of the first multicast data and the multicast stream information.

19. The controller according to claim 17 or 18, wherein, The multicast stream information includes any one of the following: The bit forwarding ingress router identifier BFIR-ID and the entropy label in the BIER header of the first BIER packet; The source address SA and the flow label in the outer Internet Protocol version 6 IPv6 header of the first BIER packet; The multicast source group of the first multicast data in the inner layer of the first BIER packet; The virtual private network multicast source group of the first multicast data in the inner layer of the first BIER packet.

20. The controller according to claim 17 or 18, wherein, The receiving module is further configured to receive interface information of the first BIER packet sent by the first network device; The processing module is further configured to determine a transmission path of the first BIER packet according to the interface information of the first BIER packet and the physical topology information.

21. A first network device, wherein, includes: A processor and a memory, where the memory is used to store a program, and the processor is used to call and run the program from the memory to execute the method according to any one of claims 1 to 6.

22. A controller, wherein, includes: A processor and a memory, the memory being used for storing a program, and the processor being used for calling and running the program from the memory to execute the method according to any one of claims 7 to 10.

23. A system for explicit copy BIER multicast traffic statistics based on bit index, comprising a first network device according to any one of claims 11 to 16 and a controller according to any one of claims 17 to 20.

Images