BIERv6 message forwarding method, device and system

Abstract

The present application provides a method, device, and system for forwarding a BIERv6 message, the method comprising: a first network device receives a BIERv6 message, the first network device being a bit forwarding router BFR or a bit forwarding egress router BFER; the first network device determines whether the value of the hop limit field in the BIERv6 message is less than or equal to a preset threshold on the first network device, wherein the preset threshold is a number greater than or equal to 2, which is determined based on the number of one or more consecutive second network devices connected to the first network device, and the second network device is a device that does not support BIER forwarding; when the value of the hop limit field in the BIERv6 message is less than or equal to the preset threshold, the first network device avoids forwarding the BIERv6 message. The technical solution provided by the present application can avoid the waste of network bandwidth and the waste of bandwidth of the attacked device caused by a large number of ICMPv6 error messages, and improve the security of BIERv6 message forwarding.

Description

[0001] This application claims priority to a Chinese patent application filed with the Patent Office of China on May 30, 2020, with application number CN 202010480456.8 and invention name “A multicast message forwarding method, device and system”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of network communications, and more specifically, to a method, a first network device, and a system for forwarding BIERv6 messages based on bit-indexed explicit replication of the sixth version of the Internet Protocol. Background Art

[0003] During the forwarding process of Internet Protocol version 6 (IPv6) messages, if the value of the hop limit field in the outer IPv6 header of the IPv6 message is less than or equal to 1, the IPv6 message will not be forwarded to the downstream device. Instead, an Internet Control Message Protocol version 6 (ICMPv6) error message will be sent to the source address of the outer IPv6 header.

[0004] Bit-indexed explicit replication internet protocol version 6 (BIERv6) messages are a combination of BIER technology and IPv6. It is a one-to-many transmission process, and BIERv6 can be a unicast message. Therefore, if an attacker forges a BIERv6 message so that it receives a BIERv6 message with a hop limit field value less than or equal to 1 on multiple nodes during the one-to-many transmission process, the source address of the outer IPv6 header will receive multiple or even a large number of ICMPv6 error messages.

[0005] Therefore, in the BIERv6 scenario, how to avoid forwarding network devices from generating multiple or even a large number of ICMPv6 error messages and improve the security of BIERv6 message forwarding has become an urgent problem that needs to be solved. Summary of the Invention

[0006] The present application provides a method, device and system for forwarding BIERv6 messages, which can avoid the waste of network bandwidth and bandwidth of attacked devices caused by a large number of ICMPv6 error messages, and improve the security of BIERv6 message forwarding.

[0007] In a first aspect, a method for forwarding a BIERv6 message is provided, comprising: a first network device receives an explicitly copied BIERv6 message based on a bit index of the sixth version of the Internet Protocol, wherein the BIERv6 message includes a hop limit hoplimit field, and the first network device is a bit forwarding router BFR or a bit forwarding egress router BFER; the first network device determines whether the value of the hop limit field in the BIERv6 message is less than or equal to a preset threshold on the first network device, wherein the preset threshold is a number greater than or equal to 2, and the preset threshold is determined based on the number of one or more consecutive second network devices connected to the first network device, and the second network device is a device that does not support BIER forwarding; when the value of the hop limit field in the BIERv6 message is less than or equal to the preset threshold, the first network device avoids forwarding the BIERv6 message.

[0008] It should be understood that the first network device avoiding forwarding the BIERv6 message can be regarded as the first network device preventing the BIERv6 message from being sent to the next-hop device, or it can also be regarded as the first network device skipping forwarding the BIERv6 message. That is, the first network device does not send the BIERv6 message to the next-hop device of the first network device.

[0009] In the above technical solution, a threshold value greater than or equal to 2 can be configured on the device (first network device) that supports BIERv6 forwarding. The device that supports BIERv6 forwarding avoids forwarding the BIERv6 message when it checks that the hoplimit of the message is less than or equal to the threshold value before BIER forwarding the BIERv6 message. In this way, the probability of generating ICMPv6 error messages on BIERv6 messages sent to non-BIERv6 forwarding devices due to the hop limit value of the BIERv6 message being 1 or 0 can be reduced, thereby improving the security of BIERv6 message forwarding and avoiding the waste of network bandwidth and bandwidth of the attacked device caused by a large number of ICMPv6 error messages.

[0010] In one possible implementation, the method further includes: the first network device discarding the BIERv6 message.

[0011] In the above technical solution, in order to avoid occupying storage resources, the first network device can also discard the BIERv6 message.

[0012] In another possible implementation, the method also includes: if the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold and the inner layer of the BIERv6 message is not a BIER OAM message, the first network device discards the BIERv6 message.

[0013] In another possible implementation, the method further includes: when the value of the hoplimit field in the BIERv6 message is equal to the preset threshold, the first network device avoids forwarding the BIERv6 message.

[0014] In another possible implementation, the method further includes: if the first network device is the BFR, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold, the first network device avoids forwarding the BIERv6 message; or if the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold, the first network device avoids forwarding the BIERv6 message.

[0015] In another possible implementation, the BIERv6 message includes a bit string BitString, and the method further includes: when the first network device determines that a bit in the BitString is valid and the bit represents the first network device, the first network device determines itself as the BFER; or when the first network device determines that a bit in the BitString is valid and the bit represents a device other than the first network device, the first network device determines itself as the BFR.

[0016] It should be understood that for a certain message, the BFER and BFR can be different network devices, or can also be the same network device, and this application does not make specific restrictions on this. In other words, the first network device may also serve as the BFER and BFR of a certain message at the same time.

[0017] In another possible implementation, the method also includes: if the first network device is the BFR, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, the first network device sends the BIERv6 message to the next hop device of the first network device; or if the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, the first network device decapsulates the BIERv6 message and forwards the decapsulated inner message.

[0018] In another possible implementation, the first network device is a BFR or BFER in a BIER domain.

[0019] In a second aspect, a first network device is provided. The first network device is a bit forwarding router (BFR) or a bit forwarding egress router (BFER). The first network device includes:

[0020] A receiving module for receiving an explicitly replicated BIERv6 message based on a bit index of Internet Protocol version 6, wherein the BIERv6 message includes a hop limit field;

[0021] A processing module, used to determine whether the value of the hop limit field in the BIERv6 message is less than or equal to a preset threshold on the first network device, wherein the preset threshold is a number greater than or equal to 2, and the preset threshold is determined based on the number of one or more consecutive second network devices connected to the first network device, and the second network device is a device that does not support BIER forwarding;

[0022] The processing module is also used to avoid forwarding the BIERv6 message when the value of the hop limit field in the BIERv6 message is less than or equal to the preset threshold.

[0023] In one possible implementation, the processing module is also used to: discard the BIERv6 message.

[0024] In another possible implementation, the processing module is further used to: avoid forwarding the BIERv6 message when the value of the hoplimit field in the BIERv6 message is equal to the preset threshold.

[0025] In another possible implementation, the processing module is further used to: if the first network device is the BFR, avoid forwarding the BIERv6 message when the value of the hop limit field in the BIERv6 message is equal to the preset threshold; or if the first network device is the BFER, avoid forwarding the BIERv6 message when the value of the hop limit field in the BIERv6 message is equal to the preset threshold.

[0026] In another possible implementation, the BIERv6 message includes a bit string BitString, and the processing module is further used to: when a bit in the BitString is valid and the bit represents the first network device, determine itself as the BFER; or when a bit in the BitString is valid and the bit represents a device other than the first network device, determine itself as the BFR.

[0027] In another possible implementation, the processing module is also used to: if the first network device is the BFR, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, send the BIERv6 message to the next hop device of the first network device; or if the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, decapsulate the BIERv6 message and forward the decapsulated inner message.

[0028] In another possible implementation, the first network device is a BFR or BFER in a BIER domain.

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

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

[0031] In one possible design, the structure of the first network device includes a processor and an interface, wherein the processor is configured to support the first network device to perform corresponding functions in the above method. The interface is used to support the first network device to receive BIERv6 messages.

[0032] The first network device may further include a memory, which is coupled to the processor and stores program instructions and data necessary for the first network device.

[0033] In another possible design, the first network device includes: a processor, a transmitter, a receiver, a random access memory, a read-only memory, and a bus. The processor is coupled to the transmitter, receiver, random access memory, and read-only memory, respectively, via the bus. When the first network device needs to be operated, it is booted via a basic input / output system embedded in the read-only memory or a bootloader in an embedded system, thereby booting the first network device into normal operation. After the first network device enters normal operation, an application program and an operating system are run in the random access memory, causing the processor to execute the method of the first aspect or any possible implementation of the first aspect.

[0034] In a fourth aspect, a first network device is provided. The first network device includes a main control board and an interface board, and may further include a switching network board. The first network device is configured to perform the method of the first aspect or any possible implementation of the first aspect. Specifically, the first network device includes a module configured to perform the method of the first aspect or any possible implementation of the first aspect.

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

