Message notification method and device, storage medium and electronic device

Abstract

The embodiment of the invention provides a message notification method and device, a storage medium and an electronic device.The method comprises the steps that Anycast BFR-ID corresponding to dual-homing BFER equipment is added to a TLV field of a first notification protocol message, a second notification protocol message is obtained, the dual-homing BFER equipment comprises the first BFER equipment and the second BFER equipment, and the first BFER equipment and the second BFER equipment are connected with the first BFER equipment; the BFER equipment is used for forwarding multicast traffic to the same receiving equipment, and the notification protocol message comprises a bit index forwarding router prefix (BFR-Prefix) of the first BFER equipment or the BFR-Prefix of the second BFER equipment; the second advertisement protocol message is advertised to other devices within the domain. By adopting the technical scheme, the problems that when Anycast BFR-IDs are announced, Anycast BFR-Prefixes corresponding to the Anycast BFR-IDs in a one-to-one mode are needed, a large number of IP prefixes need to be consumed, network deployment is complex, and network resource consumption is large in the prior art are solved.

Description

Technical Field

[0001] The present application 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 been used more and more widely. BIER (Bit Indexed Explicit Replication) is a multicast data forwarding technology that represents nodes at the edge of the network with only one bit. When multicast traffic is transmitted in the intermediate network, a specific BIER header will be additionally encapsulated. This message header marks all destination nodes of the multicast stream in the form of a BitString. The intermediate network forwarding node searches the BIER forwarding table for routing based on the bit to ensure that the traffic can be sent to all destination nodes. In general, each BFER will have a corresponding BFR-ID value, which is announced along with the BFER's own BFR-Prefix. The announcement protocol is generally OSPF (OSPF 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 routing calculation functions of these protocols, the BIER forwarding table entries are calculated. The entries in the forwarding table include the BFR-ID to 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 IngressRouter) of the BIER domain encapsulates the corresponding BFER bits into the BitString of the BIER message according to the specific receivers of the multicast stream. The intermediate devices in the BIER domain will forward the messages to the corresponding BFER devices.

[0004] For a downstream device or receiver that needs to receive multicast traffic, in order to improve the reliability of traffic reception, it may be connected to more than one BFER device, so that when a BFER fails, another BFER can forward the traffic. Figure 1As shown, there is an ingress device BFIR1 in the BIER network, devices BFER3 / 4 / 5 / 6 connected to the receiver, and several forwarding devices BFRm to BFRn in the network. Receiver R1 is connected to BFER3 and BFER4 at the same time, and R1 can receive traffic from BFER3 or BFER4; receiver R2 is connected to BFER4 and BFER5 at the same time, and R2 can receive traffic from BFER4 or BFER5; receiver R3 is connected to BFER5 and BFER6 at the same time, and R3 can receive traffic from BFER5 or BFER6.

[0005] like Figure 1 As shown in the figure, because R1 can receive traffic from BFER3 or BFER4, if both devices forward traffic to R1 at the same time, R1 will receive duplicate traffic, and the same traffic will reach BFER3 and BFER4 through different paths, which will also waste bandwidth in the network. Therefore, under normal circumstances, only one of BFER3 and BFER4 will receive and forward multicast traffic to R1. In this way, when the ingress device BFIR1 sends the multicast traffic required by R1, it is necessary to select only the BFR-ID of one device in BFER3 or BFER4 and fill it into the BitString of the BIER header, so that the multicast stream will only reach BFER3 or BFER4 and then be forwarded to R1. Assuming that BFER3 is selected, there is no problem when BFER3 is working normally, but if BFER3 suddenly fails, or the link connected to it fails, causing the traffic to be unable to reach BFER3, BFIR1 needs to select BFER4 as the destination of the traffic. However, it takes a long time for BFIR1 to be informed of the change, during which time traffic is interrupted. In addition, 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 Figure 1 BFER3 and BFER4 are backup traffic forwarding devices for each other as receivers of R1, 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 of the multicast traffic encapsulation required by R1, and the intermediate device selects the optimal path, forwards the traffic to BFER3 or BFER4, and then forwards it to R1. In order to realize this function, the difficulty lies in how to let the intermediate device correctly establish the forwarding table to Anycast BFR-ID to ensure that it can be routed to one of the BFER devices.

