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 INVENTION Embodiments of the present invention relate to the field of communications, and more particularly 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 multicast data forwarding technology. Each network edge node is designated by only one BIT bit. When multicast traffic is transmitted through an intermediate network, a specific BIER header is additionally packaged. This packet header marks all destination nodes (BFERs) of the multicast traffic in the form of a BIT bit string. Intermediate network forwarding nodes route traffic based on the BIT bit to ensure that the traffic can be delivered to all destination nodes. Intermediate node forwarding devices pre-form a table to guide BIER forwarding through a routing protocol. Upon receiving traffic packaged with a BIER header, they complete the forwarding of the packet to the destination node based on the BIFT (Bit Index Forwarding Table). The ingress node of the BIER domain, the Bit-Forwarding Ingress Router (BFIR), packages multicast traffic entering the BIER domain as the payload of a BIER header. After forwarding by intermediate nodes, the egress node of the BIER domain, the BFIR, receives the BIER packet, removes the BIER header, and forwards the payload to the corresponding receiver. Data plane forwarding technologies such as BIER eliminate the multicast tree establishment issue, eliminating the delay of multicast tree establishment. When a link or node failure occurs in the network, the convergence speed is the same as that of Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (ISIS) protocols, reducing the huge delay compared to re-establishing the original multicast tree.

[0003] When a BFIR (Bit-Forwarding Ingress Router) in a BIER domain wants to transmit multicast traffic, it needs to know which BFER (Bit-Forwarding Ingress Router) in the BIER domain needs this multicast traffic. Therefore, signaling interaction between the BFIR and the BFER is required. The signaling technology for these interactions is called BIER Overlay technology. An intermediate BFR (Bit-Forwarding Router) device simply 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, allowing all nodes in a BIER domain to receive the BIER information of other nodes and build BIER forwarding table entries accordingly. 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 related art, when protocols such as OSPF and ISIS notify BIER information by extension, the main contents of the notification include a routing prefix and BFR-ID (BFR-Identifier), etc. For example, when OSPF notifies a routing prefix based on the definition of RFC8444, it adds a BIER SUB-TLV to include information such as BFR-ID. After the protocol performs routing calculation based on the prefix, the BIER forwarding table entry is accurately generated based on both.

[0007] Through the flooding mechanism of the OSPF protocol, after a device in the 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 routing tables in related technologies may cause routing information leakage, and routing information that does not need to be fully learned by different domains is learned by devices in each domain, resulting in a large amount of notification, unnecessarily occupying network bandwidth and increasing device load.In addition, excessive notification volume is likely to cause packet loss issues.

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

[0010] The embodiments of the present invention provide a method and apparatus for generating a forwarding table, a storage medium, and an electronic device to solve at least the problems present in the related art of 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: when generating a target forwarding table based on a received first notification message, a step of determining whether a second BFR-ID that is the same as a first BFR-ID exists among the bit forwarding router identifiers BFR-IDs already present in the target forwarding table, the first notification message notifying the first BFR-ID of a first BFER; if it is determined that a second BFR-ID exists, 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; and a step of generating the target forwarding table based on the target BFR-Prefix.

[0012] According to another embodiment of the present invention, there is provided a forwarding table generation device including: a determination module that, when generating a target forwarding table based on a received first notification message, determines whether a second BFR-ID that is the same as a first BFR-ID exists among the bit forwarding router identifiers BFR-IDs already present in the target forwarding table, 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 a target BFR-Prefix 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 the computer program is executed.

