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

Abstract

The present invention provides a method and device for generating a forwarding table, a storage medium, and an electronic device, the method including the steps of: determining whether a second BFR-ID, which is the same as a first BFR-ID, exists in a bit forwarding router identifier BFR-ID already existing in the target forwarding table when generating a target forwarding table based on a received first notification message, the first notification message notifying the first BFR-ID of a first BFER; 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, if determined to exist; and generating the target forwarding table based on the target BFR-Prefix. The present invention solves the problems of unnecessary occupation of network bandwidth, overloading of devices, and packet loss due to excessive notification amount existing in the related art.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE Embodiments of the present invention 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 technology]

[0002] BIER (Bit Indexed Explicit Replication) (RFC8279) is a new type of multicast data forwarding technology, in which each node at the edge of the network is indicated by only one BIT bit, and the multicast traffic transmitted through the intermediate network additionally packages one specific BIER header, which marks all destination nodes BFER (Bit-Forwarding Egress Router) of the multicast traffic in the form of a BIT bit string, and the intermediate network forwarding node routes based on the bit bit to ensure that the traffic can be sent to all destination nodes. The intermediate node forwarding device pre-forms a table to guide BIER forwarding through a routing protocol, and when it receives traffic that packages a BIER header, it completes the forwarding of the packet to the destination node based on the BIFT (Bit Index Forwarding Table). The ingress node BFIR (Bit-Forwarding Ingress Router) of the BIER domain packages the multicast traffic entering the BIER domain as the payload of the BIER header, and after forwarding by the intermediate nodes, the egress node BFER of the BIER domain receives the BIER packet, removes the BIER header, and forwards the payload to the corresponding receiver. Data plane forwarding technology such as BIER does not have the multicast tree establishment challenge, so it eliminates the delay of multicast tree establishment, and when a link or node failure occurs in the network, the convergence speed is the same as OSPF (Open Shortest Path First) or ISIS (Intermediate System-to-Intermediate System) protocols, reducing the huge delay compared to the re-establishment of the original multicast tree.

[0003] When an ingress device BFIR of a BIER domain wants to transmit some multicast traffic, it needs to know which egress device BFER (Bit-Forwarding Ingress Router) of the BIER domain needs this multicast traffic, so there needs to be signaling interaction between BFIR and BFER, and the signaling technology of these interactions is called BIER Overlay technology. An intermediate device BFR (Bit-Forwarding Router) used for BIER forwarding does not need to know the multicast traffic information.

[0004] To build BIER forwarding table entries, protocols such as OSPF or ISIS support BIER information notification through signaling extensions, so that all nodes in a BIER domain receive the BIER information of other nodes, and thus build BIER forwarding table entries. Protocols such as OSPF or ISIS that support BIER information interaction through extended signaling are called BIER Underlay technology.

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

[0006] In the related art, when BIER information is notified by extension in protocols such as OSPF and ISIS, the main contents of the notification include routing prefixes and BFR-ID (BFR-Identifier), etc. For example, when OSPF notifies a routing prefix based on the definition of RFC8444, it includes information such as BFR-ID by adding a BIER SUB-TLV. After the protocol performs routing calculation based on the prefix, the BIER forwarding table entry is generated accurately based on both.

[0007] Through the flooding mechanism of the OSPF protocol, after a device in a network receives notifications from other devices, it performs routing calculations based on the received prefix information to generate a unicast routing table for normal forwarding, and thereby generates a BIER routing table for BIER forwarding.

[0008] In addition, the method of generating a routing table in the related art may cause routing leakage, and routing that does not need to be completely mutually learned in different domains is learned by devices in each domain, resulting in a large amount of notifications, unnecessarily occupying network bandwidth and increasing device load. In addition, excessive notifications are likely to cause packet loss issues.

[0009] Currently, no effective solutions have been proposed for the above problems in the related art. Summary of the Invention [Problem to be solved by the invention]

[0010] An embodiment of the present invention provides a method and apparatus for generating a forwarding table, a storage medium, and an electronic device to solve at least the problems existing in the related art, such as unnecessary occupation of network bandwidth, overloading of devices, and packet loss due to excessive notification volume. [Means for solving the problem]

[0011] According to one embodiment of the present invention, there is provided a method for generating a forwarding table, the method including: a step of determining whether a second BFR-ID that is the same as a first BFR-ID exists in a bit forwarding router identifier BFR-ID already existing in the target forwarding table based on a received first notification message, the first notification message notifying the first BFR-ID of a first BFER; a step of 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 if it is determined that the target BFR-Prefix exists; and a step of generating the target forwarding table based on the target BFR-Prefix.

[0012] According to another embodiment of the present invention, a forwarding table generating device is provided, the device including: a determination module for determining whether a second BFR-ID that is the same as a first BFR-ID exists in a bit forwarding router identifier BFR-ID already existing in the target forwarding table when generating a target forwarding table based on a received first notification message, the first notification message notifying the first BFR-ID of a first BFER; a determination module configured to 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 if it is determined that the second BFR-ID exists; and a generation module configured to generate the target forwarding table based on the target BFR-Prefix.

[0013] According to yet another embodiment of the present invention there is further provided a computer readable storage medium having stored thereon a computer program, the computer program being configured to perform the steps of the method embodiments described above when executed.

[0014] According to yet another embodiment of the invention there is further provided an electronic device comprising a memory having a computer program stored therein and a processor configured to execute said computer program to implement the steps of the method embodiments described above. [Brief description of the drawings]