[0007] The existing solution is that when an Anycast BFR-ID is announced, a BFR-Prefix corresponding to it is required, which is called Anycast BFR-Prefix. For a set of such protection relationships, for example, BFER3 and BFER4 form a set of Anycast relationships, in addition to the need to allocate a special Anycast BFR-ID for this purpose, a special Anycast BFR-Prefix also needs to be allocated at the same time. For the set of protection relationships formed by BFER4 and BFER5, in addition to allocating another special Anycast BFR-ID, another special Anycast BFR-Prefix needs to be allocated at the same time. The same is true for BFER5 and BFER6. Therefore, for these three sets of protection relationships, in addition to the need to allocate 3 different Anycast BFR-IDs, 3 different Anycast BFR-Prefixes also need to be allocated. Anycast BFR-ID must be allocated, but AnycastBFR-Prefix is ​​an IP address, which is a common 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 groups of protection relationships, hundreds of dedicated IP address prefixes will be 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. In addition, 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, resulting in 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. Summary of the invention

[0010] The embodiments of the present application provide 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.

[0011] According to one aspect of an embodiment of the present application, 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 comprises: 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 comprises: a bit index 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 the domain.

[0012] In an exemplary embodiment, adding the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first announcement protocol message includes: when 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; when the BFR-ID of the dual-homing BFER device itself exists in the first announcement protocol message, adding the Anycast BFR-ID to the sub-sub-TLV field of the first announcement protocol message.

[0013] In an exemplary embodiment, after notifying the second notification protocol message to other devices in the domain, the method also 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 AnycastBFR-ID in the forwarding table.

[0014] In an exemplary embodiment, after notifying other devices in the domain of the second announcement protocol message, the method also 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 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.

[0015] 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 the storage space of the other device.

[0016] 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 cost.

[0017] In an exemplary embodiment, after notifying other devices within the domain of the second notification protocol message, the method also 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.

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

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

[0020] According to another aspect of an embodiment of the present application, a message notification device is also provided, including: an adding module, used to add the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the 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; a notification module, used to notify the second notification protocol message to other devices in the domain.

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

[0022] According to another aspect of an embodiment of the present application, 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.

[0023] Through the present application, the Anycast BFR-ID corresponding to the dual-homing BFER device is added to the TLV field of the 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: the bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device; the second notification protocol message is notified to other devices in the domain. That is, by adding the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first notification protocol message including BFR-Prefix corresponding to the dual-homing BFER device, the second notification protocol message is obtained, and the second notification protocol message is notified to other devices in the domain, which solves the technical problem in the related art that when announcing the Anycast BFR-ID, an Anycast BFR-Prefix corresponding to one of them is required, thereby consuming a large number of IP prefixes, resulting in complex network deployment and large network resource consumption. The technical effect of saving network resources is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0025] Figure 1 This is a schematic diagram of the BIER Anycast scenario in the related technology;

[0026] Figure 2 It is a hardware structure block diagram of a computer terminal of the message notification method of an embodiment of the present application;

[0027] Figure 3 is a flowchart of a method for notifying a message according to an embodiment of the present application (I);

[0028] Figure 4 1 is a schematic diagram of an Anycast BFR-ID notification method according to an embodiment of the present application (I);

[0029] Figure 5 Schematic diagram (II) of notification of Anycast BFR-ID according to the message notification method of an embodiment of the present application;

[0030] Figure 6 It is a schematic diagram of the notification format of Anycast BFR-ID according to the message notification method of an embodiment of the present application;

[0031] Figure 7 1 is a schematic diagram of a forwarding table reaching all Anycast BFR-IDs according to a method for notifying a message in an embodiment of the present application (I);

[0032] Figure 8 is a flowchart of a method for notifying a message according to an embodiment of the present application (II);

[0033] Fig. 9 This is a schematic diagram of information storage of the next hop and the like of the message notification method according to an embodiment of the present application;

[0034] Fig.10 is a flowchart of a method for notifying a message according to an embodiment of the present application (III);

