Message advertisement method, apparatus, storage medium and electronic apparatus

Abstract

Provided in the present disclosure are a message advertisement method, an apparatus, a storage medium and an electronic apparatus. The method comprises: adding to a TLV field of a first advertisement protocol message an Anycast BFR-ID corresponding to a dual-homed BFER device, so as to obtain a second advertisement protocol message, wherein the dual-homed BFER device comprises: a first BFER device and a second BFER device, the dual-homed BFER device is used for forwarding multicast traffic to the same receiving device, and the advertisement protocol message comprises: a bit forwarding router prefix (BFR-Prefix) of the first BFER device, or a BFR-prefix of the second BFER device; and advertising the second advertisement protocol message to other intra-domain devices.

Description

Message notification method, device, storage medium and electronic device Technical Field

[0001] The present disclosure relates to the field of communications, and in particular to a message notification method, device, storage medium, and electronic device. Background Art

[0002] With the rapid development of Internet services, multicast technology has become increasingly widely used. BIER (Bit Indexed Explicit Replication) is a multicast data forwarding technology that represents nodes at the edge of the network with a single bit. Multicast traffic transmitted in the intermediate network is encapsulated with a specific BIER header. This header, in the form of a bit string, identifies all destination nodes for the multicast stream. Intermediate network forwarding nodes perform routing based on the bit position by searching the BIER forwarding table to ensure that traffic is sent to all destination nodes. Generally, each BFER has a corresponding BFR-ID value, which is announced along with the BFER's own BFR-Prefix. The announcement protocol is generally OSPF (0SPF Open Shortest Path First), IS-IS (Intermediate System-to-Intermediate System) or BGP (Border Gateway Protocol), BABEL and other routing protocols. Relying on the announcement and route calculation functions of these protocols, the BIER forwarding table entries are calculated. The entries in the forwarding table include the BFR-ID reaching each BFER and its corresponding next hop and other elements.

[0003] BFER (Bit-Forwarding Egress Routers) is the egress node of the BIER domain, connected to the downstream devices or receivers that need to receive multicast traffic. The ingress node BFIR (Bit-Forwarding Ingress Router) of the BIER domain encapsulates the corresponding BFER bits into the BitString of the BIER message according to the specific receiver of the multicast stream. The intermediate device of the BIER domain will forward the message to the corresponding BFER device.

[0004] To improve the reliability of traffic reception, a downstream device or receiver that needs to receive multicast traffic may be connected to more than one BFER device. This allows traffic to be forwarded by another BFER if one BFER fails. As shown in Figure 1, the BIER network has an ingress device, BFIR1, and receiver-connected devices, BFER3 / 4 / 5 / 6. The network also contains several forwarding devices, BFRm through BFRn. Receiver R1 is connected to both BFER3 and BFER4, allowing R1 to receive traffic from either BFER3 or BFER4. Receiver R2 is connected to both BFER4 and BFER5, allowing R2 to receive traffic from either BFER4 or BFER5. Receiver R3 is connected to both BFER5 and BFER6, allowing R3 to receive traffic from either BFER5 or BFER6.

[0005] As shown in Figure 1, because R1 can receive traffic from either BFER3 or BFER4, if both devices forward traffic to R1 simultaneously, R1 will receive duplicate traffic. The same traffic will reach BFER3 and BFER4 via different paths, wasting network bandwidth. Therefore, normally, only one of BFER3 and BFER4 will receive and forward multicast traffic to R1. Therefore, when ingress device BFIR1 sends multicast traffic intended for R1, it must select only one of BFER3 or BFER4's BFR-IDs and enter it into the BitString field of the BIER header. This ensures that the multicast stream reaches only BFER3 or BFER4 and is then forwarded to R1. Assuming BFER3 is selected, this is not a problem when BFER3 is operating normally. However, if BFER3 suddenly fails, or the link connecting to it fails, preventing the traffic from reaching BFER3, BFIR1 must select BFER4 as the destination for the traffic. However, it takes a long time for BFIR1 to be informed of this change, resulting in traffic interruption during this period. In addition, the traffic that has been sent by BFIR1 and forwarded in the network will be discarded or even cause a loop because it cannot reach BFER3. Therefore, the BIER Anycast function is needed to solve this problem.

[0006] The basic element of BIER Anycast is to use the same BFR-ID for the BFER devices that make up the dual homing. For example, BFER3 and BFER4 in Figure 1 are each other's backup traffic forwarding devices for the R1 receiver, and both can announce the same BFR-ID value (called Anycast BFR-ID). In this way, BFIR1 only needs to fill in the Anycast BFR-ID value into the destination of the BIER header encapsulated by the multicast traffic required by R1. The intermediate device selects the optimal path, forwards the traffic to BFER3 or BFER4, and then forwards it to R1. In order to achieve this function, the difficulty lies in how to enable the intermediate device to correctly establish a forwarding table to reach the Anycast BFR-ID to ensure that it can be routed to one of the BFER devices.

[0007] The existing solution is to allocate a corresponding BFR-Prefix when an Anycast BFR-ID is announced, which is called an Anycast BFR-Prefix. For a set of such protection relationships, such as BFER3 and BFER4 forming an Anycast relationship, in addition to allocating a dedicated Anycast BFR-ID, a dedicated Anycast BFR-Prefix also needs to be allocated. For the protection relationship formed by BFER4 and BFER5, in addition to allocating another dedicated Anycast BFR-ID, another dedicated Anycast BFR-Prefix also needs to be allocated. The same is true for BFER5 and BFER6. Therefore, for these three sets of protection relationships, in addition to allocating three different Anycast BFR-IDs, three different Anycast BFR-Prefixes also need to be allocated. Anycast BFR-ID must be allocated, but Anycast BFR-Prefix is ​​an IP address, which is a general network resource and requires whole-network planning. When the BIER Anycast scenario is simple and not many protection relationships are required, fewer IP address prefix resources are required. However, when the BIER Anycast scenario is complex, such as when there are hundreds of protection relationships, hundreds of dedicated IP address prefixes are required, which will greatly consume network resources and pose a considerable challenge to network planning. Therefore, the current solution cannot be applied to large-scale network deployment because it relies too much on the allocation of IP address prefix resources. Moreover, the one-to-one relationship between the prefix and the BFR-ID also needs to be strictly bound in the network, which greatly increases the deployment complexity.

[0008] Regarding the related technology, when an Anycast BFR-ID is announced, a corresponding Anycast BFR-Prefix is ​​required, which consumes a large number of IP prefixes, leading to complex network deployment and high network resource consumption. No effective solution has been proposed yet.

[0009] Therefore, it is necessary to improve the related technology to overcome the above-mentioned defects in the related technology.

[0010] Summary of the Invention

[0011] The present disclosure provides a message notification method, device, storage medium and electronic device to at least solve the problem that when notifying Anycast BFR-ID, a corresponding Anycast BFR-Prefix is ​​required, which in turn consumes a large number of IP prefixes, resulting in complex network deployment and high network resource consumption.