[0015] [Figure 1] FIG. 1 is a network architecture diagram (part 1) of a related technology. [Diagram 2] FIG. 1 is a schematic diagram of a BIER forwarding table on a BFR1 in the related art. [Diagram 3] FIG. 1 is a schematic diagram of a typical forwarding table in the related art. [Figure 4] FIG. 2 is a network architecture diagram (part 2) of the related technology. [Diagram 5] FIG. 1 is a schematic diagram of a unicast routing table in the related art. [Figure 6] FIG. 1 is a schematic diagram (part 1) of a BIER forwarding routing table in the related art. [Figure 7] FIG. 1 is a schematic diagram of a unicast routing table on a BFRm of domain 2 in the related art; [Figure 8] FIG. 2 is a schematic diagram (part 2) of a BIER forwarding routing table in the related art. [Figure 9] 1 is a block diagram of a hardware configuration of a mobile terminal for a method of generating a forwarding table according to an embodiment of the present invention. [Figure 10] 4 is a flowchart of a method for generating a forwarding table according to an embodiment of the present invention. [Figure 11] FIG. 1 is a schematic diagram (part 1) of an outer domain SUB-SUB-TLV format according to an embodiment of the present invention. [Figure 12] FIG. 2 is a schematic diagram (part 2) of an outer domain SUB-SUB-TLV format according to an embodiment of the present invention. [Figure 13]1 is a schematic diagram of a format in which an outer-domain SUB-SUB-TLV according to an embodiment of the present invention includes a DOMAIN-ID alone. [Figure 14] 1 is a schematic diagram (part 1) of a format when an extra-domain SUB-SUB-TLV according to an embodiment of the present invention includes a DOMAIN-ID. [Figure 15] 13 is a schematic diagram (part 2) of a format when an extra-domain SUB-SUB-TLV according to an embodiment of the present invention includes a DOMAIN-ID. [Figure 16] 4 is an overall flowchart of a device generating a BIER forwarding table according to an embodiment of the present invention; [Figure 17] FIG. 4 is a schematic diagram of a unicast routing table according to a first specific embodiment of the present invention. [Figure 18] FIG. 2 is a schematic diagram of a BIER forwarding table according to a specific embodiment 1 of the present invention; [Figure 19] FIG. 11 is a schematic diagram of a unicast routing table according to a specific embodiment 2 of the present invention; [Figure 20] FIG. 11 is a schematic diagram (part 1) of a BIER forwarding table according to a specific embodiment 2 of the present invention. [Figure 21] FIG. 2 is a schematic diagram (part 2) of a BIER forwarding table according to a specific embodiment 2 of the present invention. [Figure 22] FIG. 11 is a schematic diagram of a unicast routing table according to a specific embodiment 3 of the present invention. [Diagram 23] FIG. 11 is a diagram showing a network architecture according to a specific embodiment 4 of the present invention. [Figure 24] FIG. 11 is a schematic diagram of a unicast routing table according to a specific embodiment 4 of the present invention. [Diagram 25] FIG. 11 is a schematic diagram of a BIER forwarding table according to a specific embodiment 4 of the present invention; [Figure 26] 1 is a block diagram of a forwarding table generating device according to an embodiment of the present invention; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] First, a related art to the embodiment of the present invention will be described. In conventional protocols such as OSPF and ISIS, when BIER information is notified by extension, the main contents of the notification include routing prefix and BFR-ID, etc. For example, when OSPF notifies a routing prefix based on the definition of RFC8444, it includes information such as BFR-ID by adding BIER SUB-TLV. After the protocol performs routing calculation based on the prefix, the BIER forwarding table entry is accurately generated based on both. Take FIG. 1 as an example, an edge device in the network includes a BFIR and several BFERs BFER1 to BFERn, and the edge device notifies its BFR-ID, corresponding Sub-Domain, BFR-Prefix, etc. together, and the prefix Prefix is ​​usually obtained from the loopback address of the device and uniquely identifies one device in the network, and in the same domain, the BFR-ID and the BFR-Prefix (BFR-Prefix is ​​the loopback prefix address of the device) have a one-to-one correspondence. Assuming that the OSPF protocol notifies based on RFC8444, the BFR-Prefix is ​​notified by the Extended Prefix TLV of OSPF, and the BIER SUB-TLV is added to this prefix to include information such as Sub-Domain-ID and BFR-ID, and the intermediate device BFR in the network also notifies according to this protocol extension, but since the intermediate device BFR does not assign a BFR-ID, the notified BFR-ID is 0. In the example of Figure 1, it is assumed that the BFR-ID of BFIR1 is 100, its BFR-Prefix is ​​P100, the BFR-ID of BFER1 is 1, its BFR-Prefix is ​​P1, and the BFR-ID of BFER2 is 2, its BFR-Prefix is ​​P2, and by analogy, it is assumed that these BFR-IDs are all in Sub-Domain 0.

[0017] According to the flooding mechanism of the OSPF protocol, after a device in a network receives notifications from other devices, it performs routing calculations based on the received prefix information to generate a unicast routing table for normal forwarding, and then generates a BIER routing table for BIER forwarding. For example, as described in RFC8279, a BIER forwarding table is a table entry whose index is the BFR-ID and includes a BFR-prefix and a next-hop neighbor BFR-NBR. For example, FIG. 2 is the BIER forwarding table in BFR1. Before generating this table, BFR1 must first generate a normal forwarding table as shown in FIG. 3 based on the received OSPF advertisement. This table is used for unicast routing forwarding. This table is generated with a prefix as an index. For example, for prefix P1 advertised by BFER1, calculate that the next hop device corresponding to the routing is BFR2, and then take out the BIER SUB-TLV contained in the advertisement TLV corresponding to the routing, and add the BFR-ID value contained therein as an index to the BIER forwarding table. By this analogy, the forwarding table of FIG. 2 is generated.

[0018] When one BIER domain consists of multiple IGP domains or AS domains (the domain here is not the same as the Sub-Domain in the above BIER notification), as in the network shown in FIG. 4, this BIER domain consists of three domains, and in each individual domain, a protocol such as OSPF, ISIS, BGP, etc. operates, and the protocols operating in each domain may be the same or different. For example, in domain 1, the BGP protocol may operate, and in domain 2 and domain 3, the OSPF protocol may operate, or in domain 1, the OSPF protocol may operate, in domain 2, the BGP protocol may operate, and in domain 3, the ISIS protocol, etc. may operate. The protocol notification range in each domain is only in that domain. Suppose that multicast traffic needs to be sent from the BFIR1 device to BFER1-6, the device needs to create a forwarding table in its own domain, and also needs to create a forwarding table that can reach receivers in other domains.

