Fault detection method and apparatus

Abstract

The embodiment of the application provides a fault detection method and device, and belongs to the technical field of communication. The embodiment of the application finds that when SI configured by a downstream BFR is less than SI configured by an upstream BFR, packet loss occurs due to forwarding failure, and thus, SI of the BFRs having an upstream-downstream relationship is acquired, and when SI of the upstream BFR is greater than SI of the downstream BFR, it is determined that there is a configuration fault, so that the configuration fault is accurately detected.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a fault detection method and device. BACKGROUND

[0002] Bit indexed explicit replication (BIER) technology is a multicast forwarding technology based on bit index explicit replication. When deploying a BIER service, a network administrator needs to configure many parameters. If the configuration is problematic, when multicast traffic is forwarded to an intermediate node, the intermediate node may fail to forward, resulting in packet loss or even flow interruption. Therefore, how to detect configuration faults needs further research and discussion. SUMMARY

[0003] Embodiments of the present application provide a fault detection method and device, which can accurately detect configuration faults. The technical solution is as follows.

[0004] In a first aspect, a fault detection method is provided, which includes: a controller obtaining SI of a first BFR and SI of a second BFR, the first BFR and the second BFR belonging to different ASs, the second BFR being a downstream node of the first BFR on a BIER forwarding path; and the controller determining that there is a configuration fault based on the SI of the first BFR being greater than the SI of the second BFR.

[0005] It is found through research and analysis that if the SI configured by a downstream BFR is less than the SI configured by an upstream BFR, packet loss may occur due to forwarding failure. In the method of the first aspect, the SIs of BFRs having an upstream-downstream relationship are obtained, and when the SI of an upstream BFR is greater than the SI of a downstream BFR, it is determined that there is a configuration fault, so the configuration fault is accurately detected.

[0006] In addition, in the scenario of BIER service deployment across ASs, a BIER forwarding path may pass through different ASs, and in the method provided in the first aspect, the SIs of BFRs belonging to different ASs are obtained by the controller for detection, thereby ensuring the comprehensiveness of information collection and avoiding omission of fault detection.

[0007] In some embodiments, the controller obtaining the SI of the first BFR and the SI of the second BFR includes: the controller obtaining the SI of the first BFR based on a BFR ID of the first BFR and a BSL of the first BFR; and the controller obtaining the SI of the second BFR based on a BFR ID of the second BFR and a BSL of the second BFR.

[0008] Through the above embodiments, the controller uniformly calculates the SI actually required by each device and then compares the SIs, thereby reducing the calculation amount of each device.

[0009] Alternatively, the controller acquires the SI of the first BFR and the SI of the second BFR, including:

[0010] The controller receives the SI of the first BFR sent by the first BFR.

[0011] The controller receives the SI of the second BFR sent by the second BFR.

[0012] In some embodiments, based on the SI of the first BFR being greater than the SI of the second BFR, the controller determines that there is a configuration fault, including:

[0013] The controller determines that there is a configuration fault based on the maximum value of the SI of the first BFR being greater than the maximum value of the SI of the second BFR.

[0014] In some embodiments, before the controller acquires the SI of the second BFR based on the BFR ID of the second BFR and the BSL of the second BFR, the method further includes:

[0015] The controller receives a first notification packet from a first routing device, and the first notification packet includes the BFR ID of the second BFR and the BSL of the second BFR.

[0016] In some embodiments, the first routing device is an edge device in an AS to which the second BFR belongs.

[0017] In some embodiments, the first routing device is the second BFR.

[0018] Through the above embodiments, in the scenario where BIER services are deployed across multiple ASes, one device (such as an ASBR) in each AS domain is responsible for reporting information, so that the controller can collect BIER information of each device in the domain and then collect BIER information of all devices in the entire BIER subdomain, thereby ensuring the comprehensiveness of the collection of BIER information in the cross-domain scenario.

[0019] In some embodiments, the first notification packet includes a BIER NLRI, and the BIER NLRI includes a BIER info description, which carries the BFR ID of the second BFR and the BSL of the second BFR.

[0020] Through the above implementation, the protocol message format is extended, and the BIER information of the device is announced by adding the BIER NLRI, thereby reducing the implementation complexity.

[0021] In some embodiments, the first notification message is a BGP-LS message, a PCEP message, a NETCOF message, an SNMP message, or a Telemetry message.

[0022] Through the above implementation, the BIER information is collected by the controller through BGP-LS, PCEP, NETCOF, SNMP, Telemetry, and the like, more business scenarios are matched, and the flexibility is improved.

[0023] In some embodiments, before the controller obtains the SI of the second BFR based on the BFR ID of the second BFR and the BSL of the second BFR, the method further includes:

[0024] The controller receives a second notification message from a root node on the BIER forwarding path, and the second notification message includes the BFR ID of the second BFR and the BSL of the second BFR.

[0025] Through the above implementation, since the BIER information of each node on the forwarding path is collected by the root node and reported to the controller, the controller not only obtains the BIER information of all nodes on the forwarding path, but also only needs to establish a peer relationship or a communication connection with the root node, without the need for the controller to establish a peer relationship with multiple nodes on the path, thereby saving the overhead of the controller.

[0026] In some embodiments, after the controller determines that there is a configuration fault based on the SI of the first BFR being greater than the SI of the second BFR, the method further includes:

[0027] The controller outputs alarm information, and the alarm information indicates that there is a configuration fault corresponding to the SI.

[0028] Through the above implementation, the network administrator is informed in a timely manner that the SI corresponding configuration has a fault, and the network administrator is helped to solve the problem of the configuration fault in a timely manner.

[0029] In some embodiments, the alarm information includes an identifier of the second BFR.

[0030] Through the above implementation, the network administrator is informed of the specific device whose configuration has a problem, the network administrator is helped to quickly locate the device with a problem in configuration, and the difficulty of changing the configuration is reduced.

[0031] In some embodiments, the alarm information comprises SI of the second BFR.

[0032] Through the above-mentioned embodiments, it is told to the network administrator which specific BIER parameter has a problem, thereby reducing the difficulty of changing the configuration.

[0033] In some embodiments, the alarm information comprises a reference value of SI configuration, which is determined by the controller based on SI of multi-hop nodes on the BIER forwarding path.

[0034] Through the above-mentioned embodiments, the reference of SI configuration is provided to the network administrator based on SI of multi-hop nodes on the comprehensive path, thereby reducing the difficulty and complexity of configuring SI, and avoiding SI configuration being too small to cause forwarding failure and SI configuration being too large to cause excessive device replication pressure.

[0035] In some embodiments, after the controller determines that there is a configuration failure based on SI of the first BFR being greater than SI of the second BFR, the method further comprises:

[0036] The controller sends a reconfiguration instruction to the second BFR, and the reconfiguration instruction instructs the second BFR to adjust SI of the second BFR to SI of the first BFR.

[0037] Through the above-mentioned embodiments, the node with a problem in configuration is instructed by the controller to adjust SI, thereby providing a means for automatically solving SI configuration failure, which is helpful for solving SI configuration failure more quickly and efficiently.

[0038] In a second aspect, a communication method is provided, and the method comprises: a first BFR sending SI related parameters of the first BFR to a controller.

[0039] In some embodiments, the first BFR is an edge device of a first AS, and the method further comprises:

[0040] The first BFR acquires SI related parameters of each BFR in the first AS;

[0041] The first BFR sends the SI related parameters of each BFR in the first AS to the controller.

[0042] In some embodiments, the first BFR acquires SI related parameters of each BFR in the first AS, comprising:

[0043] The first BFR receives an IGP packet from each BFR in the first AS;

[0044] The first BFR obtains SI-related parameters of each BFR from the IGP packet of each BFR.

[0045] In some embodiments, the SI-related parameters include the BFR-ID and BSL.

[0046] In some embodiments, the SI-related parameters include SI maximum value.

[0047] In some embodiments, the first BFR sends SI-related parameters of the first BFR to a controller, including:

[0048] The controller sends an advertisement packet to the controller, the advertisement packet including the SI-related parameters of the first BFR.

[0049] In some embodiments, the advertisement packet is a BGP-LS packet, a PCEP packet, a NETCOF packet, an SNMP packet, or a Telemetry packet.

[0050] In some embodiments, the advertisement packet includes a BIER NLRI, the BIER NLRI including a local node description and a BIER info description, the local node description carrying a BFR-prefix of the BFR, and the BIER info description carrying the SI-related parameters.

[0051] In a third aspect, a fault detection method is provided, the method comprising:

[0052] A controller obtains a SI comparison result of a first BFR and a second BFR, the comparison result indicating a numerical relationship between SI of the first BFR and SI of the second BFR, the second BFR being a downstream node of the first BFR on a BIER forwarding path.

[0053] The controller determines that there is a configuration fault based on the comparison result indicating that the SI of the first BFR is greater than the SI of the second BFR.

[0054] In some embodiments, the first BFR and the second BFR belong to different ASs.

[0055] In some embodiments, the first BFR and the second BFR belong to the same AS.

[0056] In some embodiments, the controller obtains a SI comparison result of a first BFR and a second BFR, including:

[0057] The controller receives the SI comparison result sent by the first BFR.

[0058] In some embodiments, the controller obtains the SI comparison result of the first BFR and the second BFR, including:

[0059] The controller receives the SI comparison result sent by the second BFR.

[0060] In some embodiments, the controller obtains the SI comparison result of the first BFR and the second BFR, including:

[0061] The controller receives the SI comparison result sent by a first routing device in a first AS to which the first BFR belongs;

[0062] The first routing device is an edge device of the first AS; or

[0063] The first routing device is a neighbor BFR of the first BFR in the first AS; or

[0064] The first routing device is a root node on the BIER forwarding path.

[0065] In some embodiments, the controller obtains the SI comparison result of the first BFR and the second BFR, including:

[0066] The controller receives the SI comparison result sent by a second routing device in a second AS to which the second BFR belongs;

[0067] The second routing device is an edge device of the second AS; or

[0068] The second routing device is a neighbor BFR of the second BFR in the second AS; or

[0069] The second routing device is a leaf node on the BIER forwarding path.

[0070] In some embodiments, the controller obtains the SI comparison result of the first BFR and the second BFR, including:

[0071] The controller receives an announcement packet, the announcement packet including a BIER NLRI, the BIER NLRI including a BIER info description, the BIER info description carrying the SI comparison result;

[0072] The controller obtains the SI comparison result from the announcement packet.

[0073] In some embodiments, the notification message is a BGP-LS message, a PCEP message, a NETCOF message, an SNMP message, or a Telemetry message.

[0074] In some embodiments, after the controller determines that the configuration fault exists, the method further comprises:

[0075] The controller outputs alarm information, the alarm information indicating that the configuration fault corresponding to the SI exists.

[0076] In some embodiments, the alarm information comprises at least one of an identity of the second BFR and the SI of the second BFR.

[0077] In some embodiments, the alarm information comprises a reference value of the SI configuration, the reference value of the SI configuration being determined by the controller based on the SI of the multi-hop node on the BIER forwarding path.

[0078] In some embodiments, after the controller determines that the configuration fault exists, the method further comprises:

[0079] The controller sends a reconfiguration instruction to the second BFR, the reconfiguration instruction instructing the second BFR to adjust the SI of the second BFR to the SI of the first BFR.

[0080] In a fourth aspect, a communication method is provided, the method comprising:

[0081] A first BFR obtains a SI of a second BFR, the second BFR being a downstream node of the first BFR on a BIER forwarding path;

[0082] The first BFR obtains a SI comparison result of the first BFR and the second BFR based on the SI of the first BFR and the SI of the second BFR, the comparison result indicating a numerical relationship between the SI of the first BFR and the SI of the second BFR;

[0083] The first BFR sends the SI comparison result to a controller.

[0084] In some embodiments, the first BFR and the second BFR belong to the same AS, and the first BFR obtaining the SI of the second BFR comprises:

[0085] The first BFR receives an IGP message from the second BFR;

[0086] The first BFR obtains the SI of the second BFR based on the IGP message.

[0087] In some embodiments, the first BFR obtains the SI of the second BFR based on the IGP packet, including:

[0088] The first BFR obtains the SI of the second BFR carried by the IGP packet.

[0089] In some embodiments, the first BFR obtains the SI of the second BFR based on the IGP packet, including:

[0090] The first BFR obtains the BFR-ID of the second BFR and the BSL of the second BFR carried by the IGP packet;

[0091] The first BFR obtains the SI of the second BFR based on the BFR-ID of the second BFR and the BSL of the second BFR.

[0092] In some embodiments, the first BFR and the second BFR belong to different ASs, and the first BFR obtains the SI of the second BFR, including:

[0093] The first BFR receives a BGP packet from the second BFR;

[0094] The first BFR obtains the SI of the second BFR based on the BGP packet.

[0095] In the fifth aspect, a fault detection method is provided, and the method includes:

[0096] The first BFR obtains the SI of the second BFR, which is a downstream node of the first BFR on a BIER forwarding path;

[0097] The first BFR compares the SI of the first BFR with the SI of the second BFR to obtain a comparison result.

[0098] If the comparison result is that the SI of the first BFR is greater than the SI of the second BFR, the first BFR determines that there is a configuration fault.

[0099] In some embodiments, the first BFR and the second BFR belong to the same AS, and the first BFR obtains the SI of the second BFR, including:

[0100] The first BFR receives an IGP packet from the second BFR;

[0101] The first BFR obtains the SI of the second BFR based on the IGP packet.

[0102] In some embodiments, the first BFR obtains the SI of the second BFR based on the IGP packet, including:

[0103] The first BFR obtains the SI of the second BFR carried by the IGP packet.

[0104] In some embodiments, the first BFR obtains the SI of the second BFR based on the IGP packet, including:

[0105] The first BFR obtains the BFR-ID of the second BFR and the BSL of the second BFR carried by the IGP packet;

[0106] The first BFR obtains the SI of the second BFR based on the BFR-ID of the second BFR and the BSL of the second BFR.

[0107] In some embodiments, the first BFR and the second BFR belong to different ASs, and the first BFR obtains the SI of the second BFR, including:

[0108] The first BFR receives a BGP packet from the second BFR;

[0109] The first BFR obtains the SI of the second BFR based on the BGP packet.

[0110] In some embodiments, after the first BFR determines that there is a configuration fault, the method further includes:

[0111] The first BFR outputs alarm information, and the alarm information indicates that there is a configuration fault corresponding to the SI.

[0112] In some embodiments, the alarm information includes at least one of an identity of the second BFR and the SI of the second BFR.