[0012] According to one aspect of the present disclosure, a message notification method is provided, comprising: adding an Anycast BFR-ID corresponding to a dual-homing BFER device to a TLV field of a first notification protocol message to obtain a second notification protocol message, wherein the dual-homing BFER device includes: a first BFER device and a second BFER device, the dual-homing BFER device being configured to forward multicast traffic to the same receiving device, the notification protocol message including: a bit-indexed forwarding router prefix (BFR-Prefix) of the first BFER device or the BFR-Prefix of the second BFER device; and notifying the second notification protocol message to other devices in a domain.

[0013] According to another aspect of the present disclosure, a message notification device is further provided, including: an adding module, configured to add the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of a first notification protocol message to obtain a second notification protocol message, wherein the dual-homing BFER device includes: a first BFER device and a second BFER device, the dual-homing BFER device is used to forward multicast traffic to the same receiving device, and the notification protocol message includes: a bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device; and a notification module, configured to notify the second notification protocol message to other devices in the domain.

[0014] According to another aspect of the present disclosure, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the above-mentioned message notification method when running.

[0015] According to another aspect of the present disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the message notification method through the computer program.

[0016] The present disclosure adds the Anycast BFR-ID corresponding to a dual-homing BFER device to the TLV field of a first announcement protocol message to obtain a second announcement protocol message. The dual-homing BFER device includes: a first BFER device and a second BFER device, and is configured to forward multicast traffic to the same receiving device. The announcement protocol message includes: a bit-indexed forwarding router prefix (BFR-Prefix) of the first BFER device or the BFR-Prefix of the second BFER device. The second announcement protocol message is then announced to other devices within the domain. In other words, by adding the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first announcement protocol message including the BFR-Prefix corresponding to the dual-homing BFER device to obtain the second announcement protocol message, and announcing the second announcement protocol message to other devices within the domain, the related art solves the technical problem that when announcing an Anycast BFR-ID, a one-to-one correspondence between the Anycast BFR-Prefix and the device is required, which in turn consumes a large number of IP prefixes, leading to complex network deployment and high network resource consumption. The technical effect of saving network resources is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The exemplary embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation of the present disclosure. In the drawings:

[0018] FIG1 is a schematic diagram of a BIER Anycast scenario in related art;

[0019] FIG2 is a hardware structure block diagram of a computer terminal of the message notification method disclosed herein;

[0020] FIG3 is a flow chart (I) of a method for announcing a message according to the present disclosure;

[0021] FIG4 is a schematic diagram (I) of an Anycast BFR-ID notification method according to the present disclosure;

[0022] FIG5 is a schematic diagram (II) of an Anycast BFR-ID notification method according to the present disclosure;

[0023] FIG6 is a schematic diagram of the notification format of the Anycast BFR-ID according to the message notification method of the present disclosure;

[0024] FIG7 is a schematic diagram of a forwarding table reaching all Anycast BFR-IDs according to the message notification method of the present disclosure (I);

[0025] FIG8 is a flowchart (II) of a method for announcing a message according to the present disclosure;

[0026] FIG9 is a schematic diagram of information storage of the next hop, etc. of the message notification method according to the present disclosure;

[0027] FIG10 is a flowchart of a method for announcing a message according to the present disclosure (III);

[0028] FIG11 is a schematic diagram (II) of a forwarding table reaching all Anycast BFR-IDs according to the message notification method of the present disclosure;

[0029] FIG12 is a structural block diagram of a message notification device according to the present disclosure. DETAILED DESCRIPTION

[0030] In order to enable those skilled in the art to better understand the disclosed solutions, the technical solutions of the disclosed solutions will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of the disclosed solutions, not all of them. Based on the embodiments of the disclosed solutions, all other embodiments obtained by those skilled in the art without creative work should fall within the scope of protection of the disclosed solutions.

[0031] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0032] The method embodiments provided in the present disclosure can be executed in a computer terminal or a similar computing device. Taking running on a computer terminal as an example, FIG2 is a hardware structure block diagram of a computer terminal for the message notification method of the present disclosure. As shown in FIG2 , the computer terminal may include one or more (only one is shown in FIG2 ) processors 202 (the processor 202 may include but is not limited to a microprocessor (Microprocessor Unit, referred to as MPU) or a programmable logic device (Programmable logic device, referred to as PLD)) and a memory 204 for storing data. In an exemplary embodiment, the above-mentioned computer terminal may also include a transmission device 206 and an input / output device 208 for communication functions. It will be understood by those skilled in the art that the structure shown in FIG2 is only for illustration and does not limit the structure of the above-mentioned computer terminal. For example, the computer terminal may also include more or fewer components than those shown in FIG2 , or have a different configuration with the same functions as those shown in FIG2 or with more functions than those shown in FIG2 .

[0033] The memory 204 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the message notification method in the present disclosure. The processor 202 executes various functional applications and data processing by running the computer program stored in the memory 204, that is, implementing the above-mentioned method. The memory 204 may include a high-speed random access memory and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 204 may further include a memory remotely located relative to the processor 202, and these remote memories can be connected to the computer terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0034] Transmission device 206 is used to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by a communications provider of a computer terminal. In one embodiment, transmission device 206 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 206 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0035] FIG3 is a flow chart (I) of a method for announcing a message according to the present disclosure, which is applied to the above-mentioned computer terminal. As shown in FIG3 , the steps of the method include:

[0036] Step S302: Add the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first announcement protocol message to obtain a second announcement protocol message, wherein the dual-homing BFER device includes: a first BFER device and a second BFER device, and the dual-homing BFER device is used to forward multicast traffic to the same receiving device. The announcement protocol message includes: the bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device:

[0037] It should be noted that the dual-homing BFER device includes a first BFER device and a second BFER device. The first BFER device and the second BFER device both have their own BFR-Prefix. The first BFER device and the second BFER device both have corresponding first notification protocol messages. The first notification protocol message corresponding to the same BFER device carries the BFR-Prefix of the same BFER device itself. For example, as shown in Figure 1, BFER3 and BFER3 in Figure 1 are connected to the same receiving device R1. Then BFER3 and BFER3 constitute a dual-homing BFER device. Then: BFER3 corresponds to the first notification protocol message of the BFER3 device, and the first notification protocol message of the BFER3 device carries the BFR-Prefix of the BFER3 device; BFER4 corresponds to the first notification protocol message of the BFER4 device, and the first notification protocol message of the BFER4 device carries the BFR-Prefix of the BFER4 device.

[0038] Step S304: Notify the second notification protocol message to other devices in the domain.

[0039] The present disclosure obtains a second announcement protocol message by adding the Anycast BFR-ID corresponding to a dual-homing BFER device to the TLV field of a first announcement protocol message. The dual-homing BFER device includes: a first BFER device and a second BFER device, and the dual-homing BFER device is configured to forward multicast traffic to the same receiving device. The announcement protocol message includes: the bit-indexed forwarding router prefix (BFR-Prefix) of the first BFER device or the BFR-Prefix of the second BFER device. The second announcement protocol message is then announced to other devices within the domain. In other words, by adding the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first announcement protocol message including the BFR-Prefix corresponding to the dual-homing BFER device, the second announcement protocol message is obtained and announced to other devices within the domain. This solves the technical problem in related art whereby an Anycast BFR-Prefix needs to be mapped to each of the two devices when announcing the Anycast BFR-ID, thereby consuming a large number of IP prefixes, leading to complex network deployment and high network resource consumption. This achieves the technical effect of conserving network resources.

