CN114690680A - Data processing method, controller and first network equipment - Google Patents

Abstract

The present application provides a data processing method. The method includes: a controller receives a plurality of online operation management and maintenance IOAM information, and the plurality of IOAM information is an explicit copy of a bit index and reported by a plurality of devices in the BIER domain. , each IOAM information in the plurality of IOAM information includes a bit forwarding entry router identification BFIR ID, a bit index forwarding table identification BIFT ID and an entropy (entropy) value; the controller according to the plurality of IOAM information each A BFIR ID, a bit index forwarding table identification BIFT ID, and an entropy value associate the plurality of IOAM information to the first multicast stream. In the above method, the controller may associate multiple IOAM information respectively reported by multiple IOAM-DEX forwarding nodes to one multicast stream.

Description

Data processing method, controller and first network device

This application claims the priority of the Chinese patent application with the application number 202011562578.8 and the invention title "Method, Apparatus and System for Sending BIER Messages" filed with the China Patent Office on December 25, 2020, the entire contents of which are incorporated by reference in in this application.

technical field

The present application relates to the field of network communication, and more particularly, to a data processing method, a controller, and a first network device.

Background technique

Operations, administration and maintenance (OAM) is a network management technology that provides fault detection, fault reporting, fault location and fault repair for the network. Online operation management and maintenance (in-situ operations, administration and maintenance, IOAM) may also be called in-band OAM, which is responsible for detecting network performance parameters along with the flow. IOAM may include IOAM direct exporting (IOAM-DEX) mode and IOAM-trace (IOAM-trace) mode.

Taking the IOAM-DEX mode as an example, the network device needs to obtain the IOAM information according to the IOAM command and report it to the controller. In a related technical solution, the controller associates the IOAM information respectively reported by multiple devices with a specific multicast flow through a flow identifier (flow identifier, flow ID) in the IOAM information. In this solution, only the IOAM information can be associated with a specific multicast stream, and the device that forwards the multicast stream cannot be determined according to the IOAM information. When a fault such as packet loss occurs in the multicast stream, the controller cannot locate the fault.

SUMMARY OF THE INVENTION

The present application provides a data processing method, which enables a controller to associate multiple IOAM information respectively reported by multiple IOAM-DEX forwarding nodes with a multicast stream, and the controller can also determine the multiple IOAM information according to the multiple IOAM information. The network device that forwards the multicast stream can locate the fault when a packet loss occurs in the multicast stream.

In a first aspect, a data processing method is provided, the method includes: a controller receives a plurality of online operation management and maintenance IOAM information, the plurality of IOAM information is an explicit copy of a bit index and reported by a plurality of devices in a BIER domain respectively , each IOAM information in the multiple IOAM information includes bit forwarding entry router identification BFIR ID, bit index forwarding table identification BIFT ID and entropy (entropy) value; and according to each BFIR ID, The bit index forwarding table identifies the BIFT ID and the entropy value associating the plurality of IOAM information to the first multicast stream.

The above method enables the controller to associate multiple IOAM information respectively reported by multiple IOAM-DEX forwarding nodes with a multicast stream, and the controller can also determine the network device that forwards the multicast stream and its network device according to the multiple IOAM information. The set and sub-domain to which it belongs. When a fault such as packet loss occurs in the multicast stream, the set and sub-domain of the faulty device can be located.

With reference to the first aspect, in some implementations of the first aspect, the controller associates the multiple IOAM information according to the same BFIR ID, bit index forwarding table identifier BIFT ID and entropy value in the multiple IOAM information to the first multicast stream.

In combination with the first aspect, in some implementations of the first aspect, each IOAM information further includes a first field and a second field, and the first field is used to indicate the current device that reports the IOAM information to the controller The identifier of the second field is used to indicate the identifier of the next-hop neighbor device of the current device.

With reference to the first aspect, in some implementations of the first aspect, the identifier of the current device is the address of the current device, and the identifier of the next-hop neighbor device is the address of the next-hop neighbor device.

With reference to the first aspect, in some implementations of the first aspect, the method further includes: the controller restores the first group according to the first field and the second field of each IOAM information in the plurality of IOAM information The forwarding path of the stream.

With reference to the first aspect, in some implementations of the first aspect, each IOAM information in the plurality of IOAM information further includes IOAM tracking data, and the method further includes: the controller according to the forwarding path of the first multicast stream and the IOAM tracking data in the plurality of IOAM information to obtain the network performance between the ingress device and the egress device of the first multicast stream.

In a second aspect, a data processing method is provided, the method comprising: a first network device obtains an explicit copy BIER message of a bit index, where the BIER message includes a bit forwarding entry router identifier BFIR ID, a bit index forwarding table Identify the BIFT ID and entropy (entropy) value and directly derive the IOAM-DEX command header from online operation management and maintenance; the first network device obtains IOAM information according to the IOAM-DEX command header, and the IOAM information includes the BFIR ID, BIFT ID and entropy value; the first network device sends the IOAM information to the controller.

With reference to the second aspect, in some implementations of the second aspect, the method further includes: the first network device acquires the identifier of the first network device according to the IOAM-DEX command header, the first network device to the next The identifier of the hop neighbor device, the next hop neighbor device is the next hop of the destination device of the BIER message of the first network device; the first network device sends the identifier of the first network device and the first network device to the controller. The identity of a network device's next-hop neighbor device.

With reference to the second aspect, in some implementations of the second aspect, the identifier of the first network device is the address of the first network device, and the identifier of the next-hop neighbor device is the address of the next-hop neighbor device.

With reference to the second aspect, in some implementations of the second aspect, the method further includes: the first network device acquires IOAM tracking data according to the IOAM-DEX command header; the first network device sends the IOAM to the controller track data.

With reference to the second aspect, in some implementations of the second aspect, the first network device is a bit forwarding ingress router BFIR of the BIER domain, and the method further includes: the first network device receives a user message; the first network device The device encapsulates the user packet to obtain the BIER packet.

With reference to the second aspect, in some implementations of the second aspect, the first network device is a bit forwarding egress router BFER of the BIER domain, and the method further includes: the first network device decapsulates the BIER message to obtain Inner user packets.

In a third aspect, a controller is provided, comprising: a receiving module, a processing module,

The receiving module is used to receive multiple online operation management and maintenance IOAM information, the multiple IOAM information is reported by multiple devices in the BIER domain of the explicit copy of the bit index, and each IOAM information in the multiple IOAM information includes Bit forwarding entry router identifier BFIR ID, bit index forwarding table identifier BIFT ID, and entropy value;

The processing module is configured to associate the plurality of IOAM information with the first multicast stream according to each BFIR ID, bit index forwarding table identifier BIFTID and entropy value in the plurality of IOAM information.

In conjunction with the third aspect, in some implementations of the third aspect, the processing module is specifically configured to: according to the same BFIR ID, bit index forwarding table identification BIFT ID and entropy value in the multiple IOAM information, the A plurality of IOAM messages are associated with the first multicast stream.

With reference to the third aspect, in some implementations of the third aspect, each IOAM information further includes a first field and a second field, and the first field is used to indicate the current device that reports the IOAM information to the controller The identifier of the second field is used to indicate the identifier of the next-hop neighbor device of the current device.

With reference to the third aspect, in some implementations of the third aspect, the identifier of the current device is the address of the current device, and the identifier of the next-hop neighbor device is the address of the next-hop neighbor device.

With reference to the third aspect, in some implementations of the third aspect, the processing module is further configured to: restore the first group according to the first field and the second field of each IOAM information in the plurality of IOAM information The forwarding path of the stream.

With reference to the third aspect, in some implementations of the third aspect, each IOAM information in the plurality of IOAM information further includes IOAM tracking data, and the processing module is further configured to: according to the forwarding path of the first multicast stream and the IOAM tracking data in the plurality of IOAM information to obtain the network performance between the ingress device and the egress device of the first multicast stream.

In a fourth aspect, a first network device is provided, comprising: an obtaining module, a sending module,

The acquisition module is used to obtain the explicit copy BIER message of the bit index. The BIER message includes the bit forwarding entry router identifier BFIR ID, the bit index forwarding table identifier BIFT ID, and the entropy (entropy) value and the direct export of online operation management and maintenance. IOAM-DEX instruction header;

The obtaining module is further configured to obtain IOAM information according to the IOAM-DEX instruction header, where the IOAM information includes the BFIR ID, BIFT ID and entropy value;

The sending module is used for sending the IOAM information to the controller.

With reference to the fourth aspect, in some implementations of the fourth aspect, the obtaining module is further configured to: obtain the identifier of the first network device, the next-hop neighbor device from the first network device according to the IOAM-DEX command header The identifier of the next hop neighbor device is the next hop of the destination device of the BIER message of the first network device; the sending module is also used for: the first network device sends the controller of the first network device The identifier and the identifier of the next-hop neighbor device of the first network device.

With reference to the fourth aspect, in some implementations of the fourth aspect, the identifier of the first network device is the address of the first network device, and the identifier of the next-hop neighbor device is the address of the next-hop neighbor device.

In conjunction with the fourth aspect, in some implementations of the fourth aspect, the obtaining module is further configured to: obtain the IOAM tracking data according to the IOAM-DEX command header; the sending module is further configured to: send the IOAM tracking data to the controller data.