[0035] Fig.11 Schematic diagram (II) of a forwarding table reaching all Anycast BFR-IDs according to a method for notifying a message in an embodiment of the present application;

[0036] Fig.12 It is a structural block diagram of a message notification device according to an embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0038] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application 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 data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising 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.

[0039] The method embodiments provided in the embodiments of the present application can be executed in a computer terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 2 1 is a hardware structure block diagram of a computer terminal of the message notification method of the embodiment of the present application. Figure 2 As shown, the computer terminal may include one or more ( Figure 2 Only one is shown in the figure) processor 202 (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 computer terminal may also include a transmission device 206 and an input / output device 208 for communication functions. It can be understood by those skilled in the art that Figure 2 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer terminal. Figure 2 More or fewer components as shown, or with Figure 2 Equivalent functions or comparisons shown Figure 2 A different configuration with more features is shown.

[0040] 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 notification method of the message in the embodiment of the present application. The processor 202 executes various functional applications and data processing by running the computer program stored in the memory 204, that is, to implement the above 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 arranged relative to the processor 202, and these remote memories may 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.

[0041] The transmission device 206 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of a computer terminal. In one example, the transmission device 206 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 206 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0042] Figure 3 1 is a flow chart of a method for notifying a message according to an embodiment of the present application, which is applied to the above-mentioned computer terminal. Figure 3 As shown, the steps of the method include:

[0043] Step S302, adding the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the 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;

[0044] 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, wherein the first notification protocol message corresponding to the same BFER device carries the BFR-Prefix of the same BFER device itself, for example, Figure 1 As shown, Figure 1 In the figure, BFER3 and BFER3 are connected to the same receiving device R1, then BFER3 and BFER3 form 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.

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

[0046] In the embodiment of the present application, the Anycast BFR-ID corresponding to the dual-homing BFER device is added to the TLV field of the 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: the bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device; the second notification protocol message is notified to other devices in the domain. That is, by adding the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first notification protocol message including BFR-Prefix corresponding to the dual-homing BFER device, the second notification protocol message is obtained, and the second notification protocol message is notified to other devices in the domain, which solves the technical problem in the related art that when notifying the Anycast BFR-ID, an Anycast BFR-Prefix corresponding to one of them is required, thereby consuming a large number of IP prefixes, resulting in complex network deployment and large network resource consumption. The technical effect of saving network resources is achieved.

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

[0048] 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 existence or non-existence 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 AnycastBFR-ID), the BFR-ID will exist in the BIER-Info sub-TLV in the first announcement protocol message. Furthermore, in the case where 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; in the case where 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.

