Method and device for generating forwarding table, storage medium and electronic device

Abstract

Embodiments of the present application provide a forwarding table generation method and device, a storage medium and an electronic device, wherein the method comprises: when a target forwarding table is generated based on a received first announcement message, judging whether a second BFR-ID same as a first BFR-ID exists in a bit forwarding router identifier (BFR-ID) already existing in the target forwarding table, wherein the first announcement message is used to announce the first BFR-ID of a first BFR; in the case of determining that the second BFR-ID exists, determining a target BFR- Prefix from a first bit forwarding router prefix (BFR- Prefix) corresponding to the first BFR-ID and a second BFR- Prefix corresponding to the second BFR-ID; and generating the target forwarding table based on the target BFR- Prefix. Through the present application, the problem of unnecessary occupation of network bandwidth, excessive burden on equipment and packet loss due to excessive announcement in the related art is solved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of communications, and in particular, to a method and apparatus for generating a forwarding table, a storage medium, and an electronic device. BACKGROUND

[0002] BIER (Bit Indexed Explicit Replication, RFC8279) is a new multicast data forwarding technology, which uses only one BIT bit to represent the nodes at the edge of the network, encapsulates a specific BIER header in the intermediate network transmission, and marks all destination nodes BFER (Bit-Forwarding Egress Router) of the multicast flow in the form of a BIT bit string. The intermediate network forwarding node routes according to the bit, and guarantees that the traffic can be sent to all destination nodes. The intermediate node forwarding device forms a table for guiding BIER forwarding in advance through a routing protocol, and when receiving the encapsulated BIER header traffic, completes the forwarding of the message to the destination node according to the BIFT (Bit Index Forwarding Table). The ingress node BFIR (Bit-Forwarding Ingress Router) of the BIER domain encapsulates the multicast traffic entering the BIER domain as the payload of the BIER header, and after forwarding through the intermediate node, the egress node BFER of the BIER domain receives the BIER message, removes the BIER header, and forwards the payload to the corresponding receiver. The data plane forwarding technology of BIER eliminates the delay of multicast tree establishment, and when the network has a link or node problem, the convergence speed is lower than that of OSPF (Open Shortest Path First) or ISIS (Intermediate System-to-Intermediate System) protocol, and the delay of the original multicast tree reconstruction is greatly reduced.

[0003] For an ingress device BFIR of a BIER domain, to transmit certain multicast traffic, it needs to know which egress device BFER (Bit-Forwarding Ingress Router) of the BIER domain needs the multicast traffic, and therefore, signaling interaction needs to exist between the BFIR and the BFER, and the signaling technology of the interaction is referred to as BIER Overlay technology. A BFR (Bit-Forwarding Router) device that is only used for BIER forwarding does not need to know the multicast traffic information.

[0004] In order to construct a BIER forwarding table entry, an OSPF or ISIS protocol can support BIER information advertisement through signaling extension, and all nodes in the BIER domain can receive BIER information of other nodes and construct a BIER forwarding table entry based on the BIER information. The protocol that supports BIER information interaction through signaling extension is referred to as BIER Underlay technology.

[0005] In addition to using OSPF, ISIS and the like to advertise, the BIER underlay technology can also use BGP (Border Gateway Protocol), BABEL and the like to advertise.

[0006] In the related art, when OSPF, ISIS and the like advertise BIER information, the main content of the advertisement includes a routing prefix and a BFR-ID (BFR-Identifier) and the like. For example, according to the definition of RFC8444, OSPF increases BIER SUB-TLV to carry BFR-ID information when advertising a routing prefix. After the protocol performs routing calculation based on the prefix, a BIER forwarding table entry is correctly generated based on the two.

[0007] With the help of the flooding mechanism of the OSPF protocol, devices in the network perform routing calculation based on the received prefix information after receiving the advertisement of other devices, to generate a unicast routing table for normal forwarding, and thereby generate a BIER routing table for BIER forwarding.

[0008] It should be noted that the way of generating a routing table in the related art can cause routing leakage, and can cause routes that do not need to be completely learned by each other in different domains to be learned by devices in each domain, resulting in a huge amount of advertisement, unnecessary occupation of network bandwidth, and heavier device burden. In addition, too much advertisement can also easily cause packet loss.

[0009] In view of the above problems in the related art, no effective solution has been proposed so far. SUMMARY

[0010] Embodiments of the present application provide a forwarding table generation method and device, a storage medium and an electronic device to at least solve the problem of unnecessary network bandwidth occupation, excessive device burden and packet loss due to excessive announcement in related technologies.

[0011] According to an embodiment of the present application, a forwarding table generation method is provided, comprising: when generating a target forwarding table based on a received first announcement message, judging whether a second BFR-ID identical to a first BFR-ID exists in bit forwarding router identifiers BFR-ID already existing in the target forwarding table, wherein the first announcement message is used to announce the first BFR-ID of a first BFER; in the case of determining that the second BFR-ID exists, determining a target BFR-Prefix from a first bit forwarding router prefix BFR-Prefix corresponding to the first BFR-ID and a second BFR-Prefix corresponding to the second BFR-ID; and generating the target forwarding table based on the target BFR-Prefix.

[0012] According to another embodiment of the present application, a forwarding table generation device is provided, comprising: a judging module configured to, when generating a target forwarding table based on a received first announcement message, judge whether a second BFR-ID identical to a first BFR-ID exists in bit forwarding router identifiers BFR-ID already existing in the target forwarding table, wherein the first announcement message is used to announce the first BFR-ID of a first BFER; a determining module configured to, in the case of determining that the second BFR-ID exists, determine a target BFR-Prefix from a first bit forwarding router prefix BFR-Prefix corresponding to the first BFR-ID and a second BFR-Prefix corresponding to the second BFR-ID; and a generating module configured to generate the target forwarding table based on the target BFR-Prefix.

[0013] According to still another embodiment of the present application, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program, wherein the computer program is configured to execute the steps in the above method embodiments when running.

[0014] According to still another embodiment of the present application, an electronic device is provided, comprising a memory and a processor, the memory stores a computer program, and the processor is configured to execute the computer program to execute the steps in the above method embodiments.