[0040] For the above step S302, the Anycast BFR-ID corresponding to the dual-homing BFER device is added to the TLV field of the first announcement protocol message, including the following implementation scheme: when the BFR-ID of the dual-homing BFER device itself exists in the first announcement protocol message, the Anycast BFR-ID is added to the sub-sub-TLV field of the first announcement protocol message, as shown in Figure 4; when the BFR-ID of the dual-homing BFER device itself does not exist in the first announcement protocol message, the Anycast BFR-ID is added to the sub-TLV field of the first announcement protocol message, as shown in Figure 5.

[0041] That is, determine whether the first announcement protocol message corresponding to the dual-homing BFER device carries the BFR-ID assigned by the dual-homing BFER device to itself, and determine whether to add the Anycast BFR-ID to the sub-sub-TLV field or sub-TLV field of the first announcement protocol message based on the presence or absence of the BFR-ID assigned to itself. Specifically, when the dual-homing BFER device announces its BFR-Prefix, if it has an assigned BFR-ID (which only identifies the BFER itself, not the Anycast BFR-ID), the BFR-ID will exist in the BIER-Info sub-TLV in the first announcement protocol message. Furthermore, if the BFR-ID exists in the first announcement protocol message, the Anycast BFR-ID corresponding to the dual-homing BFER device is added to the sub-sub-TLV field of the first announcement protocol message; if the BFR-ID does not exist in the first announcement protocol message, the Anycast BFR-ID corresponding to the dual-homing BFER device is added to the sub-TLV field of the first announcement protocol message.

[0042] It should be noted that the dual-homing BFER device corresponds to a first announcement protocol message, and the dual-homing BFER device includes a first BFER device and a second BFER device. The first BFER device and / or the second BFER device may also be included in other dual-homing BFER devices, and thus the first BFER device may correspond to multiple Anycast BFR-IDs, and the second BFER device may also correspond to multiple Anycast BFR-IDs. When adding a TLV field to the first announcement protocol message, all Anycast BFR-IDs corresponding to the same BFER device (the first BFER device or the second BFER device) need to be added to the TLV field of the first announcement protocol message, as shown in Figure 5. Typically, the length value of the announced Anycast sub-sub-TLV is a fixed value, preferably 2 bytes. If the same BFER device corresponds to two Anycast BFR-IDs (that is, included in two sets of dual-homing BFER devices), the second announcement protocol message obtained by the same BFER device carries two 4-byte Anycast BFR-IDs, and so on.

[0043] In an exemplary embodiment, after notifying other devices in the domain of the second announcement protocol message, the method further includes: determining multiple BFR-Prefixes corresponding to the Anycast BFR-ID; determining the path costs to reach the multiple BFR-Prefixes to obtain multiple path costs; determining the target cost from the multiple path costs according to preset rules, and using the next hop device in the path corresponding to the target cost as the next hop device to reach the Anycast BFR-ID in the forwarding table.

[0044] It is understood that a dual-homed BFER device corresponds to an Anycast BFR-ID, and a dual-homed device includes multiple BFER devices. Therefore, the Anycast BFR-ID corresponds to multiple BFR-Prefixes. The path costs to reach the multiple BFR-Prefixes are determined, and the next-hop device in the path corresponding to the target cost indicated by the preset rule in the multiple path costs is set as the next-hop device of the current device in the forwarding table of the current device.

[0045] For example, as shown in Figure 1, BFER3 and BFER4 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned to them is 101; BFER4 and BFER5 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned to them is 102; BFER5 and BFER6 form a group of Anycast protection relationships with BFER4 and BFER5, assuming that the Anycast BFR-ID value assigned to them is 103. If multicast traffic needs to be forwarded to receiving device R1, the Anycast BFR-ID corresponding to R1 is determined, and its value is 101. Then, multiple BFR-Prefixes corresponding to Anycast BFR-ID 101 are determined. Based on Figure 1, it can be seen that the multiple BFR-Prefixes include the BFR-Prefix of BFER3 and the BFR-Prefix of BFER4. Then calculate multiple path costs from the current device (i.e., other devices in the domain) that receives the second announcement protocol message to the BFR-Prefix of BFER3 and the BFR-Prefix of BFER4, select the path cost determined by the preset rule as the target cost, and use the next-hop device corresponding to the target cost as the next-hop device for the current device to forward multicast traffic to the receiving device R1, and write the next-hop device (such as the port number of the device) into the forwarding table of the current device.

[0046] In an exemplary embodiment, after notifying other devices in the domain of the second announcement protocol message, the method further includes: determining the BFR-Prefix carried by all received second announcement protocol messages; determining the path cost to reach all the BFR-Prefixes to obtain the total path cost; determining multiple path costs corresponding to the Anycast BFR-ID from the total path cost; determining the target cost from the multiple path costs according to a preset rule, and using the next hop device in the path corresponding to the target cost as the next hop device to reach the Anycast BFR-ID in the forwarding table.

[0047] Another solution for determining the next-hop device in the forwarding table is: when any of the other devices in the domain (equivalent to the current device in the above embodiment) receives the second announcement protocol message, the total path cost between the device and the BFER devices that the device can reach can be directly calculated and stored in the storage space of the device. The BFR-Prefix of multiple BFERs corresponding to each Anycast BFR-ID is then determined, and the path cost of the BFR-Prefix of the multiple BFERs is determined from the total path cost recorded in the storage space, thereby determining the target cost.

[0048] In an exemplary embodiment, after determining the path costs to reach the multiple BFR-Prefixes and obtaining the multiple path costs, the method further includes: saving the multiple path costs into a storage space of the other device.

[0049] It can be understood that after other devices in the domain calculate the path cost, they can save the path cost in the storage space of this device to avoid the situation where there is duplication of BFER BFR-Prefix corresponding to other Anycast BFR-IDs, or when the forwarding table needs to be recalculated due to network failures, etc., which requires the path cost to be calculated again, resulting in a waste of network resources. In addition, when the path cost is needed, the path cost information can be read directly from the storage space of this device.

[0050] In an exemplary embodiment, a target overhead is determined from the multiple path costs according to a preset rule, including one of the following: determining the minimum path overhead among the multiple path costs, and determining the minimum path overhead as the target overhead; determining multiple identical path costs among the multiple path costs, and determining the multiple identical path costs as the target overhead; determining the minimum path cost among the multiple path costs, and determining the suboptimal path cost among the multiple path costs; determining the minimum path cost and the suboptimal path cost as the target overhead.

[0051] Different preset rules for calculating the target cost result in different target costs. These preset rules may include selecting the minimum path cost; selecting the minimum path cost and the suboptimal path cost, so that if the forwarding network for the multicast traffic indicated by the minimum path cost fails, the next-hop path corresponding to the suboptimal path cost can be directly used to forward the multicast traffic, ensuring smooth multicast traffic forwarding; or selecting multiple paths with the same cost to achieve load balancing, preventing the loss of some multicast traffic due to insufficient load capacity of a single BFER device.

[0052] In an exemplary embodiment, after notifying other devices within the domain of the second announcement protocol message, the method further includes: in the event of a network failure within the domain, determining multiple reachable BFR-Prefixes corresponding to the Anycast BFR-ID; determining the minimum path cost among the path costs corresponding to the multiple reachable BFR-Prefixes; and updating the next hop device corresponding to the minimum path cost recorded in the forwarding table to the next hop device corresponding to the minimum path cost among the path costs.