[0036] It is understandable that, in practical applications, the first network device may include any number of interfaces, processors or memories.

[0037] In a sixth aspect, a computer program product is provided, comprising: a computer program code, which, when executed on a computer, enables the computer to execute the above-mentioned first aspect or any possible execution method of the first aspect.

[0038] In a seventh aspect, a computer-readable medium is provided, the computer-readable medium storing program code, which, when executed on a computer, causes the computer to execute the method of the first aspect or any possible execution of the first aspect. Such computer-readable storage includes, but is not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), Flash memory, electrically EPROM (EEPROM), and hard drive.

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

[0040] In a ninth aspect, a system is provided, which includes the above-mentioned first network device. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a schematic network diagram of the BIER technology provided in an embodiment of this application.

[0042] Figure 2 This is a schematic diagram of a possible BIER header format provided in an embodiment of the present application.

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

[0044] Figure 4 It is a process of establishing a BIER forwarding table and forwarding BIER messages based on BIER technology.

[0045] Figure 5 This is a schematic diagram of a possible BIERv6 encapsulated message format provided in an embodiment of the present application.

[0046] Figure 6 This is a schematic diagram of a BIERv6 forwarding scenario provided in an embodiment of the present application.

[0047] Figure 7 This is a schematic diagram of another BIERv6 forwarding scenario provided in an embodiment of the present application.

[0048] Figure 8 This is a schematic flowchart of a BIERv6 message forwarding method provided in an embodiment of the present application.

[0049] Figure 9 This is a schematic flowchart of another BIERv6 message forwarding method provided in an embodiment of the present application.

[0050] Figure 10 This is a schematic flowchart of another BIERv6 message forwarding method provided in an embodiment of the present application.

[0051] Figure 11 It is a schematic structural diagram of a first network device 1100 provided in an embodiment of the present application.

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

[0053] Figure 13 This is a schematic diagram of the hardware structure of another first network device 2100 according to an embodiment of the present application. DETAILED DESCRIPTION

[0054] The technical solution in this application will be described below with reference to the accompanying drawings.

[0055] This application will present various aspects, embodiments, or features around systems including multiple devices, components, modules, etc. It should be understood and appreciated that each system may include additional devices, components, modules, etc., and / or may not include all of the devices, components, modules, etc. discussed in conjunction with the figures. Furthermore, combinations of these aspects may also be used.

[0056] Additionally, in the embodiments of this application, words such as "exemplary" and "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this application as "exemplary" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of the word "exemplary" is intended to present concepts in a concrete manner.

[0057] In the embodiments of the present application, “corresponding” and “relevant” may sometimes be used interchangeably. It should be noted that when the distinction between them is not emphasized, the meanings they intend to express are consistent.

[0058] The network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. A person skilled in the art will appreciate that, with the evolution of the network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

[0059] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in yet other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0060] In this application, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: including the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0061] Multicast is a data transmission method that uses a single multicast address to efficiently send data to multiple receivers on a Transmission Control Protocol (TCP) / Internet Protocol (IP) network at the same time. A multicast source sends a multicast stream to all members of a multicast group via links in the network, and all members of the multicast group can receive the multicast stream. Multicast transmission enables point-to-multipoint data connections between the multicast source and multicast group members. Because a multicast stream only needs to be transmitted once on each network link and is replicated only when a branch occurs on the link, multicast transmission improves data transmission efficiency and reduces the likelihood of backbone network congestion.

[0062] Internet Protocol (IP) multicast technology enables efficient point-to-multipoint data transmission within IP networks, effectively conserving network bandwidth and reducing network load. Therefore, it has broad applications in real-time data transmission, multimedia conferencing, data copying, interactive Internet Protocol Television (IPTV), gaming, and simulation. This multicast technology uses the multicast protocol to construct a control plane multicast tree, which is then used to logically organize the network plane into a tree-like structure to implement multicast point-to-multipoint data forwarding. These intermediate devices, centered around building a distribution tree, require maintaining complex multicast forwarding information states. As networks grow larger and multicast data traffic increases, this multicast technology faces increasing challenges in terms of cost and operational maintenance.

[0063] To this end, the industry has proposed a new technology for building multicast data forwarding paths, called bit index explicit replication (BIER) technology, which proposes a multicast technology architecture that does not require the construction of a multicast distribution tree. Figure 1As shown, the router that supports BIER technology is called a bit-forwarding router (BFR). The BFR that performs BIER encapsulation on user multicast data packets is called a bit forwarding ingress router (BFIR). The BFR that decapsulates user multicast data packets from BIER packets is called a bit forwarding egress router (BFER). A multicast forwarding domain composed of one or more BFIRs, one or more BFRs and one or more BFERs is called a BIER domain (BIERdomain), wherein the BFIR is located at the ingress of the BIER domain and is responsible for encapsulating the BIER packets as the head node for forwarding BIER packets; the BFR is located in the middle of the BIER domain and is responsible for forwarding the BIER packets as the intermediate forwarding node; the BFER is located at the egress of the BIER domain and is responsible for decapsulating the BIER packets as the tail node for forwarding BIER packets.

[0064] It should be understood that BFIR and BFER in the BIER domain can also be referred to as edge BFR in the BIER domain.

[0065] Optionally, the middle position of the BIER domain may also include a device that does not support BIER message forwarding. A device that does not support BIER message forwarding can be understood as a device that cannot recognize and parse the BIER header of the BIER message and only forwards the BIER message as an ordinary message.

[0066] For ease of understanding, the following Figure 2-Figure 5 , first describe the relevant technologies of BIER in detail.

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

[0068] In an embodiment of the present application, a specific BIER header needs to be additionally encapsulated when a user multicast data message is transmitted in the BIER domain. The BIER header marks all destination devices of the user multicast data message through a bit string. The BFR in the BIER domain can forward according to the bit index forwarding table (BIFT) and the bit string carried in the BIER header to ensure that the user multicast data message can be sent to all destination addresses.

[0069] It should be understood that the user multicast data message following the BIER header may be an Internet Protocol version 6 (IPv6) message, or an Internet Protocol version 4 (IPv4) message, or a BIER operation administration and maintenance (OAM) message, and this application does not make any specific limitations.

[0070] There can be many types of BIER encapsulation, which are not specifically limited in this application. As an example, the BIER message can be encapsulated by multi-protocol label switching (MPLS), which can be called BIER-MPLS encapsulation. As another example, the BIER message can be encapsulated based on Internet Protocol version 6 (IPv6), which can be called BIERv6 encapsulation.

[0071] The following combination Figure 2-Figure 4 , and describes the related technologies of BIER-MPLS encapsulation in detail.

[0072] The embodiment of the present application does not specifically limit the format of the above-mentioned BIER header, as long as the BIER header contains a bitstring field.

[0073] For ease of understanding, let's first combine Figure 2-Figure 3 , describes the format of the BIER header in detail.

[0074] Figure 2 The following is a schematic diagram of a possible BIER header format. Figure 2As shown, the BIER header may include but is not limited to: bit index forwarding table identifier (BIFT ID), bit string length (BSL), and other fields. The other fields may include but are not limited to: traffic class (TC), stack (S), time to live (TTL) field, entropy (entropy) field, version number (Ver) field, nibble field, protocol (proto) field, operation administration and maintenance (OAM) field, reserve (Rsv) field, differential service codepoints (DSCP) field, etc. of the user multicast data message following the BIER header.

[0075] The following is a detailed description of some fields in the BIER header.

[0076] (1)BIFT ID field

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

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

[0079] 1. Sub-domain (SD)

[0080] A BIER domain can be divided and configured into different subdomains SD according to the needs of actual business scenarios to support features such as interior gateway protocol (IGP) multi-topology. Each subdomain SD can be represented by a sub-domain identifier (SD-ID). For example, the value of SD-ID is [0-255] and the length is 8 bits.

[0081] 2. Bit string length (BSL)

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

[0083] 3. Set identifier (SI)

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

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

[0086] After receiving the BIER message, the BFR in the BIER domain can determine which SD the BIER message belongs to, the BSL used, and the SI set of the BSL to which the message belongs based on the BIFT ID in the BIER header.

[0087] It should be noted that the BIFT ID field value and a<SD,BSL,SI> The BIFT-id field can be used to obtain the unique<SD,BSL,SI> It has the following functions: obtain the length of the BitString of the BIER message header through BSL, thereby knowing the length of the entire BIER message header; through BSL and SI information, know whether the BitString represents the BFR-ID 1 to 256 or 257 to 512, etc.; through SD information, find the corresponding forwarding table.

[0088] (2) Bit string field

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

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

[0091] Taking BIFT ID=2 as an example, after receiving the BIER message, BFR can obtain the BIER message belonging to SD 0 based on the BIFTID in the BIER header. The BSL used in the BIER header is 256 bits and belongs to set 1 (including the set of 256 edge BFRs with BFR IDs from 257 to 512).