With reference to the fourth aspect, in some implementations of the fourth aspect, the first network device is a bit forwarding ingress router BFIR of the BIER domain, and the first network device further includes: a receiving module, an encapsulating module,

The receiving module is used to receive user messages;

The encapsulation module is used for encapsulating the user message to obtain the BIER message.

With reference to the fourth aspect, in some implementations of the fourth aspect, the first network device is a bit forwarding egress router BFER in the BIER domain, and the first network device further includes: a decapsulation module,

The decapsulation module is used to decapsulate the BIER message to obtain the inner user message.

In a fifth aspect, a controller is provided, the controller including a processor, a memory, an interface and a bus. The interface may be implemented in a wireless or wired manner, specifically a network card. The above-mentioned processor, memory and interface are connected by a bus.

Specifically, the interface may include a transmitter and a receiver, for the controller to implement the above-mentioned transceiver. For example, this interface is used to support receiving multiple IOAM messages.

This processor is used to execute the processing performed by the controller in the above-described embodiments. For example, the processor is configured to associate the plurality of IOAM messages with the first multicast stream according to each of the BFIR ID, bit index forwarding table identification BIFT ID and entropy value in the plurality of IOAM messages; and/or for Other procedures for the techniques described herein. The memory includes an operating system and an application program, and is used to store programs, codes or instructions. When the processor or hardware device executes these programs, codes or instructions, the processing process involving the controller in the method embodiment can be completed. Optionally, the memory may include read-only memory (ROM) and random access memory (RAM). Wherein, the ROM includes a basic input/output system (basic input/output system, BIOS) or an embedded system; the RAM includes an application program and an operating system. When the controller needs to be run, the system is booted through the BIOS solidified in the ROM or the bootloader in the embedded system, and the controller is guided into a normal operation state. After the controller enters the normal running state, the application program and the operating system running in the RAM, thereby completing the processing process related to the controller in the method embodiment in the above-mentioned first aspect and any possible implementation manner.

It will be appreciated that, in practical applications, the controller may contain any number of interfaces, processors or memories.

In a sixth aspect, a first network device is provided, where the first network device includes a processor, a memory, an interface, and a bus. The interface may be implemented in a wireless or wired manner, specifically a network card. The above-mentioned processor, memory and interface are connected by a bus.

Specifically, the interface may include a transmitter and a receiver, which are used by the first network device to implement the above-mentioned transceiving. For example, this interface is used to support sending IOAM information to the controller. For another example, this interface is used to support sending BIER packets.

The processor is configured to execute the processing performed by the first network device in the above embodiment. For example, the processor is used to obtain BIER messages; to obtain IOAM information from the IOAM-DEX instruction header; and/or other processes for the techniques described herein. The memory includes an operating system and an application program, and is used to store programs, codes or instructions. When the processor or the 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 may include read-only memory (ROM) and random access memory (RAM). Wherein, the ROM includes a basic input/output system (basic input/output system, BIOS) or an embedded system; the RAM includes an application program and an operating system. When the first network device needs to be run, the system is booted through the BIOS solidified in the ROM or the bootloader in the embedded system to boot the first network device into a normal operation state. After the first network device enters the normal running state, the application program and the operating system running in the RAM, thereby completing the processing process involving the first network device in the method embodiment of the above-mentioned first aspect and any possible implementation manner .

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

In a seventh aspect, a computer program product is provided, the computer program product comprising: computer program code, when the computer program code is run on the controller, the controller executes the first aspect or any one of the first aspects possible methods.

In an eighth aspect, a computer program product is provided, the computer program product comprising: computer program code, when the computer program code is executed on the first network device, the first network device is made to perform the above-mentioned second aspect or the second aspect any possible method of implementation.

In a ninth aspect, a computer-readable medium is provided, and the computer-readable medium stores program codes that, when the computer program codes are executed on the controller, cause the controller to execute the above-mentioned first aspect or any one of the first aspects a possible way to do it. 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 (erasablePROM, EPROM), Flash Memory, electrical EPROM (electrically EPROM, EEPROM) and hard drive (harddrive).

In a tenth aspect, a computer-readable medium is provided, the computer-readable medium stores program codes, and when the computer program codes are executed on the first network device, the first network device is made to execute the above-mentioned second aspect or the second Any possible method of performing the aspect. 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 (erasable PROM, EPROM), Flash memory, electrical EPROM (electrically EPROM, EEPROM) and hard drive (hard drive).

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

A twelfth aspect provides a chip, the chip includes a processor and a data interface, wherein the processor reads an instruction stored in a memory through the data interface to execute the second aspect or any possible implementation of the second aspect method in method. In the specific implementation process, the chip can be a central processing unit (CPU), a microcontroller (micro controller unit, MCU), a microprocessor (micro processing unit, MPU), a digital signal processor (digital signal processor) processing, DSP), system on chip (system on chip, SoC), application-specific integrated circuit (application-specific integrated circuit, ASIC), field programmable gate array (field programmable gate array, FPGA) or programmable logic device (programmable logic device, PLD) is implemented in the form of.

In a thirteenth aspect, a system is provided, the system including the controller in the third aspect and any possible implementation manner, the fourth aspect and the first network device in any possible implementation manner.

Description of drawings

Figure 1 is a schematic block diagram of a BIER domain.

Figure 2 is a schematic block diagram of one possible BIER header format.

Figure 3 is a schematic block diagram of another possible BIER header format.

FIG. 4 is a schematic diagram of a scenario of BIER forwarding.

FIG. 5 is a schematic flowchart of a data processing method provided by an embodiment of the present application.

FIG. 6 is a schematic flowchart of another data processing method provided by an embodiment of the present application.

FIG. 7 is a schematic block diagram of an IOAM-DEX command header.

FIG. 8 is a schematic structural diagram of a controller 800 provided by an embodiment of the present application.

FIG. 9 is a schematic structural diagram of a first network device 900 provided by an embodiment of the present application.

FIG. 10 is a schematic diagram of a hardware structure of a first network device 2000 according to an embodiment of the present application.

FIG. 11 is a schematic diagram of a hardware structure of another first network device 2100 provided by an embodiment of the present application.

FIG. 12 is a schematic diagram of a hardware structure of a controller 2200 provided by an embodiment of the present application.

Detailed ways

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

In this application, "at least one" means one or more, and "plurality" means two or more. "And/or", which describes the relationship of the associated objects, means that there can be three relationships, for example, A and/or B, which can mean: including the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character "/" generally indicates that the associated objects are an "or" relationship. "At least one item(s) below" or similar expressions thereof refer to any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (a) of a, b, or c can represent: a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, c may be single or multiple .

Multicast (multicast) is a data transmission method that sends data to multiple recipients on a Transmission Control Protocol (TCP)/Internet Protocol (IP) network in an efficient manner by using a multicast address . The multicast source sends the multicast stream to the members of the multicast group via the links in the network, and all the members of the multicast group can receive the multicast stream. The multicast transmission mode realizes the point-to-multipoint data connection between the multicast source and the members of the multicast group. Since the multicast stream only needs to be transmitted once on each network link, and only when the link has a branch, the multicast will be replicated. Therefore, the multicast transmission method improves the data transmission efficiency and reduces the possibility of congestion in the backbone network.

The Internet Protocol (IP) multicast technology realizes efficient point-to-multipoint data transmission in an IP network, which can effectively save network bandwidth and reduce network load. Therefore, it is widely used in many aspects such as real-time data transmission, multimedia conference, data copying, internet protocol television (IPTV), games and simulation. However, this multicast technology needs to use a multicast protocol to build a multicast tree, and then use the multicast tree to logically tree the network plane to implement multicast point-to-multipoint data forwarding. This kind of intermediate equipment with the construction of the distribution tree as the core needs to maintain the complex multicast forwarding information state. As the network scale is getting larger and larger and the traffic of multicast packets is increasing day by day, this multicast technology faces more and more challenges in terms of cost and operation and maintenance.

To this end, the industry has proposed a new technology for building multicast packet forwarding paths, which is called bit index explicit replication (BIER) technology. Figure 3 illustrates the related concepts of BIER technology.

As shown in Fig. 1, a router supporting the BIER technology is called a Bit-forwarding router (BFR). In the BIER domain, a BFR that encapsulates a user message (also referred to as a service message) to obtain a BIER message is called a bit forwarding ingress router (BFIR). The BFR that decapsulates the user message from the BIER message is called a Bit Forwarding Egress Router (BFER). The network domain that transmits BIER packets, which is composed of the above-mentioned BFIR and one or more BFERs, is called a BIER domain (BIER domain). Optionally, the BIER domain may also include one or more BFRs. Among them, BFIR is located at the entrance of the BIER domain. As the head node of BIER packet forwarding, it is responsible for BIER encapsulation of user packets; BFER is located at the exit position of the BIER domain, and as the tail node of BIER packet forwarding, it is responsible for decoding BIER packets. package. It should be understood that BFIR and BFER in the BIER domain can also be referred to as edge BFRs in the BIER domain.