[0053] In the event of a network failure within a domain, devices within the domain need to recalculate their forwarding tables. Specifically, if the preset rule is to determine the minimum path cost, the BFR-Prefix of the path where the failure occurred is determined (generally, the path indicated by the previously calculated minimum path cost), multiple reachable BFR-Prefixes corresponding to the Anycast BFR-ID other than the BFR-Prefix of the failed path are determined, and the minimum path cost to reach the multiple reachable BFR-Prefixes is re-determined.

[0054] In an exemplary embodiment, after notifying other devices within the domain of the second notification protocol message, the method further includes: in the event of a network failure within the domain, forwarding the multicast traffic through the next hop device corresponding to the suboptimal path cost recorded in the forwarding table.

[0055] Based on the aforementioned embodiment, when the preset rule is to determine the minimum path cost and the suboptimal path cost, if the intra-domain network is not faulty, then generally only the next-hop path indicated by the minimum path cost is used to forward multicast traffic, and the next-hop device indicated by the suboptimal path cost is used as a backup forwarding device; however, if the intra-domain network fails, the next-hop device indicated by the suboptimal path cost is enabled to forward multicast traffic. The backup forwarding solution provided by the present disclosure can quickly switch forwarding devices in the event of an intra-domain network failure, avoiding the waste of resources and time caused by recalculating the next-hop device, thereby ensuring smooth forwarding of multicast traffic.

[0056] In an exemplary embodiment, after determining the target cost from the multiple path costs according to a preset rule, and using the device corresponding to the target cost as the next-hop device to reach the Anycast BFR-ID in the forwarding table, the method further includes: sharing and forwarding the multicast traffic through multiple next-hop devices corresponding one-to-one to the multiple identical paths recorded in the forwarding table.

[0057] Based on the above embodiment, when the preset rule is to determine multiple identical path costs, multiple next-hop devices indicated by the multiple identical path costs are recorded in the forwarding table. When forwarding multicast traffic, the forwarding is shared by multiple next-hop devices to avoid packet loss caused by insufficient carrying capacity of a single device.

[0058] Next, the message notification method will be further described in conjunction with the following embodiments.

[0059] The present disclosure provides a solution that can realize the BIER Anycast function without relying on IP address resource allocation, without the need for one-to-one binding of BFR-Prefix and Anycast BFR-ID. It is suitable for large-scale network deployment and greatly simplifies deployment complexity.

[0060] Specifically, the BIER Anycast function is implemented without relying on IP address resource allocation, including the following:

[0061] When announcing the Anycast BFR-ID that represents the protection relationship, it is announced directly following the BFR-Prefix of the BFER as a newly added type; when there are multiple Anycast BFR-IDs that need to be announced on the same node, they are all announced following the BFR-Prefix, without the need to allocate and announce a dedicated Anycast BFR-Prefix.

[0062] Among them, Anycast BFR-ID is a new sub-TLV type, which is announced following the BFR-Prefix of the device itself; or as a new sub-sub-TLV type, it is announced following the BIER-info sub-TLV. TLV (Type-Length-Value) is a universal data structure format.

[0063] When calculating the BIER forwarding table, devices in the network need to find the BFR-Prefix corresponding to multiple devices that may have the Anycast BFR-ID, calculate the path cost to reach these BFR-Prefixes, select the BFR-Prefix with the smallest path cost, and use the next-hop device corresponding to the BFR-Prefix with the smallest path cost as the next hop in the BIER forwarding table to reach the Anycast BFR-ID.

[0064] Furthermore, the calculation process can be optimized by storing the calculated BFR-Prefix path cost to reduce the repeated calculation process in subsequent searches.

[0065] When a failure occurs in the network, another optimal path to the Anycast BFR-ID is directly calculated and sent to the forwarding table to achieve fast switching.

[0066] Furthermore, you can also choose to send the next hop with the suboptimal path cost to the BIER forwarding table. When the optimal path fails, the next hop of the suboptimal path can be used directly for forwarding traffic, realizing the fast switching fast recovery routing (Fast Reroute, FRR for short) function.

[0067] Furthermore, when there are multiple paths with the same cost, the next hops of multiple paths can also be sent to the BIER forwarding table, and the traffic can be directly shared on multiple paths during forwarding, thereby realizing the load sharing (Equal-Cost Multi-Path, abbreviated as ECMP) function.

[0068] Based on the above content, without relying on IP address resource allocation, the implementation of BIER Anycast function also includes device processing and signaling notification:

[0069] 1) Equipment processing part:

[0070] When the device calculates the BIER forwarding table, for Anycast BFR-ID, it will search for the BFR-Prefix announced by all corresponding devices, calculate the path cost to reach these BFR-Prefixes, select the path with the lowest cost, and use its corresponding next hop as the next hop corresponding to the Anycast BFR-ID and fill it into the BIER forwarding table.

[0071] When a problem occurs in the network and triggers the BIER forwarding table calculation, the shortest path to its BFR-Prefix is ​​selected from other devices that announce the Anycast BFR-ID, and the corresponding next hop is updated to the BIER forwarding table.

[0072] Further optimization measures can be used to store the path costs to reach the BFR-Prefix of all devices. In this way, when calculating the next hop of the Anycast BFR-ID, there is no need to calculate the device path that announces the Anycast BFR-ID again. You can directly select the one with the lowest cost and fill in or update the corresponding next hop to the BIER forwarding table.

[0073] Furthermore, the next hop of the suboptimal path can also be sent to the BIER forwarding table to implement the FRR function;

[0074] Furthermore, when the costs of multiple paths are the same, the next hops of these paths can be sent to the BIER forwarding table together to implement the ECMP function.

[0075] 2) Signaling notification part:

[0076] When an Anycast BFR-ID is announced, it is announced as a new sub-TLV type directly following the BFR-Prefix of the BFER; when there are multiple Anycast BFR-IDs that need to be announced on the same node, they are all announced following the BFR-Prefix.

[0077] Among them, Anycast BFR-ID is announced as a new sub-TLV type following the BFR-Prefix of the device itself; it can also be announced as a new sub-sub-TLV type following the BIER-info sub-TLV.

[0078] The process of implementing the BIER Anycast function without relying on IP address resource allocation includes:

[0079] The device advertises the Anycast BFR-ID, followed by the device's own BFR-Prefix.

[0080] After receiving the Anycast BFR-ID announced by other devices, perform routing calculation. For each Anycast BFR-ID, find all devices that announce the Anycast BFR-ID, calculate the BFR-Prefix path cost to these devices, select the path with the lowest cost, and fill in the corresponding next hop in the entry corresponding to the Anycast BFR-ID in the BIER forwarding table.

[0081] When a problem occurs in the network and the path is recalculated, because the corresponding BFER is unreachable, the BFR-Prefix path with the lowest cost is selected from other reachable devices, and its corresponding next hop is updated to the entry corresponding to the Anycast BFR-ID in the BIER forwarding table.