[0113] In some embodiments, the alarm information includes a reference value of the SI configuration, and the reference value of the SI configuration is determined by the first BFR based on the SI of the multi-hop node on the BIER forwarding path.

[0114] In some embodiments, after the first BFR determines that there is a configuration fault, the method further includes:

[0115] The first BFR sends a reconfiguration instruction to the second BFR, and the reconfiguration instruction instructs the second BFR to adjust the SI of the second BFR to the SI of the first BFR.

[0116] Sixthly, a fault detection device is provided, which has the function of implementing the first aspect, any optional mode of the first aspect, the third aspect, any optional mode of the third aspect, the fifth aspect, or any optional mode of the fifth aspect. The fault detection device includes at least one unit, which is used to implement the method provided by the first aspect, any optional mode of the first aspect, the third aspect, any optional mode of the third aspect, the fifth aspect, or any optional mode of the fifth aspect. In some embodiments, the unit in the fault detection device is implemented by software, and the unit in the fault detection device is a program module. In other embodiments, the unit in the fault detection device is implemented by hardware or firmware. Specific details of the fault detection device provided in the sixth aspect can be found in the first aspect, any optional mode of the first aspect, the third aspect, any optional mode of the third aspect, the fifth aspect, or any optional mode of the fifth aspect, and will not be repeated here.

[0117] A seventh aspect provides a routing device having the functionality to implement the second aspect, any alternative to the second aspect, the fourth aspect, or any alternative to the fourth aspect described above. The routing device includes at least one unit for implementing the methods provided by the second aspect, any alternative to the second aspect, the fourth aspect, or any alternative to the fourth aspect described above. In some embodiments, the unit in the routing device is implemented in software, and the unit in the routing device is a program module. In other embodiments, the unit in the routing device is implemented in hardware or firmware. Specific details of the routing device provided in the seventh aspect can be found in the second aspect, any alternative to the second aspect, the fourth aspect, or any alternative to the fourth aspect described above, and will not be repeated here.

[0118] Eighthly, a controller is provided, comprising a processor coupled to a memory storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the processor to enable the controller to perform the functions of the first aspect, any alternative to the first aspect, the third aspect, any alternative to the third aspect, the fifth aspect, or any alternative to the fifth aspect described above. Specific details of the controller provided in the eighth aspect can be found in the functions of the first aspect, any alternative to the first aspect, the third aspect, any alternative to the third aspect, the fifth aspect, or any alternative to the fifth aspect described above, and will not be repeated here.

[0119] In a ninth aspect, a routing device is provided, which includes a processor configured to execute instructions to cause the routing device to perform the functions of the second aspect, any of the optional modes of the second aspect, the fourth aspect, or any of the optional modes of the fourth aspect, and a network interface configured to receive or send packets. The routing device of the ninth aspect can include the details of the second aspect, any of the optional modes of the second aspect, the fourth aspect, or any of the optional modes of the fourth aspect, which are not repeated here.

[0120] In a tenth aspect, a computer-readable storage medium is provided, which stores at least one instruction, which, when executed on a computer, causes the computer to perform the functions of the first aspect, any of the optional modes of the first aspect, the third aspect, any of the optional modes of the third aspect, the fifth aspect, or any of the optional modes of the fifth aspect.

[0121] In an eleventh aspect, a computer-readable storage medium is provided, which stores at least one instruction, which, when executed on a computer, causes the computer to perform the functions of the second aspect, any of the optional modes of the second aspect, the fourth aspect, or any of the optional modes of the fourth aspect.

[0122] In a twelfth aspect, a computer program product is provided, which includes one or more computer program instructions, which, when loaded and executed on a computer, cause the computer to perform the functions of the first aspect, any of the optional modes of the first aspect, the third aspect, any of the optional modes of the third aspect, the fifth aspect, or any of the optional modes of the fifth aspect.

[0123] In a thirteenth aspect, a computer program product is provided, which includes one or more computer program instructions, which, when loaded and executed on a computer, cause the computer to perform the functions of the second aspect, any of the optional modes of the second aspect, the fourth aspect, or any of the optional modes of the fourth aspect.

[0124] In a fourteenth aspect, a chip is provided, which includes programmable logic circuitry and / or program instructions, which, when executed on the chip, are configured to perform the functions of the first aspect, any of the optional modes of the first aspect, the third aspect, any of the optional modes of the third aspect, the fifth aspect, or any of the optional modes of the fifth aspect.

[0125] In a fifteenth aspect, a chip is provided, which includes programmable logic circuitry and / or program instructions, which, when executed on the chip, are configured to perform the functions of the second aspect, any of the optional modes of the second aspect, the fourth aspect, or any of the optional modes of the fourth aspect.

[0126] In a sixteenth aspect, a communication system is provided, which comprises the fault detection apparatus of the sixth aspect and the routing device of the seventh aspect.

[0127] In a seventeenth aspect, a communication system is provided, which comprises the controller of the eighth aspect and the routing device of the ninth aspect. BRIEF DESCRIPTION OF DRAWINGS

[0128] Figure 1 is a schematic diagram of a typical application scenario provided by an embodiment of the present application;

[0129] Figure 2 is a schematic diagram of a system running environment provided by an embodiment of the present application;

[0130] Figure 3 is a flowchart of a fault detection method provided by an embodiment of the present application;

[0131] Figure 4 is a flowchart of a fault detection method provided by an embodiment of the present application;

[0132] Figure 5 is a flowchart of a fault detection method provided by an embodiment of the present application;

[0133] Figure 6 is a format schematic diagram of a BGP-LS added BIER NLRI provided by an embodiment of the present application;

[0134] Figure 7 is a format schematic diagram of a BGP-LS added TLV provided by an embodiment of the present application;

[0135] Figure 8 is a flowchart of a fault detection method provided by an embodiment of the present application;

[0136] Figure 9 is a flowchart of a fault detection method provided by an embodiment of the present application;

[0137] Figure 10 is a flowchart of a fault detection method provided by an embodiment of the present application;

[0138] Figure 11 is a structural schematic diagram of a fault detection apparatus 400 provided by an embodiment of the present application;

[0139] Figure 12 is a structural schematic diagram of a controller 600 provided by an embodiment of the present application;

[0140] Figure 13 is a structural schematic diagram of a routing device 500 provided by an embodiment of the present application;

[0141] Figure 14 Figure 1 is a structural schematic diagram of a routing device 700 provided by an embodiment of the present application. DETAILED DESCRIPTION

[0142] To make the purposes, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.

[0143] To help the reader understand, some terms and concepts are first explained. The following term and concept explanations are common to the embodiments described below.

[0144] (1) BIER forwarding router (BFR)

[0145] The so-called BFR refers to a routing device supporting BIER forwarding. The "device" or "node" appearing in the following embodiments of the present application is generally a short form of BFR. The typical product form of BFR is, for example, a router or a switch, or other network devices. In some scenarios, the BFR can also be a host.

[0146] (2) BIER domain

[0147] The so-called BIER domain refers to a network area supporting BIER forwarding. A BIER domain contains at least one BIER sub-domain (SD). Optionally, according to the requirements of multicast service deployment, a BIER domain is divided into multiple SDs. For example, the multicast service of virtual private network (VPN) 1 runs through SD 1, and the multicast service of VPN 2 runs through SD 2.

[0148] (3) BIER sub-domain (SD)

[0149] The so-called BIER sub-domain is a concept finer than BIER domain, and a BIER domain contains one or more BIER sub-domains. In some embodiments, the BFR is configured with a sub-domain identifier (SD ID) of the BIER sub-domain to which the BFR belongs. The sub-domain ID is used to identify the corresponding BIER sub-domain. Generally, one BIER sub-domain corresponds to one sub-domain ID uniquely. The sub-domain IDs of the BFRs in the same BIER sub-domain are the same.

[0150] (4) bit forwarding ingress router (BFIR)

[0151] The so-called BFIR refers to a BFR located at an ingress of a BIER domain (or a BIER sub-domain). The BFIR is responsible for encapsulating a multicast packet into a BIER packet containing a bit string. The BFIR is also referred to as a root node, a head node, or a source node of the BIER packet. Optionally, the BFIR is a provider edge (PE) device.

[0152] (5) bit-forwarding egress router (BFER)

[0153] The so-called BFER refers to a BFR located at an egress of a BIER domain (or a BIER sub-domain). The BFER is responsible for decapsulating a BIER packet containing a bit string into a multicast packet, and forwarding the multicast packet to a receiver outside the BIER domain (or the sub-domain). The BFER is also referred to as a leaf node, a tail node, or a destination node of the BIER packet. Optionally, the BFER is a PE device.

[0154] (6) edge BFR

[0155] The so-called edge BFR is a name shared by both the BFIR and the BFER. The edge BFR refers to a BFR located at an edge of a BIER domain (or a BIER sub-domain).

[0156] (7) intermediate node

[0157] Unless otherwise specified, the intermediate node refers to a one-hop BFR between the BFIR and the BFER in a BIER forwarding path. For example, the intermediate node is a next-hop BFR of the BFIR. For another example, the intermediate node is a previous-hop BFR of the BFER. For yet another example, the intermediate node is a one-hop BFR between a next-hop BFR of the BFIR and a previous-hop BFR of the BFER. Optionally, the intermediate node is a provider backbone (P) device. Optionally, the intermediate node is an autonomous system border router (ASBR).

[0158] (8) BIER forwarding router identifier (BFR ID)

[0159] The so-called BFR ID is an identifier of a BFR (e.g., an edge BFR or an intermediate node) in a BIER sub-domain (or a BIER domain). The BFR ID represents a corresponding bit in a bit string. For example, if the length of the bit string is 256 bits and the BFR ID of a routing device is 1, it means that the routing device corresponds to the first bit (the lowest bit) in the 256-bit bit string. Optionally, the BFR ID corresponds to a bit in a forwarding bit mask (FBM) in a forwarding table. Optionally, the BFR ID is an integer ranging from 1 to 65535.

[0160] In some embodiments, the BFR ID is configured on the BFR. The source of the BFR ID on the BFR, i.e., how the BFR obtains the BFR ID, includes various implementations. In some embodiments, a network administrator configures a corresponding BFR ID for each BFR (e.g., each edge BFR) through static configuration. In other embodiments, a controller automatically assigns a corresponding BFR ID for each BFR (e.g., each edge BFR). The present embodiment does not limit the implementation of how the BFR obtains the BFR ID.

[0161] In some embodiments, each edge BFR in a BIER sub-domain (or a BIER domain) has a corresponding BFR ID. In other embodiments, not only edge BFRs have corresponding BFR IDs, but intermediate nodes also have corresponding BFR IDs. For example, each BIER-enabled routing device in a BIER sub-domain (or a BIER domain) has a corresponding BFR ID.

[0162] Optionally, the BFR ID of each BFR is unique in the entire BIER sub-domain (or BIER domain). In other words, different BFRs in the same BIER sub-domain (or BIER domain) have different BFR IDs, and the BFR IDs of different BFRs cannot conflict. Alternatively, the BFR ID of each BFR is unique in the entire BIER sub-domain (or BIER domain), while the BFR IDs of different intermediate nodes are allowed to be the same, e.g., the BFR IDs of all intermediate nodes in a BIER sub-domain are all 0 or all default values.

[0163] (9) bit string

[0164] The bit string is used to identify the set of destination edge BFRs (or the set of destination leaf nodes) of the BIER packet. The bit string includes a series of bits, and the position or index of each bit in the bit string corresponds to the BFR ID of an edge BFR. For example, the lowest bit (i.e., the first bit from the right) in the bit string is used to identify the BFR with a BFR ID of 1, the second-lowest bit (i.e., the second bit from the right) in the bit string is used to identify the BFR with a BFR ID of 2, and so on. The bit string is carried in the BIER packet.

[0165] Exemplarily, a set bit in the bit string identifies a destination edge BFR. For example, node A (BFIR) receives a multicast packet and finds that the destination edge nodes of the multicast packet are node B and node C, the BFR ID of node B is 1, and the BFR ID of node C is 2. Node A sets the bit corresponding to node B and node C to 1, and the encapsulated bit string is, for example, 0011.

[0166] (10) Bit string length (BSL)

[0167] The BSL, as the name implies, refers to the length of the bit string. The length of the bit string in a BIER packet includes, but is not limited to, 64 bits, 128 bits, 512 bits, 1028 bits, 2048 bits, and 4096 bits.

[0168] In some embodiments, the BFR is configured with a BSL. The BSL configured on the BFR includes various cases. Alternatively, the BSL configured on all BFRs in a BIER sub-domain is the same. Alternatively, each BFR in a BIER sub-domain is configured with a corresponding BSL. The correspondence between the BFR and the configured BSL can be a one-to-one relationship or a many-to-one relationship. In other words, the BSLs configured on different BFRs in the same BIER sub-domain can be the same or different.

[0169] The source of the BSL on the BFR, that is, how the BFR obtains the BSL includes various implementation manners. In some embodiments, the network administrator configures a corresponding BSL for each BFR (such as each edge BFR) through static configuration. In other embodiments, the controller automatically allocates a corresponding BSL for each BFR (such as each edge BFR). The present embodiment does not limit the implementation manner of how the BFR obtains the BSL.

[0170] (11) Set index (SI)

[0171] The SI refers to the identification of the set to which the BFR ID belongs, or the identification of the set to which the BFR (or BFER) belongs.

[0172] SI can play a role in expanding the range of BFR ID allocation. For example, in the case of allocating BFR ID for each BFR, when the number of BFRs in a BIER sub-domain exceeds the length of the bit string, then different BFRs are divided into different sets. For example, the length of the bit string is 256 bits, then the BFRs with BFR ID 1 to 256 in the BIER sub-domain are divided into a set with SI = 0, and the BFRs with BFR ID 257 to 512 in the BIER sub-domain are divided into a set with SI = 1. In this way, whenever the number of BFRs in the BIER sub-domain exceeds a BSL, the SI maximum value (max SI, also referred to as max-SI, MAX-SI or MAX SI) increases by one.

[0173] The SI maximum value is related to the number of BFRs in the BIER sub-domain and the BSL. For example, the three parameters of SI, BSL and BFR ID need to satisfy the constraint condition: BFR ID <= BSL * (SI maximum value + 1). That is, among the three parameters of SI, BSL and BFR ID, if two of them are known, the other parameter can be calculated using the constraint condition.

[0174] In some embodiments, SI is configured on each BFR (including intermediate nodes and edge BFRs) in the BIER sub-domain. In other embodiments, SI is configured on each edge BFR in the BIER sub-domain, and intermediate nodes are optionally not configured with SI.