[0049] It should be noted that the dual-homing BFER device corresponds to the first announcement protocol message, the dual-homing BFER device includes the first BFER device and the 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 the 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, such as Figure 5 Typically, the Length value of the announced Anycast sub-sub-TLV is a fixed value, preferably 2 bytes, and if the same BFER device corresponds to two Anycast BFR-IDs (that is, included in two groups 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.

[0050] In an exemplary embodiment, after notifying the second notification protocol message to other devices in the domain, the method also 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 AnycastBFR-ID in the forwarding table.

[0051] It can be understood that the dual-homing BFER device corresponds to an Anycast BFR-ID, and the dual-homing device includes multiple BFER devices. Therefore, the Anycast BFR-ID corresponds to multiple BFR-Prefixes. The path costs to reach 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.

[0052] For example, Figure 1 As shown, BFER3 and BFER4 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned for this is 101; BFER4 and BFER5 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned for this is 102, and BFER5 and BFER6 BFER4 and BFER5 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned for this is 103. If multicast traffic needs to be forwarded to the receiving device R1, the Anycast BFR-ID corresponding to R1 is determined, and its value is 101, and 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 the 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 the 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.

[0053] In an exemplary embodiment, after notifying other devices in the domain of the second announcement protocol message, the method also 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 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.

[0054] Another solution for determining the next hop device in the forwarding table is: when any device among 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 any device and the BFER device that the any device can reach can be directly calculated and stored in the storage space of the any device. Then, the BFR-Prefix of multiple BFERs corresponding to each Anycast BFR-ID is determined, and the path cost of the BFR-Prefix of multiple BFERs is determined from the total path cost recorded in the storage space, and then the target cost is determined.

[0055] 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 the storage space of the other device.

[0056] 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 there is a network failure and the forwarding table needs to be recalculated. The path cost needs 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 directly read from the storage space of this device.

[0057] 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 cost.

[0058] Different preset rules for calculating the target cost will eventually determine different target costs. The preset rules may be: selecting the minimum path cost; selecting the minimum path cost and the suboptimal path cost, so that when the forwarding network of 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 forwarding of the multicast traffic; selecting multiple identical path costs to achieve load sharing function, avoiding the situation where part of the multicast traffic is lost due to insufficient load capacity of a single BFER device.

[0059] In an exemplary embodiment, after notifying other devices within the domain of the second notification protocol message, the method also 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.

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

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

[0062] Based on the above embodiments, when the preset rule is to determine the minimum path cost and the suboptimal path cost, if the intra-domain network does not fail, then generally only the next-hop path indicated by the minimum path cost is used to forward the multicast traffic, and the next-hop device indicated by the suboptimal path cost is used as a backup forwarding device; but once the intra-domain network fails, the next-hop device indicated by the suboptimal path cost is enabled to forward the multicast traffic. The backup forwarding solution provided by the embodiment of the present application can quickly switch the forwarding device when the intra-domain network fails, avoiding the waste of resources and time caused by recalculating the next-hop device, thereby making the forwarding of multicast traffic smooth.

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

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

[0065] Next, the message notification method is further described in conjunction with the following embodiments.

[0066] The embodiment of the present application 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, which can be applied to large-scale network deployment and greatly simplifies the deployment complexity.

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

[0068] When an Anycast BFR-ID representing a protection relationship is announced, 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.

[0069] 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

[0070] When calculating the BIER forwarding table, for Anycast BFR-ID, the devices in the network need to find the BFR-Prefix corresponding to multiple devices that may have AnycastBFR-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.

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

[0072] 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.

[0073] 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, thereby realizing the fast switching fast recovery routing (Fast Reroute, FRR for short) function.

[0074] Furthermore, when there are multiple paths with the same cost, the next hops of the 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, ECMP for short) function.

[0075] 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:

[0076] 1) Equipment processing part:

[0077] 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 the corresponding next hop as the next hop corresponding to the Anycast BFR-ID and fill it into the BIER forwarding table.

[0078] 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.

[0079] Further optimization measures can be taken to store the path costs to reach the BFR-Prefix of all devices. In this way, when calculating the next hop of 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.

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

[0081] 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.

[0082] 2) Signaling notification part:

[0083] When an Anycast BFR-ID is announced, it is announced as a newly added 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.

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

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

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

[0087] 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 the corresponding next hop into the entry corresponding to the Anycast BFR-ID in the BIER forwarding table.

[0088] 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 the BFR-Prefix path calculations of other reachable devices, and its corresponding next hop is updated to the entry corresponding to the Anycast BFR-ID in the BIER forwarding table.

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

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

[0091] 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.

[0092] The following is an explanation of the implementation scheme of the above information notification in conjunction with optional embodiments, but is not intended to limit the implementation method of the embodiments of the present application.

[0093] Embodiment 1:

[0094] like Figure 1 In the network shown, BFER3 / 4 / 5 / 6 need to announce AnycastBFR-ID because they implement the BIER Anycast function. BFER3 only forms a set of Anycast protection relationships with BFER4. Assume that the AnycastBFR-ID value assigned for this is 101. For the protection relationship formed by BFER4 and BFER5, assume that the Anycast BFR-ID value assigned for this is 102. For the protection relationship formed by BFER5 and BFER6, assume that the Anycast BFR-ID value assigned for this is 103. When each BFER announces its BFR-Prefix, if it has an assigned BFR-ID (which only identifies the BFER itself, not the AnycastBFR-ID), it will announce the BIER-Info sub-TLV (to carry its own BFR-ID) under the BFR-Prefix. In this way, the Anycast BFR-ID can be announced as a sub-sub-TLV following the BIER-Info sub-TLV, such as Figure 4Other 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.