[0082] A further optimization measure is that after the device first calculates the BFR-Prefix path to all devices, it stores the corresponding cost. Therefore, when calculating the next hop for an Anycast BFR-ID, after finding the corresponding advertising device, the path cost to its BFR-Prefix can be directly compared. In this way, when a device advertises multiple Anycast BFR-IDs, its BFR-Prefix path is only calculated once, greatly reducing the calculation cost.

[0083] Furthermore, during route calculation, the next hop of the suboptimal path can be sent to the BIER forwarding table together to implement the FRR function;

[0084] Furthermore, when the routing calculation has the same cost for multiple paths, the next hops of these paths can be sent to the BIER forwarding table together to implement the ECMP function.

[0085] The following explains the implementation of the above information notification in conjunction with optional embodiments, but is not intended to limit the implementation of the present disclosure.

[0086] Example 1:

[0087] In the network shown in Figure 1, BFERs 3 / 4 / 5 / 6 all need to advertise their Anycast BFR-IDs to implement the BIER Anycast functionality. BFER 3 forms an Anycast protection relationship only with BFER 4, assuming the assigned Anycast BFR-ID value is 101. For the protection relationship formed between BFER 4 and BFER 5, the assigned Anycast BFR-ID value is 102, and for the protection relationship formed between BFER 5 and BFER 6, the assigned Anycast BFR-ID value is 103. When advertising their BFR-Prefix, if each BFER has an assigned BFR-ID (which only identifies the BFER itself, not the Anycast BFR-ID), it will also advertise the BIER-Info sub-TLV (carrying its own BFR-ID) under the BFR-Prefix. This allows the Anycast BFR-ID to be advertised as a sub-sub-TLV following the BIER-Info sub-TLV, as shown in Figure 4. Other sub-sub-TLVs that originally followed the BIER-Info announcement, such as MPLS (Multi Protocol Label Switching) encapsulation and other sub-sub-TLVs, will be announced in parallel with the Anycast BFR-ID sub-sub-TLV.

[0088] The format of the Anycast BFR-ID is shown in Figure 6. It uses a TLV (Type, Length, Value) format, where Type is the newly added Anycast BFR-ID type value and Length is the total length of the actual Anycast BFR-ID value carried. The length of a single BFR-ID is 2 bytes, so this total length is an integer multiple of 2 bytes. For BFER3, the Length value of the advertised Anycast sub-sub-TLV is 2, and it carries only one Anycast BFR-ID value, namely 101. Similarly, for BFER6, since it also has only one Anycast BFR-ID, the Length value of the advertised Anycast sub-sub-TLV is also 2, and it also carries only one Anycast BFR-ID value, namely 103. For BFER4 / 5, because both devices are responsible for two groups of protection relationships, they need to advertise two Anycast BFR-ID values. Therefore, the Length value of the Anycast sub-sub-TLV they advertise is 4, carrying two Anycast BFR-ID values ​​representing two groups of Anycast protection relationships. For example, the two Anycast BFR-ID values ​​advertised by BFER4 are 101 and 102; the two Anycast BFR-ID values ​​advertised by BFER5 are 102 and 103.

[0089] After devices on the network advertise to each other, each device can obtain the BFR-Prefix advertised by other devices, as well as any Anycast BFR-ID information it may carry. For example, a BFRm device will receive the BFR-Prefix from each BFER3 / 4 / 5 / 6 device, along with the Anycast BFR-ID sub-TLV or sub-sub-TLV it carries. The device performs routing calculation. Assuming that it processes the Anycast BFR-ID (101) announced by BFER3, it will traverse the Anycast BFR-ID announced by other devices and find that the BFER4 device also announced this Anycast BFR-ID (101). In this way, the two devices BFER3 and BFER4 that announced 101 are obtained, and the path costs of the BFR-Prefix to these two devices are calculated respectively. The path with the smallest cost is taken. Assuming that the calculated path cost to BFER3 is the smallest, this path is selected. Assuming that the next hop of this path is BFRx, BFRm will send the entry with BFR-ID 101 and next hop BFRx to the BIER forwarding table. Then, when processing the Anycast BFR-ID 102 announced by BFER4, the same processing method will be used to find the BFER5 device that also announced this Anycast BFR-ID. The BFR-Prefix path cost to BFER4 and BFER5 is calculated respectively, and the path with the shortest cost is selected. The next hop of this path (assuming it is BFRy) and Anycast BFR-ID 102 are sent to the BIER forwarding table. Repeat the above process until the forwarding table reaching all Anycast BFR-IDs is obtained, as shown in Figure 7. The overall process description is shown in Figure 8, which includes the following steps:

[0090] Step S801: Send / receive BFR-Prefix and Anycast BFR-ID;

[0091] Step S802: Perform routing calculation to collect BFR-Prefixes of all devices that advertise the same Anycast BFR-ID;

[0092] Step S803: Calculate the path costs to the BFR-Prefix of these devices;

[0093] Step S804: Select the BFR-Prefix with the shortest path cost, set the next hop to the BFR-Prefix as the next hop of the Anycast BFR-ID, and fill it into the BIER forwarding table;

[0094] Step S805: Repeat steps S802 to S804 for the next Anycast BFR-ID.

[0095] Therefore, for traffic to be received by R1, BFIR1 encapsulates the Anycast BFR-ID 101 into the BitString of the BIER header. The intermediate device forwards it hop by hop based on the BIER forwarding table to the BFER3 device, which then forwards it to R1. The same process applies to traffic to be received by R2 / R3, so I will not repeat it here.

[0096] Furthermore, during the routing calculation process, because it has been discovered that there are multiple paths to the same Anycast BFR-ID, in addition to selecting the optimal path, the next hop of the suboptimal path can also be filled in the BIER forwarding table. Usually, forwarding is only performed through the next hop of the optimal path. When the optimal path fails, it can be forwarded directly through the second next hop in the table, thereby realizing the FRR (Fast Re-route) function, that is, fast switching.

[0097] Example 2:

[0098] For some special cases, such as when BFER itself does not allocate its own BFR-ID, there is no BIER-Info sub-TLV announcement. Therefore, the Anycast BFR-ID cannot be announced following the BIER-Info sub-TLV. In this case, the Anycast BFR-ID can be directly announced as a sub-TLV following the BFR-Prefix, as shown in Figure 8. Of course, this method is also applicable to scenarios where the BIER-Info sub-TLV announcement is omitted for various reasons. After the Anycast BFR-ID sub-TLV, the MPLS encapsulation and other sub-sub-TLVs are announced.

[0099] The notification and calculation processes are also performed as described in the first embodiment.

[0100] Example 3:

[0101] The calculation process of the equipment can be further optimized.

[0102] Taking device BFRm as an example, it receives the BFR-Prefix from each of the BFER3 / 4 / 5 / 6 devices, along with the Anycast BFR-ID sub-TLV or sub-sub-TLV. The device then performs route calculation, calculates and stores the path cost to each of the BFR-Prefixes on the device, including the path cost and next hop to BFER3 / 4 / 5 / 6, as shown in Figure 9.