The above BIER message includes a BIER header and a user message. The user message may be an Internet Protocol version 6 (Internet Protocol version 6, IPv6) multicast message, or may also be an Internet Protocol version 4 (Internet Protocol version 4, IPv4) multicast message, or It is an Ethernet (Ethernet) message, which is not specifically limited in this application. The BIER header may include a bit string (Bit String) field, where the Bit String marks all destination devices of the user message. It should be understood that all destination devices of the user packet may be a set of multiple BFERs to which the user packet needs to be sent.

This embodiment of the present application does not specifically limit the format of the BIER header, as long as the BIER header includes a Bit String field. Two possible formats of the BIER header are described in detail below with reference to Figures 2 to 3 respectively.

Figure 2 is a schematic block diagram of one possible BIER header format. As shown in Figure 2, the BIER header may include but is not limited to: bit index forwarding table identifier (BIFT ID), bit string length (BSL), 64bit (8 bytes) Other fields, for example, the traffic type (traffic class, TC), stack (stack, S), time to live (TTL) field, entropy (entropy) field, version of the original multicast data packet after the BIER header number (version, Ver) field, nibble (nibble) field, protocol (protocol, proto) field, operation administration and maintenance (OAM) field, reserve (reserve, Rsv) field, differentiated services code point ( differential service code points, DSCP) fields, etc.

The fields in the BIER header are described in detail below.

(1) BIFT ID field

The BIFT ID is an MPLS label (label, L) under BIER Multi Protocol Label Switching (Multi Protocol Label Switching, MPLS) encapsulation. A BIFT ID may correspond to a combination of sub-domain (sub-domain, SD)/bit string length (BSL)/set identifier (set identifier, SI). That is, different BIFT IDs may correspond to different SD/BSL/SI combinations.

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

1. Sub-domain (SD)

A BIER domain can be divided and configured into different SDs according to the requirements of actual business scenarios to support features such as Interior Gateway Protocol (Interior Gateway Protocol, IGP) multi-topology. Each BIER domain must contain at least one sub-domain, the default sub-domain 0. When dividing multiple sub-domains, each BFR router in the BIER domain must configure all sub-domains. For example, you can configure a sub-domain 0 on each BFR router in the BIER domain to use the system default topology, and configure a sub-domain 1 to use the multicast topology.

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

It should be noted that multiple VPNs can also use the same SD, and different SDs in the BIER domain can be in an Interior Gateway Protocol (IGP) process or topology, or not in an IGP process or topology. This is not specifically limited in the application examples.

2. Bit String Length (BSL)

BSL is the length of the bit string included in the BIER header. There may be multiple BSLs, which are not specifically limited in this embodiment of the present application. The smallest BSL is 64 bits, and the BSL can also have 128 bits, 256 bits, 512 bits, 1024 bits, 2048 bits, and the largest BSL is 4096 bits. Specifically, the message is identified by 4 bits. For example, when the BSL is 64 bits, the message is identified with 0001; when the BSL is 128 bits, the message is identified with 0010; when the BSL is 512 bits, the message The text is marked with 0100. When the BSL is 1024 bits, the message is marked with 0101, and so on.

3. Set Identifier (SI)

If the number of BFER devices in the network is greater than 256, in order to adapt to this situation, the BIER package contains not only a Bit String, but also a Set Identifier (SI). The role of SI is to divide the number of BIER devices into multiple different intervals, thereby supporting larger-scale network addressing.

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

After receiving the BIER message, the BFR in the BIER domain can determine which SD the BIER message belongs to, the BSL used, and which SI of the BSL the message belongs to according to the BIFT ID in the BIER header.

The following lists the corresponding SD/BSL/SI combinations represented by several possible BIFT IDs.

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

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

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

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

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

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

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

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

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

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

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

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

It should be noted that the BIFT-ID field in the BIER message can identify SI, sub-domain and BSL. If the packet is to be sent to specific BFR neighbors (Neighbors, NBRs), the BIFT-ID field can be changed to the same value as the SI, sub-domain and BSL advertised by the BFR NBRs. It has the following functions: obtain the length of the Bit String of the BIER header through BSL; through BSL and SI, you can know whether the BFR ID represented by the Bit String belongs to the range of 1 to 256 or 257 to 512 or other ranges; The subdomain to which it belongs can be found.

(2) Bit String field

Each bit in the Bit String is used to identify the edge BFR, for example, the lower (rightmost) bit of the bit string is used to identify the BFER with BFR ID=1. The second bit from right to left in the bit string is used to identify the BFER with BFR ID=2. The forwarding entry on the forwarding plane is based on the bit string in the packet to determine which BFERs to send the packet to. When the BFR in the BIER field receives the BIER header, it forwards the BIER packet according to the bit string and BIFT ID carried in the BIER header.

It should be noted that a bit value of 1 indicates that the packet is to be sent to the BFER device represented by the BFR ID, and a bit value of 0 indicates that the packet does not need to be sent to the BFER device represented by the BFR ID. Taking BIFT ID=2 as an example, after receiving the BIER message, the BFR can obtain that the BIER message belongs to SD 0 according to the BIFT ID in the BIER header, and the BSL used in the BIER header is 256 bits, belonging to set 1 (including BFR). A set of 256 edge BFRs with IDs 257 to 512).

(3) Entropy field

used for load sharing. BIER forwarding may perform equal-cost load balancing. In this case, load balancing must select the same path for two BIER packets with the same entropy and bit string. That is to say, the entropy of multiple packets belonging to a multicast stream is the same, and the entropy of multiple packets of different multicast streams is different. When packets are forwarded, different multicast streams can be shared on different links according to entropy, and multiple packets of the same multicast stream go on the same link. It should be understood that, in order to ensure that different entropy identifies different multicast streams, when BFIR allocates entropy, it is required to allocate different entropy labels based on different multicast streams, which cannot be repeated.

(4)BFIR ID

BFIR ID can also be understood as the BFR ID of BFIR. The BFIR encapsulates the BIER header on the user message to obtain the BIER message. Therefore, the BFIR ID field in the BIER header needs to be filled with the BFR ID under the sub-domain of the BFIR. The BFIR ID can identify the BFIR from which the multicast stream is sent, so as to uniquely identify a multicast stream.

Figure 3 is a schematic block diagram of another possible BIER header format. Compared with the BIER header format shown in FIG. 2 , the BIER header format shown in FIG. 3 does not contain the BIFT ID field, but is shown to contain three fields of SD/BSL/SI. That is to say, the BIER header format shown in FIG. 3 directly includes three fields of SD/BSL/SI, without mapping SD/BSL/SI values from the BIFT ID field. It should be understood that the fields included in the BIER header format shown in FIG. 3 are similar to the fields included in the BIER header format shown in FIG. 2 , and for specific descriptions of the fields in the BIER header format shown in FIG. 3, please refer to FIG. 2 The descriptions in , will not be repeated here.

FIG. 4 is a schematic diagram of a scenario of BIER forwarding. As shown in FIG. 4 , as an ingress device of the BIER domain, device A is responsible for performing BIER encapsulation on user messages to obtain BIER messages, which corresponds to the BFIR in FIG. 1 . Device D, device E, and device F are egress devices in the BIER domain, responsible for decapsulating user packets from BIER packets, corresponding to BFER in FIG. 1 . Device B and Device C belong to intermediate forwarding devices in the BIER domain, corresponding to the BFR in FIG. 1 .

As an example, a unique BFR ID can be assigned to each edge BFR in the BIER domain. For example, in Figure 4, the BFR IDs configured for device A, device E, device D, and device F are 2. It should be noted that, in the embodiments of the present application, "ID" and "id" may sometimes be used interchangeably. It should be noted that, when the difference is not emphasized, the meanings to be expressed are the same. Wherein, the BFR ID in this application may refer to the id in FIG. 4 .

Operations, administration and maintenance (OAM) is a network management technology that provides fault detection, fault reporting, fault location and fault repair for the network. Online operation management and maintenance (in-situ operations, administration and maintenance, IOAM) may also be called in-band OAM, which is responsible for detecting network performance parameters along with the flow. IOAM can include IOAM direct exporting (IOAM-DEX) mode, IOAM Edge-to-Edge (IOAM Edge-to-Edge), IOAM Proof of Transit (IOAM Proof of Transit), and IOAM-trace (IOAM-trace) mode. Taking the IOAM-DEX mode as an example, device A, device B, device C, device D, device E, and device F in Figure 4 (for ease of description, may also be referred to as device A-device F) can be IOAM-DEX forwarding Each IOAM-DEX forwarding node needs to obtain the IOAM information according to the IOAM command and report it to the controller respectively. It should be understood that the IOAM information reported by each IOAM-DEX forwarding node may include the IOAM information obtained by each IOAM-DEX forwarding node according to the IOAM-DEX instruction.

In a related technical solution, the controller associates a plurality of IOAM information with a specific multicast flow through a flow identifier (flow identifier, flowID) in the IOAM information. In this solution, only the IOAM information can be associated with a specific multicast stream, and the network device that forwards the multicast stream and the SD/BSL/SI to which it belongs cannot be determined according to the IOAM information. When a fault such as packet loss occurs in the multicast stream, the controller cannot locate the faulty device and its SD/BSL/SI.