[0014] According to yet another 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 said computer program to implement the steps of the method embodiments described above. [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 is a network architecture diagram (part 1) of a related technology. [Figure 2] FIG. 1 is a schematic diagram of a BIER forwarding table on a BFR1 in the related art. [Figure 3] FIG. 1 is a schematic diagram of a general forwarding table in the related art. [Figure 4] This is a network architecture diagram (part 2) of the related technology. [Figure 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] FIG. 2 is a block diagram of the 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] 1 is a schematic diagram (part 1) of an extra-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 extra-domain SUB-SUB-TLV format according to an embodiment of the present invention. [Figure 13]10 is a schematic diagram of a format in which an extra-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] 10 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] 1 is an overall flowchart illustrating a device generating a BIER forwarding table according to an embodiment of the present invention. [Figure 17] FIG. 3 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. 10 is a schematic diagram of a unicast routing table according to a specific embodiment 2 of the present invention. [Figure 20] FIG. 10 is a schematic diagram (part 1) of a BIER forwarding table according to a specific embodiment 2 of the present invention. [Figure 21] FIG. 10 is a second schematic diagram of a BIER forwarding table according to a specific embodiment 2 of the present invention. [Figure 22] FIG. 10 is a schematic diagram of a unicast routing table according to a specific embodiment 3 of the present invention. [Figure 23] FIG. 10 is a diagram illustrating a network architecture according to a specific fourth embodiment of the present invention. [Figure 24] FIG. 10 is a schematic diagram of a unicast routing table according to a specific embodiment 4 of the present invention. [Figure 25] FIG. 10 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 generation device according to an embodiment of the present invention; DETAILED DESCRIPTION OF THE INVENTION

[0016] First, the 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 a routing prefix and a BFR-ID. For example, when OSPF notifies a routing prefix based on the definition of RFC8444, it adds a BIER SUB-TLV to include information such as a BFR-ID. After the protocol performs routing calculation based on the prefix, a BIER forwarding table entry is accurately generated based on both. Taking FIG. 1 as an example, an edge device in the network includes a BFIR and several BFERS, BFER1 to BFERn. The edge device notifies its BFR-ID, corresponding sub-domain, BFR-Prefix, etc. The prefix is ​​usually derived from the device's loopback address and uniquely identifies a device in the network. In the same domain, there is a one-to-one correspondence between the BFR-ID and the BFR-Prefix (the BFR-Prefix is ​​the device's loopback prefix address). Assuming that the OSPF protocol is notified based on RFC8444, the BFR-Prefix is ​​notified using the OSPF Extended Prefix TLV, and the BIER SUB-TLV is added to this prefix to include information such as Sub-Domain-ID and BFR-ID. The BFRs in the network intermediate devices also notify according to this protocol extension, but because the BFRs in the intermediate devices do not assign BFR-IDs, the notified BFR-ID is 0. In the example of Figure 1, assume that BFIR1's BFR-ID is 100 and its BFR-Prefix is ​​P100, BFER1's BFR-ID is 1 and its BFR-Prefix is ​​P1, and BFER2's BFR-ID is 2 and its BFR-Prefix is ​​P2. By analogy, assume 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, the BIER forwarding table is a table entry whose index is the BFR-ID and includes the BFR-prefix and the next-hop neighbor BFR-NBR. For example, Figure 2 shows the BIER forwarding table in BFR1. Before generating this table, BFR1 must first generate a normal forwarding table as shown in Figure 3 based on the received OSPF notification. This table is used for unicast routing forwarding. This table is generated using prefixes as indexes. For example, for prefix P1 notified by BFR1, it calculates that the next-hop device corresponding to this routing is BFR2. Then, it extracts the BIER SUB-TLV contained in the notification TLV corresponding to this routing, and adds the BFR-ID value contained therein as an index to the BIER forwarding table. By this analogy, the forwarding table in Figure 2 is generated.

[0018] When a BIER domain consists of multiple IGP domains or AS domains (the term "domain" here is not the same as the "sub-domain" used in the BIER notification), as in the network shown in Figure 4, this BIER domain consists of three domains, and protocols such as OSPF, ISIS, and BGP operate in each domain. The protocols operating in each domain may be the same or different. For example, the BGP protocol may operate in domain 1, and the OSPF protocol may operate in domain 2 and domain 3, or the OSPF protocol may operate in domain 1, the BGP protocol may operate in domain 2, and the ISIS protocol may operate in domain 3. The protocol notification scope within each domain is limited to that domain. Assume that multicast traffic needs to be sent from device BFIR1 to BFER1-6. In addition to creating a forwarding table within its own domain, the device also needs to create a forwarding table that can reach receivers in other domains.