[0095] The format of Anycast BFR-ID is as follows Figure 6 As shown, it is a TLV (Type, Length, Value) method, 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 announced Anycastsub-sub-TLV is 2, and it only carries one Anycast BFR-ID value, that is, 101; similarly for BFER6, because there is only one Anycast BFR-ID, the Length value of the announced Anycast sub-sub-TLV is also 2, and it also carries only one Anycast BFR-ID value, that is, 103. For BFER4 / 5, because these two devices are responsible for two groups of protection relationships, they need to announce two Anycast BFR-ID values. Therefore, the Length value of the Anycast sub-sub-TLV they announce is 4, carrying two Anycast BFR-ID values ​​representing two groups of Anycast protection relationships. For example, the two Anycast BFR-ID values ​​announced by BFER4 are 101 and 102; the two Anycast BFR-ID values ​​announced by BFER5 are 102 and 103.

[0096] After the devices in the network announce to each other, each device can obtain the BFR-Prefix announced by other devices, as well as the Anycast BFR-ID information that may be carried. Taking the BFRm device as an example, it will receive the BFR-Prefix of the BFER3 / 4 / 5 / 6 device, and the Anycast BFR-ID sub-TLV or sub-sub-TLV carried. 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 has 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 calculation finds that the path cost to reach 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 Anycast BFR-ID 102 announced by BFER4, the same processing method will be used to find that BFER5 device also announced this Anycast BFR-ID, and the BFR-Prefix path cost to BFER4 and BFER5 is calculated respectively, and the path with the shortest cost is selected, and 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 that reaches all Anycast BFR-IDs is obtained, such as Figure 7 The overall process is described as follows Figure 8 As shown, the following steps are included:

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

[0098] Step S802: perform route calculation and collect BFR-Prefix of all devices that announce the same Anycast BFR-ID;

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

[0100] 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 in the BIER forwarding table;

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

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

[0103] Furthermore, in the process of routing calculation, because it has been found 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.

[0104] Embodiment 2:

[0105] For some special cases, such as BFER itself does not allocate its own BFR-ID, there is no BIER-Info sub-TLV announcement, so Anycast BFR-ID cannot be announced following BIER-Info sub-TLV. In this case, Anycast BFR-ID can be directly announced as a sub-TLV following BFR-Prefix, such as Figure 8 As shown; of course, this method is also applicable to the scenario where you want to omit the BIER-Info sub-TLV announcement for various reasons. After the Anycast BFR-ID sub-TLV, follow the announcement of MPLS encapsulation and other sub-sub-TLVs.

[0106] The notification and calculation process is also performed as described in the first embodiment.

[0107] Embodiment three:

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

[0109] Taking device BFRm as an example, it will receive the BFR-Prefix of each BFER3 / 4 / 5 / 6 device, as well as the Anycast BFR-ID sub-TLV or sub-sub-TLV it carries. The device performs routing calculation, calculates and stores the path cost to reach the BFR-Prefix of all devices, that is, stores the path cost to reach BFER3 / 4 / 5 / 6 and the next hop information, such as Fig. 9 shown.

[0110] 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-Prefix of the two devices BFER3 and BFER4 that announced 101 is obtained. At this time, directly search for Fig. 9 The stored information shown is compared to the path costs of the two BFR-Prefixes, and the next hop corresponding to the path with the smallest cost is selected and sent to the BIER forwarding table together with Anycast BFR-ID 101. The above process is repeated until a forwarding table that reaches all Anycast BFR-IDs is obtained. The overall process is described as follows Fig.10 As shown, including:

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

[0112] Step S1002: perform route calculation and store the path cost to all devices BFR-Prefix;

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

[0114] 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 smallest 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;

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

[0116] Embodiment 4:

[0117] 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 announced by the BFER3 device and the Anycast BFR-ID and other information it carries are invalid. The other situation is that the BFR-Prefix announced by the BFER3 device and the information it carries are still valid, but there is no path to reach BFER3.

[0118] For the first case, still taking BFRm as an example, the Anycast BFR-ID announced by the BFER3 device will not be obtained, so Anycast BFR-ID 101 will only be obtained from the BFER4 device, so 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 this, so the traffic sent to Anycast BFR-ID 101 will be forwarded to BFER4, and then forwarded to R1 by BFER4.