In view of this, an embodiment of the present application provides a data processing method, the method enables the controller to associate multiple IOAM information respectively reported by multiple IOAM-DEX forwarding nodes with one multicast stream, and the controller further The network device that forwards the multicast stream and its set and sub-domain can be determined according to multiple IOAM information. When a fault such as packet loss occurs in the multicast stream, the set and sub-domain of the faulty device can be located.

A data processing method provided by an embodiment of the present application will be described in detail below with reference to FIG. 5 .

FIG. 5 is a schematic flowchart of a data processing method provided by an embodiment of the present application. As shown in FIG. 5, the method may include steps 510-520, and the steps 510-520 will be described in detail below respectively.

Step 510: The controller receives multiple IOAM messages.

Taking the scenario shown in FIG. 4 as an example, devices A-device F report IOAM information to the controller respectively, and the IOAM information reported by each device may include, but is not limited to: BFIR ID, BIFT ID, and entropy value. Specifically, as an example, after acquiring the BIER message, each device may report the IOAM information to the controller according to the IOAM-DEX command header in the BIER message. For the specific format of the IOAM-DEX command header, please refer to the description in FIG. 6 , which will not be described in detail here.

Optionally, in some embodiments, the IOAM information reported by each device may further include the identifier of the current device that reports the IOAM information to the controller, and the identifier of the next-hop neighbor device of the current device. As an example, the identification may be the address of the device. Taking the identifier of the current device as an example, the identifier may be an IPv4 address or an IPv6 address of the current device.

Optionally, in some embodiments, the IOAM information reported by each device may further include IOAM tracking data (also referred to as IOAM measurement data). The IOAM tracking data may include some corresponding network parameters collected by the device that reports the IOAM information to the controller. Specifically, as an example, the network parameter may include, but is not limited to, a combination of one or more of the following: forwarding delay of the node, queue length of the node, time stamp of the packet arriving at the node, time of the packet leaving the node stamp, the ID of the inbound interface that the node receives the packet, and the ID of the outbound interface that the node sends the packet.

Step 520: The controller associates the plurality of IOAM information with the first multicast stream according to each BFIR ID, bit index forwarding table identifier BIFT ID and entropy value in the plurality of IOAM information.

After acquiring the multiple IOAM information reported by the multiple devices, the controller may associate the multiple IOAM information with the first multicast stream according to each BFIR ID, BIFT ID and entropy value in the multiple IOAM information. Specifically, as an example, the controller associates the multiple IOAM information with the same multicast stream according to the same BFIR ID, the same BIFT ID, and the same entropy value in the multiple IOAM information.

In the above technical solution, the controller may associate multiple IOAM information respectively reported by multiple devices to one multicast stream. In addition, the controller can also determine the sub-domain, BSL and SI to which the multicast stream belongs according to the BFIR ID in the IOAM information. In this way, the controller can determine the network device that forwards the multicast stream (for example, the ingress node and egress device that forwards the multicast stream in the BIER domain), and can locate the fault when the multicast stream has a packet loss or other fault. .

Optionally, in some embodiments, the controller may further restore the forwarding path of the multicast stream according to the identifier of the current device in the IOAM information and the identifier of the next-hop neighbor device of the current device. That is to say, the controller can determine the network device forwarding the multicast stream on the basis of associating the above-mentioned multiple IOAM information with one multicast stream, so as to associate the multiple IOAM information with the one that forwards the multicast stream. Network devices are associated. In this way, when a fault such as packet loss occurs in the multicast stream, the faulty device can be determined, thereby accurately locating the fault.

Optionally, in some embodiments, the controller may further obtain the network performance between the ingress device and the egress device of the multicast stream according to the IOAM tracking data in the IOAM information.

The following takes the forwarding scenario shown in FIG. 4 as an example, and in conjunction with FIG. 6 , a specific implementation manner of a data processing method provided by an embodiment of the present application will be described in detail. It should be understood that the example in FIG. 6 is only for helping those skilled in the art to understand the embodiments of the present application, and is not intended to limit the embodiments of the present application to specific numerical values or specific scenarios exemplified. Those skilled in the art can obviously make various equivalent modifications or changes according to the example of FIG. 6 given below, and such modifications and changes also fall within the scope of the embodiments of the present application.

FIG. 6 is a schematic flowchart of another data processing method provided by an embodiment of the present application. Referring to FIG. 6 , the method may include steps 610-670, and the steps 610-670 will be described in detail below, respectively.

It should be understood that the above-mentioned first network device may be any one of device A, or device B, or device C, or device D, or device E, or device F in FIG. 6 .

Step 610: After receiving the user message, device A obtains a BIER message according to the user message.

As an example, before receiving the user message, device A may establish a BIFT (for example, a BIFT with ID=1), where the BIFT is used to instruct device A to forward the BIER message. By way of example, a method for establishing BIFT by device A is described in detail below.

As an example, each edge BFR in the BIER domain may flood the allocated BFR IDs in the BIER domain through an interior gateway protocol (IGP) or an exterior gateway protocol (BGP), so as to facilitate the Other edge BFRs can establish BIFT based on the flooded information. For example, for device A, it can obtain by flooding that the BFR ID of device E is 1, the BFR ID of device F is 2, and the BFR ID of device D is 3. If device A needs to send BIER packets to device E with BFR ID 1, device F with BFR ID 2, and device D with BFR ID 3, and device A to the next device of device E, device F, and device D The hop devices are all device B, and the BIFT established by device A is: neighbor (neighbor, Nbr)=B, forwarding bit mask (forwarding bit mask, FBM)=0111. Among them, Nbr=B indicates that the neighbor of device A is device B, and FBM=0111 indicates that when there is a bit string of a BIER message, any one of the first bit, the second bit, and the third bit from right to left When it is 1, the above BIFT is used to instruct device A to send the BIER message to device B.

Device A, as the ingress device of the BIER domain, is responsible for performing BIER encapsulation on user packets to obtain BIER packets. In the embodiment of the present application, the device A may encapsulate the BIER header on the user message, and insert the IOAM-DEX command header into the BIER header. That is, the BIER message obtained by device A may include: a BIER header, an IOAM-DEX command header, and a user message.

For the format of the above-mentioned BIER header, reference may be made to the description in FIG. 2 or FIG. 3 above, which will not be repeated here. As an example, in the BIER packet encapsulated by device A, the bit string field of the BIER header indicates all destination devices of the BIER packet. Assume that the recipients of the user packets are the destination device D with BFR ID 3, the destination device F with BFR ID 2, and the destination device E with BFR ID 1, respectively, and send the messages to device D, device E, and device F respectively. The multiple sent packets belong to the first multicast stream. For example, the bit string field in the BIER header encapsulated by device A may be 0111; the BFIR ID field of the BIER header may be the BFR ID of device A (for example, the BFR ID of device A is 4); the entropy of the BIER header The field may be 1, which is used to identify the above-mentioned first multicast stream; the value of the BIFT ID field of the BIER header is 1.

For the format of the IOAM-DEX instruction header provided by the embodiment of the present application, reference may be made to FIG. 7 . As shown in FIG. 7 , the IOAM instruction header may include, but is not limited to: an IOAM-trace-type field, a Flow ID field, an identification field of the current node, an identification field of a next-hop node, and the like. The Flow ID field is used to indicate the ID of a multicast flow. The identifier field of the current node is used to indicate the identifier of the node that currently reports IOAM information. As an example, the identifier of the node that currently reports IOAM information can be the address of the node (it can also be expressed as Local BFR-prefix). For example, on the node an IPv4 address or an IPv6 address. The identifier field of the next-hop node is used to indicate the node identifier of the next-hop neighbor of the node that currently reports the IOAM information. As an example, the node identifier of the next-hop neighbor of the node that currently reports IOAM information may be the address of the next-hop neighbor (which may also be expressed as Next BFR-prefix), for example, an IPv4 address on the next-hop neighbor or IPv6 address. The IOAM-trace-type field is used to instruct the node to collect the corresponding network parameters (also called IOAM trace data or IOAM measurement values). network parameters. For example, the network parameters that the node needs to collect may include, but are not limited to, one or a combination of the following: the forwarding delay of the node, the queue length of the node, the time stamp of the packet arriving at the node, and the time when the packet leaves the node stamp, the ID of the inbound interface that the node receives the packet, and the ID of the outbound interface that the node sends the packet.

It should be understood that the identification field of the next-hop node is used to indicate the node identification of the next-hop neighbor of the node that currently reports the IOAM information. The next-hop neighbor node may be one device, or may also be multiple devices. This is not specifically limited. If there are multiple next-hop neighbor nodes, the identifiers of the multiple next-hop neighbor nodes can be reported to the controller.

Optionally, the above-mentioned node identifier that currently reports the IOAM information and the node identifier of the next-hop neighbor may also indicate records through the IOAM-trace-type field. For example, the IOAM-trace-type field may be extended, and a bit of the IOAM-trace-type field may be used to indicate the identifier of the node that records the currently reported IOAM information and the identifier of the next-hop neighbor node.

Step 613: Device A obtains IOAM information according to the IOAM-DEX command header in the BIER message.