[0019] Border devices of domains, for example, BR1 to BR4 in Figure 4, need to transmit BFR-ID information in different domains as bridges. For example, BR1 / 2 needs to notify domain 1 of the BFR-IDs of BFER1 and BFER2 in domain 2, and notify domain 2 of the BFR-IDs of BFER3 and BFER4 in domain 3 and the BFR-IDs of BFER5 and BFER6 in domain 1 received from BR3 / 4. Similarly, BR3 / 4 needs to notify domain 1 of the BFR-IDs of BFER3 and BFER4 in domain 3, and notify domain 3 of the BFR-IDs of BFER1 and BFER2 in domain 2 and the BFR-IDs of BFER5 and BFER6 in domain 1 received from BR1 / 2. To achieve this goal, this 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 BFR-ID of BFER1 in domain2, the BFR-Prefix and BFR-ID of BFER2, and the BFR-Prefix and BFR-ID of BFER5 in domain1, the BFR-Prefix and BFR-ID of BFER6, and the BFR-Prefix and BFR-ID of BFIR1, and directly notifies domain2 of the BFR-Prefix and BFR-ID of BFER3 and the BFR-Prefix and BFR-ID of BFER4 obtained from BR3 / 4. By analogy, in each domain, in addition to the information of BFER1 and BFER2 in this domain, it can also receive the BFR-Prefix and BFR-ID of BFER devices in other domains. Taking BFR1 as an example, the unicast routing table in Figure 5 can be calculated, and the BIER forwarding routing table in Figure 6 can be generated. Similarly, the unicast routing table on BFRm of domain2 is shown in Figure 7, and the BIER forwarding routing table is shown in Figure 8.

[0020] The advantages of this method are simplicity and directness, but the disadvantages are also obvious. First, routing leakage occurs between domains. For example, if the prefixes of two BFER devices in domain 2 exist in both domain 1 and domain 3, in reality, all routing information in different domains does not need to be fully mutually learned. Second, assuming a very large number of BFIR / BFER devices, the device load becomes very large. Assuming that each domain has 200 edge devices, the BFR-Prefix and BFR-ID of 600 edge devices across all three domains must be advertised to each domain. This large advertisement volume not only occupies network bandwidth and affects all devices (e.g., flooding of OSPF and ISIS devices), but also places a heavy computational load on devices because each device must first calculate 600 unicast routes before it can generate a BIER forwarding table for forwarding. BRs 1 to 4, as border devices, must advertise all BFR-Prefixes and their corresponding BFR-IDs as bridges. The large advertisement volume is prone to problems such as packet loss.

[0021] In response to the above-mentioned problems, an embodiment of the present invention provides a method for generating a forwarding table, and the embodiment of the present invention will be described in detail below 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 between similar objects.