[0119] For the second case, still taking BFRm as an example, the Anycast BFR-ID announced by the BFER3 device will be obtained. For Anycast BFR-ID 101, the two devices BFER3 and BFER4 will still be obtained, but 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, the path to the BFR-Prefix of BFER3 cannot be found, so 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 be processed in this way, and the traffic sent to Anycast BFR-ID 101 will be forwarded to BFER4, and then forwarded to R1 by BFER4.

[0120] Embodiment five:

[0121] Based on the notification and calculation method of the embodiment of the present application, the ECMP (Equal-cost multi-path routing) function can also be easily implemented.

[0122] In some scenarios, the receiver can receive traffic from two BFER devices at the same time (but not duplicate traffic), so that the traffic can reach the two BFER devices along the ECMP path, and then both BFERs forward it to the receiver. This can avoid traffic being concentrated on one BFER device, which will cause a forwarding performance bottleneck.

[0123] like Figure 1As shown, assuming that all devices in the network choose the path to BFER4, the traffic that R1 and R2 need to receive needs to be forwarded by BFER4, but the capacity of the BFER4 device is not enough to bear so much traffic forwarding, which may cause some traffic loss. At this time, the ECMP function can be enabled in the network so that when the device is calculating, if it finds that the BFR-Prefix path costs of multiple devices that announce Anycast BFR-ID are the same, the next hops to multiple devices will be written into the BIER forwarding table. In this way, when forwarding traffic, the traffic will be distributed over multiple paths, so as to achieve the purpose of reducing the forwarding burden of a single BFER device. For example, suppose that when BFRm performs routing calculation, it is found that two devices BFER3 and BFER4 have announced Anycast BFR-ID 101. When calculating the path to the BFR-Prefix of these two devices, it is found that the costs are the same. In this way, the two next hops of the path to BFER3 and BFER4 (assuming they are BFRxa and BFRxb) can be filled into the BIER forwarding table, as shown in Fig.11 As shown in the figure, when forwarding traffic, the traffic to 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.

[0124] In summary, after adopting the notification and processing method of the real-time example of this application, 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 and reduces the difficulty of planning. It is suitable for large-scale network deployment.

[0125] Furthermore, the BIER Anycast scenario is a common scenario for the application of BIER technology, which has 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.

[0126] In the present embodiment, a message notification device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the equipment described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware is also possible and conceived.

[0127] Fig.12 is a structural block diagram of a message notification device according to an embodiment of the present application. Fig.12As shown, the message notification device includes:

[0128] The adding module 122 is used to add the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the 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;

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

[0130] In the embodiment of the present application, the Anycast BFR-ID corresponding to the dual-homing BFER device is added to the TLV field of the first notification protocol message through the above module 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: the bit index forwarding router prefix BFR-Prefix of the first BFER device, or the BFR-Prefix of the second BFER device; the second notification protocol message is notified to other devices in the domain. That is, by adding the Anycast BFR-ID corresponding to the dual-homing BFER device to the TLV field of the first notification protocol message including BFR-Prefix corresponding to the dual-homing BFER device, the second notification protocol message is obtained, and the second notification protocol message is notified to other devices in the domain, which solves the technical problem in the related art that when notifying the Anycast BFR-ID, an Anycast BFR-Prefix corresponding to one of them is required, thereby consuming a large number of IP prefixes, resulting in complex network deployment and large network resource consumption. The technical effect of saving network resources is achieved.

[0131] 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 notification protocol message when the BFR-ID of the dual-homing BFER device itself exists in the first notification protocol message, such as Figure 4 As shown; in the case where the BFR-ID of the dual-homing BFER device itself does not exist in the first notification protocol message, the Anycast BFR-ID is added to the sub-TLV field of the first notification protocol message, such as Figure 5 shown.

[0132] 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 existence or non-existence 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 AnycastBFR-ID), the BFR-ID will exist in the BIER-Info sub-TLV in the first announcement protocol message. Furthermore, in the case where 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; in the case where 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.