Device A can obtain IOAM information data according to the IOAM-DEX command header. The IOAM information may include but is not limited to: the corresponding network parameters collected according to the IOAM-trace-type field of the IOAM-DEX command header, the Local BFR-prefix field (for example, this field is the BFR-prefix of device A), Next BFR-prefix field (for example, this field is the BFR-prefix of device B), BFIR ID in the BIER header (for example, the BFR ID of device A, the value is 4), BIFT ID (for example, the value is 1) , entropy (for example, the value is 1), etc.

Step 615: Device A sends the IOAM information to the controller.

Device A may send the IOAM information to the controller after acquiring the IOAM information.

Step 617: Device A sends a BIER message to device B.

Device A may also send the BIER message to the neighbor of device A (device B) according to the bit string field of the BIER header as 0111 and the above BIFT with ID=1.

Step 620: After receiving the BIER message, the device B obtains the IOAM information according to the IOAM-DEX command header in the BIER message.

As an example, before receiving the BIER message, device B may establish a BIFT (for example, a BIFT with ID=1), where the BIFT is used to instruct device B to forward the BIER message. As an example, the BFR ID of the device E can be set to 1, the BFR ID of the device F can be set to 2, and the BFR ID of the device D can be set to 3 through flooding. If device B needs to send BIER packets to device E with BFRID 1, device F with BFR ID 2, and device D with BFR ID 3, and the next hop device from device B to device E and device F is the device C, the next hop device to device D is device D. Therefore, the BIFT established by device B is: Nbr=C, FBM=0011; Nbr=D, FBM=0100. Among them, Nbr=C in the entry <Nbr=C, FBM=0011> indicates that the neighbor of device B is device C, and FBM=0011 indicates that when there is a bit string of a BIER packet, the first bit, the first bit from the right and the left When any one of the two bits is 1, the above BIFT is used to instruct device B to send the BIER message to device C. Nbr=D in the entry <Nbr=D, FBM=0100> indicates that the neighbor of device B is device D, and FBM=0100 indicates that when the third bit of the bit string of the BIER message from right to left is 1, The BIFT is used to instruct device B to send the BIER message to device D.

After receiving the BIER message sent by device A, device B can obtain IOAM information according to the IOAM-DEX command header in the BIER message. The IOAM information may include, but is not limited to: the corresponding network parameters collected according to the IOAM-trace-type field of the IOAM-DEX command header, the Local BFR-prefix field (for example, this field is the BFR-prefix of device B), Next BFR-prefix field (for example, this field is the BFR-prefix of device C and device D), BFIR ID in the BIER header (for example, the BFR ID of device A, the value is 4), BIFT ID (for example, the value is 1), entropy (for example, the value is 1), etc. It should be understood that, for the description of the network parameters, please refer to the above description, which will not be described in detail here.

Step 623: Device B sends the IOAM information to the controller.

After acquiring the IOAM information, device B can send the IOAM information to the controller.

Step 625: Device B sends a BIER message to device C and device D.

Device B may also send the BIER message to the neighbors of device B (device C and device D) according to the bit string field of the BIER header as 0111 and the above BIFT with ID=1. Specifically, as an example, when device B sends the BIER message to device C, it can perform AND operation on the bit string (0111) of the BIER header and the FBM field (0011) corresponding to Nbr=C in the BIFT entry. The result of AND in the example is 0011. Therefore, device B can modify the bit string in the BIER header of the BIER packet to 0011, and send the BIER packet to device C. In another example, when device B sends the BIER message to device D, it can perform an AND operation on the bit string (0111) of the BIER header and the FBM field (0100) corresponding to Nbr=D in the BIFT entry. The result of the AND is 0100. Therefore, device B can modify the bit string in the BIER header of the BIER packet to 0100, and send the BIER packet to device D.

Step 630: After receiving the BIER message, the device C obtains the IOAM information according to the IOAM-DEX command header in the BIER message.

As an example, before receiving the BIER message, device C may establish a BIFT (for example, a BIFT with ID=1), where the BIFT is used to instruct device C to forward the BIER message. As an example, the BFR ID of the device E can be set to 1, the BFR ID of the device F can be set to 2, and the BFR ID of the device D can be set to 3 through flooding. If device C needs to send BIER packets to device E with a BFR ID of 1, device F with a BFR ID of 2, and device D with a BFR ID of 3, and the next hop from device C to device E is device E, to device The next-hop device of F is device F, and the next-hop device of device D is device D. Therefore, the BIFT established by device C is: Nbr=E, FBM=0001; Nbr=F, FBM=0010; Nbr=D, FBM=0100. Among them, Nbr=E in the entry <Nbr=E, FBM=0001> indicates that the neighbor of device C is device E, and FBM=0001 indicates that when there is a bit string of a BIER packet, the first bit from right to left is 1 , the BIFT is used to instruct device C to send the BIER message to device E. Nbr=F in the entry <Nbr=F, FBM=0010>, the neighbor of device C is device F, and FBM=0010 means that when the second bit from right to left of the bit string of the BIER packet is 1, the BIFT is used to instruct device C to send the BIER message to device F. Nbr=D in the entry <Nbr=D, FBM=0100> indicates that the neighbor of device C is device D, and FBM=0100 indicates that when the third bit from right to left of the bitstring of the BIER packet is 1, the BIFT is used to instruct device C to send the BIER message to device D.

After receiving the BIER message sent by device B, device C can obtain IOAM information according to the IOAM-DEX command header in the BIER message. The IOAM information may include, but is not limited to: the corresponding network parameters collected according to the IOAM-trace-type field of the IOAM-DEX command header, the Local BFR-prefix field (for example, this field is the BFR-prefix of device C), Next BFR-prefix field (for example, this field is the BFR-prefix of device E and device F), BFIR ID in the BIER header (for example, the BFR ID of device A, the value is 4), BIFT ID (for example, the value is 1), entropy (for example, the value is 1), etc. It should be understood that, for the description of the network parameters, please refer to the above description, which will not be described in detail here.

Step 633: Device C sends the IOAM information to the controller.

After acquiring the IOAM information, the device C can send the IOAM information to the controller.

Step 635: Device C sends a BIER message to device E and device F.

Device C may also send the BIER message to the neighbors (device E and device F) of device C respectively according to the bit string field of the BIER header being 0011 and the above ID=1BIFT. Specifically, as an example, when device C sends the BIER message to device E, it can perform AND operation on the bit string (0011) of the BIER header and the FBM field (0001) corresponding to Nbr=E in the BIFT entry. The result of AND in the example is 0001. Therefore, device C can modify the bit string in the BIER header of the BIER packet to 0001, and send the BIER packet to device E. In another example, when device C sends the BIER message to device F, it can perform an AND operation on the bit string (0011) of the BIER header and the FBM field (0010) corresponding to Nbr=F in the BIFT entry. The result of AND is 0010. Therefore, device C can modify the bit string in the BIER header of the BIER packet to 0010, and send the BIER packet to device F.

Step 640: After receiving the BIER message, the device D obtains the IOAM information according to the IOAM-DEX command header in the BIER message.

As an example, device D may establish a BIFT (eg, BIFT with ID=1) before receiving the BIER message. As an example, the BFR ID of device D is 3, and the BIFT established by device D is: Nbr=*D*, FBM=0100. Among them, the identifier * means itself, Nbr=*D* means that the next hop device of device D is itself, and FBM=0100 means that when the third bit of the bit string of the BIER message from right to left is 1, the above BIFT It is used to instruct device D to send the BIER message to itself. For example, device D decapsulates BIER packets.

After receiving the BIER message sent by device B, device D can obtain IOAM information according to the IOAM-DEX command header in the BIER message. The IOAM information may include, but is not limited to: the corresponding network parameters collected according to the IOAM-trace-type field of the IOAM-DEX command header, the Local BFR-prefix field (for example, this field is the BFR-prefix of device D), Next BFR-prefix field (for example, this field is the BFR-prefix of device D), BFIR ID in the BIER header (for example, the BFR ID of device A, the value is 4), BIFT ID (for example, the value is 1) , entropy (for example, the value is 1), etc. It should be understood that, for the description of the network parameters, please refer to the above description, which will not be described in detail here.

Step 643: Device D sends the IOAM information to the controller.

Device D may send the IOAM information to the controller after acquiring the IOAM information.

Step 645: Device D decapsulates the BIER packet.

Device D can also determine that it is an egress device of the BIER domain according to the bit string field of the BIER header as 0100 and the FBM field (0100) corresponding to Nbr=*D* in the BIFT entry with ID=1. BIER packets are decapsulated to obtain inner user packets. Specifically, as an example, device D may remove the BIER header and the IOAM-DEX command header in the BIER packet, obtain the inner user packet, and forward the user packet.

Step 650: After receiving the BIER message, the device E obtains the IOAM information according to the IOAM-DEX command header in the BIER message.

As an example, the device E may establish a BIFT (eg, BIFT with ID=1) before receiving the BIER message. As an example, the BFR ID of the device E is 1, and the ID=1 BIFT established by the device E is: Nbr=*E*, FBM=0001. Among them, the mark * indicates itself, Nbr=*E* indicates that the next hop device of device E is itself, and FBM=0001 indicates that when the first bit of the bitstring of the BIER message from right to left is 1, the above BIFT uses To instruct device E to send the BIER message to itself. For example, device E decapsulates BIER packets.