[0019] Border devices of a domain, for example, BR1 to BR4 in FIG. 4, need to transmit BFR-ID information in different domains as bridges. For example, BR1 / 2 needs to notify domain1 of the BFR-IDs of BFER1 and BFER2 in domain2, and notify domain2 of the BFR-IDs of BFER3 and BFER4 in domain3 and the BFR-IDs of BFER5 and BFER6 in domain1 received from BR3 / 4. Similarly, BR3 / 4 needs to notify domain1 of the BFR-IDs of BFER3 and BFER4 in domain3, and notify domain3 of the BFR-IDs of BFER1 and BFER2 in domain2 and the BFR-IDs of BFER5 and BFER6 in domain1 received from BR1 / 2. To achieve this objective, the method directly notifies the prefixes of BFIR / BFER, i.e., their loopback addresses, to border devices of the domain; that is, BR1 / 2 directly notifies domain1 of the BFR-Prefix and its BFR-ID of BFER1 in domain2, the BFR-Prefix and its BFR-ID of BFER2, directly notifies domain2 of the BFR-Prefix and its BFR-ID of BFER5, the BFR-Prefix and its BFR-ID of BFER6, and the BFR-Prefix and its BFR-ID of BFIR1 in domain1, and directly notifies domain2 of the BFR-Prefix and its BFR-ID of BFER3, the BFR-Prefix and its BFR-ID of BFER4 obtained from BR3 / 4, thereby inferring that in each domain, in addition to the information of BFER1 and BFER2 in this domain, it can also receive the BFR-Prefix and its BFR-ID of BFER devices in other domains. Taking BFR1 as an example, the unicast routing table in FIG. 5 can be calculated, and the BIER forwarding routing table in FIG. 6 can be generated. Similarly, the unicast routing table on BFRm of domain2 is shown in FIG. 7, and the BIER forwarding routing table is shown in FIG. 8.

[0020] The advantages of this method are simple and direct, and the disadvantages are obvious. First, routing leakage occurs between domains. For example, the prefixes of two BFER devices in domain 2 exist in both domain 1 and domain 3. In reality, all the routings of different domains do not need to be completely mutually learned. Second, if the number of BFIR / BFER devices is very large, the load on the devices will be very large. If each domain has 200 edge devices, the BFR-Prefix and BFR-ID of 600 edge devices in the entire three domains will be notified in each domain. The large amount of notification not only occupies the network bandwidth and affects all devices (e.g., flooding of OSPF devices and ISIS devices), but also places a large load on device calculations, because each device must first calculate 600 unicast routes before it can generate a BIER forwarding table for forwarding. BR1 to BR4 as border devices need to notify all BFR-Prefixes and their corresponding BFR-IDs as bridges, and the device notification amount is too large, which is prone to problems such as packet loss.

[0021] In order to solve the above problems, an embodiment of the present invention provides a method for generating a forwarding table. Hereinafter, the embodiment of the present invention will be described in detail with reference to the drawings.

[0022] In addition, terms such as "first" and "second" in the specification, claims and drawings of the embodiments of the present invention are not necessarily used to describe a specific order or chronology, but are used to distinguish similar objects.