[0175] In some scenarios, the SI configured on different BFRs is different. For example, the SI maximum value configured on some BFRs is the default value, i.e. 255. The SI maximum value configured on some BFRs is the SI actually needed by the device, calculated according to the constraint condition described above: BFR ID <= BSL * (SI maximum value + 1).

[0176] (12) Bit index forwarding table (BIFT)

[0177] BIFT is a forwarding table entry used by each BFR in the BIER sub-domain to forward BIER packets.

[0178] The index of the BIFT is usually a combination of the three parameters of SI, BSL and sub-domain ID. In other words, the three parameters of SI, BSL and sub-domain ID usually correspond to one BIFT on a BFR. For example, among the three parameters of SI, BSL and sub-domain ID, different values of any one parameter correspond to different BIFTs on the BFR. In other words, when the value of SI is different, it corresponds to different BIFTs on the BFR.

[0179] In the generating phase of the BIFT, the BFR can optionally generate the index of the BIFT according to the SI maximum value configured on the device, the BSL configured on the device, and the sub-domain ID configured on the device. For example, there is a BFR in a BIER sub-domain, which is called device A. The SI maximum value configured on the device A is 1, the sub-domain ID configured on the device A is 0, and the BSL configured on the device A is 256. Then, the device A generates two BIFTs in the generating phase of the BIFT. The index of the BIFT 1 is, for example, SI = 0, sub-domain ID = 0, and BSL = 256, and the index of the BIFT 2 is, for example, SI = 1, sub-domain ID = 0, and BSL = 256.

[0180] In the forwarding phase of the BIER packet, the technical means for the BFR to query the BIFT is, for example, to match the content of the BIFT field in the BIER packet header with the local table index, so as to query the matched BIFT. Still taking the device A described in the previous paragraph as an example, if the device A receives a BIER packet, and the device A finds that the content of the bit index forwarding table identifier (BIFT ID) field in the BIER packet header is 1, which is equivalent to decapsulating SI = 0, sub-domain ID = 0, and BSL = 256, then the device A queries the local BIFT with SI = 0, sub-domain ID = 0, and BSL = 256 as the index. At this time, the device A can query the matched BIFT, which is the BIFT 1 described in the previous paragraph. If the device A finds that the content of the BIFT ID field in the BIER packet header is 4, which is equivalent to decapsulating SI = 3, sub-domain ID = 0, and BSL = 256, then the device A queries the local BIFT with SI = 3, sub-domain ID = 0, and BSL = 256 as the index. At this time, the device A cannot query the matched BIFT, and then the device A discards the BIER packet.

[0181] Optionally, the content of the BIFT includes a BFR neighbor (Nbr) and an FBM. The BFR neighbor identifies the next-hop BFR to which the device forwards the packet. The way of forwarding the packet by using the BIFT is, for example, when the BFR queries the matched BIFT by the table lookup method described in the previous paragraph, the BFR performs an and operation on the bit string in the BIER header and the FBM in the matched BIFT, modifies the bit string in the BIER header as the result of the and operation, and forwards the modified BIER packet to the BFR neighbor in the matched BIFT.

[0182] (13) Bit indexed explicit replication (BIER)

[0183] BIER is a multicast technology based on bit index for explicit replication. In the BIER technology, intermediate nodes replicate and forward messages according to bit strings without maintaining the state of multicast groups or creating multicast distribution trees, thereby saving the huge overhead caused by maintaining the state of multicast groups and constructing multicast distribution trees in traditional multicast technologies.

[0184] The bit string in the BIER technology is generally carried in a BIER header (also referred to as a BIER option), and a multicast message is encapsulated in an inner layer of the BIER header. The multicast message encapsulated in the BIER message can be an Internet Protocol version 4 (IPv4) message or an Internet Protocol version 6 (IPv6) message. Types of the BIER message include, but are not limited to, BIER-Multi-Protocol Label Switching (MPLS) and BIER based on IPv6 data plane (BIERv6).

[0185] The process of BIER in technical implementation generally includes: allocating a BFR ID to each edge BFR in a BIER sub-domain. In the BIER forwarding process, when a multicast message arrives at the BIER sub-domain, a BFIR (i.e., an ingress node) determines to which BFER (i.e., a destination leaf node of the multicast message) the multicast message is to be sent, encapsulates a bit string representing the BFERs into a BIER header of the multicast message, thereby generating a BIER message. When an intermediate node receives the BIER message, the intermediate node replicates and forwards the BIER message according to the bit string, so that the BIER message is forwarded to a next-hop BFR node. When a BFER (i.e., an egress node) receives the BIER message, the BFER determines that the BFR ID of the node in the bit string is set, and then removes the BIER header in the BIER message, thereby restoring the BIER message to the original multicast message, and forwarding the multicast message to a receiver by querying a routing forwarding table.

[0186] (14) Silent failure

[0187] The so-called silent failure refers to that, when a fault occurs, a device does not report a corresponding alarm, and does not perform automatic recovery.

[0188] (15) Autonomous system (AS)

[0189] Generally, when the network is large, it is divided into multiple domains, such as different ASs according to different management domains, and the boundary of the AS can be an ASBR. Alternatively, in the case of BIER service deployment in an AS, each BFR in the AS is configured to flood BIER information based on an interior gateway protocol (IGP) so as to establish a BIFT based on the flooded BIER information. In the case of BIER service deployment in multiple ASs, each BFR is configured to flood BIER information in the AS to which it belongs by IGP, and BGP protocol is deployed between different ASs without flooding BIER information. The IGP based on which the BIER information is flooded is, for example, an intermediate system to intermediate system (IS-IS) protocol or an (open shortest path first, OSPF) protocol.

[0190] Alternatively, the protocol based on which the BIER information is flooded in the AS is replaced from IGP to border gateway protocol (BGP), or other routing protocols.

[0191] The technical solutions are illustrated below.

[0192] The configuration problem that causes packet loss due to forwarding failure in the BIER service (i.e., a mute failure) is mainly caused by the fact that the max SI configured by a downstream node is less than the max SI configured by an upstream node.

[0193] Here, the upstream and downstream refer to the forwarding direction of multicast traffic. The transmission direction of multicast traffic from a root node to a leaf node is the direction from upstream to downstream. The root node and the intermediate node can be referred to as having an upstream-downstream relationship, and the intermediate node and the leaf node can also be referred to as having an upstream-downstream relationship. That is, the problem is caused by the fact that the max SI configured by an intermediate node is less than the max SI configured by a root node, and the problem is also caused by the fact that the max SI configured by a leaf node is less than the max SI configured by an intermediate node. In addition, whether a device is an upstream node or a downstream node is related to the role played by the device in forwarding multicast traffic. That is, the same device does not necessarily always play the role of an upstream node or a downstream node in the existing network.

[0194] Please refer to Figure 1 , Figure 1 A typical scenario in which a configuration problem causes a forwarding failure is shown. As Figure 1As shown, the forwarding path of the multicast traffic is PE1 node (root node) → P node (intermediate forwarding node) → PE2 node (leaf node), and the max SI configured on the P node is smaller than that configured on the PE1 node. In the forwarding phase, when the BIER packet is forwarded to the P node, the P node discards the BIER packet because no matching forwarding table entry is found, resulting in the interruption of the transmission of the multicast traffic at the P node.

[0195] In the following, the reason why the too small max SI configuration leads to the forwarding failure is analyzed in combination with the principle of querying the forwarding table entry in the BIER technology.

[0196] In the BIER technology, a device forwards a BIER packet by querying a BIFT. The index of the BIFT is usually a combination of SI, BSL and sub-domain ID. Each combination of SI, BSL and sub-domain ID corresponds to a BIFT on the device and is reflected in the BIFT ID field in the BIER packet. When the device receives the BIER packet, the device decapsulates the BIER packet to obtain SI, BSL and sub-domain ID; and the device queries the BIFT saved on the device with SI, BSL and sub-domain ID as the index.

[0197] In combination with the above forwarding principle, the scenario shown in FIG. 1 is still taken as an example to analyze the problem of the silent failure. Figure 1 The forwarding path of the multicast traffic shown in FIG. 1 includes PE1 → P → PE2, and the scenario is taken as an example to analyze the problem of the silent failure.

[0198] For example, the max SI configured on the PE1 is 100, the BSL configured on the PE1 is 256, the max SI configured on the P is 10, and the BFR ID of the PE2 is 20005. When the PE1 wants to forward the BIER packet to the PE2, the PE1 calculates SI = 78 according to the BFR ID of the PE2 and the BSL configured on the PE1 in the manner of dividing the BFR ID (20005) by the BSL (256) and rounding up, and then the PE1 encapsulates the information of SI = 78 into the BIER packet and sends the BIER packet to the P node. After receiving the BIER packet, the P node decapsulates the BIER packet to obtain SI = 78. Since the maximum value of SI in the index of the BIFT on the P node is 10, the P node cannot index the corresponding BIFT according to SI = 78. That is, the SI encapsulated in the packet has exceeded the processing range of the table entry on the P node, or the forwarding capability of the P node. Therefore, the P node discards the packet, resulting in the interruption of the transmission of the traffic.

[0199] In addition, in the scenario where the BIER service is deployed across AS domains, the above-described problem is more difficult to solve. This is because the nodes in the same AS domain can obtain the max SI flooded by other nodes through the IGP protocol, while different AS domains are naturally isolated to a certain extent. If the upstream node and the downstream node are in different AS domains, the upstream node cannot obtain the max SI of the downstream node through IGP flooding, and it is difficult to analyze whether the configuration is problematic according to the max SI of the device and the max SI of the downstream node.

[0200] In the embodiments of the present application, the SI of two BFRs having an upstream and downstream relationship is obtained, the SI of the upstream BFR is compared with the SI of the downstream BFR, and when it is found that the SI of the upstream BFR is greater than the SI of the downstream BFR, it can be known from the analysis of the technical problem that this situation may cause a forwarding failure, and therefore it is determined that there is a configuration failure, so that the configuration failure is accurately and effectively detected.

[0201] In addition, since the controller can accurately detect the configuration failure, it helps to solve the configuration failure to a certain extent, thereby reducing the risk of packet loss or even flow interruption when the intermediate node forwards the packet caused by the configuration failure.

[0202] The implementation details of the two actions of obtaining SI and comparing SI in the embodiments of the present application include multiple cases. Next, the related features of the two actions are described in a general manner from multiple angles such as the execution subject, the execution time, and the execution scenario, and then some detailed method embodiment is described to describe how to execute the two actions.

[0203] (A) Execution subject

[0204] Next, the execution subject of the two actions of obtaining SI and comparing SI is described by way of example in combination with three cases, as described below in (A-1) to (A-3).

[0205] (A-1) The execution subject is the controller

[0206] For example, the execution subject of the two actions of obtaining SI and comparing SI is the controller. That is, the controller collects the SI of two-hop BFRs having an upstream and downstream relationship, and the controller compares the SI of the upstream BFR with the SI of the downstream BFR to determine whether the configuration has a failure. This implementation can be referred to the description of the Figure 3 embodiment, Figure 4 embodiment, and Figure 5 embodiment.

[0207] The controller in the embodiments of the present application refers to any entity of a control plane or a management plane, and can be replaced by a network management system (NMS) or an element management system (EMS).

[0208] (A-2) The execution subject is a device responsible for forwarding

[0209] For example, the execution subject of the two actions of acquiring SI and comparing SI is a BFR, that is, the device collects SI of BFRs having an upstream-downstream relationship within two hops, such as acquiring SI of the device itself and SI of a neighbor BFR (such as a previous-hop BFR or a next-hop BFR), or acquiring SI of a BFR two hops before the device or SI of a BFR two hops after the device, or acquiring SI of a BFR one hop before the device and SI of a BFR one hop after the device, and the device determines whether a configuration is faulty by comparing SI of an upstream BFR with SI of a downstream BFR. This implementation can be referred to the description of the following Figure 8 embodiment and Figure 9 embodiment. The device as the execution subject of detecting a fault is, for example, a BFIR or a root node, or a one-hop intermediate BFR, or a BFER or a leaf node.

[0210] (A-3) The execution subject is a combination of a controller and a device

[0211] For example, the two actions of acquiring SI and comparing SI are cooperatively executed by a controller and a device. For example, the device acquires SI of two BFRs having an upstream-downstream relationship, the device compares the SI and then notifies the comparison result to the controller, and the controller determines whether a fault exists according to the comparison result reported by the device. This implementation can be referred to the description of the following Figure 10 embodiment.

[0212] The various possible cases of the execution subject listed above are all examples, and the embodiments do not limit the execution subject of the two actions of acquiring SI and comparing SI.

[0213] (B) Execution time

[0214] Optionally, from the perspective of the device, the device acquires SI-related parameters of other devices in the process of notifying BIER information in the process of establishing a BIFT.

[0215] In a typical implementation of the BIFT establishment procedure, each BFR in a BIER sub-domain advertises its BIER information (e.g., BFR prefix, sub-domain ID, BSL, or BFR ID) to other BFRs in the BIER sub-domain through IGP, so as to flood the BIER information in the BIER sub-domain. After receiving the BIER information flooded by other BFRs through IGP, each BFR learns the BFR neighbors from the BFR to each BFER through path computation, so as to establish the BIFT.

[0216] In the method flow of the embodiments of the present application, optionally, the device receives SI-related parameters from other devices in the process of advertising BIER information, e.g., receives SI-related parameters carried by other devices through IGP packets in the process of flooding BIER information through IGP. Optionally, the device performs the action of comparing SI after IGP flooding, or sends the SI-related parameters to the controller after IGP flooding.

[0217] From the perspective of the controller, the two actions of obtaining SI and comparing SI are optionally performed in the network planning phase.

[0218] The network planning, e.g., a procedure for implementing traffic engineering, generally includes the steps of information uploading, path computation, path establishment, and traffic forwarding. In the method flow of the embodiments of the present application, the action of obtaining SI is performed, e.g., when uploading information, and the action of comparing SI is performed, e.g., before traffic forwarding.

[0219] For example, the device uploads SI-related parameters to the controller together with the information required for path computation (e.g., bandwidth, delay, etc. of the link between the device and other BFRs). After obtaining the SI-related parameters uploaded by the device, the controller compares SI to determine whether there is a configuration failure. If the controller finds that there is a configuration failure, it solves the configuration failure problem by prompting an administrator or reconfiguring, etc., and then performs the steps of path computation, path establishment, and traffic forwarding, so as to solve the configuration failure problem in advance before the BIER service is opened, and avoid traffic forwarding failure due to configuration failure after the BIER service is opened.