[0092] (3) Protocol (protocol, proto) field

[0093] Used to identify or distinguish the payload following the BIER message header. For example, the proto field can distinguish whether the payload following the BIER message header is an Internet Protocol version 6 (IPv6) multicast message, an Internet Protocol version 4 (IPv4) multicast message, or a BIER OAM message.

[0094] In one possible implementation, the type of payload message can be distinguished by the value of the proto field in the BIER header. For example, a proto field value of 5 (proto=5) indicates that the BIER message header is followed by a BIER OAM message, while a proto field value not equal to 5 (proto!=5) indicates that the BIER message header is followed by an IPv4 / IPv6 message.

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

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

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

[0098] In the embodiment of the present application, a unique BFR-ID can be assigned to each edge BFR in the BIER domain, for example, Figure 4 In the example, the BFR-IDs configured for devices A, D, E, and F are 4, 1, 3, and 2, respectively. Intermediate forwarding BFRs, such as devices B and C, are not assigned BFR-IDs.

[0099] It should be noted that in the embodiments of this application, "ID" and "id" can sometimes be used interchangeably. It should be noted that when the distinction is not emphasized, the meanings they intend to express are the same. Among them, BFR-ID in this application can refer to Figure 4 The id in .

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

[0101] It should be understood that the BFR-ID value assigned to each edge BFR in the BIER domain can be flooded to other BFRs in the BIER domain through the routing protocol, and the flooded BIER information also includes the IP address and encapsulation information of the edge BFR. For example, the flooded BIER information of device A will carry the IP address and BIFT-id of device A. BFRs in the BIER domain (for example, Figure 4 Device F) in the BIFT table can establish BIFT entries based on the flooded BIER information so that Figure 4 After device F receives the BIER message, it forwards the BIER message to the destination device according to the established BIFT table entry.

[0102] For device A, if it needs to send a BIER message to BFERs with BFR-IDs 1, 2, and 3, the BIER message must first be sent to device A's neighbor (device B). The edge BFR with BFR-ID 4 is itself. Therefore, the BIFT table entry established by device A is as follows:

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

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

[0105] Among them, forwarding table item 1 is used to indicate that when any of the first, second, and third bits of the bit string of the BIER message from right to left is 1, the BIER message will be sent to the neighbor of device A (device B), and Nbr=B means that the neighbor of device A is device B.

[0106] Forwarding table entry 2 is used to indicate that when the 4th bit from right to left of the bit string of the BIER message is 1, the BIER message will be sent to device A. Since device A is itself, device A will strip off the BIER header and forward it according to the information in the user multicast data message. It should be noted that * is used in the above forwarding table entry 2 to identify the Nbr as itself. For example, for device A, Nbr*=A means that the neighbor device of device A is itself. Similarly, Figure 4 Other devices in the network can also create BIFT entries based on their own neighboring devices. Figure 4 , I will not go into details here.

[0107] When device A, as the BFIR at the entrance of the BIER domain, receives a user multicast data message, it encapsulates a BIER header in front of the user multicast data message. It should be understood that for the sake of ease of description, it will be referred to as the entrance device A below. As an example, after receiving the user multicast data message, the entrance device A can obtain the destination device of the user multicast data message based on the correspondence information between the user multicast source group information and the BFR-id published in the Border Gateway Protocol BGP message. For example, the recipients of the user multicast data message are the destination device E with BFR-ID 3, the destination device F with BFR-ID 2, and the destination device D with BFR-ID 1. The bit string of the BIER header encapsulated by the entrance device A is 0111, and the encapsulated BIER message is forwarded to the neighboring device B according to the above-mentioned forwarding table entry 1. After receiving the BIER message, device B determines that the BIER message needs to be sent to device C and device E respectively based on the bit string of 0111 and the BIFT table entry. When device B sends the BIER message to device C, it can perform an AND operation on the bit string (0111) of the BIER header and the FBM field corresponding to Nbr=C in the BIFT table entry. In the embodiment of the present application, the result of AND is 0011. Therefore, device B can modify the bit string of the BIER header to 0011 and send it to device C. Similarly, when device B sends the BIER message to device E, it can modify the bit string of the BIER header to 0100. After receiving the BIER message, device E determines that the BIER message is to be sent to the neighboring device E based on the bit string being 0100. Since device E determines that the neighboring device E is itself based on the identifier * in the forwarding table, device E, as the BFER at the BIER domain exit, can decapsulate the user multicast data message from the BIER message and forward it based on the information in the inner user multicast data message.

[0108] The following combination Figure 5 , a detailed description of the relevant technologies of BIERv6 encapsulation is given.

[0109] Figure 5 This is a schematic block diagram of a possible BIERv6 encapsulation. Figure 5 The format of the encapsulated IPv6 message can be: IPv6 header + IPv6 extension header (including BIER header) + user multicast data message. Under this encapsulation, the IPv6 header and the IPv6 extension header including the BIER header together constitute the outer message header of the IPv6 message, which can also be referred to as the BIERv6 header in the embodiment of the present application.

[0110] The embodiment of the present application does not specifically limit the IPv6 extension header including the BIER header. For example, the IPv6 extension header may be a destination option header (DOH), or, for another example, the IPv6 extension header may be a routing header (RH).

[0111] The following describes in detail some of the fields contained in the outer IPv6 header.

[0112] Hop Limit (HL) field: This field indicates the number of times a packet can be effectively forwarded. The hop limit value decreases by 1 each time a packet passes through a router. When the value of this field is less than or equal to 1, the router will not forward the packet to the downstream device.

[0113] Source address (SA) field: identifies the source node address of the message.

[0114] Destination address (DA) field: identifies the destination node address of the receiving message.

[0115] The DA field will be continuously updated to the next hop IP address. Figure 4 Take the BIER domain shown as an example. Device A, as the head node (ingress device) of the IPv6 network, receives the user multicast data message and encapsulates the message in the BIERv6 header. That is, the encapsulated BIERv6 message is composed of an outer IPv6 header and an IPv6 extension header containing the BIER header.

[0116] Among them, the BIER message header contained in the IPv6 extension header carries a bit string representing the destination device set. Device A sends the encapsulated BIERv6 message to B based on the BIER message header and its bit string information. When sending, the destination address field in the IPv6 header can use B's unicast address (for example, B::100). Device B sends the message to C and E based on the BIER message header and its bit string information. When sending, the destination address field in the IPv6 header can use C's unicast address (for example, C::100) and E's unicast address (for example, E::100). Similarly, device C sends the message to D and F based on the BIER message header and its bit string information. When sending, the destination address field in the IPv6 header can use D's unicast address (for example, D::100) and F's unicast address (for example, D::100).

[0117] For IPv6 messages, when the intermediate devices in the BIER domain (routers or switches with router functions) are forwarding IPv6 messages, if the value of the hop limit field in the outer IPv6 header of the IPv6 message is less than or equal to 1, the IPv6 message will not be forwarded to the downstream device. The above-mentioned intermediate devices will send an Internet Control Message Protocol version 6 (ICMPv6) error message to the source address of the outer IPv6 header.

[0118] One security threat to IPv6 packet forwarding is that an attacker could forge an IPv6 packet, replacing the IPv6 source address with the IPv6 address of the victim (e.g., a host or router) and specifying a smaller value in the hop limit field of the IPv6 header. Consequently, when the IPv6 packet is forwarded to an intermediate device, the intermediate device will send an ICMPv6 error message to the victim (host or router) because the hop limit value is less than or equal to 1.

[0119] BIERv6 messages are a combination of BIER technology and IPv6. They are a one-to-many sending process, and BIERv6 can be unicast messages. Therefore, forging a BIERv6 message can cause multiple intermediate devices to send ICMPv6 error messages to the attacked party, which will amplify the attack effect. If there are ordinary IPv6 devices in the network that do not support BIERv6 forwarding, and the device cannot recognize and parse the BIER header of the BIERv6 message on both the control and forwarding planes, it will not be able to distinguish whether the received message is an ordinary IPv6 message or a BIERv6 message. The device will send an ICMPv6 error message when the hop limit value of the message is less than or equal to 1. The presence of multiple ordinary IPv6 devices that do not support BIERv6 forwarding will further amplify the attack effect.

[0120] by Figure 6 Take the scenario shown as an example. The intermediate devices in this scenario may include devices that do not support BIERv6 forwarding. That is, the intermediate devices include devices that support BIERv6 forwarding (for example, BFR2, BFR3, BFR4) and devices that do not support BIERv6 forwarding (for example, R5).

[0121] It should be understood that a device that supports BIERv6 forwarding (BFR) means that the device can recognize and parse the BIER header in the outer IPv6 header of the BIERv6 message. A device that supports BIERv6 forwarding (BFR) will actually participate in the forwarding of BIERv6 messages, and the destination address of the message received when participating in the forwarding of BIERv6 messages is the device itself.