After receiving the BIER message sent by device C, device E can obtain IOAM information according to the IOAM-DEX command header in the BIER message. The IOAM information may include, but is not limited to: the corresponding network parameters collected according to the IOAM-trace-type field of the IOAM-DEX command header, the Local BFR-prefix field (for example, this field is the BFR-prefix of the device E), Next BFR-prefix field (for example, this field is the BFR-prefix of device E), BFIR ID in the BIER header (for example, the BFR ID of device A, the value is 4), BIFT ID (for example, the value is 1) , entropy (for example, the value is 1), etc. It should be understood that, for the description of the network parameters, please refer to the above description, which will not be described in detail here.

Step 653: Device E sends the IOAM information to the controller.

After acquiring the IOAM information, the device E can send the IOAM information to the controller.

Step 655: Device E decapsulates the BIER packet.

Device E can also determine that it is an egress device in the BIER domain according to the bit string field of the BIER header as 0001 and the FBM field (0001) corresponding to Nbr=*E* in the above BIFT entry. Device E processes the BIER message. Decapsulate to obtain inner user packets. Specifically, as an example, the device E may remove the BIER header and the IOAM-DEX command header in the BIER packet, obtain the inner layer user packet, and forward the user packet.

Step 660: After receiving the BIER message, the device F obtains the IOAM information according to the IOAM-DEX command header in the BIER message.

As an example, device F may establish a BIFT (eg, BIFT with ID=1) before receiving the BIER message. As an example, the BFR ID of device F is 2, and the BIFT of ID=1 established by device F is: Nbr=*F*, FBM=0010. Among them, the mark * indicates itself, Nbr=*F* indicates that the next hop device of device F is itself, and FBM=0010 indicates that when the second bit of the bitstring of the BIER message from right to left is 1, the above BIFT uses To instruct device F to send the BIER message to itself. For example, device F decapsulates BIER packets.

After receiving the BIER message sent by device C, device F can obtain IOAM information according to the IOAM-DEX command header in the BIER message. The IOAM information may include, but is not limited to: the corresponding network parameters collected according to the IOAM-trace-type field of the IOAM-DEX command header, the Local BFR-prefix field (for example, this field is the BFR-prefix of device F), Next BFR-prefix field (for example, this field is the BFR-prefix of device F), BFIR ID in the BIER header (for example, the BFR ID of device A, the value is 4), BIFT ID (for example, the value is 1) , entropy (for example, the value is 1), etc. It should be understood that, for the description of the network parameters, please refer to the above description, which will not be described in detail here.

Step 663: Device F sends the IOAM information to the controller.

After acquiring the IOAM information, the device F can send the IOAM information to the controller.

Step 665: Device F decapsulates the BIER message.

Device F can also determine that it is an egress device of the BIER domain according to the bit string field of the BIER header as 0010 and the FBM field (0010) corresponding to Nbr=*F* in the above BIFT entry. Decapsulate to obtain inner user packets. Specifically, as an example, device F may remove the BIER header and the IOAM-DEX command header in the BIER packet, obtain the inner user packet, and forward the user packet.

Step 670: The controller associates the acquired pieces of IOAM information.

An example, after the controller obtains the IOAM information reported by each IOAM-DEX forwarding node (for example, the above-mentioned device A-device F), it can, according to the values of the BFIR ID field, the BIFT ID field and the entropy field in the IOAM information, Associate IOAM information with the same value to the same multicast stream. For example, taking the forwarding scenario shown in FIG. 4 as an example, the controller determines the BFIR ID field, BIFT ID field and entropy field of the IOAM information reported by Device A, Device B, Device C, Device D, Device E, and Device F respectively. The values are the same. Therefore, the controller can associate the IOAM information reported by device A and device F respectively to the same multicast stream.

In another example, the controller may also determine the corresponding SD/BSL/SI combination according to the BFIR ID in the IOAM information when a failure such as packet loss occurs in the multicast stream. That is, the controller can determine the SD, BSL and SI to which the multicast stream belongs according to the BFIR ID in the IOAM information.

In another example, the controller can also restore the multicast path of the same multicast stream according to the identifiers in the IOAM information (for example, the Local BFR-prefix field and the Next BFR-prefix field), so that the same multicast stream can be measured and obtained. Performance parameters of any pair of BFIR-BFERs in a multicast stream. For example, the controller can use the Local BFR-prefix field of the IOAM information reported by Device A to be the BFR-prefix of Device A, and the Next BFR-prefix field to be the BFR-prefix of Device B, and the Local BFR-prefix of the IOAM information reported by Device B to be the BFR-prefix of Device B The field is the BFR-prefix of device B, the NextBFR-prefix field is the BFR-prefix of device C, the Local BFR-prefix field of the IOAM information reported by device C is the BFR-prefix of device C, and the Next BFR-prefix field is the BFR-prefix of device E. BFR-prefix, which determines a multicast path from device A->device B->device C->device E. And according to the network parameters in the IOAM information reported by device A and device F respectively, the IOAM performance parameters of any pair of BFIR-BFERs in the same multicast stream are obtained, so as to manage the network and detect faults.

In the above technical solution, the controller can associate the IOAM information sent by each BFR, thereby obtaining the IOAM performance parameters of any pair of BFIR-BFERs in the same multicast stream. At the same time, it can also reduce unnecessary packet header overhead, save network bandwidth, simplify data processing, and avoid large packet headers caused by a large number of redundant measurement data caused by IOAM information being copied into multiple copies. overhead and wasted network bandwidth.

A data processing method provided by an embodiment of the present application is described in detail above with reference to FIGS. 1 to 7 , and an embodiment of the apparatus of the present application will be described in detail below with reference to FIGS. 8 to 12 . It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments. Therefore, for the parts not described in detail, reference may be made to the foregoing method embodiments.

FIG. 8 is a schematic structural diagram of a controller 800 provided by an embodiment of the present application. The controller 800 shown in FIG. 8 can execute the corresponding steps executed by the controller in the methods of the above embodiments. As shown in FIG. 8 , the controller 800 includes: a receiving module 810 and a processing module 820 .

It should be understood that the controller 800 may perform corresponding steps performed by the controller in the methods of the above embodiments, for example, the corresponding steps performed by the controller in FIG. 5 . Specifically, the receiving module 810 may implement the method flow of step 510 in FIG. 5 for receiving multiple online operation management and maintenance IOAM information; the processing module 820 may implement the method flow of step 520 in FIG. Each BFIR ID, bit index forwarding table identification BIFT ID and entropy value in the IOAM information associates the plurality of IOAM information to the first multicast stream.

Optionally, the processing module 820 is specifically configured to: associate the multiple IOAM information with the first multicast according to the same value of each BFIR ID, the bit index forwarding table identification BIFT ID and the entropy value in the multiple IOAM information. flow.

Optionally, each IOAM information also includes a first field and a second field, the first field is used to indicate the identifier of the current device reporting the IOAM information to the controller, and the second field is used to indicate the current device. The identifier of the device's next-hop neighbor device.

Optionally, the identifier of the current device is the address of the current device, and the identifier of the next-hop neighbor device is the address of the next-hop neighbor device.

Optionally, the processing module 820 is further configured to: restore the forwarding path of the first multicast stream according to the first field and the second field of each IOAM information in the plurality of IOAM information.

Optionally, each IOAM information in the multiple IOAM information further includes IOAM tracking data, and the processing module 820 is further configured to: according to the forwarding path of the first multicast stream and the IOAM tracking data in the multiple IOAM information , to obtain the network performance between the ingress device and the egress device of the first multicast stream.

FIG. 9 is a schematic structural diagram of a first network device 900 provided by an embodiment of the present application. The first network device 900 shown in FIG. 9 may perform corresponding steps performed by any one of devices A-device F in the methods of the foregoing embodiments. As shown in FIG. 9 , the first network device 900 includes: an obtaining module 910 and a sending module 920 .

It should be understood that the first network device 900 may perform corresponding steps performed by any one of devices A-device F in the methods of the above embodiments, for example, corresponding steps performed by any one of devices A-device F in FIG. 6 . Specifically, taking the first network device 900 as device A as an example, the acquisition module 910 can implement the method flow of step 610 in FIG. 6 to acquire the BIER message; the acquisition module 910 can also implement the method flow of step 613 in FIG. 6 . , for obtaining IOAM information according to the IOAM-DEX command header; the sending module 920 can implement the method flow of step 615 in FIG. 6 , for sending the IOAM information to the controller; the sending module 920 can implement the method in FIG. 6 . The method flow of step 617 is used to send a BIER message.

Optionally, the obtaining module 910 is further configured to: obtain the identification of the first network device, the identification of the first network device to the next-hop neighbor device according to the IOAM-DEX instruction header, and the next-hop neighbor device is the the next hop of the destination device of the BIER message of the first network device; the sending module 920 is further configured to: the first network device sends the identifier of the first network device and the next hop of the first network device to the controller The ID of the hop neighbor device.

Optionally, the identifier of the first network device is the address of the first network device, and the identifier of the next-hop neighbor device is the address of the next-hop neighbor device.