[0023] The method according to the present invention may be implemented in a mobile terminal, a router or network switch, a computer terminal, or a similar computing device. For example, FIG. 9 is a block diagram of a hardware configuration of a mobile terminal for implementing the method for generating a forwarding table according to the present invention, as implemented on a mobile terminal. As shown in FIG. 9, the mobile terminal may include one or more processors 902 (only one of which is shown in FIG. 9) (the processor 902 may include, 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. The mobile terminal may further include a transmission device 906 and an input / output device 908 for communication functions. As will be appreciated by those skilled in the art, the structure 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 fewer components than those shown in FIG. 9, or may have a different configuration than that shown in FIG. 9.

[0024] 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. Processor 902 executes the computer programs stored in memory 904 to perform various functional applications and data processing, i.e., to realize the above-described method. 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, memory 904 may further include memory located remotely from processor 902, and these remote memories may be connected to the mobile terminal via 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 over 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 interface controller (NIC) that is connected to other network devices via a base station and can communicate with the Internet. In one embodiment, the transmission device 906 may be a radio frequency (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 to this. Figure 10 is a flowchart of the method for generating a forwarding table according to an 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 among the bit forwarding router identifiers BFR-IDs already present 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, or may be another processing device with similar processing capabilities, etc.

[0031] In the above embodiment, if there is no entry for the same BFR-ID as 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 entered. If there is an entry for the same BFR-ID, a final routing prefix needs to be determined from the routing prefixes corresponding to the multiple same BFR-IDs, and the entry in the forwarding table is adjusted based on the final routing prefix. Note that if the final 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 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.

[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. This avoids repeatedly creating multiple forwarding entries corresponding to the same BFR-ID in the forwarding table, avoiding the unnecessary occupation of network bandwidth due to excessive notification volume, overloading of devices, and packet loss, thereby achieving the effects of improving network bandwidth utilization and reducing device load.

[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 specific 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 specific 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 the target BFR-Prefix. The more detailed the content, the more content can be included in the BFR-Prefix. Specifically, the longer the mask length of the prefix of the BFR-Prefix.

[0036] Determination method 2 The first attribute information of the first BFR-Prefix is ​​compared with the second attribute information of the second BFR-Prefix, 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 this 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, 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 next hop device corresponding to the second BFR-ID already present in the target forwarding table to the first BFR-Prefix and 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. 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 of the domain where the first BFER is located, after determining that a second BFR-ID identical to the first BFR-ID exists among the BFR-IDs already present in the target forwarding table, the method further includes: performing error processing if it is determined that the BFR-Prefixes corresponding to the first BFR-ID and the second BFR-ID are from within the domain; and if it is determined that the BFR-Prefixes corresponding to the first BFR-ID and the second BFR-ID are both from outside the domain, determining second DOMAIN-ID of the domain where the second BFER 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. In this embodiment, if it is determined that the BFR-Prefixes corresponding to the same BFR-ID are from different domains, a configuration error is indicated, and updating of the forwarding table must be stopped and error processing must be performed.

[0040] In a preferred embodiment, the second notification message includes a second extra-domain TLV, which includes the second BFR-ID information, or the second extra-domain TLV includes the second BFR-ID information and second DOMAIN-ID information of the domain where the second BFR 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 varies depending on the protocol. 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 notification message includes the second BFR-Prefix, and the second extra-domain TLV is sent according to the second BFR-Prefix, where 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 notification 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 notification, or may follow a BFR-Prefix notification of a border device.

[0042] In a preferred embodiment, the first notification message includes a first extra-domain TLV, which includes the first BFR-ID information, or the first extra-domain TLV includes the first BFR-ID information and 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 varies depending on the protocol. 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 notification message includes the first BFR-Prefix, and the first extra-domain TLV is sent according to the first BFR-Prefix, where 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 notification 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 notification, or a BFR-Prefix notification of a border device.

[0044] In a preferred embodiment, the step of performing error processing includes at least one of the steps of: issuing an alarm to indicate 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 specific method described above, the error processing may be other processing methods, such as sending error notification information to a specific device or sending error notification information to an administrator's terminal, and the error processing method is not limited.

[0045] Embodiments of the invention will now be described with reference to general embodiments. The border device may advertise an extra-domain SUB-SUB-TLV to indicate the prefix following the advertisement, and the format may be as shown in Figure 11, where the included BFR-IDs can be listed. If the BFR-ID is a set of consecutive values, the format shown in Figure 12 may be used to indicate the start and end values ​​of the advertised BFR-IDs, and the DOMAIN-ID value may also be included separately, as shown in Figure 13. The DOMAIN-ID value may also be included directly within the same SUB-SUB-TLV, and may be included in the same manner as in Figures 14 and 15. FIG. 16 shows the overall flow of how a device generates a BIER forwarding table, and specifically includes the following steps S1602 to S1618.

[0046] In S1602, the BRF-ID included in the prefix is ​​extracted, In S1604, when calculating and generating the BIER forwarding table, the device searches whether an entry with the same BFR-ID as the extracted BRF-ID exists; 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 prefixes are 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, the prefixes corresponding to the same BFR-ID entry are compared, and the next hop corresponding to the more specific prefix is ​​selected, where the more specific means that the mask length of the prefix is ​​longer; or other attributes such as the cost / metric of the prefix are compared, and the more superior (e.g., smaller cost / metric) prefix and its corresponding next hop are selected, and this attribute can also be compared independently, i.e., the comparison of the specificity of the prefix after step 1612 is skipped, and other attributes such as the cost / metric of the prefix are directly compared; 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 To reduce the load on devices across the network, border devices may use several methods to reduce the number of prefixes advertised when advertising BFR-IDs, such as using aggregated routing or default routing. In these methods, an aggregated prefix may cover the prefixes of one or more border devices. A default routing prefix includes the prefixes of all border devices and therefore has multiple corresponding BFR-IDs. Although prefixes do not correspond one-to-one to BFR-IDs within the same domain, there is still a one-to-one correspondence between prefixes and BFR-IDs. In this case, advertising BFR-IDs from other domains must be distinguished from advertising BFR-IDs within the same domain. Therefore, when advertising BFR-IDs from other domains, they are included in a new TLV rather than the original BIER SUB-TLV, or by adding a new type of SUB-SUB-TLV to the original BIER SUB-TLV, which is referred to herein as extra-domain SUB-SUB-TLV.

[0048] For example, in Figure 4, the border device can reduce the number of advertised prefixes and exercise certain control over traffic. For example, when advertising domain 2's BFR-ID to domain 1 to send traffic destined for BFER1 via BR1, it can select the aggregate routing (assuming that prefix is ​​P11) placed on BR1. Assuming that P11 only contains prefixes of BFER1, BR1 will only include BFR-ID 1 of BFER1 when advertising prefixes of P11. The default routing (0 / 0 routing, conveniently called P0) placed on BR2 will include all routing prefixes of domain 2. Assuming that P0 contains all routing prefixes of domain 2, BR2 will include BFR-ID 1 / 2 of BFER1 and BFER2 when advertising P0 to domain 1. As shown in Figure 17, when a device in domain 1 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, suppose the BIER forwarding table is calculated and the BFR-ID information contained in the P11 prefix is ​​processed first. Since P11 contains only BFR-ID 1, a BIER forwarding table entry with BFR-ID 1, prefix P11, and next hop BR1 is generated. When processing default route P0, it finds that the BFR-IDs contained are 1 and 2, and the BFR-ID notifications for the two prefixes are both out-of-domain SUB-SUB-TLVs. This cannot be processed directly according to the original processing principle. Otherwise, the entry for BFR-ID 1 in the BIER forwarding table is updated to prefix P0 and next hop BR2, which fails to achieve the original control purpose. Therefore, when processing the default routing P0 and finding that the included BFR-ID1 already exists in the BIER forwarding table, it is necessary 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 Figure 18 (other routing entries are omitted for simplicity).

[0050] Specific Example 2 Border device notification may further reduce the prefix of the notification. When notifying its own BFR-Prefix, it may directly include an extra-domain SUB-SUB-TLV to include the BFR-ID of another domain. For example, in Figure 4, assuming that BR1's prefix is ​​PB1 and BR2's prefix is ​​PB2, when notifying domain 2's BFR-ID to domain 1, the same prefix BFR-Prefix must not only notify the BIER SUB-TLV within this domain but also include an extra-domain SUB-SUB-TLV. Therefore, when BR1 notifies its prefix PB1, it must include the extra-domain SUB-SUB-TLV and include domain 2's BFR-ID1 / 2, and the same applies to BR2.

[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 then generates a BIER forwarding table. It first extracts BFR-ID1 / 2 contained in the PB1 prefix to generate two BIER forwarding entries, with BFR-IDs 1 and 2 respectively, both prefixes being PB1, and both next hops being BR1. When processing the BFR-ID contained in PB2, it finds that a corresponding entry already exists in the BIER forwarding table. 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 performs ECMP (Equal-cost Multicast Routing). Alternatively, the BIER forwarding table may be generated by comparing 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 cost / metric attributes 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 configuration errors in the network. Assume that the network is still as shown in Figure 4, and the BFR-IDs assigned to devices BFER5 and BFER1 are both 50 due to incorrect configuration by the network administrator. Suppose that device BFER5 advertises its prefix P5 and BFR-ID 50 in domain 1, and device BFER1 advertises its prefix P1 and BFR-ID 50 in domain 2. When border device BR1 advertises its BFR-ID in domain 2 to domain 1, it advertises it as an extra-domain SUB-SUB-TLV of prefix PB1 of BR1. Similarly, the advertisement from domain 1 to domain 2 is similar, and the description will not be repeated here.

[0053] Taking BFR1 as an example, when a device performs routing calculation, 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. Assume that BFR1 then extracts the BIER SUB-TLV contained in the routing for prefix P5, and obtains a BIER forwarding entry with a BFR-ID of 50, prefix P5, and next hop BFER5. When processing the BIER SUB-TLV and extra-domain SUB-SUB-TLV contained in prefix PB1, it finds BFR-ID 50 and searches the BIER forwarding table to find that this BFR-ID entry already exists and that its source is the intra-domain BIER SUB-TLV for prefix P5. At this time, it explains that an error has occurred, and needs to stop updating the BIER forwarding entry, and display an alarm or error information, or report it to a controller to indicate that a network configuration error has occurred.

[0054] In the above embodiments, the notification is performed using the OSPF protocol as an example. If the notification is performed using the 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. If the notification is performed using the 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 in the form of an extra-domain SUB-TLV. In the embodiments of the present invention, the notification location is not particularly limited.

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

[0056] Assume that the OSPF protocol is configured to run in domain 2 and the ISIS protocol is configured to run in domain 1. Take border device BR5 / 6 as an example. Assume BR5 / 6 is configured to distribute the BFR-ID information in domain 2 to BR1 / 2. First, BR5 notifies the BFR-ID information of BFER1 / 2 obtained from the OSPF protocol as an out-of-domain SUB-TLV in its BIER TLV according to its own device prefix, with itself as the next hop, and sends it to BR1 and BR2, and then to BR6. As shown in Figure 24, after receiving the notification from BR5 and BR6, BR1 calculates its 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 they can include the extra-domain SUB-SUB-TLV when notifying their prefix routing via the ISIS protocol, so that domain1 can receive the BFR-ID information from domain2. The methods from domain1 to domain2 / 3 and from domain3 to domain1 are similar, and are not described 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 level of detail of both is the same, an ECMP table entry is formed.

[0059] Suppose a network configuration error occurs. Among the BFR-IDs transmitted from domain 3 to domain 1, there is one that is the same as the border device BFER1 of domain 2. Taking BFER1 as an example, when calculating the BIER forwarding table, it is found that there is an identical BFR-ID entry, and the 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, display it in the form of an alarm or error information, or report it to the controller, indicating that a network configuration error has occurred.

[0060] For simplicity, the number of edge devices and intermediate devices in the figure is not large, and the number of these devices is not limited 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 actual device as the next hop 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 BIER deployment, avoiding the problem of miscalculation of BIER forwarding table entries and accelerating the widespread deployment of BIER technology. Furthermore, the BIER underlay protocol clearly distinguishes between receiving intra-domain and inter-domain BFR-IDs when calculating and generating routing tables and BIER forwarding tables based on notification prefixes, ensuring accurate generation of BIER forwarding table entries and error-free 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, or can naturally be realized by hardware, and in many cases the former is the preferred embodiment. Based on this understanding, the substance of the technical solutions of the embodiments of the present invention or a part that contributes to the prior art can be 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 that cause a terminal device (which may be a mobile phone, computer, server, network device, etc.) to execute the methods described in each embodiment of the present invention.

[0063] In this embodiment, a forwarding table generation device is further provided, which is configured to realize the above-mentioned embodiments and preferred embodiments, and the description of what has already been described will be omitted. The term "module" used below can realize a combination of software and / or hardware for a given 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 a determination module 262 for determining whether a second BFR-ID identical to a first BFR-ID exists in the bit forwarding router identifiers BFR-IDs already present in the target forwarding table when generating the target forwarding table based on a received first notification message, the first notification message notifying the first BFR-ID of a first BFER; If determined to exist, 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; a generation module 266 configured to generate the target forwarding table based on the target BFR-Prefix.

[0065] In a preferred embodiment, the decision 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 determining unit configured to determine the first BFR-Prefix as the target BFR-Prefix if it determines that the first content is more specific than the second content; 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 decision 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 generation module 266: an update module configured to, when the target BFR-Prefix is ​​the first BFR-Prefix, 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; 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, 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 among the BFR-IDs already existing in the target forwarding table, and then perform 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; 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-IDs already existing in the target forwarding table, and then, when it is determined that both the 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 out-of-domain TLV, and the second out-of-domain TLV includes the second BFR-ID information, or the second out-of-domain TLV includes the second BFR-ID information and 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 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.

[0071] In a preferred embodiment, the first notification message includes a first out-of-domain TLV, and the first out-of-domain TLV includes the first BFR-ID information, or the first out-of-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 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.

[0073] In a preferred embodiment, the first execution module and the second execution module both include: Execute an alarm notification to indicate that the current network configuration is insufficient; and sending alarm information to the controller indicating that there is a deficiency in the current network configuration of the controller.

[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 a computer program stored thereon, the computer program being configured to perform the steps of any of the method embodiments described above when executed.

[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 connected to the processor and an input / output device connected to the processor.

[0079] For specific examples of this embodiment, reference can be made to the examples described in the above examples 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 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, and may be stored in a storage device and executed by a computing device, and in some cases, may execute the steps illustrated or described in the specification in a different order than in the specification, or may be implemented by forming each module into an integrated circuit module, or may implement multiple modules or steps 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. Those skilled in the art may make various modifications and changes to the embodiments of the present invention. Any modifications, equivalent replacements, and improvements made within the principles of the embodiments of the present invention shall fall within the protection scope of the embodiments of the present invention.

Claims

1. A method for generating a forwarding table by a forwarding table generation device, comprising: 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-IDs 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 it is determined that there is, 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; If the first notification message further includes first domain identifier DOMAIN-ID information of the domain in which the first BFER is located, after determining that a second BFER-ID that is the same as the first BFER-ID exists in the BFER-IDs already existing in the target forwarding table, the method: performing error processing 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; If it is determined that the BFR-Prefixes corresponding to the first BFR-ID and the second BFR-ID are both 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.

2. The 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 includes: 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 determining the second BFR-Prefix as the target BFR-Prefix if the second content is determined to be more detailed than the first content.

3. The 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 includes: 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: determining the second BFR-Prefix as the target BFR-Prefix when it is determined that the attribute value of the second attribute information is superior to the attribute value of the first attribute information.

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 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; If the target BFR-Prefix is ​​the second BFR-Prefix, maintaining the second BFR-ID, the second BFR-Prefix corresponding to the second BFR-ID, and a next hop device that were already present in the forwarding table.

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

6. 6. The method of claim 5, wherein the second notification message includes the second BFR-Prefix, the second extra-domain TLV is transmitted 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.

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

8. 8. The method of claim 7, wherein the first notification message includes the first BFR-Prefix, the first extra-domain TLV is transmitted 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.

9. The step of performing error handling includes: Executing an alarm indication to indicate that the current network configuration is insufficient; and b. sending alarm information to a controller indicating that there is a deficiency in the controller's current network deployment.

10. a determination module that, when generating a target forwarding table based on a received first notification message, determines whether a second BFR-ID that is the same as a first BFR-ID exists in the bit forwarding router identifiers BFR-IDs already present in the target forwarding table, the first notification message notifying the first BFR-ID of a first BFER; if determined to exist, 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; and if the first notification message further includes first domain identifier DOMAIN-ID information of the domain in which the first BFER is located, a second execution module configured to determine that a second BFR-ID identical to the first BFR-ID exists among the BFR-IDs already present in the target forwarding table, and if it is determined that both the first BFR-ID and the BFR-Prefix corresponding to 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.

11. A computer-readable storage medium having stored thereon a computer program, the computer program being adapted to implement the steps of the method according to any one of claims 1 to 9 when executed by a processor.

12. 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 9 when executing the computer program.

Images