[0023] The embodiment of the method according to the embodiment of the present application can be realized in a mobile terminal, a router or a network switch, a computer terminal or a similar computing device. As an example of being executed on a mobile terminal, FIG. 9 is a block diagram of a hardware configuration of a mobile terminal of the method of generating a forwarding table according to the embodiment of the present invention. As shown in FIG. 9, the mobile terminal may include one or more (only one is shown in FIG. 9) processors 902 (processor 902 includes, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 904 for storing data, and the mobile terminal may further include a transmission device 906 and an input / output device 908 for communication functions. As can be understood by those skilled in the art, the structure as shown in FIG. 9 is merely schematic and does not limit the structure of the mobile terminal. For example, the mobile terminal may further include more or less components than those shown in FIG. 9, or have a different configuration than those shown in FIG. 9.

[0024] The memory 904 may store software programs and modules of application software, such as a computer program corresponding to a method for generating a forwarding table in an embodiment of the present invention, and the processor 902 executes various functional applications and data processing, i.e., realizes the above-mentioned method, by executing the computer programs stored in the memory 904. The memory 904 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some embodiments, the memory 904 may further include memories located remotely to the processor 902, and these remote memories may be connected to the mobile terminal through a network. Examples of such networks include, but are not limited to, the Internet, a corporate intranet, a local area network, a mobile communication network, and combinations thereof.

[0025] The transmission device 906 transmits and receives data through a network. An example of the network may include a wireless network provided by a carrier of the mobile terminal. In one embodiment, the transmission device 906 includes a network adapter (abbreviated as Network Interface Controller, NIC) that is connected to other network devices by a base station and can communicate with the Internet. In one embodiment, the transmission device 906 may be a radio frequency (abbreviated as RF) module that communicates with the Internet wirelessly.

[0026] In this embodiment, a method for generating a forwarding table is provided, which can be operated on the above terminal, but is not limited thereto. Figure 10 is a flowchart of the method for generating a forwarding table according to the embodiment of the present invention. As shown in Figure 10, the flow includes the following steps S1002 to S1006.

[0027] In step S1002, when generating a target forwarding table based on the received first notification message, it is determined whether a second BFR-ID that is the same as the first BFR-ID exists in the bit forwarding router identifier BFR-ID already existing in the target forwarding table, and the first notification message notifies the first BFR-ID of the first BFER.

[0028] In step S1004, if it is determined that there is, 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.

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

[0030] The entity that performs the above steps may be a BFR device within the BIER domain, or of course, may be another device within the BIER domain, may be a processor relatively independent of the BFR device, may be another processing device having similar processing capabilities, etc.

[0031] In the above embodiment, if there is no BFR-ID entry with the same BFR-ID as the first BFR-ID, add the entry corresponding to the first BFR-ID directly to the forwarding table, and fill in the corresponding prefix and next hop. If there is an entry with the same BFR-ID, it is necessary to determine the final routing prefix from the routing prefixes corresponding to the multiple same BFR-IDs, and adjust the entry in the forwarding table based on the final routing prefix. Note that if the final routing prefix is ​​the routing prefix corresponding to the second BFR-ID, it is not necessary to adjust the entry in the forwarding table, and if the final routing prefix is ​​the routing prefix corresponding to the first BFR-ID, it is necessary to update the routing prefix and next hop corresponding to the first BFR-ID in the forwarding table to the routing prefix and next hop corresponding to the first BFR-ID.

[0032] According to the above embodiment, when generating a forwarding table, if there are multiple identical BFR-IDs, the prefixes of the same BFR-ID are compared, and a more appropriate prefix corresponding to the BFR-ID is determined, thereby avoiding the repeated creation of multiple forwarding entries corresponding to the same BFR-ID in the forwarding table, and avoiding the problems of unnecessary occupation of network bandwidth, overload of devices, and packet loss due to excessive notification volume, thereby achieving the effects of improving the utilization rate of network bandwidth and reducing the load on devices.

[0033] In a preferred embodiment, when determining a target BFR-Prefix from multiple BFR-Prefixes corresponding to the same BFR-ID, the target BFR-Prefix can be determined comprehensively based on the content contained in the BFR-Prefix corresponding to each BFR-ID. The following describes how to comprehensively determine the target BFR-Prefix.

[0034] Determination method 1 A first content included in the first BFR-Prefix is ​​compared with a second content included in the second BFR-Prefix, and if 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, and if 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.

[0035] In this determination method, a BFR-Prefix with more detailed content is preferentially selected as a target BFR-Prefix, and the more detailed the content, the more content can be contained in the BFR-Prefix, specifically, the longer the mask length of the prefix of the BFR-Prefix.

[0036] Determination method 2 First attribute information of the first BFR-Prefix and second attribute information of the second BFR-Prefix are compared, and if it is determined that the attribute value of the first attribute information is superior to the attribute value of the second attribute information, the first BFR-Prefix is ​​determined as the target BFR-Prefix, and if it is determined that the attribute value of the second attribute information is superior to the attribute value of the first attribute information, the second BFR-Prefix is ​​determined as the target BFR-Prefix.

[0037] In the determination method, the attribute information of the BFR-Prefix may include one or more of a cost attribute, a metric attribute, or other attributes of the BFR-Prefix, and a better attribute value may be a smaller value of the cost attribute, a smaller value of the metric attribute, etc.

[0038] In a preferred embodiment, the step of generating the target forwarding table based on the target BFR-Prefix includes the steps of: updating the second BFR-Prefix and the next hop device corresponding to the second BFR-ID already existing in the target forwarding table to the first BFR-Prefix and the next hop device corresponding to the first BFR-Prefix when the target BFR-Prefix is ​​the first BFR-Prefix; and maintaining the second BFR-ID and the second BFR-Prefix and the next hop device corresponding to the second BFR-ID already existing in the forwarding table when the target BFR-Prefix is ​​the second BFR-Prefix. In this embodiment, if it is determined that there is no need to update the existing entry in the forwarding table, the first BFR-Prefix may be directly discarded.

[0039] In a preferred embodiment, if the first notification message further includes a first domain identifier DOMAIN-ID information of the domain where the first BFER is located, after determining that the BFR-ID already existing in the target forwarding table has a second BFR-ID that is the same as the first BFR-ID, the method includes the steps of: performing error processing when it is determined that the BFR-Prefixes corresponding to the first BFR-ID and the second BFR-ID are from within the domain; determining second DOMAIN-ID information of the domain where the second BFER is located, which is included in a second notification message for notifying the second BFR-ID, when it is determined that the BFR-Prefixes corresponding to the first BFR-ID and the second BFR-ID are both from outside the domain, and performing error processing when the first DOMAIN-ID information is different from the second DOMAIN-ID information. In this embodiment, if it is determined that the BFR-Prefixes corresponding to the same BFR-ID are from different domains, it indicates that there is a configuration error, and it is necessary to stop updating the forwarding table and perform error processing.

[0040] In a preferred embodiment, the second notification message includes a second extra-domain TLV, and the second extra-domain TLV includes the second BFR-ID information, or the second extra-domain TLV includes the second BFR-ID information and a second DOMAIN-ID information of the domain where the second BFER is located. In this embodiment, the second extra-domain TLV is a TLV added to the notification message, or a new type of TLV added to the original TLV, and the format of the added TLV is different in different protocols. For example, in the OSPF protocol, when a border device notifies an extra-domain BFR-ID, it is notified in the form of a new extra-domain SUB-TLV or extra-domain SUB-SUB-TLV (TLV: Type, Length, Value), etc.

[0041] In a preferred embodiment, the second advertisement message includes the second BFR-Prefix, and the second extra-domain TLV is sent according to the second BFR-Prefix, and the second BFR-Prefix includes one of an aggregate routing prefix, a default routing prefix, and a BFR-Prefix of a border device. In this embodiment, the second advertisement message may include domain DOMAIN-ID information, and the extra-domain SUB-TLV / extra-domain SUB-SUB-TLV may follow an aggregate or default routing prefix advertisement, or may follow a BFR-Prefix advertisement of a border device.

[0042] In a preferred embodiment, the first notification message includes a first extra-domain TLV, and the first extra-domain TLV includes the first BFR-ID information, or the first extra-domain TLV includes the first BFR-ID information and the first DOMAIN-ID information of the domain where the first BFER is located. In this embodiment, the first extra-domain TLV is a TLV added to the notification message, or a new type of TLV added to the original TLV, and the format of the added TLV is different in different protocols. For example, in the OSPF protocol, when a border device notifies an extra-domain BFR-ID, it is notified in the form of a new extra-domain SUB-TLV or extra-domain SUB-SUB-TLV (TLV: Type, Length, Value), etc.

[0043] In a preferred embodiment, the first advertisement message includes the first BFR-Prefix, and the first extra-domain TLV is sent according to the first BFR-Prefix, and the first BFR-Prefix includes one of an aggregate routing prefix, a default routing prefix, and a BFR-Prefix of a border device. In this embodiment, the first advertisement message may include domain DOMAIN-ID information, and an extra-domain SUB-TLV / extra-domain SUB-SUB-TLV may follow an aggregate or default routing prefix advertisement, or may follow a BFR-Prefix advertisement of a border device.

[0044] In a preferred embodiment, the step of performing error processing includes at least one of the following steps: performing an alarm presentation to present that there is a defect in the current network configuration; and sending alarm information to a controller to indicate that there is a defect in the current network configuration of the controller. In this embodiment, in addition to the above specific method, the error processing may be other processing methods, such as sending error notification information to a specific device or sending error notification information to a manager's terminal, and the error processing method is not limited.

[0045] Embodiments of the invention will now be described with reference to an overall embodiment. The border device may be configured to notify an extra-domain SUB-SUB-TLV to indicate the prefix following the notification, and the format may be as shown in Figure 11, which may list the included BFR-IDs; if the BFR-ID is a set of consecutive values, the format may be as shown in Figure 12, which may indicate the start and end values ​​of the notified BFR-IDs; and, at the same time, the DOMAIN-ID value may be included separately, as shown in Figure 13. The DOMAIN-ID value may be included directly in the same SUB-SUB-TLV, or may be included in the same manner as in Figures 14 and 15; The overall flow of a device generating a BIER forwarding table is shown in FIG. 16, which specifically includes the following steps S1602 to S1618.

[0046] In S1602, the BRF-ID included in the prefix is ​​extracted, In S1604, when the device calculates and generates the BIER forwarding table, it searches whether there is an entry of the BFR-ID that is the same as the retrieved BRF-ID; In S1606, if the same BFR-ID entry does not exist, the entry is directly added, the corresponding prefix and next hop are entered, and the process proceeds to step S1620. In S1608, if the same BFR-ID entry exists, it is determined whether there is a prefix from within the domain (whether it is included in the BIER SUB-TLV), In S1610, if there is a prefix from within the domain, error processing is performed, including presenting an alarm or reporting to the controller. In S1612, if the prefix is ​​from outside the domain, determine whether each prefix is ​​from a different domain, and if so, execute S1610; In S1614, if they are from the same domain, compare the prefixes corresponding to the same BFR-ID entry, and select the next hop corresponding to the more specific prefix, where the more specific means that the mask length of the prefix is ​​longer; or compare other attributes such as the cost / metric of the prefix, and select the better (e.g., smaller cost / metric) prefix and its corresponding next hop, and this attribute can also be compared alone, that is, skip comparing the specificity of the prefix after step 1612, and directly compare other attributes such as the cost / metric of the prefix; In S1616, it is determined whether the entry in the forwarding table needs to be updated based on the comparison result, and if it is determined that the entry needs to be updated, it proceeds to S1606, otherwise, it proceeds to S1618; In S1618, the next BFR-ID is processed.

[0047] Hereinafter, the present invention will be described by way of example with reference to specific examples. Specific Example 1 In order to reduce the load of devices in the entire network, when a border device notifies a BFR-ID, it uses some means to reduce the number of prefixes to be notified, for example, it uses aggregated routing or default routing notification methods, in which an aggregated prefix may cover one or more border device prefixes, and a default routing prefix includes all border device prefixes, so there are multiple corresponding BFR-IDs, and although a prefix does not correspond one-to-one to a BFR-ID, in the same domain, a prefix and a BFR-ID still correspond one-to-one, so that in this case, the BFR-ID notification of other domains must be distinguished from the BFR-ID notification within this domain. Therefore, when notifying a BFR-ID of another domain, it is included in a new TLV instead of the original BIER SUB-TLV, or in the original BIER SUB-TLV by adding a new type of SUB-SUB-TLV, which is referred to herein as an extra-domain SUB-SUB-TLV.

[0048] For example, in FIG. 4, the border device can reduce the number of advertised prefixes and exercise certain control over traffic, for example, to send traffic destined for BFER1 via BR1, when advertising domain2's BFR-ID to domain1, it can select aggregate routing (assuming that prefix is ​​P11) placed on BR1, and assuming that P11 only contains prefixes of BFER1, when BR1 advertises prefixes of P11, it only contains BFR-ID 1 of BFER1, and the default routing (0 / 0 routing, conveniently called P0) placed on BR2, assuming that it contains all routing prefixes of domain2, when BR2 advertises P0 to domain1, it contains BFR-ID 1 / 2 of BFER1 and BFER2. As shown in FIG. 17, when a device in domain1 performs routing calculation, it still takes BFR1 as an example to generate unicast routing for P11 and P0, where the next hop of P11 is BR1 and the next hop of P0 is BR2 (other routing entries are omitted for simplicity).

[0049] Next, calculate the BIER forwarding table, assume that the BFR-ID information contained in the P11 prefix is ​​processed first, since the BFR-ID contained in P11 is only 1, generate a BIER forwarding table entry with BFR-ID 1, prefix P11, and next hop BR1, and process the default routing P0, find that the BFR-IDs contained are 1 and 2, and the BFR-ID notifications of the two prefixes are both out-of-domain SUB-SUB-TLV, at this time, it cannot be directly processed according to the original processing principle, otherwise, update the entry of BFR-ID 1 in the BIER forwarding table to prefix P0, next hop BR2, which cannot achieve the original control purpose. Therefore, when processing the default routing P0 and finding that the BFR-ID1 contained therein is already present in the BIER forwarding table, it just needs to compare the routing prefix P0 with the prefix P11 in the original BFR-ID 1, and find that P11 is more specific (its mask length is longer), so there is no need to update the entry for BFR-ID 1, and thus the finally generated BIER forwarding table is as shown in FIG. 18 (other routing entries are omitted for simplicity).

[0050] Specific Example 2 The notification of the border device may further use a method of reducing the prefix of the notification, and when notifying the BFR-Prefix of the border device itself, it may directly include the extra-domain SUB-SUB-TLV to include the BFR-ID of another domain. For example, in FIG. 4, assuming that the prefix of BR1 is PB1 and the prefix of BR2 is PB2, when notifying the BFR-ID of domain2 to domain1, the same prefix BFR-Prefix needs to include the extra-domain SUB-SUB-TLV in addition to notifying the BIER SUB-TLV in this domain. Therefore, when notifying its prefix PB1, BR1 needs to include the extra-domain SUB-SUB-TLV and include the BFR-ID1 / 2 of domain2, and the same applies to the BR2 device.

[0051] In this way, when a device in the domain performs calculations, still taking BFR1 as an example, as shown in Figure 19, it first calculates a unicast routing table based on the prefix, and when generating a BIER forwarding table, it first takes out the BFR-ID1 / 2 contained in the PB1 prefix to generate two BIER forwarding entries, and the BFR-IDs are 1 and 2 respectively, the prefixes are both PB1, and the next hops are both BR1. When processing the BFR-ID contained in PB2, it finds that the corresponding entry already exists in the BIER forwarding table, and when comparing the prefixes of PB2 and PB1, it finds that the specificity of both may be the same (for example, if the prefix is ​​IPv4, both are 32-bit host routing, and if the prefix is ​​IPv6, both are 128-bit host routing). At this time, as shown in Figure 20, it uses ECMP (Equal-cost forwarding). Alternatively, the BIER forwarding table may choose to directly generate a BIER forwarding link between prefixes PB1 and PB2, or may choose to compare other OSPF protocol attributes such as cost / metric of the two prefixes (these attributes are signaled based on other TLVs of the prefixes and are not necessarily present in the BIER SUB-TLV or the outer domain SUB-SUB-TLV). Assuming that the attributes such as cost / metric of prefix PB1 are better than those of prefix PB2, the final generated BIER forwarding table is as shown in Figure 21.

[0052] Specific Example 3 In some cases, there may be an error in the configuration in the network. Assuming that the network is still in FIG. 4, and that the BFR-IDs assigned to the devices BFER5 and BFER1 are both 50 due to incorrect configuration by the network administrator, the BFER5 device advertises its prefix P5 and BFR-ID 50 in domain1, and the BFER1 device advertises its prefix P1 and BFR-ID 50 in domain2. When the border device BR1 advertises its BFR-ID in domain2 to domain1, it is assumed that it advertises it as an extra-domain SUB-SUB-TLV of BR1's prefix PB1. Similarly, the advertisement from domain1 to domain2 is similar, and the description will not be repeated here.

[0053] When a device performs routing calculation, still take BFR1 as an example, as shown in FIG. 22, BFR1 first generates a normal unicast routing table, until the next hops of prefixes P5 and PB1 are BFER5 and BR1 respectively. Suppose BFR1 first extracts a BIER SUB-TLV contained in the routing of prefix P5, and obtains a BIER forwarding entry with BFR-ID of 50, prefix P5 and next hop of BFER5. When processing the BIER SUB-TLV and extra-domain SUB-SUB-TLV contained in prefix PB1, it finds BFR-ID 50, searches the BIER forwarding table and finds that the BFR-ID entry already exists and its source is the intra-domain BIER SUB-TLV of prefix P5. At this time, it explains that an error has occurred, and needs to stop updating the BIER forwarding entry, and displays it in the form of an alarm or error information, or reports it to a controller, indicating that an error has occurred in the network configuration.

[0054] In addition, the notification in the above embodiment is taken as an example of OSPF protocol, and assuming that notification is made by ISIS protocol, the BIER SUB-TLV of the OSPF protocol corresponds to the BIER Info SUB-TLV of the ISIS protocol, and the corresponding extra-domain SUB-SUB-TLV may be added to the BIER Info SUB-TLV, and assuming that notification is made by BGP protocol, the BIER SUB-TLV of the OSPF protocol corresponds to the BIER TLV, and the extra-domain notification that may be added to the BIER TLV is the extra-domain SUB-TLV method. In the embodiment of the present invention, the notification position is not particularly limited.

[0055] Specific Example 4 When we encounter a scene where multiple AS domains are combined into one BIER domain, for example, in the network shown in Figure 23, three domains combine into one BIER domain, and domain1 / 2 / 3 represent the three AS domains, respectively. The BGP protocol runs between the border devices of each domain. For example, between BR1 / 2 in domain1 and BR5 / 6 in domain2, and between BR3 / 4 in domain1 and BR7 / 8 in domain3. However, within each domain, OSPF or ISIS protocols may be running, or similarly BGP protocols may be running.

[0056] Assuming that the OSPF protocol is configured to run in domain2 and the ISIS protocol is configured to run in domain1, and taking the border device BR5 / 6 as an example, assuming that BR5 / 6 is configured to need to distribute the BFR-ID information in domain2 to the BR1 / 2 device, first, BR5 notifies the BFR-ID information of BFER1 / 2 obtained from the OSPF protocol as an outside-domain SUB-TLV in its BIER TLV according to its own device prefix, and sends it to the BR1 and BR2 devices with itself as the next hop, and notifies the BR6 device in the same way. As shown in Figure 24, after receiving the notification from the BR5 and BR6 devices, the BR1 device calculates its own unicast routing forwarding table in the same manner as in Example 2, and generates a BIER forwarding table entry. Assuming that the metric of the prefix notified by BR5 is considered to be better, the BIER forwarding table generated by BR1 is shown in Figure 25. The same is true for the BR2 device, and in the process of calculating the BIER forwarding table, the metric of the prefix notified by BR6 may be considered to be better, so the prefix corresponding to BFR-ID1 / 2 on the BR2 device may be BR6-Prefix and next hop BR6.

[0057] BR1 and BR2 devices also need to notify these two BFR-IDs to domain1, so that BR1 and BR2 devices can include the out-of-domain SUB-SUB-TLV when notifying their own prefix routing by ISIS protocol, so that domain1 receives the BFR-ID information from domain2. The methods from domain1 to domain2 / 3 and from domain3 to domain1 are similar, and the description is omitted here.

[0058] Taking BFR1 as an example, first calculate the unicast routing table to BR1 and BR2, and then calculate the BIER forwarding table. Similarly, the same method as in Example 2 is used. If there is a BFR-ID entry outside the same domain, the prefix with the better cost is selected as the prefix and its next hop is used, or if the specificity of both is the same, an ECMP table entry is formed.

[0059] Assume that an error occurs in the network configuration. Among the BFR-IDs transmitted from domain 3 to domain 1, there is one that is the same as that of the border device BFER1 of domain 2. Taking BFR1 as an example, when calculating the BIER forwarding table, it is found that there is a same BFR-ID entry and its corresponding prefixes are both from outside the domain, but from different domains. In this case, it is also explained that a configuration error has occurred, and it is necessary to stop updating the BIER forwarding entry, and display it in the form of an alarm or error information, or report it to the controller, indicating that an error has occurred in the network configuration.

[0060] For simplicity, the number of edge devices and intermediate devices in the figure is not large, and does not limit the number of these devices in an actual network to which the embodiment of the present invention is applied. The calculated normal unicast routing table and BIER forwarding table are based on the next hop of the actual device and are not limited to the direct connection case described in the embodiment of the present invention.

[0061] Therefore, the notification and calculation method according to the embodiment of the present invention can provide an accurate notification and calculation method for cross-domain deployment of BIER, avoiding the problem of miscalculation of BIER forwarding table entries, and accelerating the widespread deployment of BIER technology. In addition, the BIER underlay protocol clearly distinguishes between receiving BFR-IDs within a domain and between domains when calculating and generating a routing table and a BIER forwarding table based on notification prefixes, ensuring that BIER forwarding table entries can be generated accurately and there is no error in BIER forwarding.

[0062] From the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be realized by combining software with a required general-purpose hardware platform, and of course can be realized by hardware, and in many cases, the former is a preferred embodiment. Based on this understanding, the substance of the technical solutions of the embodiments of the present invention or the contributions to the prior art are embodied in the form of a software product, and the computer software product is stored in a storage medium (e.g., ROM / RAM, magnetic disk, optical disk) and includes several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, a network device, etc.) to execute the methods described in each embodiment of the present invention.