[0015] By the present application, when generating the forwarding table, if there are multiple same BFR-IDs, the prefixes of the same BFR-IDs are compared, and then a more suitable prefix corresponding to the BFR-ID is determined, thereby avoiding repeated establishment of multiple forwarding entries corresponding to the same BFR-ID in the forwarding table, avoiding unnecessary occupation of network bandwidth caused by too much announcement, and avoiding the problems of excessive device burden and packet loss, thereby achieving the effects of improving network bandwidth utilization and reducing device burden. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is a network architecture in the related art Figure 1 ;

[0017] Figure 2 is a BIER forwarding representation intention on BFR1 in the related art

[0018] Figure 3 is a general forwarding representation intention in the related art

[0019] Figure 4 is a network architecture in the related art Figure 2 ;

[0020] Figure 5 is a unicast routing representation intention in the related art

[0021] Figure 6 is a BIER forwarding routing representation intention in the related art Figure 1 ;

[0022] Figure 7 is a unicast routing representation intention on BFRm of domain2 in the related art

[0023] Figure 8 is a BIER forwarding routing representation intention in the related art Figure 2 ;

[0024] Figure 9 is a hardware structure block diagram of a mobile terminal of the forwarding table generation method of the embodiment of the present application

[0025] Figure 10 is a flow chart of the forwarding table generation method according to the embodiment of the present application

[0026] Figure 11 is a domain-out SUB-SUB-TLV format diagram according to the embodiment of the present application Figure 1 ;

[0027] Figure 12 is a domain-out SUB-SUB-TLV format diagram according to the embodiment of the present application Figure 2 ;

[0028] Figure 13 is a format diagram of the SUB-SUB-TLV carrying DOMAIN-ID according to an embodiment of the present application;

[0029] Figure 14 is a format diagram of the SUB-SUB-TLV carrying DOMAIN-ID according to an embodiment of the present application Figure 1 ;

[0030] Figure 15 is a format diagram of the SUB-SUB-TLV carrying DOMAIN-ID according to an embodiment of the present application Figure 2 ;

[0031] Figure 16 is a whole flow diagram of the device generating the BIER forwarding table according to an embodiment of the present application;

[0032] Figure 17 is a unicast routing representation diagram according to a first specific embodiment of the present application;

[0033] Figure 18 is a BIER forwarding representation diagram according to the first specific embodiment of the present application;

[0034] Figure 19 is a unicast routing representation diagram according to a second specific embodiment of the present application;

[0035] Figure 20 is a BIER forwarding representation diagram according to the second specific embodiment of the present application Figure 1 ;

[0036] Figure 21 is a BIER forwarding representation diagram according to the second specific embodiment of the present application Figure 2 ;

[0037] Figure 22 is a unicast routing representation diagram according to a third specific embodiment of the present application;

[0038] Figure 23 is a network architecture diagram according to a fourth specific embodiment of the present application;

[0039] Figure 24 is a unicast routing representation diagram according to the fourth specific embodiment of the present application;

[0040] Figure 25 is a BIER forwarding representation diagram according to the fourth specific embodiment of the present application;

[0041] Figure 26 is a structure block diagram of the generating device of the forwarding table according to an embodiment of the present application. DETAILED DESCRIPTION

[0042] Firstly, the related technologies involved in the present application are described:

[0043] The existing OSPF, ISIS and other protocols expand the main contents of the announcement when announcing BIER information, including route prefix and BFR-ID, etc. For example, according to the definition of RFC8444, OSPF increases BIER SUB-TLV to carry BFR-ID information when announcing route prefix; after the protocol performs route calculation according to the prefix, the BIER forwarding table is correctly generated according to the two. Figure 1 For example, the edge devices in this network include BFIR and a plurality of BFER: BFER1 to BFERn. The edge devices announce their BFR-ID together with corresponding Sub-Domain, BFR-Prefix, etc. The prefix Prefix is usually taken from the Loopback address of the device, which is used to uniquely identify a device in the network; in the same domain, BFR-ID and BFR-Prefix (BFR-Prefix is the Loopback prefix address of the device) are one-to-one corresponding. Assuming that OSPF protocol announces according to RFC8444, BFR-Prefix is announced through OSPF Extended Prefix TLV, and BIER SUB-TLV is added under this prefix to carry Sub-Domain-ID, BFR-ID, etc. The intermediate device BFR of the network also announces according to this protocol extension, but because the intermediate device BFR does not allocate BFR-ID, the announced BFR-ID is 0. Figure 1 In the example of , it is assumed that the BFR-ID of BFIR1 is 100, and the BFR-Prefix is P100; the BFR-ID of BFER1 is 1, and the BFR-Prefix is P1; the BFR-ID of BFER2 is 2, and the BFR-Prefix is P2; and so on. It is assumed that these BFR-IDs are all in Sub-Domain 0.

[0044] With the flooding mechanism of the OSPF protocol, the devices in the network perform route calculation according to the received prefix information after receiving the announcement of other devices, to generate unicast routing table for ordinary forwarding, and then generate BIER routing table for BIER forwarding; as described in RFC8279, the BIER forwarding table is indexed by BFR-ID, and contains BFR-prefix and next-hop neighbor BFR-NBR. For example: Figure 2 is the BIER forwarding table on BFR1. Before generating this table, BFR1 first needs to generate Figure 3The common forwarding table shown, which is used for unicast routing forwarding, is generated with prefixes as indexes. For example, for the prefix P1 announced by BFER1, it is calculated that the next hop device of the route is BFR2, and then the BIER SUB-TLV carried in the announcement TLV corresponding to the route is taken out, and the BFR-ID value contained therein is taken as an index to be added to the BIER forwarding table. In this way, the forwarding table of Figure 2 .

[0045] When a BIER domain is composed of multiple IGP domains or AS domains (here, the domain is not the same as the sub-domain mentioned above in the BIER announcement), as shown in the network of Figure 4 , the BIER domain is composed of three domains, and in each domain, a protocol such as OSPF, ISIS, BGP, etc. is run. The protocols run in the domains can be the same or different. For example, BGP protocol can be run in domain1, and OSPF protocol can be run in domain2 and domain3; or OSPF protocol can be run in domain1, BGP protocol can be run in domain2, and ISIS protocol can be run in domain3, etc. The protocol announcement range in each domain is only in the domain. It is assumed that multicast traffic needs to be sent from BFIR1 to BFER1-6, and the device needs to establish a forwarding table that can reach the receivers in other domains in addition to the forwarding table in its own domain.