[0133] It should be noted that the dual-homing BFER device corresponds to the first announcement protocol message, the dual-homing BFER device includes the first BFER device and the 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 the 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, such as Figure 5 Typically, the Length value of the announced Anycast sub-sub-TLV is a fixed value, preferably 2 bytes, and if the same BFER device corresponds to two Anycast BFR-IDs (that is, included in two groups 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.

[0134] In an exemplary embodiment, the notification module 124 is also used 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 preset rules, 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.

[0135] It can be understood that the dual-homing BFER device corresponds to the same Anycast BFR-ID, and the dual-homing device includes multiple BFER devices. Therefore, the same Anycast BFR-ID corresponds to multiple BFR-Prefixes. The path costs to reach 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.

[0136] For example, Figure 1 As shown, BFER3 and BFER4 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned for this is 101; BFER4 and BFER5 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned for this is 102, and BFER5 and BFER6 BFER4 and BFER5 form a group of Anycast protection relationships, assuming that the Anycast BFR-ID value assigned for this is 103. If multicast traffic needs to be forwarded to the receiving device R1, the Anycast BFR-ID corresponding to R1 is determined, and its value is 101, and 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 the 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 the 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.

[0137] In an exemplary embodiment, the announcement module 124 is also used to determine the BFR-Prefix carried by all the 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 preset rules, 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.

[0138] Another solution for determining the next hop device in the forwarding table is: when any device among 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 any device and the BFER device that the any device can reach can be directly calculated and stored in the storage space of the any device. Then, the BFR-Prefix of multiple BFERs corresponding to each Anycast BFR-ID is determined, and the path cost of the BFR-Prefix of multiple BFERs is determined from the total path cost recorded in the storage space, and then the target cost is determined.

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

[0140] 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 there is a network failure and the forwarding table needs to be recalculated. The path cost needs 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 directly read from the storage space of this device.

[0141] In an exemplary embodiment, the notification module 124 is also used for one of the following: determining the minimum path cost among the multiple path costs, and determining the minimum path cost as the target cost; determining multiple identical path costs among the multiple path costs, and determining the multiple identical path costs as the target cost; 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 cost.

[0142] Different preset rules for calculating the target cost will eventually determine different target costs. The preset rules may be: selecting the minimum path cost; selecting the minimum path cost and the suboptimal path cost, so that when the forwarding network of 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 forwarding of the multicast traffic; selecting multiple identical path costs to achieve load sharing function, avoiding the situation where part of the multicast traffic is lost due to insufficient load capacity of a single BFER device.

[0143] In an exemplary embodiment, the notification module 124 is also used 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.

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

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

[0146] Based on the above embodiments, when the preset rule is to determine the minimum path cost and the suboptimal path cost, if the intra-domain network does not fail, then generally only the next-hop path indicated by the minimum path cost is used to forward the multicast traffic, and the next-hop device indicated by the suboptimal path cost is used as a backup forwarding device; but once the intra-domain network fails, the next-hop device indicated by the suboptimal path cost is enabled to forward the multicast traffic. The backup forwarding solution provided by the embodiment of the present application can quickly switch the forwarding device when the intra-domain network fails, avoiding the waste of resources and time caused by recalculating the next-hop device, thereby making the forwarding of multicast traffic smooth.

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

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

[0149] 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 a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, 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, a disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods of each embodiment of the present application.

[0150] 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.

[0151] 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 herein.

[0152] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

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

[0154] 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;

[0155] S2: Notify other devices in the domain of the second notification protocol message.

[0156] 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.

[0157] 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 notification protocol message, and 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: 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 notification protocol message to other devices in the domain.

[0158] 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.

[0159] 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 herein.

[0160] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that 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 executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0161] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A message notification method, characterized in that: include: 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 message notification method according to claim 1, characterized in that: 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 message notification method according to claim 1, characterized in that: 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 message notification method according to claim 1, characterized in that: 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 message notification method according to claim 3, characterized in that: 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 message notification method according to claim 3, characterized in that: 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 message notification method according to claim 6, characterized in that: 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 message notification method according to claim 6, characterized in that: 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 message notification method according to claim 6, characterized in that: 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 AnycastBFR-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, characterized in that: include: An adding module is used 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; A notification module is used to notify other devices in the domain of the second notification protocol message.

11. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, 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, characterized in that: The method comprises 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