[0220] For another example, the controller deletes nodes with configuration problems (e.g., nodes with too small SI configuration) from the topology when performing path computation, and then performs path computation again, so that the calculated BIER forwarding path does not pass through the nodes with configuration problems. When deploying the BIER service based on the BIER forwarding path, since the multicast traffic does not pass through the nodes with configuration problems, the problem of traffic forwarding failure is naturally avoided.

[0221] (C) Execution scenario

[0222] The embodiments of the present application are applicable to various execution scenarios, which are described from different dimensions as follows.

[0223] (C-1) Cross-AS domain and single-AS domain

[0224] Optionally, the embodiments of the present application are applied to the scenario of BIER service across AS domains.

[0225] The so-called BIER service across AS domains refers to that BIER packet forwarding needs to cross different AS domains. A typical scenario of BIER service across AS domains is that, for example, a video server (multicast source) is connected to a PE device of an operator backbone network, and a viewer terminal (receiver) is connected to a gateway device of each metropolitan network, and the backbone network and the metropolitan network are divided into different AS domains. In this service scenario, BIER packet forwarding needs to cross the AS domain of the backbone network and the AS domain of the metropolitan network.

[0226] In the cross-AS domain scenario, the BFRs in a BIER sub-domain are located in different AS domains. For example, the BFIR and the BFER in a BIER sub-domain are located in different AS domains; for another example, different intermediate nodes in a BIER sub-domain are located in different AS domains; for another example, the BFIR and the intermediate nodes in a BIER sub-domain are located in different AS domains, or the intermediate nodes and the BFER in a BIER sub-domain are located in different AS domains.

[0227] In the cross-AS domain scenario, the action of obtaining SI is, for example, obtaining the SI of two BFRs belonging to different AS domains and having an upstream and downstream relationship, according to the embodiments of the present application. The communication protocol based on which SI is obtained is, for example, a protocol supporting inter-domain communication, such as BGP, for example, BGP link-state (BGP-LS), for another example, BGP multicast VPN (MVPN), for another example, Path Computation Element Communication Protocol (PCEP), Network configuration protocol (NETCOF), Simple Network Management Protocol (SNMP) or Telemetry, for another example, Representational State Transfer (RESTful).

[0228] Alternatively, the embodiments of the present application are applied to a scenario of BIER service single AS domain deployment. In the single AS domain scenario, all BFRs in a BIER sub-domain are located in the same AS domain. In combination with the embodiments of the present application, the action of obtaining SI in the single AS domain scenario is, for example, obtaining SI of BFRs having an upstream and downstream relationship in the same AS domain. The type of the communication protocol based on which SI is obtained is, for example, a protocol of intra-domain communication, for example, IGP, such as an OSPF protocol or an IS-IS protocol.

[0229] (C-2) BIERv6 and BIER-MPLS

[0230] Optionally, the embodiments of the present application are applied to a BIERv6 scenario. The so-called BIERv6 refers to carrying BIER based on native IPv6. In the BIERv6 scenario, a destination address field of an IPv6 basic message header of an outer layer of a BIER message carries a specific IPv6 address of a next-hop BFR, that is, an End.BIER address, and the BIER message is guided to the next-hop BFR through the End.BIER address.

[0231] Alternatively, the embodiments of the present application are applied to a BIER-MPLS scenario. The so-called BIER-MPLS, sometimes referred to as BIER, refers to carrying BIER based on MPLS. In the BIER-MPLS scenario, an MPLS label of a next-hop BFR is carried in a BIER message.

[0232] (C-3) BIERv6 and BIER-MPLS

[0233] Optionally, the embodiments of the present application are applied to a scenario of a multicast message being an IPv6 message. In the scenario of the multicast message being an IPv6 message, a multicast message encapsulated in an inner layer of a BIER header in a BIER message is an IPv6 message.

[0234] Alternatively, the embodiments of the present application are applied to a scenario of a multicast message being an IPv4 message. In the scenario of the multicast message being an IPv6 message, a multicast message encapsulated in an inner layer of a BIER header in a BIER message is an IPv4 message.

[0235] The following is an example of an operating environment of the embodiments of the present application. Figure 2 The following is an example of an operating environment of the embodiments of the present application.

[0236] Figure 2 FIG. 1 is a schematic diagram of an architecture of a system 20 provided by the embodiments of the present application. Figure 2 The system 20 shown includes PE1, ASBR 1, ASBR 2, PE2, PE3, and a controller. PE1, ASBR 1, ASBR 2, PE2, and PE3 belong to the same BIER sub-domain.

[0237] The functions, positions, connection relationships and typical product forms of each device in the following are exemplified. Figure 2

[0238] (1) PE1

[0239] PE1 is a root node, which can also be referred to as a BFIR, or an ingress node, or a head node. PE1 is deployed at the boundary of AS 65001. PE1 and a multicast source are connected through a network. When the multicast source initiates a multicast packet, PE1 is configured to receive the multicast packet from the multicast source, encapsulate a BIER header to the multicast packet to obtain a BIER packet, and then PE1 forwards the BIER packet to ASBR1. PE1 is, for example, a router or a switch.

[0240] (2) ASBR 1

[0241] ASBR1 is an intermediate node responsible for cross-domain traffic forwarding, which can also be referred to as an intermediate BFR. ASBR1 is deployed at the boundary of AS 65001. When ASBR1 receives the BIER packet from PE1, ASBR1 is configured to forward the BIER packet to ASBR2, so that the BIER packet is forwarded from AS 65001 to AS 65002. ASBR1 and PE1, ASBR2 are connected through a network respectively. ASBR1 is, for example, a router or a switch.

[0242] (3) ASBR 2

[0243] ASBR2 is an intermediate node. ASBR2 is deployed at the boundary of AS 65002. When ASBR2 receives the BIER packet from ASBR1, ASBR2 is configured to forward the BIER packet to the destination leaf node in AS 65002, such as PE2 and PE3. ASBR2 and ASBR1, PE2 and PE3 are connected through a network respectively. ASBR2 is, for example, a router or a switch.

[0244] (4) PE2

[0245] PE2 is a leaf node, which can also be referred to as a BFER, or an egress node, or a tail node. PE2 is deployed at the boundary of AS 65002. PE2 is connected to a receiver 1. When PE2 receives the BIER packet from ASBR2, PE2 is configured to decapsulate the BIER packet to obtain a multicast packet, and PE2 forwards the multicast packet to the receiver 1. PE2 is, for example, a router or a switch.

[0246] (5) PE3

[0247] ​PE3 is a leaf node. PE3 is deployed at the border of AS 65002. PE2 and receiver 2 are connected. When PE3 receives a BIER packet from ASBR 2, PE3 is configured to decapsulate the BIER packet to obtain a multicast packet, and PE3 forwards the multicast packet to receiver 2. PE3 is, for example, a router or a switch.

[0248] (6) Controller

[0249] The controller is responsible for managing each device in the BIER sub-domain. The controller is connected to ASBR 1 and ASBR 2 through the network. For example, the controller and ASBR 1 establish a BGP peer relationship, and the controller and ASBR 2 establish a BGP peer relationship.

[0250] The controller is configured to obtain BIER information of all nodes in the BIER sub-domain from ASBR 1 and ASBR 2 through the BSP LS protocol, such as BIER sub-domain ID, BSL, SI maximum value, BFR ID, and the like.

[0251] The controller is, for example, a server, a personal computer, a network device, or the like. Alternatively, the controller is a separate physical device, or a cluster or distributed system formed by multiple physical devices, and can also be a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, and the like basic cloud computing services.

[0252] The method flow is described below in conjunction with the operating environment described above.

[0253] Embodiments of the present application relate to a process of collecting SI-related parameters of multi-hop BFRs on a BIER forwarding path. For the sake of brevity and clarity, the following description focuses on how to collect SI-related parameters of two-hop BFRs. In the case of three or more BFRs on the BIER forwarding path, the process of collecting SI-related parameters of more-hop BFRs can refer to the process of collecting SI-related parameters of two-hop BFRs. Alternatively, in the case of N-hop BFRs on the BIER forwarding path, the method provided by the embodiments of the present application is used to collect SI-related parameters of each hop BFR in the N-hop BFRs, thereby ensuring the comprehensiveness of information collection and avoiding missing fault detection, N being a positive integer.

[0254] Embodiments of the present application relate to collecting and comparing SI related parameters of BFRs with upstream and downstream relationship. In order to distinguish the description of upstream BFR and downstream BFR, "first BFR" and "second BFR" are used to respectively refer to the BFR upstream and downstream on the BIER forwarding path. That is, the first BFR and the second BFR have upstream and downstream relationship, and the second BFR is a downstream node of the first BFR on the BIER forwarding path.

[0255] The roles played by the first BFR and the second BFR in the BIER forwarding path include various cases, which are illustrated below in combination with case (1) to case (3). The following case (1) to case (3) are commonly applicable to each of the embodiments below.

[0256] Case (1) the first BFR is a root node (BFIR), and the second BFR is an intermediate node.

[0257] For example, in combination with the running environment shown in Figure 2 , the first BFR in the method flow described below is PE1 in Figure 2 , and the second BFR in the method flow described below is ASBR 1 or ASBR 2 in Figure 2 . For another example, in combination with the running environment shown in Figure 2 , the first BFR in the method flow described below is PE1 in Figure 2 , and the second BFR in the method flow described below is P node in Figure 2 .

[0258] Case (2) the first BFR is an intermediate node, and the second BFR is a leaf node (BFER). For example, in combination with the running environment shown in Figure 2 , the first BFR in the method flow described below is ASBR 1 or ASBR 2 in Figure 2 , and the second BFR in the method flow described below is PE2 or PE3 in Figure 2 .

[0259] Case (3) the first BFR is one intermediate node, and the second BFR is another intermediate node. For example, in combination with the running environment shown in Figure 2 , the first BFR in the method flow described below is ASBR 1 in Figure 2 , and the second BFR in the method flow described below is ASBR 2 in Figure 2 .

[0260] The positional relationship of the first BFR and the second BFR in the BIER forwarding path includes various cases, which are illustrated below in combination with case I to case II. The following case I to case II are commonly applicable to each of the embodiments below.

[0261] Case I, the second BFR and the first BFR are adjacent in the BIER forwarding path, that is, the second BFR and the first BFR have an up-and-down hop relationship, and the second BFR is the next hop node of the first BFR in the BIER forwarding path. In other words, the second BFR and the first BFR have a BFR neighbor relationship.

[0262] For example, in combination with the running environment shown in Figure 2 , the first BFR in the method process described below is PE1 in Figure 2 , and the second BFR in the method process described below is P node in Figure 2 .

[0263] The so-called up-and-down hop relationship or BFR neighbor relationship herein is achieved, for example, by a direct connection manner, and also achieved, for example, by a non-direct connection manner.

[0264] The typical feature of the direct connection manner is that two BFR neighbors (such as the first BFR and the second BFR) are physically connected by an optical fiber or other wired medium. From the IP routing level, the two BFR neighbors are one-hop reachable. For a more detailed explanation of the direct connection concept, reference can be made to the description in section 2.1 of RFC4903 Multi-Link Subnet Issues.

[0265] The typical feature of the non-direct connection manner is that there is one or more non-BIER nodes between two BFR neighbors (such as the first BFR and the second BFR). For example, there is a unicast tunnel between the two BFR neighbors, for example, there is a multicast tunnel other than BIER between the two BFR neighbors, for example, there is a layer 2 path or a physical layer path (such as an Ethernet or optical switching path) between the two BFR neighbors, for example, the two BFR neighbors are connected through a private network built by an enterprise.

[0266] Case II, the second BFR and the first BFR are separated by one or more hop BFRs.

[0267] For example, in combination with the running environment shown in Figure 2 , the first BFR in the method process described below is PE1 in Figure 2 , and the second BFR in the method process described below is ASBR 2 or PE2 or PE 3 in Figure 2 .

[0268] The first BFR and the second BFR belong to the same BIER sub-domain, and the BIER sub-domain includes an AS to which the first BFR belongs and an AS to which the second BFR belongs. For example, the sub-domain ID of the first BFR and the sub-domain ID of the second BFR are the same.

[0269] Optionally, the first BFR and the second BFR belong to different ASs. For example, combining Figure 2 Based on the operating environment shown, the first BFR in the method flow described below is Figure 2 In AS 65001, PE1 or ASBR 1 is used, while the second BFR is... Figure 2 ASBR 2, PE2, or PE3 in AS65002.

[0270] Alternatively, the first BFR and the second BFR belong to the same AS. For example, in combination Figure 3 Based on the operating environment shown, the first BFR in the method flow described below is Figure 3 In AS 65001, PE1, the second BFR is Figure 3 ASBR 1 in AS 65001. For example, the first BFR is... Figure 3 ASBR 2 in AS 65002, the second BFR is Figure 2 PE2 or PE3 in AS 65002.

[0271] The following describes some method embodiments, which are described in a progressive manner. The same or similar parts between the embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.

[0272] Figure 2 This is a flowchart of a fault detection method provided in an embodiment of this application. Figure 2 The method shown is, for example, a solution for cross-AS domain scenarios. Figure 2 In the method shown, the first BFR and the second BFR belong to different AS. Figure 2 The method shown includes the following steps S301 to S306.

[0273] Step S301: The first BFR sends the SI-related parameters of the first BFR to the routing device A.

[0274] SI-related parameters refer to parameters that can be used to calculate the SI, or the SI itself. Parameters that can be used to calculate the SI include, for example, the BFR ID and BSL. For instance, the SI-related parameters for the first BFR include the BFR ID and BSL of the first BFR. Similarly, the SI-related parameters for the first BFR include the SI of the first BFR.

[0275] Step S302: Routing device A sends the SI-related parameters of the first BFR to the controller.

[0276] The routing device A is a device in the AS where the first BFR is located. For example, the routing device A is an edge device in the AS where the first BFR is located. For example, in combination with the running environment shown in FIG. 1, the routing device A is the ASBR 1 in the AS 1, and the first BFR is the PE1 in the AS 1. Figure 2 For example, in combination with the running environment shown in FIG. 1, the routing device A is the ASBR 1 in the AS 1, and the first BFR is the PE1 in the AS 1. Figure 3 For example, in combination with the running environment shown in FIG. 1, the routing device A is the ASBR 1 in the AS 1, and the first BFR is the PE1 in the AS 1. Figure 4 For example, in combination with the running environment shown in FIG. 1, the routing device A is the ASBR 1 in the AS 1, and the first BFR is the PE1 in the AS 1.