[0063] In this embodiment, a forwarding table generating device is further provided, which is configured to realize the above embodiment and preferred embodiment, and the description of what has already been described is omitted. The term "module" used below can realize a combination of software and / or hardware of a certain function. The device described in the following embodiment is preferably realized in software, but may also be realized in hardware or a combination of software and hardware.

[0064] FIG. 26 is a block diagram of a forwarding table generating device according to an embodiment of the present invention. As shown in FIG. 26, the device includes: A determination module 262, which determines whether a second BFR-ID that is the same as a first BFR-ID exists in the bit forwarding router identifier BFR-ID already existing in the target forwarding table when generating the target forwarding table based on the received first notification message, the first notification message notifying the first BFR-ID of the first BFER; if so, a determination module 264 configured to 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 266 configured to generate the target forwarding table based on the target BFR-Prefix.

[0065] In a preferred embodiment, the determination module 264: A first comparison unit configured to compare a first content included in the first BFR-Prefix with a second content included in the second BFR-Prefix; a first determination unit configured to determine the first BFR-Prefix as the target BFR-Prefix when determining that the first content is more specific than the second content; and a second determining unit configured to determine the second BFR-Prefix as the target BFR-Prefix if it determines that the second content is more specific than the first content.

[0066] In a preferred embodiment, the determination module 264: A second comparison unit configured to compare first attribute information of the first BFR-Prefix with second attribute information of the second BFR-Prefix; a third determination unit configured to determine the first BFR-Prefix as the target BFR-Prefix when determining that an attribute value of the first attribute information is superior to an attribute value of the second attribute information; and a fourth determining unit configured to determine the second BFR-Prefix as the target BFR-Prefix when determining that an attribute value of the second attribute information is superior to an attribute value of the first attribute information.