[0046] The border device of the domain, such as Figure 4BR1~4 need to transmit the BFR-ID information in different domains as a bridge, for example, BR1 / 2 need to announce the BFR-ID of BFER1 and BFER2 in domain2 to domain1, the BFR-ID of BFER3 and BFER4 in domain3 received from BR3 / 4, and the BFR-ID of BFER5 and BFER6 in domain1 to domain2; similarly, BR3 / 4 need to announce the BFR-ID of BFER3 and BFER4 in domain3 to domain1, the BFR-ID of BFER1 and BFER2 in domain2 received from BR1 / 2, and the BFR-ID of BFER5 and BFER6 in domain1 to domain3. In order to achieve this purpose, one implementation of the method is to directly announce the prefix of BFIR / BFER, that is, its loopback address, on the border device of the domain, that is, BR1 / 2 directly announces the BFR-Prefix of BFER1 and its BFR-ID, the BFR-Prefix of BFER2 and its BFR-ID in domain2 to domain1; directly announces the BFR-Prefix of BFER5 and its BFR-ID, the BFR-Prefix of BFER6 and its BFR-ID, the BFR-Prefix of BFIR1 and its BFR-ID in domain1 to domain2; directly announces the BFR-Prefix of BFER3 and its BFR-ID, the BFR-Prefix of BFER4 and its BFR-ID obtained from BR3 / 4 to domain2; and so on, so that in each domain, in addition to the information of the local domain BFER1 and BFER2, the BFR-Prefix and the BFR-ID of the BFER device in other domains can also be received. Taking BFR1 as an example, the unicast routing table of Figure 5 can be calculated, and the BIER forwarding routing table of Figure 6 is generated thereby; similarly, the unicast routing table on the BFRm of domain2 is as shown in Figure 7 , and the BIER forwarding routing table is as shown in Figure 8 .

[0047] The advantage of this method is its simplicity and directness, but its disadvantages are also obvious. First, it introduces route leakage between domains. For example, the prefixes of two BFR devices in domain2 exist in both domain1 and domain3, meaning that routes across different domains do not necessarily need to be fully learned from each other. Second, if the number of BFIR / BFER devices is very large, the device load becomes very heavy. Assuming each domain has 200 edge devices, the BFR-Prefix and BFR-ID of a total of 600 edge devices across three domains will be advertised in every domain. This huge amount of advertising not only consumes network bandwidth and affects all devices (e.g., flooding of OSPF and ISIS devices), but also places a significant burden on device computation, as each device must first calculate 600 unicast routes to generate the BIER forwarding table for forwarding. Specifically, BR1-4, acting as bridges, must advertise all BFR-Prefixes and their corresponding BFR-IDs, and their excessive advertising volume can easily lead to packet loss and other problems.

[0048] To address the aforementioned problems, this invention proposes a method for generating a forwarding table. The embodiments of this invention will be described in detail below with reference to the accompanying drawings and examples.