[0277] Optionally, the first BFR and the routing device A interact with the SI-related parameters through IGP. For example, the first BFR generates a first IGP packet, the first BFR sends the first IGP packet to the routing device A, and the first IGP packet includes the SI-related parameters of the first BFR. The routing device A receives the first IGP packet and obtains the SI-related parameters of the first BFR from the first IGP packet.

[0278] Step S303, the second BFR sends the SI-related parameters of the second BFR to the routing device B.

[0279] The routing device B is a device in the AS where the second BFR is located. For example, the routing device B is an edge device in the AS where the second BFR is located. For example, in combination with the running environment shown in FIG. 1, the routing device B is the ASBR 2 in the AS 2, and the second BFR is the PE2 or PE3 in the AS 2. Figure 4 For example, in combination with the running environment shown in FIG. 1, the routing device B is the ASBR 2 in the AS 2, and the second BFR is the PE2 or PE3 in the AS 2. Figure 4 For example, in combination with the running environment shown in FIG. 1, the routing device B is the ASBR 2 in the AS 2, and the second BFR is the PE2 or PE3 in the AS 2. Figure 4 For example, in combination with the running environment shown in FIG. 1, the routing device B is the ASBR 2 in the AS 2, and the second BFR is the PE2 or PE3 in the AS 2.

[0280] For example, the SI-related parameters of the second BFR include the BFR ID of the second BFR and the BSL of the BFR. For another example, the SI-related parameters of the second BFR include the SI of the second BFR.

[0281] Optionally, the second BFR and the routing device B interact with the SI-related parameters through IGP. For example, the second BFR generates a second IGP packet, the second BFR sends the second IGP packet to the routing device B, and the second IGP packet includes the SI-related parameters of the second BFR. The routing device B receives the second IGP packet and obtains the SI-related parameters of the second BFR from the second IGP packet.

[0282] Step S304, the routing device B sends the SI-related parameters of the second BFR to the controller.

[0283] Step S305, the controller obtains the SI of the first BFR and the SI of the second BFR.

[0284] The controller receives the SI-related parameters of the first BFR from the routing device A and receives the SI-related parameters of the second BFR from the routing device B. The controller obtains the SI of the first BFR based on the SI-related parameters of the first BFR. The controller obtains the SI of the second BFR based on the SI-related parameters of the second BFR.

[0285] For example, the SI-related parameter is the BFR ID and the BSL, and the process of obtaining the SI by the controller includes: obtaining the SI of the first BFR based on the BFR ID of the first BFR and the BSL of the first BFR; and obtaining the SI of the second BFR based on the BFR ID of the second BFR and the BSL of the second BFR. In this way, the controller can uniformly calculate the SI actually required by each device and then compare the SI, thereby reducing the calculation amount of each device.

[0286] For example, the SI-related parameter is the SI itself, and the process of obtaining the SI by the controller includes: receiving the SI of the first BFR sent by the routing device A, and receiving the SI of the second BFR sent by the routing device B. In this way, the controller can directly compare the SI sent by the device, thereby reducing the calculation amount of the controller.

[0287] In step S306, the controller determines that there is a configuration fault based on the SI of the first BFR being greater than the SI of the second BFR.

[0288] The method provided in the embodiment enables the controller to obtain the SI of the BFRs having an upstream-downstream relationship in different AS domains, compare the SI of the upstream BFR with the SI of the downstream BFR, and determine that there is a configuration fault when it is found that the SI of the upstream BFR is greater than the SI of the downstream BFR, thereby accurately and effectively detecting the configuration fault in the BIER service cross-AS domain deployment scenario.

[0289] In addition, in the scenario where the BIER service is deployed across multiple ASs, one routing device (such as an ASBR) in each AS domain is responsible for reporting information, so that the controller can collect the SI-related parameters of each device in the domain and further collect the BIER information of all devices in the entire BIER sub-domain, thereby ensuring the comprehensiveness of information collection in the cross-domain scenario and further avoiding missing of fault detection.

[0290] Figure 2 The embodiments shown take the BFR as an example to describe that the BFR transmits the SI-related parameter to other devices (such as ASBRs) in the AS, and then the other devices in the AS upload the SI-related parameter to the controller. In other embodiments, the interaction action between the BFR and the other devices in the AS is omitted. For example, the BFR is just an edge device of the AS, or each BFR in the BIER sub-domain respectively notifies the SI parameter to the controller. The following describes the embodiments in combination with the following Figure 2 The embodiments shown are taken as examples.

[0291] Figure 2 FIG. 1 is a flowchart of a fault detection method provided by an embodiment of the present application.

[0292] Figure 4The method is provided, for example, as a solution in a cross-AS domain scenario. Figure 3 In the method, the first BFR and the second BFR belong to different ASs. For example, in combination with Figure 5 In the running environment, the first BFR is Figure 5 the ASBR 1, and the second BFR is Figure 5 the ASBR 2. Figure 5 The method includes the following steps S311 to S316.

[0293] In step S311, the first BFR sends SI-related parameters of the first BFR to a controller.

[0294] In step S313, the second BFR sends SI-related parameters of the second BFR to the controller.

[0295] In step S315, the controller acquires SI of the first BFR and SI of the second BFR.

[0296] In step S316, the controller determines that there is a configuration fault based on the SI of the first BFR being greater than the SI of the second BFR.

[0297] The method provided in the embodiment enables the controller to acquire SI of BFRs having an upstream-downstream relationship in different AS domains, compare SI of an upstream BFR with SI of a downstream BFR, and determine that there is a configuration fault when it is found that the SI of the upstream BFR is greater than the SI of the downstream BFR, thereby accurately and effectively detecting a configuration fault in a BIER service cross-AS domain deployment scenario.

[0298] The above-described Figure 5 In the embodiment, it is described that one device (a routing device A or a routing device B) in each AS through which a BIER forwarding path passes is selected to be responsible for reporting parameters of devices in the AS to a controller. In other embodiments, the parameters of devices of a BIER forwarding path are collected by a root node and then reported to the controller. The following embodiments are used as examples. Figure 3 The embodiments are used as examples.

[0299] Figure 4 FIG. 1 is a flowchart of a fault detection method provided by an embodiment of the application. Figure 5 The method is provided, for example, as a solution in a cross-AS domain scenario. Figure 3 In the method, the first BFR and the second BFR belong to different ASs. Figure 4 The method includes the following steps S321 to S326.

[0300] In step S321, the first BFR sends SI-related parameters of the first BFR to a root node.

[0301] Step S323, the second BFR sends SI-related parameters of the second BFR to the root node.

[0302] Step S324, the root node receives the SI-related parameters from the first BFR and the SI-related parameters from the second BFR, and the root node sends the SI-related parameters of the first BFR and the SI-related parameters of the second BFR to the controller.

[0303] Step S325, the controller obtains the SI of the first BFR and the SI of the second BFR.

[0304] Step S326, the controller determines that there is a configuration fault based on the SI of the first BFR being greater than the SI of the second BFR.

[0305] The method provided by the embodiment, the controller obtains the SI of the BFRs having an upstream-downstream relationship in different AS domains, compares the SI of the upstream BFR with the SI of the downstream BFR, and when it is found that the SI of the upstream BFR is greater than the SI of the downstream BFR, determines that there is a configuration fault, thereby accurately and effectively detecting a configuration fault in a BIER service cross-AS domain deployment scenario.

[0306] In addition, since the root node is used to uniformly collect the BIER information of the nodes on the forwarding path and report the BIER information to the controller, not only does the controller obtain the BIER information of all the nodes on the forwarding path, but also the controller only needs to establish a peer relationship or a communication connection with the root node, without requiring the controller to establish a peer relationship or a communication connection with multiple nodes on the path, thereby saving the communication overhead of the controller.

[0307] The above describes the basic flow of some implementation manners that may be adopted when the controller is responsible for fault detection through the three embodiments of Figure 5 、 Figure 3 and Figure 4 The following describes some features commonly applicable to the three embodiments of Figure 5 、 Figure 3 and Figure 4 from different aspects, see the following aspects one to five.

[0308] Aspect one, for a scenario within an AS domain

[0309] Figure 5 、 Figure 3 and Figure 4 The three embodiments describe how to detect a fault in a cross-AS domain scenario. Figure 5 、 Figure 3 and Figure 4 The three embodiments are also applicable to detecting a fault in an AS domain scenario. In an AS domain scenario, Figure 5 、 Figure 3 andFigure 4 The first BFR and the second BFR in the three embodiments are replaced by BFRs belonging to the same AS, for example, BFRs belonging to different ASs.

[0310] The application is applied to the scenario in the AS domain, Figure 5 The changes that the embodiments can produce are, for example, that the first BFR and the second BFR send respective SI-related parameters to the same routing device, and the routing device reports the SI-related parameters of the first BFR and the SI-related parameters of the second BFR to the controller together. The routing device is, for example, an edge device of the AS to which the first BFR and the second BFR belong.

[0311] Aspect two, action of the controller in the case where the SI of the first BFR is greater than the SI of the second BFR

[0312] In some embodiments, in the case where the SI of the first BFR is greater than the SI of the second BFR, the controller helps the network administrator to solve the fault or to realize the automatic solution of the fault by performing some actions. The following is illustrated by way of example in ways A to C.

[0313] Way A, alarm

[0314] In some embodiments, in the case where the SI of the first BFR is greater than the SI of the second BFR, the controller generates alarm information and outputs the alarm information.

[0315] The alarm information indicates that there is a configuration fault corresponding to the SI. The form of the alarm information or how the controller implements the alarm includes various ways. For example, the controller plays an alarm audio signal (i.e., outputs the alarm information) by using a buzzer, and the alarm audio signal indicates that there is a configuration fault corresponding to the SI, thereby prompting the configuration fault through sound. For another example, the controller controls a light to turn on or flash (i.e., outputs the alarm information), thereby prompting the configuration fault through light; for another example, the controller displays a prompt box in an alarm interface, and the prompt box includes the alarm information, thereby prompting the configuration fault in a visual manner through the interface.

[0316] The controller prompts the network administrator in a timely manner that there is a configuration fault corresponding to the SI by performing the alarm, thereby helping the network administrator to solve the problem of the configuration fault in a timely manner.

[0317] The content of the alarm information output by the controller includes various cases, and the following illustrates the content that the alarm information can include, see ways A-1 to A-4.

[0318] Way A-1, the alarm information includes the identity of the second BFR.

[0319] In some embodiments, the controller finds that the SI of the first BFR is greater than the SI of the second BFR, carries the identity of the second BFR in the alarm information, and outputs the alarm information containing the identity of the second BFR. For example, the controller carries the BFR prefix of the second BFR in the alarm information.

[0320] Through the above-mentioned embodiments, it is told to the network administrator which specific device has a configuration problem, helping the network administrator to quickly locate the device with a configuration problem, thereby reducing the difficulty of changing the configuration.

[0321] Method A-2, the alarm information includes the SI of the second BFR.

[0322] In some embodiments, the controller finds that the SI of the first BFR is greater than the SI of the second BFR, carries the SI of the second BFR in the alarm information, and outputs the alarm information containing the SI of the second BFR.

[0323] Through the above-mentioned embodiments, it is told to the network administrator which specific device has a configuration problem, helping the network administrator to quickly locate the device with a configuration problem, thereby reducing the difficulty of changing the configuration.

[0324] Method A-3, the alarm information includes the reference value of the SI configuration.

[0325] In some embodiments, the controller determines the reference value of the SI configuration based on the SI of the multi-hop nodes on the BIER forwarding path, and carries the reference value of the SI configuration in the alarm information.

[0326] For example, after the controller collects the max SI configured on all devices through which the BIER forwarding path passes, the controller determines which device among all devices through which the BIER forwarding path passes has the maximum max SI configured thereon, and takes the max SI of the device with the maximum max SI as the reference value of the SI configuration.

[0327] For another example, after the controller collects the BFR ID and BSL configured on all devices through which the BIER forwarding path passes, the controller calculates the actual required max SI of each device according to the BFR ID and BSL configured on each device. The controller determines which device among all devices through which the BIER forwarding path passes has the maximum actual required max SI, and takes the required max SI of the device as the reference value of the SI configuration.

[0328] For another example, the controller takes the max SI configured on the root node as the reference value of the SI configuration.

[0329] Through the above embodiments, the SI configuration reference is provided for the network administrator due to the SI of the multi-hop node on the integrated path, so as to reduce the difficulty and complexity of the SI configuration, and to avoid the SI configuration being too small to cause the forwarding failure and the SI configuration being too large to cause the device replication pressure being too large.

[0330] In a manner A-4, the alarm information includes consequence prompt information of the SI configuration failure, and the consequence prompt information indicates that there is a risk of packet loss when the multicast service traffic is forwarded to the second BFR. Through this manner, the administrator is prompted that there may be a consequence of forwarding failure.

[0331] In a manner B, the SI of the fault point is adjusted

[0332] The fault point in the scenario of the embodiment mainly refers to the BFR with the SI being too small. Taking the scenario described in the above embodiment as an example, the fault point is, for example, the second BFR, and in the case that the SI of the first BFR is greater than the SI of the second BFR, the controller automatically instructs the second BFR to adjust the SI.

[0333] The implementation manner in which the controller instructs the second BFR to adjust the SI is, for example, that the controller generates a reconfiguration instruction and sends the reconfiguration instruction to the second BFR. The second BFR adjusts the SI of the second BFR to the SI of the first BFR according to the reconfiguration instruction.

[0334] The reconfiguration instruction is used to instruct the second BFR to adjust the SI of the second BFR to the SI of the first BFR. The information that the reconfiguration instruction can carry includes various cases, which are exemplarily described below.

[0335] In a possible implementation, the controller carries the SI of the first BFR in the reconfiguration instruction. Through this manner, the target value of the SI adjustment (the SI of the first BFR) is told to the second BFR, so as to help the second BFR automatically adjust the SI.

[0336] In another possible implementation, the controller determines the difference between the SI of the second BFR and the SI of the first BFR, and carries the difference between the SI of the second BFR and the SI of the first BFR in the reconfiguration instruction. Through this manner, the adjustment amount of the SI adjustment (the difference between the SI of the second BFR and the SI of the first BFR) is told to the second BFR, so as to help the second BFR automatically adjust the SI.

[0337] Optionally, the controller carries the reconfiguration instruction in a NETCOF packet, an SNMP packet or other management plane packet and sends the reconfiguration instruction to the second BFR.

[0338] Through the above-mentioned embodiments, the SI configuration failure problem is solved automatically by triggering the automatic updating of the configuration of the problematic node, thereby improving the speed and efficiency of solving the SI configuration failure problem.