[0067] In a preferred embodiment, the generating module 266 comprises: an update module configured to update the second BFR-Prefix and a next hop device corresponding to the second BFR-ID already present in the target forwarding table to the first BFR-Prefix and a next hop device corresponding to the first BFR-Prefix when the target BFR-Prefix is ​​the first BFR-Prefix; and a maintenance module configured to maintain, if the target BFR-Prefix is ​​the second BFR-Prefix, the second BFR-ID, the second BFR-Prefix corresponding to the second BFR-ID, and a next hop device already present in the forwarding table.

[0068] In a preferred embodiment, the device comprises: a first execution module configured to perform error processing when the first notification message further includes a first domain identifier DOMAIN-ID information of the domain in which the first BFER is located, and then determine that a second BFR-ID identical to the first BFR-ID exists in the BFR-ID already existing in the target forwarding table, and determine that the BFR-Prefix corresponding to the first BFR-ID and the second BFR-ID respectively is from within the domain; and a second execution module configured to, when the first notification message further includes first domain identifier DOMAIN-ID information of the domain in which the first BFER is located, determine that a second BFR-ID identical to the first BFR-ID exists in the BFR-ID already existing in the target forwarding table, and then determine that both BFR-Prefixes corresponding to the first BFR-ID and the second BFR-ID are from outside the domain, determine second DOMAIN-ID information of the domain in which the second BFER is located, which is included in a second notification message for notifying the second BFR-ID, and perform error processing if the first DOMAIN-ID information is different from the second DOMAIN-ID information.