[0049] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0050] The methods and embodiments provided in this application can be executed in a mobile terminal, router or switch, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 9 This is a hardware structure block diagram of a mobile terminal for a method of generating a forwarding table according to an embodiment of the present invention. Figure 9 As shown, a mobile terminal may include one or more ( Figure 9 Only one is shown in the diagram. A processor 902 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 904 for storing data are also shown. The mobile terminal may further include a transmission device 906 for communication functions and an input / output device 908. Those skilled in the art will understand that... Figure 9 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 9 The more or fewer components shown, or having the same Figure 9 The different configurations shown.

[0051] The memory 904 can be used to store computer programs, such as software programs of application software and modules, for example, a computer program corresponding to the method for generating a forwarding table in the embodiments of the present application. The processor 902 can execute various functional applications and data processing, i.e., implement the above method, by running the computer program stored in the memory 904. The memory 904 can include a high-speed random access memory, and can further include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 904 can further include a memory remotely arranged with respect to the processor 902, which can be connected to the mobile terminal through a network. Examples of the above network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0052] The transmission device 906 is configured to receive or send data via a network. Specific examples of the above network can include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device 906 includes a network adapter (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 906 can be a radio frequency (RF) module, which is configured to communicate with the Internet in a wireless manner.

[0053] In the present embodiment, a method for generating a forwarding table, which can be but is not limited to running in the above terminal, is provided, Figure 10 is a flowchart of the method for generating a forwarding table according to the embodiments of the present application, as shown in Figure 10 , the flowchart includes the following steps:

[0054] In step S1002, when generating a target forwarding table based on a received first notification message, it is determined whether a second BFR-ID identical to a first BFR-ID exists in a bit forwarding router identifier (BFR-ID) already existing in the target forwarding table, wherein the first notification message is used to notify the first BFR-ID of a first BFR.

[0055] In step S1004, when it is determined that the second BFR-ID exists, a target BFR-Prefix is determined from a first bit forwarding router prefix (BFR-Prefix) corresponding to the first BFR-ID and a second BFR-Prefix corresponding to the second BFR-ID.

[0056] In step S1006, the target forwarding table is generated based on the target BFR-Prefix.

[0057] The execution subject of the above steps can be a BFR device in a BIER domain, of course, can also be other devices in the BIER domain, or can also be a processor independent of the above BFR device, or can also be other processing devices with similar processing capabilities, and the like.

[0058] In the above embodiment, if there is no BFR-ID entry identical to the first BFR-ID, an entry corresponding to the first BFR-ID is directly added to the forwarding table, and the corresponding prefix and next hop are filled in. If there is an entry identical to the BFR-ID, the final routing prefix needs to be determined from the routing prefixes corresponding to the multiple identical BFR-IDs, and then the entry in the forwarding table is adjusted based on the final routing prefix. It should be noted that if the final determined routing prefix is the routing prefix corresponding to the second BFR-ID, there is no need to adjust the entry in the forwarding table. If the final determined routing prefix is the routing prefix corresponding to the first BFR-ID, the routing prefix and next hop corresponding to the first BFR-ID in the forwarding table need to be updated to the routing prefix and next hop corresponding to the first BFR-ID.

[0059] Through the above embodiment, when generating the forwarding table, if there are multiple identical BFR-IDs, the prefixes of the identical BFR-IDs are compared, and then a more suitable prefix corresponding to the BFR-ID is determined, so as to avoid repeatedly establishing multiple forwarding entries corresponding to the same BFR-ID in the forwarding table, avoid unnecessary occupation of network bandwidth caused by too much announcement, and avoid the problem of excessive device burden and packet loss, thereby achieving the effect of improving network bandwidth utilization and reducing device burden.

[0060] In an optional embodiment, when the target BFR-Prefix is determined from the BFR-Prefixes corresponding to the multiple identical BFR-IDs, the target BFR-Prefix can be determined comprehensively based on the contents contained in the BFR-Prefixes corresponding to the BFR-IDs. The following describes how to comprehensively determine the target BFR-Prefix:

[0061] Determination mode one:

[0062] The first content included in the first BFR-Prefix is compared with the second content included in the second BFR-Prefix. In a case where it is determined that the first content is more detailed than the second content, the first BFR-Prefix is determined as the target BFR-Prefix. In a case where it is determined that the second content is more detailed than the first content, the second BFR-Prefix is determined as the target BFR-Prefix.

[0063] In the determination manner, a BFR-Prefix with more detailed content is preferentially selected as the target BFR-Prefix, where the more detailed content can include more content contained in the BFR-Prefix, specifically, a longer prefix mask length of the BFR-Prefix.

[0064] Determination manner two:

[0065] The first attribute information of the first BFR-Prefix is compared with the second attribute information of the second BFR-Prefix, and in a case where it is determined that the attribute value of the first attribute information is better than the attribute value of the second attribute information, the first BFR-Prefix is determined as the target BFR-Prefix; in a case where it is determined that the attribute value of the second attribute information is better than the attribute value of the first attribute information, the second BFR-Prefix is determined as the target BFR-Prefix.

[0066] In the determination manner, the attribute information of the BFR-Prefix can include one or more of a cost attribute, a metric attribute, or other attributes of the BFR-Prefix, where a more optimal attribute value can be a smaller cost attribute value, a smaller metric attribute value, and the like.

[0067] In an optional embodiment, generating the target forwarding table based on the target BFR-Prefix includes: in a case where the target BFR-Prefix is the first BFR-Prefix, updating the second BFR-Prefix and a next hop device corresponding to the second BFR-ID that already exist in the target forwarding table to the first BFR-Prefix and a next hop device corresponding to the first BFR-Prefix; in a case where the target BFR-Prefix is the second BFR-Prefix, maintaining the second BFR-ID and the second BFR-Prefix and a next hop device corresponding to the second BFR-ID that already exist in the forwarding table unchanged. In this embodiment, in a case where it is determined that there is no need to update the existing entry of the forwarding table, the first BFR-Prefix can be discarded directly.

[0068] In an optional embodiment, in the case that the first DOMAIN-ID information of the domain where the first BFER is located is further included in the first advertisement message, after determining that a second BFR-ID same as the first BFR-ID exists in the BFR-ID already existing in the target forwarding table, the method further comprises: in the case that the BFR-Prefix corresponding to the first BFR-ID and the second BFR-ID respectively is from within the domain, performing error processing; in the case that the BFR-Prefix corresponding to the first BFR-ID and the second BFR-ID respectively is from outside the domain, determining the second DOMAIN-ID information of the domain where the second BFER is located carried in the second advertisement message used for advertising the second BFR-ID, and in the case that the first DOMAIN-ID information is different from the second DOMAIN-ID information, performing error processing. In this embodiment, in the case that the BFR-Prefix corresponding to the same BFR-ID is from different domains, it indicates that the configuration is wrong, the updating of the forwarding table needs to be stopped, and error processing is performed.

[0069] In an optional embodiment, the second advertisement message includes a second inter-domain TLV, wherein: the second inter-domain TLV carries the second BFR-ID information; or the second inter-domain TLV carries the second BFR-ID information and second DOMAIN-ID information of the domain where the second BFER is located. In this embodiment, the second inter-domain TLV is a TLV newly added in the advertisement message or a new type of TLV newly added under the original TLV, and the format of the newly added TLV is different under different protocols. For example, under the OSPF protocol, the border device uses a new inter-domain SUB-TLV or inter-domain SUB-SUB-TLV (TLV: Type, Length, Value) form to advertise the inter-domain BFR-ID.

[0070] In an optional embodiment, the second advertisement message includes the second BFR-Prefix, and the second inter-domain TLV is sent following the second BFR-Prefix, wherein the second BFR-Prefix includes one of the following: an aggregated route prefix, a default route prefix, and a BFR-Prefix of the border device. In this embodiment, the domain DOMAIN-ID information can be carried in the second advertisement message; the inter-domain SUB-TLV / inter-domain SUB-SUB-TLV can be advertised following the aggregated or default route prefix, or can be advertised following the BFR-Prefix of the border device.

[0071] In an optional embodiment, the first announcement message includes a first out-of-domain TLV, wherein: the first out-of-domain TLV carries the first BFR-ID information; or the first out-of-domain TLV carries the first BFR-ID information and first DOMAIN-ID information of the domain where the first BFR is located. In this embodiment, the first out-of-domain TLV is a TLV newly added in the announcement message or a new type of TLV newly added under the original TLV. The format of the newly added TLV is different under different protocols. For example, under the OSPF protocol, the border device announces the out-of-domain BFR-ID in the form of a new out-of-domain SUB-TLV or out-of-domain SUB-SUB-TLV (TLV: Type, Length, Value).

[0072] In an optional embodiment, the first announcement message includes the first BFR-Prefix, and the first out-of-domain TLV is sent following the first BFR-Prefix, wherein the first BFR-Prefix includes one of: an aggregated route prefix, a default route prefix, and a BFR-Prefix of the border device. In this embodiment, the first announcement message can carry DOMAIN-ID information; and the out-of-domain SUB-TLV / out-of-domain SUB-SUB-TLV can be announced following the aggregated route prefix or the default route prefix, or can be announced following the BFR-Prefix of the border device.

[0073] In an optional embodiment, the error processing includes at least one of: performing an alarm prompt to indicate that there is a problem in the current network deployment; and sending alarm information to a controller to indicate that there is a problem in the current network deployment of the controller. In this embodiment, in addition to the specific manners described above, the error processing can also be other processing manners, for example, sending error information to a specific device or sending error information to a terminal of an administrator, and the error processing manner is not limited.

[0074] The application will be described below in conjunction with an overall embodiment:

[0075] The border device announces the out-of-domain SUB-SUB-TLV, indicating the prefix to be announced, and the format is similar to Figure 11 , which lists the BFR-ID to be carried. When the BFR-ID is a set of continuous values, the format similar to Figure 12 can be used to fill in the start value and end value of the BFR-ID to be announced; and a DOMAIN-ID value can be optionally carried separately, as shown in Figure 13 . The DOMAIN-ID value can also be directly carried in the same SUB-SUB-TLV, and thus the format similar to Figure 14 andFigure 15 carried in a manner of prefix;

[0076] The overall flow of the device generating the BIER forwarding table is shown in Figure 16 , and specifically includes the following steps:

[0077] S1602, taking out the BRF-ID carried in the prefix;

[0078] S1604, when the device calculates and generates the BIER forwarding table, checking whether there is an entry of the same BFR-ID as the taken-out BRF-ID;

[0079] S1606, if there is no entry of the same BFR-ID, directly adding the entry and filling in the corresponding prefix and next hop, and turning to step S1620;

[0080] S1608, if there is an entry of the same BFR-ID, judging whether the prefix thereof is from the domain (judging whether it is carried by the BIER SUB-TLV);

[0081] S1610, if the prefix is from the domain, performing error processing, including alarm prompt or reporting to the controller;

[0082] S1612, if the prefix is from the outside of the domain, judging whether the prefixes are from different domains, and if so, executing S1610;

[0083] S1614, if the prefixes are from the same domain, comparing the prefixes corresponding to the same BFR-ID entry, selecting the next hop corresponding to the more detailed prefix, and the more detailed meaning is that the prefix mask length is longer; or comparing the cost / metric and other attributes of the prefix, selecting the more optimal (such as smaller cost / metric) prefix and the next hop corresponding thereto; this attribute can also be compared alone, i.e., after step 1612, skipping the comparison of the detailed degree of the prefix and directly comparing the cost / metric and other attributes of the prefix;

[0084] S1616, determining whether the entry in the forwarding table needs to be updated based on the comparison result, and if so, turning to S1606, otherwise, turning to S1618;

[0085] S1618, processing the next BFR-ID.

[0086] The application will be exemplarily described in combination with specific embodiments: Embodiment one:

[0088] In order to reduce the burden of the whole network device, the border device will adopt some means to reduce the number of announced prefixes when announcing BFR-ID, such as adopting aggregated routing or default routing announcement method, in which the aggregated prefix may cover one or more border device prefixes, and the default routing prefix contains all border device prefixes, so the corresponding BFR-ID will also have multiple, and the prefix is no longer one-to-one corresponding to the BFR-ID; but for the same domain, the prefix and BFR-ID are still one-to-one corresponding, so the BFR-ID announcement of other domains must be distinguished from the BFR-ID announcement in the domain; therefore, when announcing the BFR-ID of other domains, a new TLV is used to carry instead of the original BIER SUB-TLV, or a new type of SUB-SUB-TLV is added under the original BIER SUB-TLV to carry, which is referred to as domain-out SUB-SUB-TLV.

[0089] For example Figure 4 In the above, in order to reduce the number of announced prefixes and want to have certain control on the traffic, such as wanting to make the traffic sent to BFER1 pass through BR1, the border device can select to announce the BFR-ID of domain2 to domain1 on BR1, and the aggregated routing configured on BR1 (assuming the prefix is P11), assuming that P11 only contains the prefix of BFER1, so BR1 will only carry the BFR-ID 1 of BFER1 when announcing the P11 prefix; assuming that the default route (0 / 0 route, for convenience we call it P0) is configured on BR2, which contains all the routing prefixes of domain2, so BR2 will carry the BFR-ID 1 / 2 of BFER1 and BFER2 when announcing P0 to domain1. When the device in domain1 performs routing calculation, taking BFR1 as an example, unicast routes of P11 and P0 will be generated, the next hop of P11 is BR1, and the next hop of P0 is BR2, as shown in Figure 17 (simplified, other routing entries are omitted).

[0090] Next, the BIER forwarding table is calculated. It is assumed that the BFR-ID information carried by the P11 prefix is processed first. Since the BFR-ID carried by P11 is only 1, a BIER forwarding table entry with BFR-ID 1, prefix P11, and next hop BR1 is generated. When processing the default route P0, it is found that the BFR-ID carried by P0 is 1 and 2, and the BFR-ID announcements of the two prefixes are both domain-out SUB-SUB-TLV. At this time, the original processing principle cannot be directly used for processing, otherwise the BIER forwarding table entry with BFR-ID 1 will be updated to prefix P0 and next hop BR2. This cannot achieve the original control purpose. Therefore, when processing the default route P0 and finding that the BFR-ID 1 carried by P0 already exists in the BIER forwarding table, the route prefix P0 is compared with the prefix P11 in the original BFR-ID 1. It is found that P11 is more detailed (its mask length is longer), so the entry of BFR-ID 1 does not need to be updated. The finally generated BIER forwarding table is similar to that shown in Figure 18 (simplified, other entries are omitted). Specific embodiment two:

[0092] The announcement of the border device can also be further reduced in the manner of announcing the BFR-Prefix of the border device. When announcing the BFR-Prefix of the border device, the domain-out SUB-SUB-TLV can be directly carried to carry the BFR-ID of other domains. For example Figure 4 , it is assumed that the prefix of BR1 is PB1 and the prefix of BR2 is PB2. When announcing the BFR-ID of domain2 to domain1, the domain-out SUB-SUB-TLV is carried under the same prefix BFR-Prefix, in addition to the announcement of the BIER SUB-TLV in the domain. Therefore, BR1 needs to carry the domain-out SUB-SUB-TLV to carry the BFR-ID 1 / 2 of domain2 when announcing its prefix PB1. BR2 device is the same.

[0093] In this way, when the device in the domain calculates, BFR1 is still taken as an example. First, the prefix-based unicast routing table is calculated as Figure 19As shown; when generating the BIER forwarding table, first take out the BFR-ID 1 / 2 carried by the PB1 prefix, generate two BIER forwarding entries, BFR-ID is 1 and 2 respectively, the prefix is PB1, and the next hop is BR1; when processing the BFR-ID carried by PB2, it is found that there is a corresponding entry in the BIER forwarding table, and when comparing the prefixes of PB2 and PB1, it is found that the details of the two may be the same (for example, for the prefix IPv4, it is a 32-bit host route; for the prefix IPv6, it is a 128-bit host route), at this time, an ECMP (Equal-cost multipath) link can be selected to be generated directly, similar to Figure 20 As shown; or the cost / metric and other OSPF protocol attributes of the two prefixes can be compared (these attributes are announced based on other TLVs of the prefix, and do not necessarily exist in the BIER SUB-TLV or the inter-domain SUB-SUB-TLV), assuming that the cost / metric and other attributes of the prefix PB1 are better than those of the prefix PB2, then the finally generated BIER forwarding table is as shown in Figure 21 As shown. Specific embodiment three:

[0095] Deployment in the network may sometimes have problems, assuming that it is still the network of Figure 4 , assuming that because of the deployment error of the network administrator, the BFR-ID allocated to the devices BFER5 and BFER1 is 50, the BFER5 device announces its own prefix P5 and BFR-ID 50 in domain1, and the BFER1 device announces its own prefix P1 and BFR-ID 50 in domain2; when the border device BR1 announces the BFR-ID in domain2 to domain1, assume that the inter-domain SUB-SUB-TLV of the prefix PB1 of BR1 is announced; similarly, the announcement from domain1 to domain2 is similar, which will not be repeated here.

[0096] When the device performs routing calculation, still taking BFR1 as an example, BFR1 will first generate a normal unicast routing table, and the next hop to the prefix P5 and PB1 is BFER5 and BR1 respectively, as shown in Figure 22As shown; further, assuming we first extract the BIER SUB-TLV carried by the prefix P5 route, we get a BIER forwarding entry with BFR-ID 50, prefix P5, and next hop BFER5; when processing the BIER SUB-TLV and external SUB-SUB-TLV carried by the prefix PB1, we find BFR-ID 50. A search of the BIER forwarding table reveals an existing entry for this BFR-ID, and its source is an internal BIER SUB-TLV of prefix P5. This indicates an error, and we need to stop updating the BIER forwarding entry and display it via alarm or error message, or send it to the controller to indicate a network deployment problem.

[0097] It should be noted that the above embodiments use the OSPF protocol as an example. If the announcement is made via the ISIS protocol, the OSPF BIER SUB-TLV corresponds to the ISIS BIER Info SUB-TLV, and the corresponding external SUB-SUB-TLV can be added under this BIER Info SUB-TLV. If the announcement is made via the BGP protocol, the OSPF BIER TLV corresponds to the OSPF BIER TLV, and the external announcements added under this BIER TLV are in the form of external SUB-TLV. This invention does not impose specific limitations on the announcement location. Specific Implementation Example 4:

[0099] When encountering scenarios where multiple AS domains belong to the same BIER domain, such as Figure 23 In the network shown, three domains are combined into a single BIER domain, with domains 1, 2, and 3 representing three AS domains. The boundary devices between these domains run the BGP protocol. For example, BR1 / 2 of domain 1 runs with BR5 / 6 of domain 2, and BR3 / 4 of domain 1 runs with BR7 / 8 of domain 3. However, within each domain, OSPF, ISIS, or BGP may be used instead.

[0100] Assuming that the OSPF protocol is running in the domain2 and the ISIS protocol is running in the domain1, taking the border device BR5 / 6 as an example, it is assumed that the BR5 / 6 needs to publish the BFR-ID information of the BFR in the domain2 to the BR1 / 2 device, first, the BR5 obtains the BFR-ID information of the BFR1 / 2 from the OSPF protocol, follows the device prefix of itself, and publishes the information as the out-of-domain SUB-TLV under the BIER TLV, sets the next hop as itself, and sends the information to the BR1 and BR2 devices, and the BR6 device also publishes the information in the same way. After the BR1 device receives the publication of the BR5 and BR6 devices, the unicast routing table of the BR1 device is calculated in the manner similar to that in the second embodiment, as shown in Table 2, and the BIER forwarding table item is generated, assuming that the prefix metric published by the BR5 is considered to be more optimal, and the BIER forwarding table generated by the BR1 is as shown in Table 3. Figure 24 Figure 25 The BR2 device also processes in the same way, and in the process of calculating the BIER forwarding table of the BR2 device, it is considered that the prefix metric published by the BR6 is more optimal, and therefore the prefix corresponding to the BFR-ID 1 / 2 of the BR2 device is the BR6-Prefix and the next hop is the BR6.

[0101] The BR1 and BR2 devices also need to continue to publish the two BFR-IDs to the domain1, and therefore the BR1 and BR2 devices can carry the out-of-domain SUB-SUB-TLV when publishing the prefix route of itself through the ISIS protocol, so that the BFR-ID information from the domain2 is received in the domain1. The manner from the domain1 to the domain2 / 3 and from the domain3 to the domain1 is similar, and is not repeated here.

[0102] Taking the BFR1 as an example, the unicast routing table to the BR1 and BR2 is calculated first, and in the calculation of the BIER forwarding table, the manner similar to that in the second embodiment is also adopted, and when the same out-of-domain BFR-ID entries exist, the prefix with the more optimal prefix cost is selected as the prefix and the next hop is taken, or when the details of the two are consistent, the ECMP table item is formed.

[0103] Assuming that the network deployment has a problem, the BFR-ID from the domain3 to the domain1 also has a border device BFER1 same as the domain2, taking the BFR1 as an example, in the calculation of the BIER forwarding table, it is found that the entries with the same BFR-ID are obtained, and the corresponding prefixes are from the out-of-domain but from different domains, which indicates that the configuration is wrong, and the BIER forwarding entry needs to be stopped from being updated, and the problem of network deployment is displayed through the alarm or error information or is sent to the controller to prompt the problem of network deployment. ​

[0104] It should be noted that, for the sake of simplicity, the number of edge devices and intermediate devices in the figure is not large, and the number of devices in the actual network to which the application is applied is not limited. The next hop of the calculated general unicast routing table and BIER forwarding table is the actual device, and is not limited to the direct connection described in the application.

[0105] Therefore, according to the notification and calculation method of the application, the correct notification and calculation method can be provided for the deployment of BIER cross-domain, thereby avoiding the problem of BIER forwarding table item calculation error, thereby accelerating the widespread deployment of BIER technology. In addition, the underlay protocol of BIER distinguishes between intra-domain and inter-domain received BFR-ID when generating the routing table and BIER forwarding table according to the notified prefix, ensuring that the BIER forwarding table item can be correctly generated, thereby ensuring the accuracy of BIER forwarding.

[0106] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and necessary general hardware platforms, of course, it can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the application can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes a plurality of instructions for causing a terminal device (which can be a mobile phone, computer, server, or network device) to execute the method described in each embodiment of the application.

[0107] In this embodiment, a forwarding table generation device is also provided, which is used to implement the above embodiments and preferred embodiments, and will not be described again. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware or a combination of software and hardware is also possible and is contemplated.

[0108] Figure 26 is a structural block diagram of the forwarding table generation device according to the embodiment of the application, as shown in Figure 26 The device comprises:

[0109] The judging module 262 is configured to judge whether a second BFR-ID same as the first BFR-ID exists in the existing bit forwarding router identifier BFR-ID in the target forwarding table when the target forwarding table is generated based on the received first notification message, wherein the first notification message is used to notify the first BFR-ID of the first BFR.

[0110] The determining module 264 is configured to determine a target BFR-Prefix from a first BFR-Prefix corresponding to the first BFR-ID and a second BFR-Prefix corresponding to the second BFR-ID in a case where the determination exists.

[0111] The generating module 266 is configured to generate the target forwarding table based on the target BFR-Prefix.

[0112] In an optional embodiment, the determining module 264 includes:

[0113] A first comparing unit is configured to compare first content included in the first BFR-Prefix with second content included in the second BFR-Prefix.

[0114] A first determining unit is configured to determine the first BFR-Prefix as the target BFR-Prefix in a case where the first content is determined to be more detailed than the second content.

[0115] A second determining unit is configured to determine the second BFR-Prefix as the target BFR-Prefix in a case where the second content is determined to be more detailed than the first content.

[0116] In an optional embodiment, the determining module 264 includes:

[0117] A second comparing unit is configured to compare first attribute information of the first BFR-Prefix with second attribute information of the second BFR-Prefix.

[0118] A third determining unit is configured to determine the first BFR-Prefix as the target BFR-Prefix in a case where an attribute value of the first attribute information is determined to be superior to an attribute value of the second attribute information.

[0119] A fourth determining unit is configured to determine the second BFR-Prefix as the target BFR-Prefix in a case where the attribute value of the second attribute information is determined to be superior to the attribute value of the first attribute information.

[0120] In an optional embodiment, the generating module 266 includes:

[0121] updating, in a case that the target BFR-Prefix is the first BFR-Prefix, the second BFR-Prefix corresponding to the second BFR-ID and a next hop device that already exist in the target forwarding table to the first BFR-Prefix and a next hop device corresponding to the first BFR-Prefix;

[0122] maintaining, in a case that the target BFR-Prefix is the second BFR-Prefix, the second BFR-ID and the second BFR-Prefix corresponding to the second BFR-ID and a next hop device that already exist in the forwarding table unchanged.

[0123] In an optional embodiment, the method further comprises:

[0124] The first execution module is configured to, in a case that the first announcement message further comprises first domain identifier DOMAIN-ID information of a domain where the first BFER is located, after determining that the target forwarding table already contains a second BFR-ID that is the same as the first BFR-ID, and in a case that the BFR-Prefix corresponding to the first BFR-ID and the second BFR-ID respectively comes from within a domain, performing error processing.

[0125] The second execution module is configured to, in a case that the first announcement message further comprises first domain identifier DOMAIN-ID information of a domain where the first BFER is located, after determining that the target forwarding table already contains a second BFR-ID that is the same as the first BFR-ID, and in a case that the BFR-Prefix corresponding to the first BFR-ID and the second BFR-ID respectively comes from outside a domain, determining second DOMAIN-ID information of a domain where a second BFER that carries the second BFR-ID is located, and in a case that the first DOMAIN-ID information is different from the second DOMAIN-ID information, performing error processing.

[0126] In an optional embodiment, the second announcement message comprises a second inter-domain TLV, wherein: the second inter-domain TLV carries the second BFR-ID information; or the second inter-domain TLV carries the second BFR-ID information and second DOMAIN-ID information of a domain where the second BFER is located.

[0127] In an optional embodiment, the second BFR-Prefix is included in the second advertising message, and the second external-domain TLV is sent following the second BFR-Prefix, wherein the second BFR-Prefix includes one of: an aggregated route prefix, a default route prefix, or a BFR-Prefix of a border device.

[0128] In an optional embodiment, a first external-domain TLV is included in the first advertising message, wherein: the first BFR-ID information is carried in the first external-domain TLV; or the first BFR-ID information and first DOMAIN-ID information of a domain in which the first BFR is located are carried in the first external-domain TLV.

[0129] In an optional embodiment, the first BFR-Prefix is included in the first advertising message, and the first external-domain TLV is sent following the first BFR-Prefix, wherein the first BFR-Prefix includes one of: an aggregated route prefix, a default route prefix, or a BFR-Prefix of a border device.

[0130] In an optional embodiment, the first execution module and the second execution module can perform error processing in at least one of the following manners:

[0131] performing an alarm prompt to indicate that there is a problem in the current network deployment;

[0132] sending alarm information to a controller to indicate that there is a problem in the current network deployment of the controller.

[0133] It should be noted that the above various modules can be implemented by software or hardware, and for the latter, the following implementation manners can be used, but are not limited thereto: the above modules are located in the same processor; or the above various modules are located in different processors in any combination.

[0134] Embodiments of the present application also provide a computer readable storage medium, which stores a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0135] In an exemplary embodiment, the above computer readable storage medium can include, but is not limited to: a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0136] The embodiment of the present application also provides an electronic device, comprising a memory and a processor, the memory stores a computer program, and the processor is arranged to run the computer program to execute the steps in any of the above method embodiments.