[0339] Mode C, adjusting the forwarding path

[0340] For example, in the case where the SI of the first BFR is greater than the SI of the second BFR, the controller re-performs path calculation with the constraint condition of not passing through the second BFR. For example, the controller deletes the node of the second BFR from the network topology of the BIER sub-domain, or the controller clips the link passing through the second BFR in the network topology of the BIER sub-domain, and then the controller re-performs path calculation with the topology after node deletion or link clipping to obtain a new BIER forwarding path that no longer passes through the second BFR. Then, the controller issues the calculated new BIER forwarding path to the root node to instruct the root node to update the BIER forwarding path.

[0341] Through the above-mentioned embodiments, the SI configuration failure problem is solved automatically by triggering the automatic updating of the configuration of the problematic node, thereby improving the speed and efficiency of solving the SI configuration failure problem.

[0342] Aspect three, message type based on which SI related parameters are announced

[0343] The message type based on which the device announces the SI related parameters to the controller includes but is not limited to BGP-LS, PCEP, NETCOF, SNMP message or Telemetry, etc., and the following is described by taking BGP-LS as an example.

[0344] For example, the device sends a BGP-LS message to the controller to announce the SI related parameters. Figure 3In the example of S302, the process of using BGP-LS to announce SI related parameters includes: the routing device A generates a BGP-LS message based on the SI related parameters of the first BFR, and sends the BGP-LS message to the controller. The controller receives the BGP-LS message sent by the routing device A, and obtains the SI related parameters of the first BFR from the BGP-LS message. The BGP-LS message carries the SI related parameters of the first BFR. For example, the BGP-LS message includes the BFR ID of the first BFR and the BSL of the first BFR. For another example, the BGP-LS message includes the SI of the first BFR. Optionally, the BGP-LS message is a BGP update message. Optionally, the BGP-LS message further includes the BFR prefix of the first BFR. The BFR prefix of the first BFR is equivalent to the device identifier of the first BFR, for example, the BFR prefix of the first BFR is the loopback address of the first BFR. The controller can distinguish different devices according to the BFR prefix in the BGP-LS message.

[0345] The above paragraph takes S302 as an example, and the method of using BGP-LS to announce SI related parameters described in the above paragraph is also applicable to Figure 4 the embodiment S304, Figure 5 the embodiment S311, S313 and Figure 3 In the embodiment S324, the corresponding processing flow can refer to the above paragraph.

[0346] The above takes the BGP-LS message as an example, and the BGP-LS message in the above can be optionally replaced by a PCEP message, a NETCOF message, an SNMP message or a Telemetry message.

[0347] Aspect four, the field (or encapsulation format / data structure) carrying the SI related parameters in the message

[0348] In some embodiments, a new type length value (TLV) is extended to carry the SI related parameters. The so-called TLV refers to an encoding structure, which generally includes a type field, a length field and a value field. The value field allows carrying another TLV, thereby producing a nested structure of TLV-sub TLV-sub sub TLV. In combination with the present embodiment, for example, the type field of the TLV indicates that this TLV is used to carry the SI related parameters. The value field of the TLV includes the sub-domain ID (SD ID) field, the max SI field, the BFR ID and the BSL field.

[0349] The carrying position of the TLV includes various manners. For example, an extended BIER network layer reachability information (NLRI) carries the TLV. The BIER NLRI is carried in a BGP-LS message, for example.

[0350] Figure 4 A BGP-LS added BIER NLRI format provided for the embodiment is shown in the figure. Figure 5 The protocol ID indicates the BGP protocol. The identifier indicates the identification of the IGP process in the BGP-LS message reported by the device, and is used to distinguish different IGP processes. Different IDs need to be configured for different IGP processes. The local node description is designed as the BFR prefix of the device, for example. Each router has its own BFR prefix, and the BFR prefix represents the unique identification of each device. The controller can distinguish different devices according to the BFR prefix. The BIER information description represents the specific BIER parameters reported by the device.

[0351] Figure 3 For Figure 4 The format of the sub-TLV in the BIER information description is shown in the figure. Figure 5 The type is generally set as BIER4 or BIER6. The length indicates the length of the entire TLV. Figure 3 The other fields except the type field and the length field are the specific BIER information reported, such as the sub-domain ID, the BFR ID, the BSL and the max SI.

[0352] Alternatively, an option in an IPv6 extension header is extended, and the TLV extended in the embodiment is carried by a new option, so as to realize the advertisement of the SI related parameters.

[0353] Aspect five, the order of sending the SI related parameters by different devices

[0354] Figure 4 , Figure 5 and Figure 2 The three embodiments described do not limit the order of sending the SI related parameters by different devices. Alternatively, each device sends the SI related parameters in a front-back order, or different devices send the SI related parameters concurrently. For example, in combination with the method shown in Figure 2 S302 and S304 can alternatively adopt a front-back order or be executed concurrently. In combination with the method shown in Figure 8As shown in the method, S311 and S313 can optionally be executed sequentially, one after the other, or concurrently. Combined with... Figure 9 As shown in the method, S321 and S323 can be executed either sequentially or concurrently. Figure 8 , Figure 9 as well as Figure 8 The three embodiments described do not limit the order in which different devices send SI-related parameters.

[0355] Figure 8 , Figure 8 and Figure 9 The example describes the process by which devices within two ASs along the path announce SI-related parameters to the controller. When the BIER forwarding path traverses three or more ASs, devices in each AS send SI-related parameters to the controller in a similar manner.

[0356] The following describes the method and process in the context of a specific scenario.

[0357] by Figure 9 Taking the scenario shown as an example, the controller collects... Figure 9 The four BIER parameters for each node in the BIER subdomains PE1, ASBR1, ASBR2, PE2, and PE3 are collected. The four BIER parameters collected are SD ID, BFR ID, BSL, and maxSI, which will be used later to analyze the conditions for the existence of silent faults.

[0358] For example, the controller collects BFR ID 20009 and BSL 256 for PE1, and the maximum SI value set on PE1 is 100. The controller calculates, using formulas or constraints, that the actual required SI for PE1 is 78. For ASBR1, the controller collects BFR ID 9, BSL 256, and the maximum SI value set on ASBR1 is 10. Therefore, the controller calculates that the actual required SI for ASBR1 is 0. Based on the calculated SI, the controller knows that ASBR1 cannot forward multicast packets sent from PE1 to ASBR1 because 78 (the actual required SI for PE1) > 0 (the actual required SI for ASBR1), exceeding the entry processing range of ASBR1. At this point, the controller issues an alarm, notifying the customer that there is a silent fault in the ASBR1 configuration, requiring manual repair; otherwise, traffic forwarding will be affected.

[0359] The above-described method embodiments illustrate the case where the controller is the entity performing the actions of obtaining and comparing SI. The following will... Figure 10 Examples and Figure 10Embodiments are illustrated by way of example with respect to a case where the execution subject of the two actions of acquiring SI and comparing SI is a device. Figure 10 Embodiments and Figure 11 Embodiments are applicable to scenarios within an AS domain.

[0360] Optionally, it is determined by an upstream node whether a downstream node (such as a neighbor BFR of the device) has a configuration fault. The following is illustrated by way of example with respect to an embodiment shown in FIG. 3. Figure 2 Figure 11 is a flowchart of a fault detection method provided by an embodiment of the present application. Figure 2 The method shown includes the following steps S333 to S336.

[0361] Step S333, the second BFR sends SI-related parameters of the second BFR to the first BFR.

[0362] Step S335, the first BFR acquires SI of the second BFR based on the SI-related parameters of the second BFR.

[0363] There are various implementation manners for the second BFR to send the SI-related parameters. For example, the first BFR and the second BFR belong to the same AS. The second BFR advertises the SI-related parameters to the first BFR through an IGP packet. Illustratively, the second BFR generates an IGP packet and sends the IGP packet to the first BFR. The IGP packet includes the SI-related parameters of the second BFR. The first BFR obtains the SI-related parameters of the second BFR from the IGP packet. Alternatively, the first BFR and the second BFR belong to different ASs. The second BFR advertises the SI-related parameters to the first BFR through a BGP packet.

[0364] Step S336, the first BFR determines that the second BFR has a configuration fault based on the SI of the first BFR being greater than the SI of the second BFR.

[0365] The method provided by the embodiment, by determining SI of a downstream node, comparing SI of the device with SI of the downstream node, and determining that there is a configuration fault when it is found that SI of the device is greater than SI of the downstream node, the configuration fault is accurately and effectively detected.

[0366] Optionally, it is determined by a downstream node whether the device itself has a configuration fault. The following is illustrated by way of example with respect to an embodiment shown in FIG. 4. Figure 3 Figure 11 is a flowchart of a fault detection method provided by an embodiment of the present application. Figure 3 The method shown includes the following steps S341 to S346.

[0367] Step S341, the first BFR sends SI-related parameters of the first BFR to the second BFR. ​​

[0368] Step S345, the second BFR obtains the SI of the first BFR based on the SI-related parameter of the first BFR.

[0369] There are various implementations of how the first BFR sends the SI-related parameter. For example, the second BFR and the first BFR belong to the same AS. The first BFR notifies the second BFR of the SI-related parameter through an IGP packet. Illustratively, the first BFR generates an IGP packet and sends the IGP packet to the second BFR. The IGP packet includes the SI-related parameter of the first BFR. The second BFR obtains the SI-related parameter of the first BFR from the IGP packet. Alternatively, the second BFR and the first BFR belong to different ASes. The first BFR notifies the second BFR of the SI-related parameter through a BGP packet.

[0370] Step S346, the second BFR determines that the second BFR has a configuration fault based on the SI of the second BFR being less than the SI of the first BFR.

[0371] The method provided by the embodiment enables the device to determine the SI of the upstream BFR, compare the SI of the device with the SI of the upstream BFR, and determine that there is a configuration fault when it is found that the SI of the device is less than the SI of the downstream BFR, thereby accurately and effectively detecting the configuration fault.

[0372] Optionally, in the case where the device is responsible for detecting whether there is a configuration fault, the device solves the fault by means of alarming or adjusting the SI when the fault is found. For example, the step of the controller outputting the alarm information described above is replaced by the first BFR or the second BFR outputting the alarm information. For another example, the step of the controller sending the reconfiguration instruction to the second BFR described above is replaced by the first BFR sending the reconfiguration instruction to the second BFR. In this way, the device automatically instructs the BFR neighbor to adjust the SI or automatically adjusts the SI of the device.

[0373] One possible implementation of how the device determines the maximum value of the SI configured in the BIER sub-domain is to design a scheme similar to the OSPF selection of a designated router (DR), that is, each device initially considers its own SI to be the maximum, until the maximum value of the SI configured on all devices in the entire BIER sub-domain is selected, and then each device modifies the SI configured on the device to the selected maximum SI.

[0374] The following illustrates the case where the two actions of obtaining the SI and comparing the SI are performed by the controller and the device in cooperation. See Figure 4 the illustrated embodiment. Figure 11 is a flowchart of a fault detection method provided by an embodiment of the application. Figure 4 The method shown includes the following steps S351 to S356.

[0375] Step S351, the second BFR sends SI-related parameters of the second BFR to the first BFR.

[0376] Step S352, the first BFR acquires the SI of the second BFR based on the SI-related parameters of the second BFR.

[0377] Step S353, the first BFR compares the SI of the first BFR with the SI of the second BFR, and obtains a comparison result of the SI.

[0378] The comparison result is used to represent the numerical relationship between the SI of the first BFR and the SI of the second BFR. The form of the comparison result, or how the BFR represents the comparison result, includes various implementation manners. In one possible implementation, the BFR uses the value of one bit to represent the comparison result. For example, if the first BFR finds that the SI of the first BFR is greater than the SI of the second BFR, the first BFR sets the bit to 1, that is, uses 1 to represent the comparison result. If the first BFR finds that the SI of the first BFR is not greater than the SI of the second BFR, the first BFR does not need to set the bit to 1, that is, uses 0 to represent the comparison result.

[0379] Step S354, the first BFR sends the comparison result of the SI to the controller.

[0380] How to send the comparison result to the controller includes various implementation manners. In one possible implementation, the first BFR carries the comparison result in a flag field of an announcement message sent to the controller. The controller parses the flag field of the announcement message to obtain the comparison result of the SI.

[0381] Optionally, a reserved field of an existing message is extended to carry the comparison result of the SI. For example, one bit in a reserved field is used as a flag field for carrying the comparison result.

[0382] Alternatively, a new type of TLV is extended, and the value field of the TLV is used as a flag field for carrying the comparison result.

[0383] The announcement message for carrying the comparison result includes but is not limited to a BGP-LS message, a PCEP message, a NETCOF message, an SNMP message, or a Telemetry message, and the like. The protocol type of the announcement message for carrying the comparison result is not limited in the embodiment.

[0384] Step S356, the controller receives the comparison result of the SI from the first BFR, and determines that there is a configuration fault based on the comparison result of the SI.

[0385] For example, if the comparison result of the first BFR is that the SI of the first BFR is greater than the SI of the second BFR, the controller determines that there is a configuration fault.

[0386] The method and device provided in the embodiment help the controller to detect whether there is a configuration fault by determining the SI of the downstream node, comparing the SI of the device with the SI of the downstream node, and sending the comparison result to the controller. On the basis of implementing the detection function, the analysis and decision process of the controller is simplified, and thus the processing overhead of the controller is saved. Moreover, since the byte amount occupied by sending the comparison result is small, for example, only one bit may be used, the occupied bandwidth resource is saved, and the communication overhead of the device and the controller is also saved.

[0387] The embodiment of the present application further provides a manner of automatically allocating BSL, and solves the problem of BSL waste.

[0388] In order to help understanding, the reasons for the problem of BSL waste are analyzed and described below.