[0103] Then process the received Anycast BFR-ID sub-TLV or sub-sub-TLV. Assuming that the Anycast BFR-ID (101) announced by BFER3 is processed, the Anycast BFR-ID announced by other devices will be traversed. It is found that the BFER4 device also announced this Anycast BFR-ID (101). In this way, the BFR-Prefixes of the two devices BFER3 and BFER4 that announced 101 are obtained. At this time, the stored information shown in Figure 9 is directly searched, and the path costs of the two BFR-Prefixes are compared. The next hop corresponding to the path with the lowest cost is taken and sent to the BIER forwarding table together with the Anycast BFR-ID 101. Repeat the above process until the forwarding table that reaches all Anycast BFR-IDs is obtained. The overall process description is shown in Figure 10, including:

[0104] Step S1001: Send / receive BFR-Prefix and Anycast BFR-ID;

[0105] Step S1002: Perform route calculation and store the path costs to all devices' BFR-Prefixes.

[0106] Step S1003: Collect BFR-Prefix of all devices that advertise the same Anycast BFR-ID;

[0107] Step S1004: Query the content stored in step S202, directly compare the path costs to the BFR-Prefix of these devices, select the one with the lowest cost, use the next hop to the BFR-Prefix as the next hop of the Anycast BFR-ID, and fill in the BIER forwarding table;

[0108] Step S1005: Repeat steps S1003-S1004 for the next Anycast BFR-ID.

[0109] Example 4:

[0110] When a problem occurs in the network, such as a failure of the BFER3 device, there may be two situations. The first is that the BFR-Prefix and the Anycast BFR-ID information announced by the BFER3 device are invalid. The other situation is that the BFR-Prefix and the information carried by the BFER3 device are still valid, but there is no path to reach BFER3.

[0111] In the first case, still using BFRm as an example, it will not obtain the Anycast BFR-ID announced by the BFER3 device. Therefore, Anycast BFR-ID 101 will only be obtained from the BFER4 device. Therefore, the next hop corresponding to the BFR-Prefix path reaching BFER4 will be updated to the entry corresponding to BFR-ID 101 in the BIER forwarding table. All devices in the network will process it in this way, and the traffic sent to Anycast BFR-ID 101 will be forwarded to BFER4, and then forwarded to R1 by BFER4.

[0112] For the second case, still taking BFRm as an example, it will obtain the Anycast BFR-ID announced by the BFER3 device. For Anycast BFR-ID 101, it will still obtain two devices, BFER3 and BFER4. However, when calculating the path to the BFR-Prefix of these two devices, it will be found that BFER3 cannot be reached, or when querying the BFR-Prefix storage table, no path to BFER3's BFR-Prefix can be found. Therefore, only the valid path to BFER4 will be calculated, and the next hop corresponding to this path will be updated to the entry corresponding to BFR-ID 101 in the BIER forwarding table. All devices in the network will process it in this way, so the traffic sent to Anycast BFR-ID 101 will be forwarded to BFER4, and then forwarded to R1 by BFER4.

[0113] Embodiment 5:

[0114] Based on the notification and calculation method disclosed in this disclosure, the ECMP (Equal-cost multi-path routing) function can also be easily implemented.

[0115] In some scenarios, a receiver can receive traffic from two BFER devices simultaneously (but not duplicate traffic). In this way, the traffic can reach both BFER devices along the ECMP path, and then both BFER devices forward it to the receiver. This can prevent traffic from being concentrated on one BFER device, which would cause a forwarding performance bottleneck.

[0116] As shown in Figure 1, assume that all devices in the network choose a path to BFER4. Traffic to be received by R1 and R2 must be forwarded by BFER4, but BFER4's capacity is insufficient to handle this amount of traffic, potentially causing some traffic loss. In this case, ECMP can be enabled in the network. When a device calculates the BFR-Prefix cost to multiple devices advertising an Anycast BFR-ID, if it finds the same path cost to each device, it will add the next hops to each of these devices to the BIER forwarding table. This allows traffic to be distributed across multiple paths during forwarding, reducing the forwarding burden on a single BFER device. For example, assume that BFRm, during route calculation, discovers that two devices, BFER3 and BFER4, both advertise Anycast BFR-ID 101. When calculating the paths to these two devices' BFR-Prefixes, it finds the same cost. Therefore, it can add the next hops (assuming they are BFRxa and BFRxb) for both paths to BFER3 and BFER4 to the BIER forwarding table, as shown in Figure 11. In this way, when forwarding traffic, the traffic destined for R1 can be shared on the path to BFER3 and BFER4, and BFER3 and BFER4 then forward it to R1, thereby reducing the processing burden of a single BFER.

[0117] In summary, after adopting the notification and processing method of the real-time example disclosed in this invention, there is no need to assign a one-to-one Anycast BFR-Prefix to each Anycast BFR-ID. All devices only need to indicate their own BFR-Prefix, which greatly reduces the consumption of IP address prefix resources, reduces the difficulty of planning, and is suitable for large-scale network deployment.

[0118] Furthermore, the BIER Anycast scenario is a common scenario for the application of BIER technology, with broad deployment prospects. While solving the problems faced by the implementation of BIER Anycast technology, it can also greatly save network IP prefix resources. It is an important aspect that operators are concerned about, and therefore has broad commercial prospects.

[0119] This embodiment also provides a message notification device for implementing the above-mentioned embodiments and preferred embodiments. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented using software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0120] FIG12 is a block diagram of a message notification device according to the present disclosure. As shown in FIG12 , the message notification device includes:

[0121] an adding module 122 configured to add the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first announcement protocol message to obtain a second announcement protocol message, wherein the dual-homing BFER device includes: a first BFER device and a second BFER device, the dual-homing BFER device is configured to forward multicast traffic to the same receiving device, and the announcement protocol message includes: a bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device;

[0122] The notification module 124 is configured to notify other devices in the domain of the second notification protocol message.

[0123] The present disclosure, through the above-mentioned module, adds the Anycast BFR-ID corresponding to a dual-homing BFER device to the TLV field of a first announcement protocol message to obtain a second announcement protocol message. The dual-homing BFER device includes: a first BFER device and a second BFER device, and is configured to forward multicast traffic to the same receiving device. The announcement protocol message includes: a bit-indexed forwarding router prefix (BFR-Prefix) of the first BFER device or the BFR-Prefix of the second BFER device. The second announcement protocol message is then announced to other devices within the domain. In other words, by adding the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first announcement protocol message including the BFR-Prefix of the dual-homing BFER device to obtain the second announcement protocol message, and announcing the second announcement protocol message to other devices within the domain, this solves the technical problem in related art whereby an Anycast BFR-Prefix needs to be mapped to each of the two devices when announcing the Anycast BFR-ID, thereby consuming a large number of IP prefixes, leading to complex network deployment and high network resource consumption. The technical effect of saving network resources is achieved.

[0124] In an exemplary embodiment, the adding module 122 is further configured to add the Anycast BFR-ID to the sub-sub-TLV field of the first announcement protocol message when the BFR-ID of the dual-homing BFER device itself exists in the first announcement protocol message, as shown in FIG4 ; and add the Anycast BFR-ID to the sub-TLV field of the first announcement protocol message when the BFR-ID of the dual-homing BFER device itself does not exist in the first announcement protocol message, as shown in FIG5 .