[0122] It should also be understood that a device that does not support BIERv6 forwarding may be an ordinary IPv6 device (Non-BFR) that does not support BIERv6 forwarding, which cannot recognize and parse the BIER header in the outer IPv6 header of the BIERv6 message.

[0123] It should be noted that devices that do not support BIERv6 forwarding (Non-BFR) will not actually participate in the forwarding of BIERv6 messages, and the destination address of the messages they receive is not the device itself. There is also a situation where a device that supports BIERv6 forwarding is used as a Non-BFR device, for example, by statically configuring the BIER route and forwarding next hop to pass through or pass through a certain device. The Non-BFR or devices that do not support BIERv6 forwarding described in this application also include such devices, which are characterized in that although the device has the ability to identify the BIER header, the destination address of the message received by the device is not itself, so it will not use the BIER header for explicit copying, and it may also send an ICMPv6 error message when receiving a message with a hop-limit less than or equal to 0.

[0124] BFR1 receives a BIERv6 message. This BIERv6 message may be a BIERv6 message constructed by an attacker (for example, the source address in the outer IPv6 header of the message is filled in with the address of the attacked party), or it may be sent by a normal router such as BFIR due to incorrect configuration or incorrect implementation (the source address in the outer IPv6 header of the message is the address of the BFIR). This application does not make specific restrictions on this.

[0125] If the destination address of the BIERv6 message received by BFR1 is a unicast address and the hop limit in the outer IPv6 header is 3, the BitString in the BIERv6 message contains the valid bits corresponding to BFER6 and BFER7. For example, when the message reaches BFR4 along the path BFR1->BFR2->BFR4, the hop limit in its outer IPv6 header is 1. For BFR4, the BIERv6 message it receives is a unicast message. According to the requirements for forwarding unicast messages, BFR4 will no longer forward this message. At the same time, BFR4 will also send an ICMPv6 error message, which will be sent to the source address of the message (the victim or BFIR). For another example, when the message reaches BFR3 along the path BFR1->BFR3, the hop limit in its outer IPv6 header is 2, and BFR3 will send it along BFR3->R5->BFER7. Among them, the destination address of the message is BFER7 but it will pass through R5. R5 cannot distinguish whether the received message is an ordinary IPv6 message or a BIERv6 message, and both will be treated as unicast messages. According to the requirements of unicast message forwarding, R5 will no longer forward this message, and will also send an ICMPv6 error message. The ICMPv6 error message will be sent to the source address of the message (the attacked person or BFIR).

[0126] Therefore, in the BIERv6 scenario, how to prevent network devices that forward BIERv6 messages from generating a large number of ICMPv6 error messages and improve the security of message forwarding has become an urgent problem that needs to be solved.

[0127] In a related technical solution, in the BIERv6 scenario, in order to avoid generating a large number of ICMPv6 error messages, each BFR device is required to implement rate limiting for ICMPv6 error messages and discard messages that exceed the rate limit, thereby reducing the number of ICMPv6 error messages sent by multiple intermediate devices to the same head node (ingress device).

[0128] In the above-mentioned related technical solutions, if an attacker constructs a BIERv6 message with a specific hop limit value, it may cause the intermediate node to receive a message with a hop limit value of 1 or 0 and send an ICMPv6 error message to the attacked device. The attacked device may also be a device that does not implement ICMPv6 speed limiting and is thus attacked. Even if the attacked device is a device that implements ICMPv6 speed limiting, this ICMPv6 error message will still cause a waste of network bandwidth and the bandwidth of the attacked device.

[0129] In view of this, an embodiment of the present application provides a method for forwarding BIERv6 messages, which can configure a threshold value greater than or equal to 2 on a device that supports BIERv6 forwarding. The device that supports BIERv6 forwarding avoids forwarding the BIERv6 message when it checks that the hop limit of the message is less than or equal to the threshold value before BIER forwarding the BIERv6 message. In this way, the probability of generating ICMPv6 error messages on BIERv6 messages sent to non-BIERv6 forwarding devices due to the hop limit value of the BIERv6 message being 1 or 0 can be reduced, thereby improving the security of BIERv6 message forwarding and avoiding the waste of network bandwidth and bandwidth of the attacked device caused by a large number of ICMPv6 error messages.

[0130] It should be understood that in the present application, avoiding forwarding the BIERv6 message can be considered as preventing the BIERv6 message from being sent to the next-hop device, or it can also be considered as skipping the forwarding of the BIERv6 message. In other words, avoiding forwarding the BIERv6 message can be understood as not sending the BIERv6 message to the next-hop device.

[0131] It should be noted that the hop limit threshold can be configured separately on one or more or even all BIERv6 routers in the network. As an example, the network administrator can configure the hop limit threshold on one or more or even all BIERv6 routers. These thresholds can be the same or different, and the embodiments of the present application do not specifically limit this.

[0132] The following combination Figure 8 , a BIERv6 message forwarding method provided in an embodiment of the present application is described in detail.

[0133] Figure 8 This is a schematic flow chart of a method for forwarding BIERv6 messages provided in an embodiment of the present application. Figure 8 As shown, the method may include steps 810-830, and steps 810-830 are described in detail below.

[0134] Step 810: The first network device receives the BIERv6 message.

[0135] The first network device in the embodiment of the present application may be Figure 1 As an example, it can be BFR or BFER in the BIER domain. For detailed description of the BIER domain and BFR, BFER, please refer to the above Figure 1 The instructions in , will not be repeated here.

[0136] Step 820: The first network device determines whether the value of the hop limit field in the BIERv6 message is less than or equal to a preset threshold on the first network device.

[0137] The preset threshold configured on the first network device is a number greater than or equal to 2. The preset threshold can be determined based on the number of one or more consecutive second network devices connected to the first network device, and the second network device is a device that does not support BIER forwarding. It should be understood that the preset threshold can also be called a hop limit threshold.

[0138] As an example, a hop limit threshold can be configured on a first network device that is connected and does not support BIER forwarding, and the value of the threshold is not less than the number of consecutive devices that do not support BIER forwarding plus 1. The specific implementation method for determining the preset threshold configured on the first network device is described in detail below.

[0139] by Figure 6 Taking the scenario shown as an example, R5 is a device that does not support BIER forwarding. BFR3 and BFER7 are both connected to the device (R5) that does not support BIER forwarding, and the number of devices that do not support BIER forwarding connected to BFR3 and BFER7 is 1. Therefore, the preset threshold on BFR3 and BFER7 can be set to a number not less than 2.

[0140] by Figure 7 Taking the scenario shown as an example, R5, R6, and R7 are all devices that do not support BIER forwarding. BFR3 and BFER7 are both connected to devices that do not support BIER forwarding (R5, R6, and R7), and the number of devices that do not support BIER forwarding connected to BFR3 and BFER7 is 3. Therefore, the preset threshold on BFR3 and BFER7 can be set to a number not less than 4.

[0141] Step 830: When the value of the hop limit field in the BIERv6 message is less than or equal to the preset threshold, the first network device avoids forwarding the BIERv6 message.

[0142] It should be understood that the first network device avoiding forwarding the BIERv6 message can be regarded as the first network device preventing the BIERv6 message from being sent to the next-hop device, or it can also be regarded as the first network device skipping forwarding the BIERv6 message. That is, the first network device does not send the BIERv6 message to the next-hop device of the first network device.

[0143] In the above technical solution, a threshold value greater than or equal to 2 can be configured on the device (first network device) that supports BIERv6 forwarding. The device that supports BIERv6 forwarding avoids forwarding the BIERv6 message when it checks that the hoplimit of the message is less than or equal to the threshold value before BIER forwarding the BIERv6 message. In this way, the probability of generating ICMPv6 error messages on BIERv6 messages sent to non-BIERv6 forwarding devices due to the hop limit value of the BIERv6 message being 1 or 0 can be reduced, thereby improving the security of BIERv6 message forwarding and avoiding the waste of network bandwidth and bandwidth of the attacked device caused by a large number of ICMPv6 error messages.

[0144] Optionally, in some embodiments, after the first network device avoids forwarding the BIERv6 message, the first network device may also discard the BIERv6 message.

[0145] Optionally, in some embodiments, the first network device determines that the value of the hop limit field in the BIERv6 message is not less than a preset threshold on the first network device. The processing process of the BIERv6 message by the first network device in this case is described in detail below.

[0146] In one example, the value of the hop limit field in the BIERv6 message is equal to the preset threshold. In one possible implementation, regardless of whether the first network device is a BFR or a BFER, the first network device avoids forwarding the BIERv6 message. In another possible implementation, when the first network device determines that it is a BFR, the first network device avoids forwarding the BIERv6 message; or, when the first network device determines that it is a BFER, the first network device decapsulates the BIERv6 message and forwards the decapsulated inner message.