[0389] In the related art, the BSL is usually provided to the device in a manual configuration manner. The manually configured BSL is usually unreasonable. The unreasonable BSL configuration mentioned here refers to that the BSL is too large relative to the number of devices. That is, the number of devices is relatively small, and the BSL is relatively long. The number of devices here usually refers to the number of BFERs in a BIER sub-domain, and in some scenarios, it refers to the number of BFRs. For example, there are only 2 BFERs in a BIER sub-domain, and the BSL is set to 256, which is a typical unreasonable BSL configuration. Because the BSL recommended in the RFC standard includes 5 values of 64, 128, 256, 512 and 1024, if there are 2 BFERs, the value of the BSL is set to 64, which is enough for the implementation of the data plane forwarding. The value of the BSL is set to 128, which is obviously too large. A basic principle of the BIER technology is that the BIER multicast datagram (usually referred to as BIER packet in the BIER protocol) carries a bit string (Bit String) in the BIER packet header (also referred to as BIER option) when forwarding along the way. Therefore, if the BSL is set to be larger, the length of the bit string in the packet will be longer, and the proportion of the payload part (multicast service data, which is the part outside the BIER header) in the entire packet will be smaller, and the packet inflation rate (the inflation rate refers to the ratio of the length of the payload to the total length of the packet) will be larger, and the technical problem of increasing the packet inflation rate will occur. In addition, the longer the bit string in the packet is, the longer the total length of the packet is, and the more bandwidth is required to transmit the packet, and the technical problem of wasting bandwidth resources occurs. The problem of bit string waste, or how to determine whether the length of the bit string is sufficient, needs to be analyzed from the role of the bit string in the BIER technology. In the BIER technology, each bit in the bit string is used to identify a BFER, so the length of the bit string is more than the number of BFERs, and theoretically, it can already meet the forwarding requirements.

[0390] In some embodiments of the present application, the controller optionally configures the BSL for the first BFR and the second BFR based on the number of BFERs in the BIER sub-domain; and the controller sends the configured BSL to the first BFR and the second BFR respectively.

[0391] For example, the controller selects a value closest to and greater than the number of BFERs from 64, 128, 256, 512 and 1024, and configures the BSL as the first BFR and the second BFR. For example, the controller configures 64 as the BSL of the first BFR and the BSL of the second BFR based on the number of BFERs in the BIER sub-domain being less than 64; the controller configures 128 as the BSL of the first BFR and the BSL of the second BFR based on the number of BFERs in the BIER sub-domain being greater than 64 and less than 128.

[0392] In the above embodiments, since the BSL is allocated according to the number of devices in the network (the number of BFERs in a BIER sub-domain), the value of the BSL matches the number of devices, avoids the bit string being too long relative to the number of devices, reduces the length of the bit string in the packet, and thus reduces the ratio of the bit string to the payload, thereby reducing the expansion rate of the packet, and the overall length of the packet is reduced, thereby saving the bandwidth required for transmitting the packet and saving bandwidth resources. For example, if the number of devices in a BIER sub-domain is less than 64, the BSL is allocated as 64. Therefore, bit string waste is avoided, the expansion rate of the packet is reduced, and bandwidth resources are saved.

[0393] The embodiments of the present application also provide a method for automatically allocating BFR IDs to avoid problems such as multiple copies of packets at the head node and waste of BSL caused by improper setting of BFR IDs. The method for automatically allocating BFR IDs may, for example, include steps (1) to (3).

[0394] Step (1) The controller collects the topology of the BIER sub-domain.

[0395] The controller can calculate the total number of devices (BFRs) in the BIER sub-domain, that is, the maximum size of the network, by collecting the topology of the entire BIER sub-domain. The controller can allocate a BFR ID to each router device within a certain range after determining the size of the network.

[0396] Step (2) The controller sets a BFR ID pool. The controller allocates BFR IDs according to the size of the network. For example, if the number of devices in the BIER sub-domain is less than 64, the controller automatically allocates BFR IDs from 1-64. If the number of devices in the BIER sub-domain is greater than 64 and less than 128, the controller automatically allocates BFR IDs from 1-128, and so on. In addition, the controller also uniformly allocates BSL. When the BFR ID pool is set to 64, the controller sets the BSL to 64. When the BFR ID pool is set to 128, the controller sets the BSL to 128.

[0397] The BFR ID pool refers to the resource pool that allocates BFR IDs. The BSL and BFR ID pool remain the same. For example, the BSL can be set to one of the three values: 64, 128, or 256.

[0398] Step (3) The controller uniformly distributes configurations. Devices with an MVPN instance configured and sender enable enabled are identified as root nodes, while devices with an MVPN instance configured but sender enable disabled are identified as leaf nodes. The root and leaf nodes distribute the maximum values ​​of SD, BSL, and SI (the minimum value that satisfies the BFR ID bit) to the BIER view. The root node additionally distributes SD and BSL data to the MVPN instance.

[0399] At this point, all BFR nodes in the same SD domain have achieved reasonable planning of the maximum values ​​of BFR ID, BSL, and SI.

[0400] The above method realizes the scheme of automatic allocation of BRF ID in BIER tunnel in the network, which improves the efficiency of bit string encapsulation, reduces multicast replication, reduces the pressure on router equipment, improves multicast replication efficiency, and improves the efficiency of network operation and maintenance. It also avoids problems such as multiple copies of packets at the header node and waste of BSL caused by improper BRF-ID settings.

[0401] The foregoing described some method flows provided by the embodiments of this application. The following describes the apparatus provided by the embodiments of this application.

[0402] Figure 5 This is a schematic diagram of the structure of a fault detection device 400 provided in an embodiment of this application. The fault detection device 400 includes an acquisition unit 402 and a determination unit 403. Optionally, the fault detection device 400 further includes a receiving unit 401, a transmitting unit 404, and an output unit 405.

[0403] The following section describes how the various functional units in the fault detection device 400 interact to execute the technical solution, based on the previously described system operating environment and method steps.

[0404] Optionally, combined Figure 11 From the system operating environment shown, Figure 5 The fault detection device 400 shown is located at Figure 10The controller in the system operating environment shown is configured as follows: The receiving unit 401 receives SI-related parameters sent by ASBR 1 and ASBR 2. The acquiring unit 402 acquires the SIs of PE1, ASBR 1, ASBR 2, PE2, and PE3. The determining unit 403 compares the SIs of upstream and downstream nodes among PE1, ASBR 1, ASBR 2, PE2, and PE3 to determine if a fault exists. The sending unit 404 sends an SI reconfiguration command to the routing device with a configuration fault among PE1, ASBR 1, ASBR 2, PE2, and PE3, thereby instructing the device to adjust its SI. Alternatively, the sending unit 404 sends a path adjustment command to PE1, thereby instructing PE1 to adjust its forwarding path. The output unit 405 outputs alarm information.

[0405] Optionally, combined Figure 11 Let's take a look. Figure 10 The fault detection device 400 shown is located at Figure 11 In the illustrated method flow, the controller receives the SI-related parameters in steps S302 and S304 using unit 401. Unit 402 executes step S305, and unit 403 executes step S306.

[0406] Optionally, combined Figure 12 Let's take a look. Figure 12 The fault detection device 400 shown is located at Figure 12 In the illustrated method flow, the controller, receiving unit 401, is used to receive SI-related parameters in S311 and S313. Acquisition unit 402 is used to execute S315, and determination unit 403 is used to execute S316.

[0407] Optionally, combined Figure 12 Let's take a look. Figure 12 The fault detection device 400 shown is located at Figure 2 In the illustrated method flow, the controller, receiving unit 401, is used to receive SI-related parameters in S324. Acquisition unit 402 is used to execute S325, and determination unit 403 is used to execute S326.

[0408] Optionally, combined Figure 11 Let's take a look. Figure 2 The fault detection device 400 shown is located at Figure 3 In the method flow shown, the controller, receiving unit 401 is used to receive the comparison result in S354, and determining unit 403 is used to execute S356.

[0409] Figure 11The described device embodiments are merely illustrative. For example, the division of the units described above is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0410] Each unit in the fault detection device 400 is implemented, in whole or in part, through software, hardware, firmware, or any combination thereof.

[0411] The following section describes, in conjunction with the controller 600, some possible implementations of the various functional units in the fault detection device 400 using hardware or software.

[0412] In some embodiments, the fault detection device 400 described above is software running in the controller, and the acquisition unit 402 and the determination unit 403 are software units with corresponding functions. For example, the acquisition unit 402 and the determination unit 403 are... Figure 3 The processor 601 in the memory 602 reads the program code stored in the memory and generates the software unit.

[0413] In some embodiments, each unit in the fault detection device 400 is implemented by different hardware; for example, the acquisition unit 402 is implemented by... Figure 4 At least a portion of the processing resources of at least one processor 601 (e.g., one or two cores of a multi-core processor) are used for processing, while the determining unit 403 is implemented by... Figure 11 The remaining processing resources in at least one processor 601 (e.g., other cores in a multi-core processor) are used, or programmable devices such as field-programmable gate arrays (FPGAs) or coprocessors are employed. The receiving unit 401 and the transmitting unit 404 are... Figure 4 The network interface 603 is implemented in the system.

[0414] Figure 5 This is a schematic diagram of the structure of a controller 600 provided in an embodiment of this application.

[0415] The controller 600 includes a processor 601 and a memory 602, and optionally also includes a network interface 603 and an input / output interface 606.

[0416] The following section describes how the various functional units in the controller 600 interact to execute the technical solution, based on the previously described system operating environment and method steps.

[0417] Optionally, combinedFigure 11 from the perspective of the system operating environment shown, Figure 5 The controller 600 shown is arranged in Figure 10 The controller in the system operating environment shown. The network interface 603 is configured to receive SI-related parameters sent by the ASBR 1 and SI-related parameters sent by the ASBR 2. The processor 601 is configured to acquire the SI of the PE1, the ASBR 1, the ASBR 2, the PE2, and the PE3. The processor 601 is further configured to compare the SI of the nodes having an upstream and downstream relationship in the PE1, the ASBR 1, the ASBR 2, the PE2, and the PE3 to determine that there is a configuration fault. The network interface 603 is configured to send an SI reconfiguration instruction to the routing device in which the configuration fault exists among the PE1, the ASBR 1, the ASBR 2, the PE2, and the PE3, so as to instruct the device to adjust the SI. Alternatively, the network interface 603 is configured to send a path adjustment instruction to the PE1, so as to instruct the PE1 to adjust the forwarding path. The input and output interface 606 is configured to output alarm information.

[0418] Optionally, in combination with Figure 11 from the perspective of the system operating environment shown, Figure 10 The controller 600 shown is arranged in Figure 12 The controller in the method flow shown, the network interface 603 is configured to receive the SI-related parameters in S302 and S304. The processor 601 is configured to perform S305 and S306.

[0419] Optionally, in combination with Figure 12 from the perspective of the system operating environment shown, Figure 13 The controller 600 shown is arranged in Figure 2 The controller in the method flow shown, the network interface 603 is configured to receive the SI-related parameters in S311 and S313. The processor 601 is configured to perform S315 and S316.

[0420] Optionally, in combination with Figure 13 from the perspective of the system operating environment shown, Figure 2 The controller 600 shown is arranged in Figure 2 The controller in the method flow shown, the network interface 603 is configured to receive the SI-related parameters in S324. The processor 601 is configured to perform S325 and S326.

[0421] Optionally, in combination with Figure 3 from the perspective of the system operating environment shown, Figure 13 The controller 600 shown is arranged in Figure 3 The controller in the method flow shown, the network interface 603 is configured to receive the comparison result in S354. The processor 601 is configured to perform S356.

[0422] The processor 601 is, for example, a general central processing unit (CPU), a network processor (NP), a graphics processing unit (GPU), a neural-network processing unit (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits used to implement the embodiments of the present application. For example, the processor 601 includes an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

[0423] The memory 602 is, for example, a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disk storage, a magnetic disk storage or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. Alternatively, the memory 602 exists independently and is connected to the processor 601 through the internal connection 604. Alternatively, the memory 602 and the processor 601 are integrated together.

[0424] The network interface 603 uses any transceiver-like mechanism for communicating with other devices or a communications network. The network interface 603 includes, for example, at least one of a wired network interface or a wireless network interface. The wired network interface is, for example, an Ethernet interface. The Ethernet interface is, for example, an optical interface, a coaxial interface, or a combination thereof. The wireless network interface is, for example, a wireless local area networks (WLAN) interface, a cellular network interface, or a combination thereof.

[0425] In some embodiments, the processor 601 includes one or more CPUs, such as the CPU0 and the CPU1 shown. Figure 13

[0426] In some embodiments, the controller 600 optionally includes multiple processors, such as the processor 601 and the processor 605 shown. Each of these processors is, for example, a single-CPU, or alternatively a multi-CPU. A processor here refers to one or more devices, circuits, and / or processing cores for processing data, such as computer program instructions. Figure 3

[0427] In some embodiments, the controller 600 further includes an internal connection 604. The processor 601, the memory 602, and the at least one network interface 603 are connected through the internal connection 604. The internal connection 604 includes pathways for transferring information between the aforementioned components. The internal connection 604 is, for example, a single board or a bus. The internal connection 604 is, for example, divided into an address bus, a data bus, a control bus, or the like.

[0428] In some embodiments, the controller 600 further includes an input / output interface 606. The input / output interface 606 is connected to the internal connection 604.

[0429] In some embodiments, the input / output interface 606 is further used to connect with an output device. The input / output interface 606 outputs the alarm information generated by the processor 301 through the output device. The output device includes, but is not limited to, a display, a buzzer, a printer, an indicator, a projector, or the like.

[0430] Optionally, the processor 601 implements the method in the above embodiments by reading program codes stored in the memory 602, or the processor 601 implements the method in the above embodiments by program codes stored internally. In the case where the processor 601 implements the method in the above embodiments by reading program codes stored in the memory 602, the memory 602 stores program codes 610 for implementing the method provided in the embodiments of the present application.

[0431] ​​For more details on how processor 601 implements the above functions, please refer to the descriptions in the previous method embodiments, which will not be repeated here.

[0432] Figure 4 This is a schematic diagram of the structure of a routing device 500 provided in an embodiment of this application. The routing device 500 includes an acquisition unit 502 and a transmission unit 504. Optionally, the routing device 500 also includes a processing unit 503.

[0433] The following section describes how the various functional units in the routing device 500 interact to execute the technical solution, based on the previously described system operating environment and method steps.

[0434] Optionally, combined Figure 13 From the system operating environment shown, Figure 4 The routing device 500 shown is Figure 5 The system operating environment shown is either ASBR 1 or ASBR 2. The transmitting unit 504 is used to send... Figure 13 The controller sends SI-related parameters.

[0435] Optionally, combined Figure 5 Let's take a look. Figure 10 The routing device 500 shown is Figure 13 In the method flow shown, routing device A, acquisition unit 502 is used to acquire SI-related parameters, and sending unit 504 is used to execute S302. Alternatively, Figure 10 The routing device 500 shown is Figure 13 In the method flow shown, the routing device B and the sending unit 504 are used to execute S304.

[0436] Optionally, combined Figure 14 Let's take a look. Figure 14 The routing device 500 shown is Figure 14 The first BFR in the method flow shown is the sending unit 504, which is used to execute S311.

[0437] Optionally, combined Figure 14 Let's take a look. Figure 14 The routing device 500 shown is Figure 2 The root node in the method flow shown is the sending unit 504, which is used to execute S324.

[0438] Optionally, combined Figure 14 Let's take a look. Figure 2 The routing device 500 shown is Figure 2 In the method flow shown, the first BFR is used to execute S352 by the acquisition unit 502, S353 by the processing unit 503, and S354 by the sending unit 504.

[0439] Figure 3 The described device embodiments are merely illustrative. For example, the division of the units described above is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0440] Each unit in the routing device 500 is implemented, in whole or in part, through software, hardware, firmware, or any combination thereof. The following description, in conjunction with the routing device 700 described later, outlines some possible implementation methods for using hardware or software to implement the various functional units in the routing device 500.