[0125] That is, determine whether the first announcement protocol message corresponding to the dual-homing BFER device carries the BFR-ID assigned by the dual-homing BFER device to itself, and determine whether to add the Anycast BFR-ID to the sub-sub-TLV field or sub-TLV field of the first announcement protocol message based on the presence or absence of the BFR-ID assigned to itself. Specifically, when the dual-homing BFER device announces its BFR-Prefix, if it has an assigned BFR-ID (which only identifies the BFER itself, not the Anycast BFR-ID), the BFR-ID will exist in the BIER-Info sub-TLV in the first announcement protocol message. Furthermore, if the BFR-ID exists in the first announcement protocol message, the Anycast BFR-ID corresponding to the dual-homing BFER device is added to the sub-sub-TLV field of the first announcement protocol message; if the BFR-ID does not exist in the first announcement protocol message, the Anycast BFR-ID corresponding to the dual-homing BFER device is added to the sub-TLV field of the first announcement protocol message.

[0126] It should be noted that the dual-homing BFER device corresponds to a first announcement protocol message, and the dual-homing BFER device includes a first BFER device and a second BFER device. The first BFER device and / or the second BFER device may also be included in other dual-homing BFER devices, and thus the first BFER device may correspond to multiple Anycast BFR-IDs, and the second BFER device may also correspond to multiple Anycast BFR-IDs. When adding a TLV field to the first announcement protocol message, all Anycast BFR-IDs corresponding to the same BFER device (the first BFER device or the second BFER device) need to be added to the TLV field of the first announcement protocol message, as shown in Figure 5. Typically, the length value of the announced Anycast sub-sub-TLV is a fixed value, preferably 2 bytes. If the same BFER device corresponds to two Anycast BFR-IDs (that is, included in two sets of dual-homing BFER devices), the second announcement protocol message obtained by the same BFER device carries two 4-byte Anycast BFR-IDs, and so on.

[0127] In an exemplary embodiment, the notification module 124 is further configured to determine multiple BFR-Prefixes corresponding to the Anycast BFR-ID; determine the path costs to reach the multiple BFR-Prefixes to obtain multiple path costs; determine the target cost from the multiple path costs according to a preset rule, and use the next hop device in the path corresponding to the target cost as the next hop device to reach the Anycast BFR-ID in the forwarding table.

[0128] It is understood that a dual-homed BFER device corresponds to the same Anycast BFR-ID, and a dual-homed device includes multiple BFER devices. Therefore, the same Anycast BFR-ID corresponds to multiple BFR-Prefixes. The path costs to reach the multiple BFR-Prefixes are determined, and the next-hop device in the path corresponding to the target cost indicated by the preset rule in the multiple path costs is set as the next-hop device of the current device in the forwarding table of the current device.

[0129] For example, as shown in Figure 1, BFER3 and BFER4 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned to them is 101; BFER4 and BFER5 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned to them is 102; BFER5 and BFER6 form a group of Anycast protection relationships with BFER4 and BFER5, assuming that the Anycast BFR-ID value assigned to them is 103. If multicast traffic needs to be forwarded to receiving device R1, the Anycast BFR-ID corresponding to R1 is determined, and its value is 101. Then, multiple BFR-Prefixes corresponding to Anycast BFR-ID 101 are determined. Based on Figure 1, it can be seen that the multiple BFR-Prefixes include the BFR-Prefix of BFER3 and the BFR-Prefix of BFER4. Then calculate multiple path costs from the current device (i.e., other devices in the domain) that receives the second announcement protocol message to the BFR-Prefix of BFER3 and the BFR-Prefix of BFER4, select the path cost determined by the preset rule as the target cost, and use the next-hop device corresponding to the target cost as the next-hop device for the current device to forward multicast traffic to the receiving device R1, and write the next-hop device (such as the port number of the device) into the forwarding table of the current device.

[0130] In an exemplary embodiment, the announcement module 124 is further configured to determine the BFR-Prefix carried by all received second announcement protocol messages; determine the path cost to reach all the BFR-Prefixes to obtain the total path cost; determine multiple path costs corresponding to the Anycast BFR-ID from the total path cost; determine the target cost from the multiple path costs according to a preset rule, and use the next hop device in the path corresponding to the target cost as the next hop device to reach the Anycast BFR-ID in the forwarding table.

[0131] Another solution for determining the next-hop device in the forwarding table is: when any of the other devices in the domain (equivalent to the current device in the above embodiment) receives the second announcement protocol message, the total path cost between the device and the BFER devices that the device can reach can be directly calculated and stored in the storage space of the device. The BFR-Prefix of multiple BFERs corresponding to each Anycast BFR-ID is then determined, and the path cost of the BFR-Prefix of the multiple BFERs is determined from the total path cost recorded in the storage space, thereby determining the target cost.

[0132] In an exemplary embodiment, the apparatus further includes: a saving module configured to save the multiple path costs into a storage space of the other device.

[0133] It can be understood that after other devices in the domain calculate the path cost, they can save the path cost in the storage space of this device to avoid the situation where there is duplication of BFER BFR-Prefix corresponding to other Anycast BFR-IDs, or when the forwarding table needs to be recalculated due to network failures, etc., which requires the path cost to be calculated again, resulting in a waste of network resources. In addition, when the path cost is needed, the path cost information can be read directly from the storage space of this device.

[0134] In an exemplary embodiment, the notification module 124 is further configured to do one of the following: determine the minimum path cost among the multiple path costs, and determine the minimum path cost as the target cost; determine multiple identical path costs among the multiple path costs, and determine the multiple identical path costs as the target cost; determine the minimum path cost among the multiple path costs, and determine the suboptimal path cost among the multiple path costs; determine the minimum path cost and the suboptimal path cost as the target cost.

[0135] Different preset rules for calculating the target cost result in different target costs. These preset rules may include selecting the minimum path cost; selecting the minimum path cost and the suboptimal path cost, so that if the forwarding network for the multicast traffic indicated by the minimum path cost fails, the next-hop path corresponding to the suboptimal path cost can be directly used to forward the multicast traffic, ensuring smooth multicast traffic forwarding; or selecting multiple paths with the same cost to achieve load balancing, preventing the loss of some multicast traffic due to insufficient load capacity of a single BFER device.

[0136] In an exemplary embodiment, the notification module 124 is further configured to determine multiple reachable BFR-Prefixes corresponding to the Anycast BFR-ID in the event of a network failure within the domain; determine the minimum path cost among the path costs corresponding to the multiple reachable BFR-Prefixes; and update the next hop device corresponding to the minimum path cost recorded in the forwarding table to the next hop device corresponding to the minimum path cost among the path costs.

[0137] In the event of a network failure within a domain, devices within the domain need to recalculate their forwarding tables. Specifically, if the preset rule is to determine the minimum path cost, the BFR-Prefix of the path where the failure occurred is determined (generally, the path indicated by the previously calculated minimum path cost), multiple reachable BFR-Prefixes corresponding to the Anycast BFR-ID other than the BFR-Prefix of the failed path are determined, and the minimum path cost to reach the multiple reachable BFR-Prefixes is re-determined.

[0138] In an exemplary embodiment, the notification module 124 is further configured to forward the multicast traffic through the next hop device corresponding to the suboptimal path cost recorded in the forwarding table when a network failure occurs within the domain.