[0137] In an exemplary embodiment, the electronic device described above can further comprise a transmission device connected with the processor and an input and output device connected with the processor.

[0138] The specific examples in the embodiment can refer to the examples described in the above embodiments and exemplary implementation manners, and the embodiment will not be described here again.

[0139] Obviously, those skilled in the art should understand that the modules or steps of the present application described above can be realized by general computing devices, which can be concentrated on a single computing device or distributed on a network composed of multiple computing devices, which can be realized by program codes executable by the computing devices, so that they can be stored in storage devices and executed by the computing devices, and in some cases, the steps shown or described can be executed in different order, or they can be manufactured into individual integrated circuit modules, or multiple modules or steps among them can be manufactured into a single integrated circuit module. Thus, the present application is not limited to any specific combination of hardware and software.

[0140] The above only describes the preferred embodiments of the present application and is not used to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for generating a forwarding table, characterized by, Comprise: When generating a target forwarding table based on a received first announcement message, it is determined whether a second BFR-ID same as the first BFR-ID exists in a bit forwarding router identifier BFR-ID already existing in the target forwarding table, wherein the first announcement message is used to announce the first BFR-ID of a first BFR; In the case of determining that the second BFR-ID exists, determining a target BFR-Prefix from a first bit forwarding router prefix BFR-Prefix corresponding to the first BFR-ID and a second BFR-Prefix corresponding to the second BFR-ID; Generating the target forwarding table based on the target BFR-Prefix.