[0147] In another example, the value of the hop limit field in the BIERv6 message is greater than the preset threshold. For example, the first network device is a BFR, and the first network device sends the BIERv6 message to the next-hop device of the first network device. For another example, the first network device is a BFER, and the first network device decapsulates the BIERv6 message and forwards the decapsulated inner message.

[0148] Below Figure 6 As an example, combining the following scenario Figure 9 , another specific implementation process of BIERv6 message forwarding by the device in the embodiment of this application is described in detail.

[0149] It should be understood that Figure 9 The examples are only for helping those skilled in the art to understand the embodiments of the present application, and are not intended to limit the embodiments of the present application to the specific numerical values or specific scenarios illustrated. Figure 9 It is obvious that various equivalent modifications or changes can be made, and such modifications and changes also fall within the scope of the embodiments of the present application.

[0150] Figure 9 This is a schematic flow chart of another method for forwarding BIERv6 messages provided in an embodiment of the present application. Figure 9 As shown, the method may include steps 910-970, and steps 910-970 are described in detail below.

[0151] Step 910: The device in the network receives the BIERv6 message sent by the BFIR.

[0152] BFIR can perform BIERv6 encapsulation on received user multicast data packets to obtain BIERv6 packets and send the BIERv6 packets to devices in the network. BIERv6 packets can carry an outer IPv6 header, an IPv6 extension header (with a BIER header in the extension header), and a payload, where the payload can be an inner IPv4 / IPv6 multicast data packet or a BIER OAM packet.

[0153] IPv4 / IPv6 multicast data packets or BIER OAM packets can be distinguished by the value of the proto field in the BIER header. For example, a proto field value of 5 (proto=5) indicates that a BIER OAM packet follows the BIER packet header, while a proto field value not equal to 5 (proto!=5) indicates that an IPv4 / Ipv6 packet follows the BIER packet header. For details, see Figure 2 The description in , will not be repeated here.

[0154] It should be noted that the device in the above network is a BIERv6 router. As an example, the device can be a BFR in the BIER domain (for example, Figure 6 BFR2, BFR3, BFR4), or BFER (e.g., Figure 6BFER6, BFER7), this application does not make specific limitations on this.

[0155] Step 920: The above-mentioned device determines that the received message is a BIERv6 message, and the destination address in the message is the local address.

[0156] After receiving the message, the above device may look up the destination address of the received message in a forward information database (FIB) and learn that the destination address of the message is the local address.

[0157] There are multiple implementations for the above-mentioned device to determine that the received message is a BIERv6 message. In one possible implementation, the device learns that the destination address of the message is a local address, and can learn that the destination address is an indication information of an endpoint for bit index explicit replication (End.BIER) address of a bit index, and therefore, can determine that the received message is a BIERv6 message. In another possible implementation, it is also possible to further determine whether the IPv6 extension header contains a BIER header based on this indication information. If the IPv6 extension header contains a BIER header, it can be determined that the received message is a BIERv6 message. In another possible implementation, it is also possible to directly check whether the IPv6 extension header contains a BIER header without using this indication information. If the IPv6 extension header contains a BIER header, it can be determined that the received message is a BIERv6 message.

[0158] Step 930: The device checks whether the hop limit in the outer IPv6 header is less than a preset threshold.

[0159] If the hop limit in the outer IPv6 header is less than the preset threshold, step 940 may be executed.

[0160] If the hop limit in the outer IPv6 header is greater than or equal to the preset threshold, step 950 may be executed.

[0161] It should be understood that in the embodiments of the present application, the preset thresholds set on various devices may be the same or different. The preset thresholds may be configured or set by default. For example, on a BFR device, the preset threshold may be set to 2 by default, while on a BFER device, the preset threshold may be set to 1 by default.

[0162] Step 940: The above device discards the received message and ends the processing.

[0163] Step 950: The above-mentioned device determines whether the value of the TTL field in the BIER header of the message is less than 1.

[0164] If the value of the TTL field in the BIER header is less than 1, for example, the TTL field is 0, execute step 960.

[0165] If the value of the TTL field in the BIER header is greater than or equal to 1, execute step 970.

[0166] Step 960: The above device sends the message to the control plane for processing.

[0167] It should be understood that routers or switches typically have a "forwarding plane" and a "control plane." The forwarding plane process involves receiving a message from a router interface and sending it to one or more interfaces. This is typically accomplished by a dedicated forwarding chip or chip combination. The control plane includes a general-purpose central processing unit (CPU) chip or chipset. If the forwarding plane detects that the TTL field value of a message is less than 1, it can send the message to the control plane for processing.

[0168] As an example, the control plane can determine the type of message and perform different processing. For example, the control plane can determine the type of message through the proto field of the BIER header and perform corresponding processing based on the type of message. Several possible implementation methods are described in detail below.

[0169] In one possible implementation, if the message is not a BIER OAM message, or if it is determined that the message is a multicast data message, the message is discarded and the processing ends.

[0170] In another possible implementation, if the message is a BIER OAM message, the message is subsequently processed by the control plane, and the processing method may be to process it according to the BIER OAM protocol. For example, check whether the BIER OAM message is of the EchoRequest type and send a BIER OAM Echo Reply to the source address of the outer IPv6 header of the message.

[0171] Step 970: The above device traverses the BitString in the BIER header of the BIERv6 message.

[0172] It should be understood that, in this embodiment, if the hop limit is greater than or equal to the preset threshold, or the value of the TTL field is greater than or equal to 1, it is necessary to further determine whether the device is BFR or BFER.

[0173] Specifically, as an example, the device can traverse the BitString in the BIER header of the BIERv6 message. When a bit in the BitString of the BIER header is valid (for example, the value of the bit is 1) and the bit represents this node, the device can determine that it is BFER.

[0174] As another example, if a bit in the BitString of the BIER header is valid (for example, the value of the bit is 1), and the bit represents a node other than the current node, the device can determine that it is a BFR.

[0175] The following describes in detail the device BFER as an example.

[0176] For BIERv6 messages whose hop limit in the outer IPv6 header is greater than or equal to the preset threshold, or for BIERv6 messages whose TTL field in the BIER header has a value greater than or equal to 1, the type of the data message in the inner layer of the BIERv6 message can be further determined. As an example, the device can determine the type of message on the data plane, for example, by determining the type of message through the proto field in the BIER header. For specific determinations, please refer to the description above and will not be repeated here.

[0177] In one possible implementation, if the message is not a BIER OAM message, the outer IPv6 header and IPv6 extension header are popped up, and subsequent forwarding is performed based on the inner multicast data message. It should be understood that in this case of forwarding BIERv6 messages with a hop limit equal to the threshold, BFER can operate in a "Pipe" mode. In this "Pipe" mode, the hop limit value in the outer IPv6 header will not be copied to the hop limit field of the inner IPv6 user multicast message or the TTL field of the inner IPv4 multicast message and further reduced by one.

[0178] In another possible implementation, if the message is not a BIER OAM message and the hoplimit in the outer IPv6 header is greater than the preset threshold, the outer IPv6 header and IPv6 are popped out; if the message is not a BIER OAM message and the hop limit in the outer IPv6 header is equal to the preset threshold, the received message is discarded and the processing ends. This case of discarding BIERv6 messages with a hop limit equal to the threshold may be a case where the BFER node operates in a "Uniform" mode. In this "Uniform" mode, the hop limit value in the outer IPv6 header will be copied to the hop limit field of the inner IPv6 user multicast message or the TTL field of the inner IPv4 multicast message and further reduced by one.

[0179] In another possible implementation, if the message is a BIER OAM message, the message is subsequently processed by the control plane, and the processing method may be to process it according to the BIER OAM protocol. For example, check whether the BIER OAM message is of the EchoRequest type and send a BIER OAM Echo Reply to the source address of the outer IPv6 header of the message.

[0180] The following describes in detail the BFR device as an example.

[0181] When the device is a BFR, it can obtain the next hop information to reach other nodes, such as the outgoing interface, the MAC address of the next hop, etc. For BIERv6 messages whose hop limit is greater than the preset threshold or whose TTL field value is greater than 1, the device can copy the BIERv6 message, reduce the hop limit value of the outer IPv6 header of the copied BIERv6 message by 1, and reduce the TTL value of the BIER header by 1, and send the copied BIERv6 message to the next hop based on the next hop information obtained to reach other nodes.

[0182] For BIERv6 messages whose hop limit is equal to the preset threshold, the device can discard them and end processing.

[0183] For BIERv6 messages whose TTL field value is equal to 1, the type of message can be determined and different processing can be performed. For example, the type of message can be determined by the proto field of the BIER header, and corresponding processing can be performed according to the type of message. In one possible implementation, if the message is not a BIER OAM message, or if it is determined that the message is a multicast data message, the message is discarded and the processing ends. In another possible implementation, if the message is a BIER OAM message, the message is subsequently processed by the control plane, and the processing method can be based on the BIER OAM protocol. For example, check whether the BIER OAM message is of the Echo Request type, and send the BIER OAM Echo Reply to the source address of the outer IPv6 header of the message.