[0441] In some embodiments, the acquisition unit 502 and processing unit 503 described above are software units with corresponding functions. For example, the acquisition unit 502 and processing unit 503 are... Figure 14 The processor 701 generates a software unit after reading the program code stored in the memory 702.

[0442] In some embodiments, each unit in the routing device 500 is implemented by different hardware; for example, the acquisition unit 502 is implemented by... Figure 3 At least a portion of the processing resources of at least one processor 701 (e.g., one or two cores of a multi-core processor) are used for processing, while the processing unit 503 is implemented by... Figure 4 The remaining processing resources in at least one processor 701 (e.g., other cores in a multi-core processor), or programmable devices such as field-programmable gate arrays (FPGAs) or coprocessors, are used to complete the process. The receiving unit 401 and the transmitting unit 504 are... Figure 14 The network interface 703 is implemented in it.

[0443] Figure 4 This is a schematic diagram of the structure of a routing device 700 provided in an embodiment of this application.

[0444] The routing device 700 includes a processor 701, a memory 702, and a network interface 703.

[0445] The following section describes how the various functional units in the routing device 700 interact to execute the technical solution, based on the previously described system operating environment and method steps.

[0446] Optionally, combined Figure 5 From the system operating environment shown, Figure 14 The routing device 700 shown isFigure 5 ASBR 1 or ASBR 2 in the system operating environment shown. The network interface 703 is configured to send SI-related parameters to the controller in S101. Figure 10

[0447] Optionally, in combination with Figure 14 , it can be seen that the routing device 700 is the ASBR 1 or ASBR 2 in the system operating environment shown. The processor 701 is configured to acquire the SI-related parameters, and instruct the network interface 703 to perform S302. Figure 10 Figure 14 Optionally, in combination with , it can be seen that the routing device 700 is the routing device A in the method flow shown. The processor 701 is configured to acquire the SI-related parameters, and instruct the network interface 703 to perform S302.

[0448] Figure 14 Optionally, in combination with ​ , it can be seen that the routing device 700 is the first BFR in the method flow shown. The processor 701 is configured to acquire the SI-related parameters, and instruct the network interface 703 to perform S311. ​

[0449] Optionally, in combination with ​ , it can be seen that the routing device 700 is the first BFR in the method flow shown. The processor 701 is configured to perform S352 and S353, and the processor 701 is further configured to instruct the network interface 703 to perform S354. ​ ​ Optionally, in combination with , it can be seen that the routing device 700 is the root node in the method flow shown. The processor 701 is configured to instruct the network interface 703 to perform S324.

[0450] ​ Optionally, in combination with ​ , it can be seen that the routing device 700 is the first BFR in the method flow shown. The processor 701 is configured to perform S352 and S353, and the processor 701 is further configured to instruct the network interface 703 to perform S354. ​

[0451] ​​​​​The processor 701 is, for example, a general central processing unit (CPU), a network processor (NP), a graphics processing unit (GPU), a neural-network processing unit (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits used to implement the embodiments of the present application. For example, the processor 701 includes an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

[0452] The memory 702 is, for example, a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disk storage, a magnetic disk storage or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. Alternatively, the memory 702 exists independently of the processor 701 and is connected to the processor 701 through the internal connection 704. Alternatively, the memory 702 and the processor 701 are integrated together.

[0453] Network interface 703 uses any transceiver-like device for communicating with other devices or communication networks. Network interface 703 includes, for example, at least one of a wired network interface or a wireless network interface. The wired network interface is, for example, an Ethernet interface. The Ethernet interface is, for example, an optical interface, an electrical interface, or a combination thereof. The wireless network interface is, for example, a wireless local area network (WLAN) interface, a cellular network interface, or a combination thereof.

[0454] In some embodiments, processor 701 includes one or more CPUs, such as ​ CPU0 and CPU1 are shown.

[0455] In some embodiments, the routing device 700 may optionally include multiple processors, such as... ​ Processors 701 and 705 are shown. Each of these processors is, for example, a single-core processor (CPU) or a multi-core processor (CPU). A processor here may optionally refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0456] In some embodiments, the routing device 700 further includes an internal connection 704. The processor 701, memory 702, and at least one network interface 703 are connected via the internal connection 704. The internal connection 704 includes pathways for transmitting information between the aforementioned components. Optionally, the internal connection 704 is a single board or a bus. Optionally, the internal connection 704 may be divided into an address bus, a data bus, a control bus, etc.

[0457] In some embodiments, the routing device 700 further includes an input / output interface 706. The input / output interface 706 is connected to the internal connection 704.

[0458] In some embodiments, the input / output interface 706 is also used to connect to an output device. The input / output interface 706 outputs alarm information generated by the processor 301 through the output device. The output device includes, but is not limited to, a display, a buzzer, a printer, an indicator light, a projector, etc.

[0459] Optionally, the processor 701 implements the method in the above embodiments by reading program code stored in the memory 702, or the processor 701 implements the method in the above embodiments by internally stored program code. When the processor 701 implements the method in the above embodiments by reading program code stored in the memory 702, the memory 702 stores program code 710 that implements the method provided in the embodiments of this application.

[0460] For more details of the processor 701 implementing the above functions, refer to the descriptions in the foregoing method embodiments, which are not repeated here.

[0461] In some embodiments, a computer readable storage medium is also provided, and the storage medium stores at least one instruction, which, when executed on a computer, causes the computer to perform the method procedure performed by the controller in the embodiments of the present application.

[0462] In some embodiments, a computer readable storage medium is also provided, and the storage medium stores at least one instruction, which, when executed on a computer, causes the computer to perform the method procedure performed by the routing device in the embodiments of the present application.

[0463] In some embodiments, a computer program product is also provided, and the computer program product includes one or more computer program instructions, which, when loaded and executed on a computer, cause the computer to perform the method procedure performed by the controller in the embodiments of the present application.

[0464] In some embodiments, a computer program product is also provided, and the computer program product includes one or more computer program instructions, which, when loaded and executed on a computer, cause the computer to perform the method procedure performed by the routing device in the embodiments of the present application.

[0465] In some embodiments, a chip is also provided, and the chip includes programmable logic circuit and / or program instructions, which, when the chip is executed, are used to implement the functions of the controller in the embodiments of the present application.

[0466] In some embodiments, a chip is also provided, and the chip includes programmable logic circuit and / or program instructions, which, when the chip is executed, are used to implement the functions of the routing device in the embodiments of the present application.

[0467] In some embodiments, a communication system is also provided, and the communication system includes a controller and a routing device. The controller is used to perform the method procedure performed by the controller in the method embodiments, and the routing device is used to perform the method procedure performed by the BFR in the method embodiments.

[0468] A refers to B, which means that A is the same as B or A is a simple transformation of B.

[0469] The terms "first" and "second" and the like in the description and claims of the embodiments of the present application are used to distinguish different objects, and are not used to describe a specific order of the objects, nor can they be understood as indicating or implying relative importance. For example, the first BFR and the second BFR are used to distinguish different BFRs, and are not used to describe a specific order of the BFRs, nor can they be understood as the first BFR being more important than the second BFR.

[0470] The data (including but not limited to SI, BFR-ID, BSL, etc.) and signals involved in the embodiments of the present application are, for example, authorized by users or fully authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0471] In the embodiments of the present application, unless otherwise specified, the meaning of "at least one" is one or more, and the meaning of "multiple" is two or more. For example, multiple BFRs refer to two or more BFRs.

[0472] The term "and / or" used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The term "and / or" is a description of the associated relationship between the associated objects, which means that there can be three relationships, for example, A and / or B can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " in the embodiments of the present application generally represents an "or" relationship between the preceding and following associated objects.

[0473] The above embodiments can be realized wholly or partially by software, hardware, firmware, or any combination thereof. When realized by software, it can be realized in the form of a computer program product wholly or partially. The computer program product includes one or more computer instructions. When loaded and executed on a computer, the computer program instructions wholly or partially produce the processes or functions described in the embodiments of the present application. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another, for example, the computer instructions can be transferred from one website, computer, server or data center to another through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be magnetic media (such as floppy disks, hard disks, magnetic tapes), optical media (such as DVDs), or semiconductor media (such as solid state disks (SSD)), etc.

[0474] The above examples are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing examples, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing examples, or make equivalent replacements for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A fault detection method, characterized in that, The method includes: The controller obtains the set identifier SI of the first bit-index-based explicitly replicated BIER forwarding router BFR and the SI of the second BFR. The first bit-index-based explicitly replicated BIER forwarding router BFR and the second BFR belong to different autonomous systems AS. The second BFR is a downstream node of the first bit-index-based explicitly replicated BIER forwarding router BFR on the BIER forwarding path. The controller determines that a configuration fault exists based on the fact that the SI of the first bit-index-based explicit copy BIER forwarding router BFR is greater than the SI of the second BFR. The controller obtains the set identifier SI of the first bit-index-based explicit copy BIER forwarding router (BFR) and the SI of the second BFR, including: The controller obtains the SI of the first bit-index-based explicit copy BIER forwarding router BFR based on the BIER forwarding router identifier BFR ID and the bit string length BSL of the first bit-index-based explicit copy BIER forwarding router BFR. The controller obtains the SI of the second BFR based on the BFR ID and the BSL of the second BFR.

2. The method according to claim 1, characterized in that, Before the controller obtains the SI of the second BFR based on the BFR ID and the BSL of the second BFR, the method further includes: The controller receives a first announcement message from the first routing device, the first announcement message including the BFR ID of the second BFR and the BSL of the second BFR.

3. The method according to claim 2, characterized in that, The first routing device is an edge device in the AS to which the second BFR belongs, or the first routing device is the second BFR.

4. The method according to claim 2, characterized in that, The first notification message includes BIER Network Layer Reachability Information (BIER NLRI), which includes the BFR ID of the second BFR and the BSL of the second BFR.

5. The method according to claim 2, characterized in that, The first notification message is a Border Gateway Protocol Link State (BGP-LS) message, a Path Calculation Unit Communication Protocol (PCEP) message, a Network Configuration Protocol (NETCOF) message, a Simple Network Management Protocol (SNMP) message, or a Telemetry message.

6. The method according to claim 1, characterized in that, Before the controller obtains the SI of the second BFR based on the BFR ID and the BSL of the second BFR, the method further includes: The controller receives a second announcement message from the root node on the BIER forwarding path. The second announcement message includes the BFR ID of the second BFR and the BSL of the second BFR.

7. The method according to any one of claims 1 to 4, characterized in that, After the controller determines that a configuration fault exists based on the fact that the SI of the first bit-index-based explicit copy BIER forwarding router BFR is greater than the SI of the second BFR, the method further includes: The controller outputs an alarm message indicating a configuration fault corresponding to the SI.

8. The method according to claim 7, characterized in that, The alarm information includes at least one of the identifier of the second BFR and the SI of the second BFR.

9. The method according to claim 7, characterized in that, The alarm information includes a reference value for the SI configuration, which is determined by the controller based on the SI of the multi-hop nodes on the BIER forwarding path.

10. The method according to any one of claims 1 to 6, characterized in that, After the controller determines that a configuration fault exists based on the fact that the SI of the first bit-index-based explicit copy BIER forwarding router BFR is greater than the SI of the second BFR, the method further includes: The controller sends a reconfiguration instruction to the second BFR, the reconfiguration instruction instructing the second BFR to adjust the SI of the second BFR to the SI of the first bit-index-based explicit copy BIER forwarding router BFR.

11. A fault detection device, characterized in that, The device is located in the controller and includes: The acquisition unit is used to acquire the set identifier SI of the first bit-index-based explicit copy BIER forwarding router BFR and the SI of the second BFR. The first bit-index-based explicit copy BIER forwarding router BFR and the second BFR belong to different autonomous systems AS. The second BFR is a downstream node of the first bit-index-based explicit copy BIER forwarding router BFR on the BIER forwarding path. The determining unit is configured to determine that a configuration fault exists based on the fact that the SI of the first bit-index-based explicit copy BIER forwarding router BFR is greater than the SI of the second BFR. The acquisition unit is used for: Based on the BIER forwarding router identifier BFR ID of the first bit-index-based explicit copy BIER forwarding router BFR and the bit string length BSL of the first bit-index-based explicit copy BIER forwarding router BFR, obtain the SI of the first bit-index-based explicit copy BIER forwarding router BFR. Based on the BFR ID and BSL of the second BFR, obtain the SI of the second BFR.

12. The apparatus according to claim 11, characterized in that, The device further includes: The receiving unit is configured to receive a first announcement message from a first routing device, the first announcement message including the BFR ID of the second BFR and the BSL of the second BFR.

13. The apparatus according to claim 12, characterized in that, The first notification message includes BIER Network Layer Reachability Information (BIER NLRI), which includes the BFR ID of the second BFR and the BSL of the second BFR.

14. The apparatus according to claim 12, characterized in that, The first notification message is a Border Gateway Protocol Link State (BGP-LS) message, a Path Calculation Unit Communication Protocol (PCEP) message, a Network Configuration Protocol (NETCOF) message, a Simple Network Management Protocol (SNMP) message, or a Telemetry message.

15. The apparatus according to claim 11, characterized in that, The device further includes: The receiving unit is configured to receive a second announcement message from the root node on the BIER forwarding path, the second announcement message including the BFR ID of the second BFR and the BSL of the second BFR.

16. The apparatus according to any one of claims 11 to 15, characterized in that, The device further includes: The output unit is used to output alarm information, which indicates the existence of a configuration fault corresponding to SI.

17. The apparatus according to any one of claims 11 to 15, characterized in that, The device further includes: A sending unit is configured to send a reconfiguration instruction to the second BFR, the reconfiguration instruction instructing the second BFR to adjust the SI of the second BFR to the SI of the first bit-index-based explicit copy BIER forwarding router BFR.

Images