[0139] Based on the aforementioned embodiment, when the preset rule is to determine the minimum path cost and the suboptimal path cost, if the intra-domain network is not faulty, then generally only the next-hop path indicated by the minimum path cost is used to forward multicast traffic, and the next-hop device indicated by the suboptimal path cost is used as a backup forwarding device; however, if the intra-domain network fails, the next-hop device indicated by the suboptimal path cost is enabled to forward multicast traffic. The backup forwarding solution provided by the present disclosure can quickly switch forwarding devices in the event of an intra-domain network failure, avoiding the waste of resources and time caused by recalculating the next-hop device, thereby ensuring smooth forwarding of multicast traffic.

[0140] In an exemplary embodiment, the notification module 124 is further configured to share and forward the multicast traffic through multiple next-hop devices corresponding to the multiple identical paths recorded in the forwarding table.

[0141] Based on the above embodiment, when the preset rule is to determine multiple identical path costs, multiple next-hop devices indicated by the multiple identical path costs are recorded in the forwarding table. When forwarding multicast traffic, the forwarding is shared by multiple next-hop devices to avoid packet loss caused by insufficient carrying capacity of a single device.

[0142] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present disclosure, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a readable storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of the present disclosure.

[0143] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0144] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail here.

[0145] An embodiment of the present disclosure further provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0146] Optionally, in this embodiment, the processor may be configured to execute the following steps through a computer program:

[0147] S1, adding the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first announcement protocol message to obtain a second announcement protocol message, wherein the dual-homing BFER device includes: a first BFER device and a second BFER device, the dual-homing BFER device is used to forward multicast traffic to the same receiving device, and the announcement protocol message includes: a bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device;

[0148] S2: Notify the second notification protocol message to other devices in the domain.

[0149] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0150] Optionally, in this embodiment, the above-mentioned electronic device can also be configured to execute the above-mentioned step S1 through a computer program, add the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first announcement protocol message, and obtain a second announcement protocol message, wherein the dual-homing BFER device includes: a first BFER device and a second BFER device, the dual-homing BFER device is used to forward multicast traffic to the same receiving device, and the announcement protocol message includes: the bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device; S2, notifying the second announcement protocol message to other devices in the domain.

[0151] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0152] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail here.

[0153] Obviously, those skilled in the art should understand that the modules or steps of the present disclosure described above can be implemented using a general-purpose computing device, they can be concentrated on a single computing device, or distributed across a network composed of multiple computing devices, they can be implemented using program code executable by the computing device, and thus, they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be performed in a different order than herein, or they can be fabricated into separate integrated circuit modules, or multiple modules or steps can be fabricated into a single integrated circuit module for implementation. Thus, the present disclosure is not limited to any particular combination of hardware and software.

[0154] The foregoing description is merely a preferred embodiment of the present disclosure and is not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, or improvements made within the principles of the present disclosure shall be included within the scope of protection of the present disclosure.

Claims

1. A method for announcing a message, comprising: Adding the forwarding router identifier Anycast BFR-ID corresponding to the dual-homing bit forwarding egress router BFER device to the TLV field of the first announcement protocol message to obtain a second announcement protocol message, wherein the dual-homing BFER device includes: a first BFER device and a second BFER device, the dual-homing BFER device is used to forward multicast traffic to the same receiving device, and the announcement protocol message includes: a bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device; Notify other devices in the domain of the second notification protocol message.

2. The method for notifying a message according to claim 1, wherein: Adding the forwarding router identifier Anycast BFR-ID corresponding to the dual-homing bit forwarding egress router BFER device to the TLV field of the first notification protocol message includes: In the case that the BFR-ID of the dual-homing BFER device itself does not exist in the first announcement protocol message, adding the Anycast BFR-ID to the sub-TLV field of the first announcement protocol message; In a case where the BFR-ID of the dual-homing BFER device itself exists in the first announcement protocol message, the Anycast BFR-ID is added to the sub-sub-TLV field of the first announcement protocol message.

3. The method for notifying a message according to claim 1, wherein: After notifying other devices in the domain of the second notification protocol message, the method further includes: Determine a plurality of the BFR-Prefixes corresponding to the Anycast BFR-ID; Determine the path costs to reach the multiple BFR-Prefixes to obtain multiple path costs; A target cost is determined from the multiple path costs according to a preset rule, and a next hop device in a path corresponding to the target cost is used as a next hop device reaching the Anycast BFR-ID in a forwarding table.

4. The method for notifying a message according to claim 1, wherein: After notifying other devices in the domain of the second notification protocol message, the method further includes: Determine the BFR-Prefix carried by all received second notification protocol messages; Determine the path costs to reach all the BFR-Prefixes to obtain the total path costs; Determine a plurality of path costs corresponding to the Anycast BFR-ID from the total path costs; A target cost is determined from the multiple path costs according to a preset rule, and a next hop device in the path corresponding to the target cost is used as a next hop device reaching the Anycast BFR-ID in the forwarding table.

5. The method for notifying a message according to claim 3, wherein: After determining the path costs to reach the multiple BFR-Prefixes and obtaining the multiple path costs, the method further includes: The multiple path costs are saved in the storage space of the other device.

6. The method for notifying a message according to claim 3, wherein: Determining a target cost from the multiple path costs according to a preset rule includes one of the following: Determine a minimum path cost among the multiple path costs, and determine the minimum path cost as the target cost; Determine a plurality of identical path costs among the plurality of path costs, and determine the plurality of identical path costs as the target costs; Determine a minimum path cost among the multiple path costs, and determine a suboptimal path cost among the multiple path costs; and determine the minimum path cost and the suboptimal path cost as the target cost.

7. The method for notifying a message according to claim 6, wherein: After notifying other devices in the domain of the second notification protocol message, the method further includes: In case of a network failure within the domain, determining a plurality of reachable BFR-Prefixes corresponding to the Anycast BFR-ID; Determine a minimum path cost among the path costs corresponding to the multiple reachable BFR-Prefixes; The next hop device corresponding to the minimum path cost recorded in the forwarding table is updated to the next hop device corresponding to the minimum path cost in the path costs.

8. The method for notifying a message according to claim 6, wherein: After notifying other devices in the domain of the second notification protocol message, the method further includes: In the event of a network failure within the domain, the multicast traffic is forwarded via a next-hop device corresponding to the suboptimal path cost recorded in the forwarding table.

9. The method for notifying a message according to claim 6, wherein: Determine the target cost from the multiple path costs according to a preset rule, and use the device corresponding to the target cost as the next hop device to the Anycast BFR-ID in the forwarding table. The method further includes: The multicast traffic is shared and forwarded by multiple next-hop devices corresponding one-to-one to the multiple identical paths recorded in the forwarding table.

10. A message notification device, comprising: An adding module is configured to add a forwarding router identifier Anycast BFR-ID corresponding to a dual-homing bit forwarding egress router BFER device to a TLV field of a first announcement protocol message to obtain a second announcement protocol message, wherein the dual-homing BFER device includes: a first BFER device and a second BFER device, the dual-homing BFER device is used to forward multicast traffic to the same receiving device, and the announcement protocol message includes: a bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device; The notification module is configured to notify other devices in the domain of the second notification protocol message.

11. A computer-readable storage medium, wherein a computer program is stored in the storage medium, wherein: The computer program is configured to execute the method according to any one of claims 1 to 9 when executed.

12. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the method according to any one of claims 1 to 9 through the computer program.

Images