[0184] Below Figure 6 Taking the scenario shown in the figure as an example, the inner data packet of the BIERv6 packet is an IPv4 / IPv6 packet. For example, the BIERv6 router in the network (for example, BFR or BFER) Figure 9 It should be understood that in the following embodiments, it is assumed that the hop limit threshold on BFR is 2 and the hop limit threshold on BFER is 1.

[0185] For example, when BFR3 receives a multicast data packet encapsulated in a BIERv6 packet, the hoplimit value in the outer IPv6 header is 2, the TTL value in the BIER header is 1, and the BitString contains a BFER7 node, the result is that BFR3 discards the packet.

[0186] In another example, when BFR3 receives a BIERv6-encapsulated multicast data packet, the hop limit value in the outer IPv6 header is 3, the TTL value in the BIER header is 1, and the BitString contains the BFER7 node. Processing result: BFR3 forwards the BIERv6 packet to R5. The destination address in the outer IPv6 header of the BIERv6 packet is BFER7's IP address, the hop limit in the outer IPv6 header is 2, and the TTL in the BIER header is 0. After receiving the BIERv6 packet, R5 forwards it to BFER7. The destination address of the BIERv6 packet is BFER7's IP address, the hop limit is 1, and the TTL is 0. After receiving the BIERv6 packet, BFER7 discards the packet according to the above-mentioned message forwarding method and ends the processing.

[0187] In another example, when BFR3 receives a BIERv6-encapsulated multicast data packet with a hop limit of 3, a TTL of 2, and a BitString containing the BFER7 node, processing result: BFR3 forwards the BIERv6 packet to R5. The destination address of the BIERv6 packet is BFER7's IP address, the hop limit is 2, and the TTL is 1. After receiving the packet, R5 forwards it to BFER7. The destination address of the BIERv6 packet is BFER7's IP address, the hop limit is 1, and the TTL is 1. After receiving the BIERv6 packet, BFER7 decapsulates the BIERv6 header according to the above-mentioned packet forwarding method and forwards it according to the inner multicast data packet.

[0188] Therefore, if a larger hop limit and TTL value is used, the data packet can be forwarded normally to the egress node (for example, BFER7) and forwarded. However, if a smaller hop limit value is used, the packet may be discarded at BFR3, thus preventing the packet from being sent to R5, resulting in a hop limit of 1, which would generate an ICMPv6 error message and pose an attack risk. Of course, an unreasonable TTL value can also prevent the packet from reaching the final BFER or from being forwarded normally at the BFER.

[0189] Therefore, when normal multicast data packets are encapsulated and sent through BIERv6, appropriate hoplimit and TTL values can be selected. Figure 6 In the network topology shown, you can choose to use hop limit and TTL as 32, so that the data message can be forwarded to BFER normally and forwarded. Figure 6 The BIERv6 message with hoplimit=3 and TTL=3 specially constructed by the network attacker can be discarded before the BIERv6 message reaches R5 through this method, thereby avoiding the attack caused by the generation of ICMPv6 error message on R5 when the message is sent to R5.

[0190] Below Figure 6 Taking the scenario shown in the figure as an example, the inner data packet of the BIERv6 packet is a BIER OAM packet as an example, the BIERv6 router in the network (for example, BFR or BFER) is based on Figure 9 It should be understood that in the following embodiments, it is assumed that the hop limit threshold on BFR is 2 and the hop limit threshold on BFER is 1.

[0191] In one possible implementation, taking BIER Trace detection as an example, assume that BIER TTL=1 / 2 / 3 messages are sent from BFIR in sequence, and each message uses hop limit=127. The processing process is as follows.

[0192] For example, when BFIR sends the first OAM message, the message carries TTL = 1 and hop limit = 127. After receiving it, BFR1 sends it to the control plane, and the control plane sends an Echo Reply OAM message.

[0193] In another example, for the second OAM message, the BFIR sends a message with a TTL of 2 and a hop limit of 127. BFR1 receives it and forwards it to BFR3. The message received by BFR3 has a TTL of 1 and a hop limit of 126. BFR3 sends the message to the control plane, which then sends an Echo Reply OAM message.

[0194] In another example, when BFIR sends the third OAM message, it carries a TTL of 3 and a hop limit of 127. BFR1 receives it and forwards it to BFR3. BFR3 receives the message with a TTL of 2 and a hop limit of 126. BFR3 then sends it to R5. R5 receives the message with a TTL of 1 and a hop limit of 125. R5 then sends it to BFER7. BFER7 receives the message with a TTL of 1 and a hop limit of 124. BFER7 then sends the message to the control plane, which then sends an EchoReply OAM message.

[0195] BIER Trace detection is used to perform hop-by-hop detection on each device in the network. It can be seen that a larger hop limit value is used in the BIER Trace detection process, and each BFR / BFER can be detected.

[0196] In another possible implementation method, taking BIER Trace detection as an example, assume that BIER TTL=1 / 2 / 3 messages are sent from BFIR in sequence, and each message uses hop limit=3. The processing process is as follows.

[0197] For example, when BFIR sends the first OAM message, the message carries TTL = 1 and hop limit = 3. After receiving it, BFR1 sends it to the control plane, and the control plane sends an Echo Reply OAM message.

[0198] In another example, for the second OAM message, when sent by BFIR, the message carries TTL = 2 and hop limit = 3. BFR1 receives it and forwards it to BFR3. The message received by BFR3 has TTL = 1 and hop limit = 2. Upon receiving the message, BFR3 discards it and does not send an Echo Reply message.

[0199] In another example, for the third OAM message, the BFIR sends a message with TTL = 3 and hop limit = 3. BFR1 receives it and forwards it to BFR3. The message received by BFR3 has TTL = 2 and hop limit = 2. Upon receiving the message, BFR3 discards it and does not send an Echo Reply message.

[0200] It can be seen that a smaller hop limit value is used in the BIER Trace detection process, and some BFR / BFER cannot be detected.

[0201] Therefore, a suitable hop limit value can be selected during the BIER Trace detection process so that each BFR / BFER can be detected.

[0202] In some embodiments, taking the hop limit threshold of 2 as an example, when the hop limit value is equal to the threshold, or the value of the TTL field is equal to 1, BFER and BFR are processed differently. Therefore, when the BIERv6 message is received, the hop limit value or the value of the TTL field is judged once, and after traversing the BitString, the hop limit value or the value of the TTL field needs to be judged again. In order to avoid the above situation, the hop limit and TTL are not repeatedly judged in the traversal of the BitString (to distinguish the processing of BFR and the processing of BFER), but are uniformly judged before starting the BitString traversal. The following is combined with Figure 10 , this implementation is described in detail.

[0203] Figure 10 This is a schematic flow chart of another method for forwarding BIERv6 messages provided in an embodiment of the present application. Figure 10 As shown, the method may include steps 1010-1070, and steps 1010-1070 are described in detail below.

[0204] Step 1010: The device in the network receives the BIERv6 message sent by the BFIR.

[0205] Corresponding to step 910, please refer to the description in step 910 for details, which will not be repeated here.

[0206] Step 1020: The above-mentioned device determines that the received message is a BIERv6 message, and the destination address in the message is the local address.

[0207] Corresponding to step 920, please refer to the description in step 920 for details, which will not be repeated here.

[0208] Step 1030: The device checks whether the hop limit in the outer IPv6 header is less than or equal to a preset threshold.

[0209] If the hop limit in the outer IPv6 header is less than or equal to the preset threshold, step 1040 may be executed.

[0210] If the hop limit in the outer IPv6 header is greater than the preset threshold, step 1050 may be executed.

[0211] Step 1040: The above device discards the received message and ends the processing.

[0212] It should be understood that in step 1040, the received message is discarded and processing ends before distinguishing whether the device is BFR or BFER. In other words, in step 1040, the received message is discarded in advance. In contrast, in step 970, after determining that the device is BFER, if the message is not a BIER OAM message and the hop limit in the outer IPv6 header is equal to the preset threshold, the received message is discarded and processing ends.

[0213] Step 1050: The above-mentioned device determines whether the value of the TTL field in the BIER header of the message is less than or equal to 1.

[0214] If the value of the TTL field in the BIER header is less than or equal to 1, execute step 1060.

[0215] If the value of the TTL field in the BIER header is greater than 1, execute step 1070.

[0216] Step 1060: The above device sends the message to the control plane for processing.

[0217] Corresponding to step 960, please refer to the description in step 960 for details, which will not be repeated here.

[0218] Step 1070: The above device traverses the BitString in the BIER header of the BIERv6 message.