Optionally, the obtaining module 910 is further configured to: obtain the IOAM tracking data according to the IOAM-DEX command header; the sending module 920 is further configured to: send the IOAM tracking data to the controller.

Optionally, the first network device is a bit forwarding ingress router BFIR of the BIER domain, and the first network device 900 further includes: a receiving module 930, an encapsulating module 940,

a receiving module 930, configured to receive user messages;

The encapsulation module 940 is configured to encapsulate the user message to obtain the BIER message.

Optionally, the first network device is a bit forwarding egress router BFER in the BIER domain, and the first network device 900 further includes: a decapsulation module 950, configured to decapsulate the BIER message to obtain an inner user message .

FIG. 10 is a schematic diagram of a hardware structure of a first network device 2000 according to an embodiment of the present application. The first network device 2000 shown in FIG. 10 may perform the corresponding steps performed by the first network device in the methods of the foregoing embodiments.

As shown in FIG. 10 , 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, and may specifically be a network card. The above-mentioned processor 2001 , memory 2002 and interface 2003 are connected through a bus 2004 .

It should be understood that the first network device 2000 may perform corresponding steps performed by the first network device in the methods of the foregoing embodiments, for example, corresponding steps performed by any one of devices A to F in FIG. 6 .

As an example, the processor 2001 is configured to: acquire a BIER message; acquire IOAM information according to the IOAM-DEX instruction header; and send the IOAM information to the controller.

Specifically, taking the first network device 900 as device A as an example, the processor 2001 in the first network device 2000 can implement the method flow of step 610 in FIG. 6 to obtain the BIER message; the processor 2001 can also implement the process shown in FIG. The method flow of step 613 in 6 is used to obtain IOAM information according to the IOAM-DEX command header; the interface 2003 in the first network device 2000 can also implement the method flow of step 615 in FIG. 6, for sending all information to the controller. The IOAM information; the interface 2003 can also implement the method flow of step 617 in FIG. 6 for sending a BIER message.

The interface 2003 may specifically include a transmitter and a receiver, which are used by the first network device to implement the above-mentioned transceiving. For example, the interface 2003 is used for acquiring BIER messages, or for sending IOAM information to the controller.

The processor 2001 is configured to execute the processing performed by the first network device in the foregoing embodiment. As an example, the processor 2001 is used to support the steps in FIG. 6 . The memory 2002 includes an operating system 20021 and an application program 20022 for storing 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 read-only memory (ROM) and random access memory (RAM). Wherein, the ROM includes a basic input/output system (basic input/output system, BIOS) or an embedded system; the RAM includes an application program and an operating system. When the first network device 2000 needs to be run, the system is booted through the BIOS solidified in the ROM or the bootloader in the embedded system, and the first network device 2000 is guided into a normal operation state. After the first network device 2000 enters the normal running state, the application program and the operating system running in the RAM, thus, the processing process involving the first network device 2000 in the method embodiment is completed.

It can be understood that FIG. 10 only shows a simplified design of the first network device 2000 . In practical applications, the first network device may contain any number of interfaces, processors or memories.

FIG. 11 is a schematic diagram of a hardware structure of another first network device 2100 according to an embodiment of the present application. The first network device 2100 shown in FIG. 11 may perform the corresponding steps performed by the first network device in the methods of the foregoing embodiments.

As shown in FIG. 11 , the first network device 2100 includes: a main control board 2110 , an interface board 2130 , a switching network board 2120 and an interface board 2140 . The main control board 2110, the interface boards 2130 and 2140, and the switching network board 2120 are connected to the system backplane through the system bus to realize intercommunication. Among them, the main control board 2110 is used to complete functions such as system management, equipment maintenance, and protocol processing. The switch fabric board 2120 is used to complete data exchange between interface boards (interface boards are also called line cards or service boards). The interface boards 2130 and 2140 are used to provide various service interfaces (eg, POS interface, GE interface, ATM interface, etc.), and realize data packet forwarding.

It should be understood that the first network device 2100 may perform the corresponding steps performed by the first network device in the methods of the foregoing embodiments, for example, the corresponding steps performed by any one of devices A to F in the method in FIG. 6 .

Specifically, taking the first network device 2100 as device A as an example, the main control board 2110 can implement the method flow of step 610 in FIG. 6 to obtain the BIER message; the main control board 2110 can also implement the process of step 613 in FIG. 6 The method flow is used to obtain IOAM information according to the IOAM-DEX command header; the interface board 2130 can implement the method flow of step 615 in FIG. 6 , for sending the IOAM information to the controller; the interface board 2130 can also implement The method flow of step 617 in FIG. 6 is used to send a BIER message.

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 on the main control board. The forwarding entry storage 2134 is used to store entries, eg, BIFT above. The physical interface card 2133 is used to receive and transmit traffic.

It should be understood that the operations on the interface board 2140 in the embodiment of the present application are consistent with the operations on the interface board 2130, and for brevity, details are not repeated here. It should be understood that the first network device 2100 in this embodiment may correspond to the functions and/or various steps performed by the foregoing method embodiments, and details are not described herein again.

It should be understood that the first network device 2100 in this embodiment may correspond to the functions and/or various steps performed by the foregoing method embodiments, and details are not described herein again.

In addition, it should be noted that there may be one or more main control boards, and when there are multiple main control boards, they may include an active main control board and a backup main control board. There may be one or more interface boards, and the stronger the data processing capability of the first network device, the more interface boards provided. There can also be one or more physical interface cards on the interface board. There may be no switch fabric boards, or there may be one or more boards. When there are multiple boards, load sharing and redundancy backup can be implemented together. Under the centralized forwarding architecture, the first network device may not need to switch the network board, and the interface board undertakes the processing function of the service data of the entire system. Under the distributed forwarding architecture, the first network device may have at least one switching network board, and the switching network board realizes data exchange between multiple interface boards, providing large-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of the first network device in the distributed architecture are greater than those in the centralized architecture. The specific architecture used depends on the specific networking deployment scenario, and there is no restriction here.

FIG. 12 is a schematic diagram of a hardware structure of a controller 2200 according to an embodiment of the present application. The controller 2200 shown in FIG. 12 can execute the corresponding steps executed by the controller in the method of the above embodiment.

As shown in FIG. 12 , 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, and may specifically be a network card. The above-mentioned processor 2201 , memory 2202 and interface 2203 are connected through a bus 2204 .

It should be understood that the controller 2200 may perform corresponding steps performed by the controller in the methods of the above embodiments, for example, the corresponding steps performed by the controller in FIG. 5 .

As an example, the interface 2203 may implement the method flow of step 510 in FIG. 5 for receiving multiple online operation management and maintenance IOAM information; the processor 2201 may implement the method flow of step 520 in FIG. Each BFIR ID, bit index forwarding table identification BIFT ID and entropy value in the information associates the plurality of IOAM information to the first multicast stream.

The interface 2203 may specifically include a transmitter and a receiver, which are used by the controller to implement the above-mentioned transceiving. For example, this interface is used to support receiving multiple online operation management and maintenance IOAM information.

The processor 2201 is used to execute the processing performed by the controller in the above-mentioned embodiment. For example, for associating the plurality of IOAM information to a first multicast stream according to each BFIR ID, bit index forwarding table identification BIFT ID, and entropy value in the plurality of IOAM information; and/or for use herein Other procedures of the described technique. The memory 2202 includes an operating system 22021 and an application program 22022 for storing programs, codes or instructions. When the processor or hardware device executes these programs, codes or instructions, the processing process involving the controller in the method embodiment can be completed. Optionally, the memory 2202 may include read-only memory (ROM) and random access memory (RAM). Wherein, the ROM includes a basic input/output system (basic input/output system, BIOS) or an embedded system; the RAM includes an application program and an operating system. When the controller 2200 needs to be run, the system is booted through the BIOS solidified in the ROM or the bootloader in the embedded system, and the controller 2200 is booted into a normal running state. After the controller 2200 enters the normal running state, the application program and the operating system run in the RAM, thereby completing the processing process involving the controller 2200 in the method embodiment.

It will be appreciated that FIG. 12 only shows a simplified design of the controller 2200 . In practical applications, the controller 2200 may contain any number of interfaces, processors or memories.

Embodiments of the present application further provide a computer-readable medium, where program codes are stored in the computer-readable medium, and when the computer program codes are run on a computer, the computer executes the method performed by the 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, electrical EPROM (electrically EPROM, EEPROM) and hard drive (harddrive).

Embodiments of the present application further provide a computer-readable medium, where program codes are stored in the computer-readable medium, and when the computer program codes are run on a computer, the computer executes 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 (erasable PROM, EPROM), Flash memory, electrical EPROM (electrically EPROM, EEPROM) and hard drive (hard drive).

An embodiment of the present application further provides a chip system, which is applied to the first network device, the chip system includes: at least one processor, at least one memory, and an interface circuit, where the interface circuit is responsible for information between the chip system and the outside world interaction, the at least one memory, the interface circuit and the at least one processor are interconnected by a wire, and the at least one memory stores instructions; the instructions are executed by the at least one processor to perform the above aspects The operation of the first network device in the method.

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