[0069] In a preferred embodiment, the second notification message includes a second outer domain TLV, which includes the second BFR-ID information, or the second outer domain TLV includes the second BFR-ID information and a second DOMAIN-ID information of the domain in which the second BFER is located.

[0070] In a preferred embodiment, the second notification message includes the second BFR-Prefix, and the second outer-domain TLV is sent according to the second BFR-Prefix, and the second BFR-Prefix includes one of an aggregate routing prefix, a default routing prefix, and a BFR-Prefix of a border device.

[0071] In a preferred embodiment, the first notification message includes a first outside-domain TLV, and the first outside-domain TLV includes the first BFR-ID information, or the first outside-domain TLV includes the first BFR-ID information and first DOMAIN-ID information of the domain in which the first BFER is located.

[0072] In a preferred embodiment, the first notification message includes the first BFR-Prefix, and the first outer-domain TLV is sent according to the first BFR-Prefix, and the first BFR-Prefix includes one of an aggregate routing prefix, a default routing prefix, and a BFR-Prefix of a border device.

[0073] In a preferred embodiment, the first execution module and the second execution module each include: Executing an alarm notification to indicate that the current network configuration is defective; and sending alarm information to a controller to indicate that there is a deficiency in the current network configuration of the controller, thereby performing error handling.