[0219] As an example, if a certain bit of the BitString traversed in the BIER header is valid (for example, the value of the bit is 1), and the bit represents this node, the type of the data message in the inner layer of the BIERv6 message can be further determined. If the message is not a BIER OAM message, the outer Ipv6 header and Ipv6 extension header are popped up, and subsequent forwarding is performed based on the inner multicast data message. If the message is a BIER OAM message, the message will be subsequently processed by the control plane, and the processing method may be based on the BIER OAM protocol. For example, check whether the BIER OAM message is of the Echo Request type, and send the BIEROAM Echo Reply to the source address of the outer Ipv6 header of the message.

[0220] As another example, if a certain bit of the BitString in the BIER header is valid (for example, the value of the bit is 1), and the bit represents a node other than the current node, the next hop information to reach the other node can be obtained, such as the outgoing interface, the MAC address of the next hop, etc. Copy the BIERv6 message, reduce the hop limit value of the outer IPv6 header of the copied BIERv6 message by 1, reduce the TTL value of the BIER header by 1, and send the copied BIERv6 message to the next hop based on the obtained next hop information to reach the other node.

[0221] It should be noted that, in step 1070, there is no need to determine the values of hop limit and TTL.

[0222] Below Figure 6 Taking the scenario shown in the figure as an example, the inner data packet of the BIERv6 packet is an IPv4 / IPv6 packet. For example, the BIERv6 router in the network (for example, BFR or BFER) Figure 10 It should be understood that in the following embodiments, it is assumed that the hop limit threshold on BFR is 2 and the hop limit threshold on BFER is 1.

[0223] For example, when BFR3 receives a multicast data packet encapsulated in a BIERv6 packet, the hoplimit value in the outer IPv6 header is 2, the TTL value in the BIER header is 1, and the BitString contains a BFER7 node, the result is that BFR3 discards the packet.

[0224] In another example, when BFR3 receives a BIERv6-encapsulated multicast data packet, the hop limit value is 3, the TTL value is 1, and the BitString contains the BFER7 node. Processing result: BFR3 forwards the BIERv6 packet to R5. The destination address in the outer IPv6 header of the BIERv6 packet is the IP address of BFER7, the hop limit in the outer IPv6 header is 2, and the TTL in the BIER header is 0. After receiving the BIERv6 packet, R5 forwards it to BFER7. The destination address of the BIERv6 packet is the IP address of BFER7, the hop limit is 1, and the TTL is 0. After receiving the BIERv6 packet, BFER7 discards the packet according to the above-mentioned message forwarding method and ends the processing.

[0225] In another example, when BFR3 receives a BIERv6-encapsulated multicast data packet with a hop limit of 3, a TTL of 2, and a BitString containing the BFER7 node, processing result: BFR3 forwards the BIERv6 packet to R5. The destination address of the BIERv6 packet is BFER7's IP address, the hop limit is 2, and the TTL is 1. After receiving the packet, R5 forwards it to BFER7. The destination address of the BIERv6 packet is BFER7's IP address, the hop limit is 1, and the TTL is 1. After receiving the BIERv6 packet, BFER7 discards it and ends processing.

[0226] In another example, when BFR3 receives a BIERv6-encapsulated multicast data packet with a hop limit of 3, a TTL of 3, and a BitString containing the BFER7 node, processing result: BFR3 forwards the BIERv6 packet to R5. The destination address of the BIERv6 packet is BFER7's IP address, the hop limit is 2, and the TTL is 2. After receiving the packet, R5 forwards it to BFER7. The destination address of the BIERv6 packet is BFER7's IP address, the hop limit is 1, and the TTL is 2. After receiving the BIERv6 packet, BFER7 discards it and ends processing.

[0227] In another example, when BFR3 receives a BIERv6-encapsulated multicast data packet with a hop limit of 4, a TTL of 3, and a BitString containing the BFER7 node, processing result: BFR3 forwards the BIERv6 packet to R5. The destination address of the BIERv6 packet is BFER7's IP address, the hop limit is 3, and the TTL is 2. After receiving the packet, R5 forwards it to BFER7. The destination address of the BIERv6 packet is BFER7's IP address, the hop limit is 2, and the TTL is 2. After receiving the BIERv6 packet, BFER7 decapsulates the BIERv6 header according to the above-mentioned packet forwarding method and forwards it according to the inner multicast data packet.

[0228] Below Figure 6 Taking the scenario shown in the figure as an example, the inner data packet of the BIERv6 packet is a BIER OAM packet as an example, the BIERv6 router in the network (for example, BFR or BFER) is based on Figure 10 It should be understood that in the following embodiments, it is assumed that the hop limit threshold on BFR is 2 and the hop limit threshold on BFER is 1.

[0229] In one possible implementation, taking BIER Trace detection as an example, assume that BIER TTL=1 / 2 / 3 messages are sent from BFIR in sequence, and each message uses hop limit=127. The processing process is as follows.

[0230] For example, when BFIR sends the first OAM message, the message carries TTL = 1 and hop limit = 127. After receiving it, BFR1 sends it to the control plane, and the control plane sends an Echo Reply OAM message.

[0231] In another example, for the second OAM message, the BFIR sends a message with a TTL of 2 and a hop limit of 127. BFR1 receives it and forwards it to BFR3. The message received by BFR3 has a TTL of 1 and a hop limit of 126. BFR3 sends the message to the control plane, which then sends an Echo Reply OAM message.

[0232] In another example, when BFIR sends the third OAM message, it carries a TTL of 3 and a hop limit of 127. BFR1 receives it and forwards it to BFR3. BFR3 receives the message with a TTL of 2 and a hop limit of 126. BFR3 then sends it to R5. R5 receives the message with a TTL of 1 and a hop limit of 125. R5 then sends it to BFER7. BFER7 receives the message with a TTL of 1 and a hop limit of 124. BFER7 then sends the message to the control plane, which then sends an EchoReply OAM message.

[0233] In another possible implementation method, taking BIER Trace detection as an example, assume that BIER TTL=1 / 2 / 3 messages are sent from BFIR in sequence, and each message uses hop limit=3. The processing process is as follows.

[0234] For example, when BFIR sends the first OAM message, the message carries TTL = 1 and hop limit = 3. After receiving it, BFR1 sends it to the control plane, and the control plane sends an Echo Reply OAM message.

[0235] In another example, for the second OAM message, when sent by BFIR, the message carries TTL = 2 and hop limit = 3. BFR1 receives it and forwards it to BFR3. The message received by BFR3 has TTL = 1 and hop limit = 2. Upon receiving the message, BFR3 discards it and does not send an Echo Reply message.

[0236] In another example, for the third OAM message, the BFIR sends a message with TTL = 3 and hop limit = 3. BFR1 receives it and forwards it to BFR3. The message received by BFR3 has TTL = 2 and hop limit = 2. Upon receiving the message, BFR3 discards it and does not send an Echo Reply message.

[0237] Combined with the above Figures 1 to 10 , describes in detail a BIER message forwarding method provided by the embodiment of the present application, and will be combined with Figures 11 to 13 , the embodiments of the device of the present application are described in detail. It should be understood that the description of the method embodiment corresponds to the description of the device embodiment, so for parts not described in detail, reference can be made to the previous method embodiment.

[0238] Figure 11 It is a schematic structural diagram of a first network device 1100 provided in an embodiment of the present application. Figure 11The first network device 1100 shown is a bit forwarding router BFR or a bit forwarding egress router BFER, and can execute the corresponding steps executed by the first network device in the method of the above embodiment. Figure 11 As shown, the first network device 1100 includes: a receiving module 1110, a processing module 1120,

[0239] A receiving module 1110 is configured to receive an explicitly replicated BIERv6 message based on a bit index of Internet Protocol version 6, wherein the BIERv6 message includes a hop limit field;

[0240] Processing module 1120, used to determine whether the value of the hop limit field in the BIERv6 message is less than or equal to a preset threshold on the first network device, wherein the preset threshold is a number greater than or equal to 2, and the preset threshold is determined based on the number of one or more consecutive second network devices connected to the first network device, and the second network device is a device that does not support BIER forwarding;

[0241] The processing module 1120 is also used to avoid forwarding the BIERv6 message when the value of the hop limit field in the BIERv6 message is less than or equal to the preset threshold.

[0242] Optionally, the processing module 1120 is also used to: discard the BIERv6 message.

[0243] Optionally, the processing module 1120 is also used to: avoid forwarding the BIERv6 message when the value of the hop limit field in the BIERv6 message is equal to the preset threshold.

[0244] Optionally, the processing module 1120 is also used to: if the first network device is the BFR, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold, avoid forwarding the BIERv6 message; or if the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold, decapsulate the BIERv6 message and forward the decapsulated inner message.

[0245] Optionally, the BIERv6 message includes a bit string BitString, and the processing module 1120 is further used to: when a bit in the BitString is valid and the bit represents the first network device, determine itself as the BFER; or when a bit in the BitString is valid and the bit represents a device other than the first network device, determine itself as the BFR.

[0246] Optionally, the processing module 1120 is also used to: if the first network device is the BFR, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, send the BIERv6 message to the next hop device of the first network device; or if the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, decapsulate the BIERv6 message and forward the decapsulated inner message.