2. The method of claim 1, wherein, Determining the target BFR-Prefix from the first bit forwarding router prefix BFR-Prefix corresponding to the first BFR-ID and the second BFR-Prefix corresponding to the second BFR-ID includes: Comparing first content included in the first BFR-Prefix with second content included in the second BFR-Prefix; In the case of determining that the first content is more detailed than the second content, determining the first BFR-Prefix as the target BFR-Prefix; In the case of determining that the second content is more detailed than the first content, determining the second BFR-Prefix as the target BFR-Prefix.

3. The method of claim 1, wherein, Determining the target BFR-Prefix from the first bit forwarding router prefix BFR-Prefix corresponding to the first BFR-ID and the second BFR-Prefix corresponding to the second BFR-ID includes: Comparing first attribute information of the first BFR-Prefix with second attribute information of the second BFR-Prefix; In the case of determining that the attribute value of the first attribute information is better than the attribute value of the second attribute information, determining the first BFR-Prefix as the target BFR-Prefix; In the case of determining that the attribute value of the second attribute information is better than the attribute value of the first attribute information, determining the second BFR-Prefix as the target BFR-Prefix.

4. The method of claim 1, wherein, Generating the target forwarding table based on the target BFR-Prefix includes: In the case of the target BFR-Prefix being the first BFR-Prefix, updating the second BFR-Prefix corresponding to the second BFR-ID already existing in the target forwarding table and a next hop device to the first BFR-Prefix and a next hop device corresponding to the first BFR-Prefix; In the case of the target BFR-Prefix being the second BFR-Prefix, maintaining the second BFR-ID and the second BFR-Prefix and a next hop device corresponding to the second BFR-ID already existing in the forwarding table unchanged.