The embodiment of the present application further provides another chip system, which is applied in a controller, and the chip system includes: at least one processor, at least one memory, and an interface circuit, where the interface circuit is responsible for information interaction between the chip system and the outside world , the at least one memory, the interface circuit and the at least one processor are interconnected through a line, and instructions are stored in the at least one memory; the instructions are executed by the at least one processor to perform the above-mentioned various aspects. the operation of the controller in the method.

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

Embodiments of the present application further provide a computer program product, which is applied to a first network device, where the computer program product includes a series of instructions, when the instructions are executed, to perform the methods described in the above aspects. Operation of the first network device.

Embodiments of the present application further provide a computer program product, which is applied in a controller, where the computer program product includes a series of instructions, when the instructions are executed, to perform the methods described in the above aspects Operation of the controller.

It should be understood that, in various embodiments of the present application, the size of the sequence numbers of the above-mentioned processes does not mean the sequence of execution, and the execution sequence of each process should be determined by its functions and internal logic, and should not be dealt with in the embodiments of the present application. implementation constitutes any limitation.

Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementations should not be considered beyond the scope of this application.

Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described systems, devices and units may refer to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.

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

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as independent products, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be embodied in the form of a software product in essence, or the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including Several instructions are used to cause 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 the various embodiments of the present application. The aforementioned storage medium includes: U disk, removable hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk and other media that can store program codes .

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited to this. should be covered within the scope of protection of this application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (28)

1. A method of data processing, comprising:

the method comprises the steps that a controller receives a plurality of pieces of online operation management maintenance IOAM information, the IOAM information is reported by a plurality of pieces of equipment in a bit-indexed explicit copy BIER domain, and each piece of IOAM information in the IOAM information comprises a bit forwarding entry router identification (BFIR ID), a bit index forwarding table identification (BIFT ID) and an entropy (entrypy) value;

the controller associates the plurality of IOAM information to a first multicast stream according to each BFIR ID, bit index forwarding table identification (BIFT ID) and entropy value in the plurality of IOAM information.

2. The method of claim 1, wherein the controller associates the plurality of IOAM information to a first multicast stream according to each BFIR ID, bit index forwarding table identification (BIFT ID), and entrypy value in the plurality of IOAM information, comprising:

and the controller associates the plurality of IOAM information to the first multicast flow according to the identity of each BFIR ID and the bit index forwarding table identification BIFT ID and the same entcopy value in the plurality of IOAM information.

3. The method according to claim 1 or 2, wherein each IOAM information further includes a first field and a second field, the first field is used for indicating an identifier of a current device reporting the IOAM information to the controller, and the second field is used for indicating an identifier of a next-hop neighbor device of the current device.

4. The method of claim 3, wherein the identity of the current device is an address of the current device and the identity of the next-hop neighbor device is an address of the next-hop neighbor device.

5. The method according to claim 3 or 4, characterized in that the method further comprises:

the controller restores a forwarding path of the first multicast stream according to the first field and the second field of each IOAM information of the plurality of IOAM information.

6. The method of any of claims 1 to 5, wherein each of the plurality of IOAM information further comprises IOAM tracking data, the method further comprising:

and the controller obtains the network performance between the inlet equipment and the outlet equipment of the first multicast flow according to the forwarding path of the first multicast flow and the IOAM tracking data in the plurality of IOAM information.

7. A method of data processing, comprising:

a first network device acquires an explicit copy BIER message of a bit index, wherein the BIER message comprises a bit forwarding entry router identifier (BFIR ID), a bit index forwarding table identifier (BIFT ID), an entropy (entrypy) value and an IOAM-DEX instruction head directly derived from online operation management and maintenance;

the first network equipment acquires IOAM information according to the IOAM-DEX instruction header, wherein the IOAM information comprises the BFIR ID, the BIFT ID and the entry value;

the first network device sends the IOAM information to a controller.

8. The method of claim 7, further comprising:

the first network equipment acquires an identifier of the first network equipment and an identifier from the first network equipment to next-hop neighbor equipment according to the IOAM-DEX instruction header, wherein the next-hop neighbor equipment is the next hop of the destination equipment of the BIER message of the first network equipment;

the first network device sends the identifier of the first network device and the identifier of the next-hop neighbor device of the first network device to the controller.

9. The method of claim 8, wherein the identity of the first network device is an address of the first network device, and wherein the identity of the next-hop neighbor device is an address of the next-hop neighbor device.

10. The method according to any one of claims 7 to 9, further comprising:

the first network equipment acquires IOAM tracking data according to the IOAM-DEX command header;

the first network device sends the IOAM trace data to the controller.

11. Method according to any of claims 7 to 10, wherein said first network device is a bit forwarding ingress router, BFIR, of a BIER domain, the method further comprising:

the first network equipment receives a user message;

and the first network equipment encapsulates the user message to obtain the BIER message.

12. The method according to any of claims 7 to 10, wherein the first network device is a bit forwarding egress router, BFER, of a BIER domain, the method further comprising:

and the first network equipment de-encapsulates the BIER message to obtain an inner layer user message.

13. A controller, comprising:

a receiving module, configured to receive a plurality of pieces of online operation management maintenance IOAM information, where the plurality of pieces of IOAM information are reported by a plurality of devices in a bit-indexed explicit replication BIER domain, and each piece of IOAM information in the plurality of pieces of IOAM information includes a bit forwarding entry router identifier (BFIR ID), a bit index forwarding table identifier (BIFT ID), and an entropy (entrypy) value;

and the processing module is used for associating the plurality of IOAM information to the first multicast flow according to each BFIRID in the plurality of IOAM information, the bit index forwarding table identification (BIFT ID) and the entrypy value.

14. The controller of claim 13, wherein the processing module is specifically configured to:

and associating the plurality of IOAM information to the first multicast stream according to the condition that each BFIR ID and bit index forwarding table identification (BIFT ID) in the plurality of IOAM information are the same as an entry value.

15. The controller according to claim 13 or 14, wherein each IOAM information further includes a first field and a second field, the first field is used for indicating an identifier of a current device reporting the IOAM information to the controller, and the second field is used for indicating an identifier of a next-hop neighbor device of the current device.

16. The controller of claim 15, wherein the identification of the current device is an address of the current device and the identification of the next-hop neighbor device is an address of the next-hop neighbor device.

17. The controller according to claim 15 or 16, wherein the processing module is further configured to:

restoring a forwarding path of the first multicast stream according to the first field and the second field of each of the plurality of IOAM information.

18. The controller of any one of claims 13 to 17, wherein each IOAM information of the plurality of IOAM information further comprises IOAM trace data, the processing module further to:

and obtaining the network performance between the inlet equipment and the outlet equipment of the first multicast flow according to the forwarding path of the first multicast flow and the IOAM tracking data in the plurality of IOAM information.

19. A first network device, comprising:

the system comprises an acquisition module, a data processing module and a data processing module, wherein the acquisition module is used for acquiring an explicit copy BIER message of a bit index, and the BIER message comprises a bit forwarding entry router identifier (BFIR ID), a bit index forwarding table identifier (BIFT ID), an entropy (entropy) value and an IOAM-DEX instruction head directly derived from online operation management maintenance;

the obtaining module is further configured to obtain IOAM information according to the IOAM-DEX instruction header, where the IOAM information includes the BFIR ID, the big ID, and the entrypy value;

and the sending module is used for sending the IOAM information to the controller.

20. The first network device of claim 19,

the acquisition module is further configured to: acquiring an identifier of the first network equipment and an identifier from the first network equipment to next-hop neighbor equipment according to the IOAM-DEX instruction header, wherein the next-hop neighbor equipment is the next hop of the destination equipment of the BIER message of the first network equipment;

the sending module is further configured to: the first network device sends the identifier of the first network device and the identifier of the next-hop neighbor device of the first network device to the controller.

21. The first network device of claim 20, wherein the identification of the first network device is an address of the first network device and the identification of the next-hop neighbor device is an address of the next-hop neighbor device.

22. The first network device of any of claims 19 to 21,

the acquisition module is further configured to: obtaining IOAM tracking data according to the IOAM-DEX instruction header;

the sending module is further configured to: sending the IOAM trace data to the controller.

23. The first network device according to any of claims 19 to 22, wherein the first network device is a bit forwarding ingress router, BFIR, of a BIER domain, the first network device further comprising:

the receiving module is used for receiving a user message;

and the encapsulation module is used for encapsulating the user message to obtain the BIER message.

24. The first network device according to any of claims 19 to 22, wherein the first network device is a bit forwarding egress router, BFER, of a BIER domain, the first network device further comprising:

and the decapsulation module is used for decapsulating the BIER message to obtain the user message of the inner layer.

25. A controller, comprising: a processor and memory for storing a program or code, the processor for invoking and running the program from the memory to perform the method of any one of claims 1-6.

26. A first network device, comprising: a processor and a memory, the memory for storing a program or code, the processor for invoking and running the program from the memory to perform the method of any one of claims 7 to 12.

27. A computer readable storage medium comprising a computer program or code which, when run on a controller, causes the controller to perform the method of any of claims 1 to 6.

28. A computer readable storage medium comprising a computer program or code which, when run on a first network device, causes the first network device to perform the method of any of claims 7 to 12.

Images