[0247] Optionally, the first network device is a BFR or BFER in a BIER domain.

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

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

[0250] The interface 2003 may specifically include a transmitter and a receiver for the first network device to implement the above-mentioned transmission and reception. For example, the interface 2003 is used to receive an explicit copy BIERv6 message based on a bit index of the sixth version of the Internet Protocol.

[0251] The processor 2001 is used to execute the processing performed by the first network device in the above-mentioned embodiment. For example, it is used to determine whether the value of the hop limit field in the BIERv6 message is less than or equal to the preset threshold on the first network device; it is also used to avoid forwarding the BIERv6 message when the value of the hop limit field in the BIERv6 message is less than or equal to the preset threshold; and / or other processes for the technology described herein. The memory 2002 includes an operating system 20021 and an application 20022, which are used to store programs, codes or instructions. When the processor or hardware device executes these programs, codes or instructions, the processing process involving the first network device in the method embodiment can be completed. Optionally, the memory 2002 may include a read-only memory (ROM) and a random access memory (RAM). The ROM includes a basic input / output system (BIOS) or an embedded system; the RAM includes an application and an operating system. When the first network device 2000 needs to be operated, it is started by the BIOS stored in the ROM or the bootloader in the embedded system, and the first network device 2000 is guided into a normal operating state. After the first network device 2000 enters the normal operating state, the application program and operating system stored in the RAM are run, thereby completing the processing process involving the first network device 2000 in the method embodiment.

[0252] It is understandable that Figure 12 Only a simplified design of the first network device 2000 is shown. In actual applications, the first network device may include any number of interfaces, processors or memories.

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

[0254] like Figure 13The first network device 2100 includes a main control board 2110, an interface board 2130, a switching network board 2120, and an interface board 2140. The main control board 2110, interface boards 2130 and 2140, and the switching network board 2120 are interconnected via a system bus and a system backplane. The main control board 2110 is used to perform functions such as system management, device maintenance, and protocol processing. The switching network board 2120 is used to exchange data between the interface boards (also known as line cards or service boards). The interface boards 2130 and 2140 are used to provide various service interfaces (e.g., POS interfaces, GE interfaces, ATM interfaces, etc.) and implement data packet forwarding.

[0255] Interface board 2130 may include a central processing unit (CPU) 2131, a forwarding table entry memory 2134, a physical interface card 2133, and a network processor 2132. CPU 2131 is used to control and manage the interface board and communicate with the CPU on the main control board. Forwarding table entry memory 2134 is used to store entries, such as the BIFT mentioned above. Physical interface card 2133 is used to receive and send traffic.

[0256] It should be understood that the operations on the interface board 2140 in the embodiment of the present application are consistent with the operations of the interface board 2130, and for the sake of brevity, they will not be repeated.

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

[0258] Additionally, it should be noted that there may be one or more main control boards, and when there are multiple boards, they may include a primary main control board and a backup main control board. There may be one or more interface boards. The stronger the data processing capabilities of the first network device, the more interface boards are provided. The interface board may also have one or more physical interface cards. There may be no switching network board, or one or more. When there are multiple switching network boards, they can collectively implement load balancing and redundant backup. In a centralized forwarding architecture, the first network device may not require a switching network board; the interface board handles the service data processing function for the entire system. In a distributed forwarding architecture, the first network device may have at least one switching network board, which enables data exchange between multiple interface boards, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of a first network device with a distributed architecture are greater than those of a device with a centralized architecture. The specific architecture to be adopted depends on the specific network deployment scenario and is not limited here.

[0259] The present application also provides a computer-readable medium storing program code, which, when executed on a computer, causes the computer to execute the method executed by the first network device. Such computer-readable storage includes, but is not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), Flash memory, electrically EPROM (EEPROM), and hard drive.

[0260] An embodiment of the present application also provides a chip system, which is applied to a first network device. The chip system includes: at least one processor, at least one memory and an interface circuit, wherein the interface circuit is responsible for information interaction between the chip system and the outside world, the at least one memory, the interface circuit and the at least one processor are interconnected through lines, and instructions are stored in the at least one memory; the instructions are executed by the at least one processor to perform the operations of the first network device in the methods described in the above aspects.

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

[0262] An embodiment of the present application further provides a computer program product, which is applied to a first network device. The computer program product includes a series of instructions. When the instructions are executed, the operations of the first network device in the methods described in the above aspects are performed.

[0263] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0264] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

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

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

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

[0269] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0270] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for forwarding BIERv6 messages based on bit-indexed explicit replication of the sixth version of the Internet Protocol, characterized in that: The method comprises: The first network device receives an explicitly copied BIERv6 message based on a bit index of the sixth version of the Internet Protocol, wherein the BIERv6 message includes a hop limit field, and the first network device is a bit forwarding router BFR or a bit forwarding egress router BFER; The first network device determines whether a value of the hop limit field in the BIERv6 message is less than or equal to a preset threshold on the first network device, wherein the preset threshold is a number greater than or equal to 2, and the preset threshold is determined based on the number of one or more consecutive second network devices connected to the first network device, and the second network device is a device that does not support BIER forwarding; When the value of the hop limit field in the BIERv6 message is less than or equal to the preset threshold, the first network device avoids forwarding the BIERv6 message.

2. The method according to claim 1, characterized in that The method further comprises: The first network device discards the BIERv6 message.

3. The method according to claim 1, characterized in that The method further comprises: If the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold and the inner layer of the BIERv6 message is not a bit indexed explicit replication operation maintenance management BIER OAM message, the first network device discards the BIERv6 message.

4. The method according to claim 1, wherein The method further comprises: If the first network device is the BFR, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold, the first network device avoids forwarding the BIERv6 message; or If the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold, the first network device avoids forwarding the BIERv6 message.

5. The method according to claim 4, characterized in that The BIERv6 message includes a bit string BitString, and the method further includes: When the first network device determines that a bit in the BitString is valid and the bit represents the first network device, the first network device determines itself as the BFER; or When the first network device determines that a bit in the BitString is valid and the bit represents a device other than the first network device, the first network device determines itself as the BFR.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: If the first network device is the BFR, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, the first network device sends the BIERv6 message to the next hop device of the first network device; or If the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, the first network device decapsulates the BIERv6 message and forwards the decapsulated inner message.

7. The method according to any one of claims 1 to 5, characterized in that The first network device is a BFR or BFER in a BIER domain.

8. A first network device, characterized in that: The first network device is a bit forwarding router BFR or a bit forwarding egress router BFER, and the first network device includes: A receiving module for receiving an explicitly replicated BIERv6 message based on a bit index of Internet Protocol version 6, wherein the BIERv6 message includes a hop limit field; A processing module, used to determine whether the value of the hop limit field in the BIERv6 message is less than or equal to a preset threshold on the first network device, wherein the preset threshold is a number greater than or equal to 2, and the preset threshold is determined based on the number of one or more consecutive second network devices connected to the first network device, and the second network device is a device that does not support BIER forwarding; The processing module is also used to avoid forwarding the BIERv6 message when the value of the hop limit field in the BIERv6 message is less than or equal to the preset threshold.

9. The first network device according to claim 8, characterized in that The processing module is further configured to: Discard the BIERv6 message.

10. The first network device according to claim 8, characterized in that The processing module is further configured to: If the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold and the inner layer of the BIERv6 message is not a bit indexed explicit replication operation maintenance management BIER OAM message, the BIERv6 message is discarded.

11. The first network device according to claim 8, characterized in that The processing module is further configured to: If the first network device is the BFR, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold, avoid forwarding the BIERv6 message; or If the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is equal to the preset threshold, avoid forwarding the BIERv6 message.

12. The first network device according to claim 11, characterized in that The BIERv6 message includes a bit string BitString, and the processing module is further used to: When a bit in the BitString is valid and the bit represents the first network device, determining itself as the BFER; or When a bit in the BitString is valid and the bit represents a device other than the first network device, the device is determined to be the BFR.

13. The first network device according to any one of claims 8 to 12, characterized in that: The processing module is further configured to: If the first network device is the BFR, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, the BIERv6 message is sent to the next hop device of the first network device; or If the first network device is the BFER, when the value of the hop limit field in the BIERv6 message is greater than the preset threshold, the BIERv6 message is decapsulated and the decapsulated inner message is forwarded.

14. The first network device according to any one of claims 8 to 12, characterized in that: The first network device is a BFR or BFER in a BIER domain.

15. A first network device, characterized in that: include: A processor and a memory, the memory being used to store a program, and the processor being used to call and run the program from the memory to execute the method according to any one of claims 1 to 7.

16. A system for bit-indexed explicit replication of BIER message forwarding, comprising a first network device as described in any one of claims 8 to 14.

17. A computer-readable storage medium, characterized in that The invention comprises a computer program which, when being run on a computer, causes the computer to execute the method according to any one of claims 1 to 7.

Images