[0074] Each of the above modules can be realized by software or hardware. In the latter case, the modules can be realized in a manner in which all of the above modules are located on the same processor, or in a manner in which each of the above modules is located on different processors in any combination, but is not limited to these.

[0075] In an embodiment of the present invention, there is further provided a computer readable storage medium having stored thereon a computer program, the computer program being configured, when executed, to perform the steps of any of the method embodiments described above.

[0076] In one exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB disk, a Read-Only Memory (abbreviated as ROM), a Random Access Memory (abbreviated as RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0077] In an embodiment of the present invention, there is further provided an electronic device comprising a memory having a computer program stored therein, and a processor configured to execute the computer program to perform the steps of any of the method embodiments described above.

[0078] In an exemplary embodiment, the electronic device may further include a transmission device coupled to the processor and an input / output device coupled to the processor.

[0079] For specific examples of this embodiment, reference can be made to the examples described in the above embodiments and exemplary embodiments, so repeated explanations of this embodiment will be omitted here.

[0080] Obviously, those skilled in the art should understand that each module or each step in the above-described embodiments of the present invention may be implemented in a general-purpose computing device, may be centralized in a single computing device, or may be distributed across a network of multiple computing devices, may be implemented in program code executable by a computing device, may be stored in a storage device and executed by a computing device, and may in some cases execute the steps illustrated or described in the specification in a different order than in the specification, or may be implemented by forming each of them into an integrated circuit module, or may implement multiple modules or steps among them into a single integrated circuit. Thus, the embodiments of the present invention are not limited to any specific combination of hardware and software.

[0081] The above is only a preferred embodiment of the present invention, and is not intended to limit the present invention, and those skilled in the art may make various modifications and changes to the embodiments of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the principles of the embodiments of the present invention should be included within the protection scope of the embodiments of the present invention.

Claims

1. A step of determining whether a second BFR-ID that is the same as a first BFR-ID exists in the bit forwarding router identifier BFR-ID already existing in the target forwarding table when generating a target forwarding table based on a received first notification message, the first notification message notifying the first BFR-ID of a first BFER; if so, 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. 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, comparing a first content included in the first BFR-Prefix with a second content included in the second BFR-Prefix; determining the first BFR-Prefix as the target BFR-Prefix if the first content is determined to be more detailed than the second content; and if the second content is determined to be more detailed than the first content, determining the second BFR-Prefix as the target BFR-Prefix.

3. 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, comparing first attribute information of the first BFR-Prefix with second attribute information of the second BFR-Prefix; determining the first BFR-Prefix as the target BFR-Prefix when it is determined that the attribute value of the first attribute information is superior to the attribute value of the second attribute information; The method of claim 1 , further comprising: if it is determined that the attribute value of the second attribute information is superior to the attribute value of the first attribute information, determining the second BFR-Prefix as the target BFR-Prefix.

4. The step of generating the target forwarding table based on the target BFR-Prefix includes: If 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 already present in the target forwarding table to the first BFR-Prefix and a next hop device corresponding to the first BFR-Prefix; and if the target BFR-Prefix is ​​the second BFR-Prefix, maintaining the second BFR-ID and the second BFR-Prefix and next hop device corresponding to the second BFR-ID already present in the forwarding table as they are.

5. If the first notification message further includes a first domain identifier DOMAIN-ID information of a domain in which the first BFER is located, after determining that a second BFR-ID that is the same as the first BFR-ID exists in the BFR-IDs already existing in the target forwarding table, the method further comprises: performing an error process if it is determined that the BFR-Prefixes corresponding to the first BFR-ID and the second BFR-ID, respectively, are from within the domain; 2. The method of claim 1, further comprising: if it is determined that both the BFR-Prefixes corresponding to the first BFR-ID and the second BFR-ID are from outside the domain, determining second DOMAIN-ID information of the domain in which the second BFR is located, which is included in a second notification message for notifying the second BFR-ID, and performing error processing if the first DOMAIN-ID information is different from the second DOMAIN-ID information.

6. The second notification message includes a second outer domain TLV; The second outer domain TLV includes the second BFR-ID information; or The method of claim 5 , wherein the second outer domain TLV includes the second BFR-ID information and a second DOMAIN-ID information of a domain in which the second BFR is located.

7. 7. The method of claim 6, wherein the second notification message includes the second BFR-Prefix, and the second extra-domain TLV is sent according to the second BFR-Prefix, and the second BFR-Prefix includes one of an aggregate routing prefix, a default routing prefix, and a BFR-Prefix of a border device.

8. The first notification message includes a first outer domain TLV; The first outer domain TLV includes the first BFR-ID information, or The method of claim 1 , wherein the first outer domain TLV includes the first BFR-ID information and a first DOMAIN-ID information of a domain in which the first BFR is located.

9. 9. The method of claim 8, wherein the first notification message includes the first BFR-Prefix, and the first extra-domain TLV is sent according to the first BFR-Prefix, and the first BFR-Prefix includes one of an aggregate routing prefix, a default routing prefix, and a BFR-Prefix of a border device.

10. The step of performing error processing includes: performing an alarm indication to indicate that the current network configuration is defective; and c) sending alarm information to a controller indicating that a current network deployment of said controller is deficient.

11. a determination module for determining whether a second BFR-ID that is the same as a first BFR-ID exists in a bit forwarding router identifier BFR-ID already existing in the target forwarding table when generating a target forwarding table based on a received first notification message, the first notification message notifying the first BFR-ID of a first BFER; if so, a determination module configured to 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; a generating module configured to generate the target forwarding table based on the target BFR-Prefix.

12. A computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 10.

13. 11. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the method according to any one of claims 1 to 10 when executing the computer program.

Images