5. The method of claim 1, wherein, In the case that the first DOMAIN-ID information of the domain where the first BFER is located is further included in the first advertising message, after determining that a second BFR-ID same as the first BFR-ID exists in the BFR-ID already existing in the target forwarding table, the method further comprises: In the case that the BFR-Prefix corresponding to the first BFR-ID and the second BFR-ID respectively comes from within the domain, performing error processing; In the case that the BFR-Prefix corresponding to the first BFR-ID and the second BFR-ID respectively comes from outside the domain, determining the second DOMAIN-ID information of the domain where the second BFER is located carried in the second advertising message used for advertising the second BFR-ID, and in the case that the first DOMAIN-ID information is different from the second DOMAIN-ID information, performing error processing.

6. The method of claim 5, wherein, The second inter-domain TLV includes the second BFR-ID information; or The second inter-domain TLV includes the second BFR-ID information and the second DOMAIN-ID information of the domain where the second BFER is located. The second advertising message includes the second BFR-Prefix, and the second inter-domain TLV is sent following the second BFR-Prefix, wherein the second BFR-Prefix includes one of the following: an aggregated routing prefix, a default routing prefix, and a BFR-Prefix of a border device.

7. The method of claim 6, wherein, The first advertising message includes a first inter-domain TLV, wherein:

8. The method of claim 1, wherein, The first inter-domain TLV includes the first BFR-ID information; or The first inter-domain TLV includes the first BFR-ID information and the first DOMAIN-ID information of the domain where the first BFER is located. The first advertising message includes the first BFR-Prefix, and the first inter-domain TLV is sent following the first BFR-Prefix, wherein the first BFR-Prefix includes one of the following: an aggregated routing prefix, a default routing prefix, and a BFR-Prefix of a border device.

9. The method of claim 8, wherein, The error processing comprises at least one of the following:

10. The method of claim 5, wherein, Performing an alarm prompt to prompt that there is a problem in the current network deployment; Sending alarm information to a controller to indicate that there is a problem in the current network deployment of the controller. The method comprises:

11. An apparatus for generating a forwarding table, characterized in that, a judging module configured to judge whether a second BFR-ID same as a first BFR-ID exists in the BFR-ID already existing in the target forwarding table when generating the target forwarding table based on the received first advertising message, wherein the first advertising message is used for advertising the first BFR-ID of a first BFER; ​ determining, from a first bit forwarding router prefix (BFR-Prefix) corresponding to the first BFR-ID and a second BFR-Prefix corresponding to the second BFR-ID, a target BFR-Prefix in a case of determination of existence; generating, based on the target BFR-Prefix, the target forwarding table.

12. A computer-readable storage medium, characterized in that, The computer program is stored in the computer readable storage medium, and when executed by a processor, the computer program implements the steps of the method in any one of claims 1 to 10.

13. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the method in any one of claims 1 to 10.

Images