Routing announcement method and electronic device

Abstract

The present application provides a route announcement method and electronic device. In this embodiment, the first ASBR in the first AS carries the NLRI and a newly added BIER Path Attribute (including at least the BFR ID collected by the first ASBR in the first AS) in the UPDATE message and announces it to the second AS, thereby realizing the exchange of BIER information within the autonomous system between ASs in the cross-AS BIER scenario and realizing BIER route announcement between ASs in the cross-AS BIER scenario.

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to a routing announcement method and an electronic device. Background Art

[0002] Bit Index Explicit Replication (BIER) is a new type of multicast technology. Among them, the router that supports BIER capabilities is called a bit forwarding router (BFR: Bit-ForwardingRouter), and the domain composed of BFRs is referred to as the BIER domain. The BFRs in the BIER domain are further divided into bit forwarding ingress routers (BFIR: Bit-Forwarding Ingress Router), bit forwarding egress routers (BFER: Bit-Forwarding EgressRouter), and intermediate BFRs between BFIR and BFER. Multicast messages enter the BIER domain from the BFIR, are transmitted to at least one BFER via the intermediate BFR, and finally leave the BIER domain from at least one BFER. Summary of the Invention

[0003] This application provides a routing announcement method and an electronic device to implement BIER routing announcement based on IPv6.

[0004] As an embodiment, the present application is implemented through the following technical solutions:

[0005] A routing advertisement method is applied to a first autonomous system border router (ASBR) in a first autonomous system (AS), wherein the first ASBR is connected to a second ASBR in a second AS; the method comprises:

[0006] Collect the BFR identification ID of each BFR in the first AS;

[0007] A routing update UPDATE message is announced to the second ASBR in the second AS; the UPDATE message carries the network layer reachability information NLRI and the bit-indexed explicit replication path attribute BIER Path Attribute; the NLRI includes at least the first BFR prefix of the first ASBR in the first SD; the BIER Path Attribute includes at least the collected BFR ID; the UPDATE message is used for the BFR in the second AS to add the corresponding BIFT forwarding table entry in the local bit index forwarding table BIFT based on the NLRI and the BIER Path Attribute; the BIFT forwarding table entry includes at least: a BFR neighbor and a forwarding bit mask F-BM, the BFR neighbor is the first BFR prefix, and the F-BM represents the BFR ID corresponding to each BFR reached via the BFR neighbor, wherein the BFR ID represented by the F-BM includes at least the BFR ID collected by the first ASBR in the first AS.

[0008] A routing advertisement method is applied to a network device in a second autonomous system (AS). The method comprises: when the network device is a second border router (ASBR), and the second ASBR is connected to a first ASBR in a first AS, then:

[0009] Receive a routing update UPDATE message announced by a first ASBR in a first AS; the UPDATE message carries network layer reachability information NLRI and a bit-indexed display replication path attribute BIER Path Attribute; the NLRI includes at least a first BFR prefix of the first ASBR in the first SD; the BIER Path Attribute includes at least a BFR ID collected by the first ASBR in the first AS;

[0010] The NLRI and BIER Path Attribute are announced in the second AS so that any BFR in the second AS that receives the NLRI and BIER Path Attribute adds a corresponding BIFT forwarding table entry in the local position index forwarding table BIFT.

[0011] An electronic device comprising: a processor and a machine-readable storage medium;

[0012] The machine-readable storage medium stores machine-executable instructions that can be executed by the processor;

[0013] The processor is used to execute machine executable instructions to implement the above method steps.

[0014] Through the above technical solution of the present application, in this embodiment, the first ASBR in the first AS carries the NLRI and a newly added BIER Path Attribute (at least including the BFR ID collected by the first ASBR in the first AS) in the UPDATE message and notifies the second AS, thereby realizing the exchange of BIER information within autonomous systems between ASs in a cross-AS BIER scenario and realizing BIER route notification between ASs in a cross-AS BIER scenario. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A flow chart of the method provided in the embodiment of the present application;

[0016] Figure 2 A schematic diagram of the format of an EBGP UPDATE message provided in an embodiment of the present application;

[0017] Figure 3 A schematic diagram of the structure of the BIER Path Attribute provided in the embodiment of this application;

[0018] Figure 4 A schematic diagram of the first TLV structure provided in an embodiment of the present application;

[0019] Figure 5 A schematic diagram of the second TLV structure provided in an embodiment of the present application;

[0020] Figure 6 A flow chart of the second method provided in an embodiment of the present application;

[0021] Figure 7 A network diagram of an embodiment of the present application providing routing notification via EBGP;

[0022] Figure 8 A flow chart of the third method provided in an embodiment of the present application;

[0023] Figure 9 A schematic diagram of the application network provided in the embodiment of the present application;

[0024] Figure 10 Schematic diagram of message forwarding provided in an embodiment of the present application;

[0025] Figure 11 A structural diagram of a first device provided in an embodiment of the present application;

[0026] Figure 12 A structural diagram of a second device provided in an embodiment of the present application;

[0027] Figure 13 A diagram showing the structure of a third device provided in an embodiment of the present application;

[0028] Figure 14 This is a hardware structure diagram of the device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0029] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0030] The terms used in this application are for the purpose of describing particular embodiments only and are not intended to limit this application. As used in this application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0031] In order to enable those skilled in the art to better understand the technical solutions provided by the embodiments of the present application and to make the above-mentioned purposes, features and advantages of the embodiments of the present application more obvious and understandable, the following first describes the technical terms related to the embodiments of the present application:

[0032] SD (Sub-Domain): Indicates a BIER subdomain. There is at least one BIER subdomain in a BIER domain. In the BIER domain, a BFR identifier (ID) is configured for each designated BFR in the BIER subdomain in units of BIER subdomains. Here, the designated BFR can be BFIR, BFER, etc., which is not specifically limited in this embodiment.

[0033] BFR Prefix: Used to identify a BFR. Different BFRs within the same SD are represented by different BFR prefixes. In specific implementations, the BFR prefix can be represented by an IPv4 address or an IPv6 address of the BFR. This embodiment uses an IPv6 address as an example.

[0034] BIER encapsulation type: indicates the BIER encapsulation type supported by BFR, such as MPLS type, Ethernet type, IPv6 type (denoted as BIER6), etc.

[0035] BSL (Bit String Length): Indicates the length of the bit string in the BIER encapsulation.

[0036] MAX SI (Set Identifier): Indicates the maximum number of SIs. SI represents the ID of the set to which the bit string in the BIER encapsulation belongs. When the BFR ID range exceeds the range that can be represented by the BSL, multiple sets are required to represent it, and each set has a unique ID. For example, if the BFR ID range is 1 to 512 and the BSL is 256, two sets are required to represent it. SI = 0 represents 1 to 256, and SI = 1 represents 257 to 512.

[0037] Based on the description of the above technical terms, the method provided in the embodiment of the present application is described below:

[0038] See also Figure 1 , Figure 1 A flow chart of the method provided for an embodiment of the present application. The method is applied to a cross-autonomous system (AS: Autonomous System) BIER scenario. Each AS in the cross-AS BIER scenario has deployed BIER (the AS that has deployed BIER is denoted as AS BIER). As an embodiment, the method can be applied to the first AS border router (ASBR: Autonomous System Border Router) in the first AS in a cross-AS BIER scenario. In this embodiment, the first ASBR is connected to the second ASBR in the second AS. It should be noted that the first AS, the first ASBR, the second AS, and the second ASBR are named only for the convenience of description and are not intended to be limiting.

[0039] like Figure 1 As shown, the process may include the following steps:

[0040] Step 101: The first ASBR collects the BFR IDs of the BFRs in the first AS.

[0041] As an embodiment, the BFR IDs of the BFRs in the first AS collected by the first ASBR may include: BFR IDs deployed as BFIRs in the first AS and BFR IDs deployed as BFERs in the first AS.

[0042] Optionally, the IGP protocol module or BIER routing management module running locally on the first ASBR may collect the BFR ID of each BFR in the AS through the IGP protocol. When executing step 101, the first ASBR may collect the BFR ID of each BFR in the first AS from the locally running IGP protocol module or BIER routing management module, such as the BFR ID deployed as a BFIR in the first AS and the BFR ID deployed as a BFER.

[0043] Step 102, the first ASBR notifies the second ASBR in the second AS of a routing update (UPDATE) message; the UPDATE message carries NLRI and BIER Path Attribute; the NLRI includes at least the first BFR prefix of the first ASBR in the first SD; the BIER Path Attribute includes at least the collected BFR ID.

[0044] As described in step 102 above, the first ASBR notifies the first ASBR of the network reachability information corresponding to the first BFR prefix in the first SD through an UPDATE message. Optionally, the UPDATE message in this embodiment can be obtained by extending the External Border Gateway Protocol (EBGP), specifically, an EBGP UPDATE message that newly extends a routing attribute (Path Attribute). Here, the newly extended Path Attribute is the above-mentioned bit index-based display replication path attribute (BIER Path Attribute). In this embodiment, the BIER PathAttribute can be regarded as a newly added Path Attribute in the EBGP UPDATE message, and its specific position in the EBGP UPDATE message is not limited. Figure 2 The example shows the existing format of EBGP UPDATE message. The BIERPath Attribute in this embodiment can be Figure 2 A new Path Attribute is added to the Path Attributes shown. In this embodiment, the BIER Path Attribute can be in TLV format, which will be described with examples below and will not be repeated here. It should be noted that the above-mentioned first SD is named only for the convenience of description and can generally refer to any SD where the first ASBR is currently located. The first BFR prefix is ​​used to uniquely identify the first ASBR and can be an IPv6 address or an IPv4 address, which is not specifically limited in this embodiment.

[0045] As described in step 102, in addition to carrying the newly added BIER Path Attribute, the UPDATE message also carries Network Layer Reachability Information (NLRI). As an embodiment, the NLRI includes at least the first BFR prefix and the length of the first BFR prefix. For example, the NLRI includes 2001:2:3F::1 / 128.

[0046] As described in step 102 above, the first ASBR notifies the second ASBR in the second AS of an UPDATE message, and when the second ASBR receives the UPDATE message, it will continue to notify the NLRI and BIER PathAttribute carried in the UPDATE message within the second AS, so that the BFRs in the second AS will receive the above NLRI and BIER PathAttribute notified by the second ASBR. When the BFR in the second AS receives the above NLRI and BIER Path Attribute notified by the second ASBR, it will add the corresponding BIFT forwarding table entry in the local BIFT. That is to say, ultimately through the above UPDATE message, the BFR in the second AS will add the corresponding BIFT forwarding table entry in the local bit index forwarding table (BIFT: Bit Index Forwarding Table) based on the NLRI and BIER Path Attribute carried in the UPDATE message.

[0047] In one example, if the second ASBR supports BIER, the second ASBR will also add the corresponding BIFT forwarding table entry in the local BIFT. On the contrary, if the second ASBR does not support BIER, for example, if BIER is supported in the control plane (software upgrade is easier) but not in the forwarding plane (for example, the hardware does not have the ability to support BIER), the second ASBR will not add the corresponding BIFT forwarding table entry in the local BIFT.

[0048] In one example, the BIFT forwarding table entry includes at least a forwarding bit mask (F-BM) and a BFR neighbor (BFR-NBR). The BFR neighbor is the first BFR prefix. The F-BM at least represents the BFR IDs corresponding to each BFR reached via the BFR neighbor. The BFR IDs represented by the F-BM include at least the BFR IDs collected by the first ASBR within the first AS.

[0049] Optionally, in this embodiment, the BFR ID may be represented by a bit mask of the SI combination corresponding to the BFR ID. For example, in the F-BM, the bit corresponding to the BFR ID corresponding to each BFR reached via the BFR neighbor is set to a first value, such as 1, and the remaining bits are set to a second value, such as 0. In the F-BM, if a bit is set to the first value, such as 1, it indicates that the BFR corresponding to the BFR ID represented by the bit can be reached via the BFR neighbor. If the bit is set to 0, it indicates that the BFR corresponding to the BFR ID represented by the bit cannot be reached via the BFR neighbor. This will be described with examples below and will not be repeated here.

[0050] pass Figure 1 It can be seen from the shown process that in this embodiment, the exchange of BIER information within autonomous systems between ASs in the cross-AS BIER scenario is realized, and the BIER route announcement between ASs in the cross-AS BIER scenario is realized.

[0051] Furthermore, based on the description of the above UPDATE message, this embodiment extends the EBGP protocol to add a new BIER Path Attribute in the EBGP UPDATE message defined by the EBGP protocol, thereby realizing the exchange of BIER information within autonomous systems between ASs in cross-AS BIER scenarios with the help of the existing EBGP protocol, thereby improving the breadth of application.

[0052] The following describes the above BIER Path Attribute:

[0053] As described above, BIER Path Attribute can be a TLV structure. Figure 3 The structure of BIER PathAttribute is shown as an example. The type field and length field in BIER Path Attribute can be set according to actual needs. Figure 3 The Sub-TLVs field in the BIER Path Attribute structure shown in the example carries the following two newly added sub-sub-TVLs, which are recorded as: first TLV and second TLV.

[0054] 1) First TLV:

[0055] In this embodiment, the first TLV is used to carry the BFR ID collected by the first ASBR in the first AS. Figure 4 As shown, the first TLV includes at least one field pair. Each field pair includes a BFRID field and a BFR ID range field that have a corresponding relationship. In this embodiment, the first TLV carries the BFR IDs collected by the first ASBR in the first AS through at least one field pair.

[0056] In each field pair, the parameter carried by the BFR ID Range field is used to represent a BFRID segment with continuous values, and the BFR ID field carries the starting BFR ID of the BFR ID segment. It should be noted that when the first TLV includes more than two field pairs, the starting BFR IDs carried by the BFR ID fields in different field pairs are different. For example, the BFR IDs collected by the first ASBR in the first AS are divided into two parts, one of which is 1 to 251 and the other is 260 to 512. Then the first TLV may include: two field pairs, one of which includes: BFR ID field 1_1 and BFR ID Range field 1_1; the other field pair includes: BFR ID field 1_2 and BFR ID Range field 1_2. Among them, the BFR ID field 1_1 carries the starting value 1 of the continuous BFR ID segment from 1 to 251, and the BFR ID Range field 1_1 carries 251, which is used to indicate that the BFR ID segment is continuous from 1 to 251, specifically indicating that there are 251 BFR IDs in the continuous BFR ID segment from 1 to 251. The BFR ID field 1_2 carries the starting value 260 of the continuous BFR ID segment from 260 to 512, and the BFR ID Range field 1_2 carries 253, which is used to indicate that the BFR ID segment is continuous from 260 to 512, specifically indicating that there are 253 BFR IDs in the continuous BFR ID segment from 260 to 512.

[0057] Alternatively, as Figure 4 As shown, in this embodiment, the first TLV also includes a Type field and a Length field. The Type field and the Length field can be set according to actual conditions, for example, the length of the Type field is 2 bytes, and the length of the Length field is 2 bytes, etc. This embodiment does not specifically limit this.

[0058] 2) Second TLV:

[0059] In this embodiment, the second TLV is used to indicate the BIER encapsulation information supported by the first ASBR. Figure 5As shown, the second TLV may include at least: a Type field, a Length field, and a BIER encapsulation information field. Among them, the Type field is used to carry the BIER encapsulation type supported by the first ASBR, such as the MPLS encapsulation type, the IPv6-based BIER (denoted as BIER6), etc. Optionally, the length of the Type field may be ie2 bytes. The Length field can be set according to actual conditions. The Length field is used to indicate the length of the BIER encapsulation information field, for example 2 bytes. The BIER encapsulation information field is used to carry the BIER encapsulation information supported by the first ASBR. As an embodiment, the BIER encapsulation information can be used to assist the second ASBR in determining the table entry identifier of the above-mentioned BIFT forwarding table entry. In an example, the BIER encapsulation information may include at least: MAX SI, BSL, and BIFT ID.

[0060] The MAX SI represents the SI corresponding to the maximum BFR ID in the first AS where the first ASBR is located. Optionally, the MAX SI may occupy 8 bits.

[0061] BSL represents the bit string length in the BIER encapsulation supported by the first ASBR. Optionally, BSL can occupy 4 bits.

[0062] BIFT ID: This field represents the identifier of the local BIFT. Here, the BSL, SD, and SI triplet corresponds to the unique BIFT identifier of the local BIFT.

[0063] Optionally, as an embodiment, BIER Path Attribute also carries Figure 3 The SD configuration field shown here carries SD configuration information. As an embodiment, the SD configuration information includes at least: the BFR ID of the first SD and the first ASBR mentioned above. To facilitate subsequent expansion, the BIER Path Attribute may also include a reserved field, which will not be described here.

[0064] The above describes the BIER Path Attribute with examples.

[0065] above Figure 1 The process shown is described from the perspective of the first ASBR in the first AS. The following describes the process of the method provided in the embodiment of the present application from the perspective of the second ASBR in the second AS:

[0066] See also Figure 6 , Figure 6This is a flow chart of the second method provided in an embodiment of the present application. This method is applied to a second ASBR in a second AS. Here, the second ASBR is connected to the first ASBR in the first AS.

[0067] like Figure 6 As shown, the process may include the following steps:

[0068] Step 601: The second ASBR receives an UPDATE message notified by the first ASBR in the first AS.

[0069] As described above, the UPDATE message here carries at least the NLRI and the newly added BIER Path Attribute; the NLRI includes at least the first BFR prefix of the first ASBR in the first SD; the BIER Path Attribute includes at least the BFR ID collected by the first ASBR in the first AS. The BFR ID collected by the first ASBR in the first AS is described above and will not be repeated here.

[0070] Step 602: The second ASBR announces the above NLRI and BIER Path Attribute in the second AS, so that the BFR in the second AS that receives the NLRI and BIER Path Attribute adds the corresponding BIFT forwarding entry in the local BIFT.

[0071] Optionally, as an embodiment, the second ASBR may extend the IBGP protocol to announce the above-mentioned NLRI and BIER Path Attribute in the second AS. In specific implementation, the IBGP UPDATE message defined by the IBGP protocol may be extended to carry the above-mentioned NLRI and BIER Path Attribute in the IBGP UPDATE message and announce it to the designated BFR (the peer of the second ASBR), so that the above-mentioned designated BFR in the second AS adds the corresponding BIFT forwarding table entry in the local BIFT. Figure 7 The example networking of the embodiment of IBGP announcement is shown as an example. The BIFT forwarding entries will be described below and will not be described here in detail.

[0072] It should be noted that, as described above, if the second ASBR supports BIER on the control plane (software upgrade is easier) but does not support BIER on the forwarding plane (for example, the hardware does not have the ability to support BIER), the second ASBR will not add the corresponding BIFT forwarding table entry in the local BIFT.

[0073] So far, completed Figure 6 The process shown.

[0074] pass Figure 6 As can be seen from the shown process, in this embodiment, the second ASBR in the second AS realizes the exchange of BIER information within autonomous systems between ASs in cross-AS BIER scenarios by announcing the prefix route reachability information in the external first AS within the second AS and carrying the above-mentioned BIER Path Attribute, thereby realizing the BIER route announcement between ASs in cross-AS BIER scenarios.

[0075] The following describes the method provided in the embodiment of the present application from the perspective of any BFR in the second AS except the second ASBR:

[0076] See also Figure 8 , Figure 8 This is a flow chart of the third method provided in the embodiment of the present application. This process is applied to any BFR in the second AS except the second ASBR. Figure 8 As shown, the process may include the following steps:

[0077] Step 801: When the notified NLRI and BIER Path Attribute are received, the corresponding BIFT forwarding table entry is added to the local BIFT.

[0078] As an embodiment, the BIFT forwarding table entry here includes at least: a forwarding bit mask (F-BM: ForwardingBitMask) and a BFR neighbor (BFR-NBR: BFR Neighbor). The BFR neighbor is the first BFR prefix, such as the IPv6 address of the first BFR, and the F-BM at least represents the BFR ID corresponding to each BFR reached via the BFR neighbor.

[0079] Optionally, the BFR ID represented by the F-BM here includes at least the aforementioned BFR IDs collected by the first ASBR within the first AS. Optionally, in this embodiment, the F-BM may represent the BFR ID using a bit mask of the SI corresponding to the BFR ID and the combination of the BFR neighbors. In a specific implementation, for each BFR ID corresponding to a BFR reached via a BFR neighbor, the bit position corresponding to the BFR ID in the F-BM is set to a first value, such as 1, to indicate that the BFR corresponding to the BFR ID represented by the bit position can be reached via the BFR neighbor. Furthermore, for each BFR ID corresponding to a BFR that cannot be reached via a BFR neighbor, the bit position corresponding to the BFR ID in the F-BM is set to a second value, such as 0, to indicate that the BFR corresponding to the BFR ID represented by the bit position cannot be reached via the BFR neighbor. The BIFT forwarding table entries will be described in detail below and will not be repeated here.

[0080] It should be noted that any BFR in the above-mentioned second AS except the second ASBR will also announce the NLRI and BIER Path Attribute in a similar manner as the second ASBR announces the NLRI and BIER Path Attribute.

[0081] Step 802: When the original multicast message is received, the IPv6 message corresponding to the original multicast message is forwarded to the target BFR; the IPv6 message is obtained by encapsulating BIER information and IPv6 information on the original multicast message, and the BIER information at least includes a bit string Bitstring, and the bit corresponding to the BFR ID of the target BFR in the Bitstring is set to a first value for indicating forwarding, and the BFR ID represented by the F-BM includes the BFR ID of the target BFR, and the outer IPv6 destination address in the IPv6 information is the first BFR prefix.

[0082] In one example, when any BFR receives the original multicast message, it will query the multicast forwarding table to obtain the bitstring corresponding to the BFER of the original multicast message, and then encapsulate the BIER information (at least including the bitstring) and IPv6 information on the original multicast message.

[0083] Based on the description of step 802, when a network device that does not support BIER in the second AS receives an IPv6 message, it matches the destination IP address of the IPv6 message (i.e., the first BFR prefix mentioned above) with the ordinary IPv6 forwarding table entry and forwards it according to IPv6 unicast. For example, when the second ASBR receives an IPv6 message, it unicast-forwards the IPv6 message based on the outer IPv6 destination address in the IPv6 message.

[0084] It can be seen from the above description that in this embodiment, only the devices connected to the multicast source in the second AS need to support BIER. The fact that other network devices in the second AS do not support BIER does not affect the forwarding of multicast messages, which facilitates smooth upgrades of the network.

[0085] So far, completed Figure 8 The process shown.

[0086] pass Figure 8 It can be seen from the shown process that in this embodiment, any BFR in the second AS except the second ASBR can realize message forwarding between ASs in the cross-AS BIER scenario by learning the prefix route reachability information in the first AS announced by the second ASBR (carrying the above-mentioned BIER PathAttribute).

[0087] The above process is described below through a specific embodiment:

[0088] See also Figure 9 , Figure 9 This is a schematic diagram of the application network provided in the embodiment of this application. Figure 9 In the embodiment shown, taking the example of ASBR902_1 in AS902 advertising the BIER route of AS902 to AS901, then:

[0089] exist Figure 9 The configuration of ASBR902_1 is shown in Table 1.

[0090] SD BFR-ID MAX SI BSL BIFT ID BFR-Prefix 1 1 4 256 2000 2001：2：3F：：1

[0091] Table 1

[0092] like Figure 9 As shown, ASBR 902_1 can collect the BFR ID of each BFR in AS 902 from the locally running IGP protocol module or BIER routing management module. As an example, the BFR IDs collected by ASBR 902_1 are 1 to 251, 260 to 512.

[0093] Based on the BIER Path Attribute described above, as an embodiment, ASBR902_1 can notify AS901_1 of the unicast prefix route reachability information corresponding to the BFR-Prefix of ASBR902_1 through an EBGP UPDATE message. The following Table 2 shows an example of the BIER Path Attribute and NLRI carried in the EBGP UPDATE message:

[0094]

[0095] Table 2

[0096] ASBR902_1 sends an EBGP UPDATE message to AS901. The EBGP UPDATE message carries at least the BIER Path Attribute and NLRI shown in Table 2.

[0097] ASBR901_1 in AS901 receives the EBGP UPDATE message. The EBGP UPDATE message carries the BIER Path Attribute and NLRI shown in Table 2.

[0098] ASBR901_1 notifies the designated BFR in AS901 (taking R901_2 as an example) through IBGP UPDATE message that the BIERPath Attribute and NLRI carried in the EBGPUPDATE message are shown in Table 2. Figure 7 The embodiment shown.

[0099] R901_2 receives the IBGP UPDATE message and adds the corresponding BIFT forwarding entry in the local BIFT. As an embodiment, taking R901_2 as an example, R901_2 adds the corresponding BIFT forwarding entry in the local BIFT as follows:

[0100] A BIFT forwarding entry is added to the BIFT with BIFT ID 2000; and a BIFT forwarding entry is added to the BIFT with BIFT ID 2001.

[0101] Here, when the BSL, SD, and SI in the above BIER Path Attribute are 3, 1, and 0 respectively, the corresponding BIFT ID is determined to be 2000. When the BSL, SD, and SI in the above BIER Path Attribute are 3, 1, and 1 respectively, the corresponding BIFT ID is determined to be 2001.

[0102] Table 3 shows an example of adding corresponding BIFT forwarding entries in the local BIFT:

[0103]

[0104] Table 3

[0105] In Table 3, when the corresponding bit on the F-BM is set to 1, it means that the BFR corresponding to the BFR ID represented by the bit can be reached through the BFR-NBR in Table 3. Conversely, when the corresponding bit on the F-BM is set to 0, it means that the BFR corresponding to the BFR ID represented by the bit cannot be reached through the BFR-NBR in Table 3. Taking the F-BM shown in the second row of Table 3: "0000011111...111111 (251 1s)" as an example, the first "1" on the right indicates that the BFR ID is 0, the second "1" on the right indicates that the BFR ID is 1, and so on.

[0106] It should be noted that this embodiment does not require all devices in AS901 to support BIER. To meet the requirements of multicast message forwarding, as an embodiment, in this embodiment, only devices in AS901 connected to the multicast source, such as the aforementioned R901_2, are required to support BIER, while devices in AS901 not connected to the multicast source, such as the aforementioned R901_3, do not support BIER.

[0107] Based on the BIFT forwarding table entries established above, the message forwarding process is described below:

[0108] Still taking R901_2 as an example, R901_2 receives an original multicast message to be forwarded to all or part of the BFERs in AS902 (for ease of description, forwarding to all BFERs in AS902 is taken as an example here), which is recorded as message a1.

[0109] R901_2 encapsulates BIER information in message a1 (referred to as BIER encapsulation header), and the bit position corresponding to the BFR ID of each BFER in the above-mentioned AS902 in the bit string (BitString) in the BIER information is 1. At the same time, IPv6 information is also encapsulated in the outer layer of message a1 (referred to as IPv6 header). Among them, the outer IPv6 destination address in the IPv6 information is set to the BFR-NBR address in the above-mentioned BIFT forwarding table entry (that is, the BFR-Prefix address 2001:2:3F::1 of ASBR902_1). For the convenience of description, message a1 encapsulated with BIER information and IPv6 information can be referred to as message a2 here. The structure of message a2 is as follows Figure 10 shown.

[0110] R901_2 forwards packet a2 in AS901.

[0111] ASBR901_1 receives packet a2, matches the outer IPv6 destination address of packet a2 with the common IPv6 forwarding table entry, and forwards it as IPv6 unicast.

[0112] ASBR902_1 receives packet a2. The outer IPv6 destination address of packet a2 is the BFR-Prefix address of the ASBR902_1. It then forwards the packet using BIER. BIER forwarding follows the existing BIER forwarding rules, ultimately achieving multicast packet forwarding.

[0113] From the forwarding process above, this embodiment may require that devices in AS901 connected to the multicast source, such as the aforementioned R901_2, support BIER, while devices in AS901 not connected to the multicast source, such as the aforementioned R901_3, do not support BIER.

[0114] This completes the description of the embodiment.

[0115] See also Figure 11 , Figure 11 This is a structural diagram of the first device provided in the embodiment of the present application. Figure 1 The device is applied to the first ASBR in the first AS, and the first ASBR is connected to the second ASBR in the second AS; Figure 11 As shown, the device may include:

[0116] A collecting unit, configured to collect the BFR identification ID of each BFR in the first AS;

[0117] The first announcement unit is used to announce a routing update UPDATE message to the second ASBR in the second AS; the UPDATE message carries NLRI and BIER Path Attribute; the NLRI at least includes the first BFR prefix of the first ASBR in the first SD; the BIER Path Attribute at least includes the collected BFR ID; the UPDATE message is used for the BFR in the second AS to add corresponding BIFT forwarding table entries in the BIFT based on the NLRI and BIER Path Attribute; the BIFT forwarding table entries include at least: BFR neighbors and F-BMs, the BFR neighbor is the first BFR prefix, and the F-BM represents the BFRID corresponding to each BFR reached via the BFR neighbor, wherein the BFR ID represented by the F-BM includes at least the BFR ID collected by the first ASBR in the first AS.

[0118] As an embodiment, the collecting of BFR IDs of each BFR in the first AS includes:

[0119] Collecting BFR IDs of BFIRs deployed as bit forwarding ingress routers (BFIRs) in the first AS; and

[0120] Collect the BFR IDs of the BFERs deployed as bit forwarding egress routers in the first AS.

[0121] As an embodiment, the BIER Path Attribute carries a first TLV; the first TLV includes at least one field pair, and each field pair includes a BFR ID field and a BFR ID Range field having a corresponding relationship;

[0122] The first TLV carries the BFR IDs collected by the first ASBR in the first AS through at least one field pair. In each field pair, the parameter carried by the BFR ID Range field is used to represent a BFR ID segment with continuous values, and the BFR ID field carries the starting BFR ID of the BFR ID segment.

[0123] As an embodiment, the BIER Path Attribute further carries: a second TLV;

[0124] The type field in the second TLV is used to carry the BIER encapsulation type supported by the first ASBR;

[0125] The second TLV also includes: a BIER encapsulation information field, which is used to carry the BIER encapsulation information supported by the first ASBR; the BIER encapsulation information is used to determine the table entry identifier of the BIFT forwarding table entry.

[0126] As an embodiment, the BIER package information mentioned above includes at least:

[0127] MAX SI, indicating the SI corresponding to the maximum BFR ID in the first AS;

[0128] BSL, indicates the bit string length in the supported BIER encapsulation;

[0129] BIFT ID, indicating the identifier of the local BIFT.

[0130] As an embodiment, the BIER Path Attribute further carries: an SD configuration field; the SD configuration field carries SD configuration information;

[0131] The SD configuration information at least includes: the first SD and the BFR ID of the first ASBR.

[0132] So far, completed Figure 11 The device structure is described as shown.

[0133] See also Figure 12 , Figure 12 The second device structure diagram provided in the embodiment of the present application. The device is applied to a network device in a second AS. Wherein, when the network device is a second ASBR, and the second ASBR is connected to the first ASBR in the first AS, the device corresponds to the above Figure 6 The process shown may include:

[0134] A receiving unit, configured to receive a routing update UPDATE message announced by a first ASBR in a first AS; the UPDATE message carries an NLRI and a BIER Path Attribute; the NLRI includes at least a first BFR prefix of the first ASBR in the first SD; the BIER Path Attribute includes at least a BFR ID collected by the first ASBR in the first AS;

[0135] The second notification unit is used to notify the NLRI and BIER Path Attribute in the second AS, so that any BFR in the second AS that receives the NLRI and BIER Path Attribute adds a corresponding BIFT forwarding table entry in the local position index forwarding table BIFT.

[0136] As an embodiment, optionally, the device may further include: a forwarding unit.

[0137] A forwarding unit is configured to, upon receiving an IPv6 message corresponding to an original multicast message, unicast forward the IPv6 message based on the outer IPv6 destination address in the IPv6 message; the IPv6 message is obtained by encapsulating BIER information and IPv6 information on the original multicast message. Here, the forwarding unit matches the outer IPv6 destination address of the IPv6 message with a common IPv6 forwarding table entry and forwards the message as IPv6 unicast.

[0138] So far, completed Figure 12 The device shown.

[0139] See also Figure 13 , Figure 13 This is a diagram of the third device structure provided in the embodiment of the present application. The device is applied to the network device in the second AS. When the network device is any BFR other than the second ASBR, the device corresponds to the above Figure 8 The process shown is as follows Figure 13 As shown, the device may include:

[0140] A table entry unit is used to add a corresponding BIFT forwarding table entry in the local position index forwarding table BIFT when receiving the NLRI and BIERPath Attribute announced by the second ASBR in the second AS; the BIFT forwarding table entry includes at least: a BFR neighbor and a forwarding bit mask F-BM, the BFR neighbor is the first BFR prefix, and the F-BM represents the BFR ID corresponding to each BFR reachable through the BFR neighbor, wherein each BFR reachable through the BFR neighbor includes the BFR corresponding to the BFR ID collected by the first ASBR in the first AS.

[0141] A forwarding unit is used to forward the IPv6 message corresponding to the original multicast message to a target BFR when an original multicast message is received, wherein the IPv6 message is obtained by encapsulating BIER information and IPv6 information on the original multicast message, and the BIER information at least includes a bit string Bitstring, and the bit corresponding to the BFR ID of the target BFR in the Bitstring is set to a first value for indicating forwarding, the BFR ID represented by the F-BM includes the BFR ID of the target BFR, and the outer IPv6 destination address in the IPv6 information is the first BFR prefix.

[0142] So far, completed Figure 13 Structural diagram of the device shown.

[0143] The embodiment of the present application also provides the hardware structure of the above device. Figure 14 , Figure 14 This is a structural diagram of an electronic device provided in an embodiment of the present application. Figure 14 As shown, the hardware structure may include: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the method disclosed in the above example of this application.

[0144] Based on the same application concept as the above method, an embodiment of the present application also provides a machine-readable storage medium, on which a number of computer instructions are stored. When the computer instructions are executed by a processor, the method disclosed in the above example of the present application can be implemented.

[0145] Exemplarily, the machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that may contain or store information, such as executable instructions, data, and the like. For example, the machine-readable storage medium may be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, a storage drive (such as a hard disk drive), a solid-state drive, any type of storage disk (such as a CD, DVD, etc.), or similar storage media, or a combination thereof.

[0146] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0147] For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0148] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the embodiments of the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0149] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0150] Furthermore, these computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0151] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The steps for the function specified in one or more boxes.

[0152] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

[0153] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A BIER route announcement method applied to IPv6, characterized in that: The method includes: In the cross-AS BIER scenario, the first autonomous system border router (ASBR) in the first autonomous system (AS) collects BFR identification IDs of each BFR in the first AS; the first ASBR connects to the second ASBR in the second AS; The first ASBR announces a routing update UPDATE message to the second ASBR in the second AS; the UPDATE message carries network layer reachability information NLRI and a bit-indexed explicit replication path attribute BIER Path Attribute; the NLRI includes at least the first BFR prefix of the first ASBR in the first SD; the BIER Path Attribute includes at least the collected BFR ID; the UPDATE message is used by the BFR in the second AS to add a corresponding BIFT forwarding table entry in the local bit index forwarding table BIFT based on the NLRI and the BIER Path Attribute; the BIFT forwarding table entry includes at least: a BFR neighbor and a forwarding bit mask F-BM, the BFR neighbor is the first BFR prefix, and the F-BM represents the BFR ID corresponding to each BFR reached via the BFR neighbor, wherein the BFR ID represented by the F-BM includes at least the BFRID collected by the first ASBR in the first AS; After the second ASBR receives the route update UPDATE message announced by the first ASBR in the first AS, it announces the NLRI and BIER Path Attribute in the second AS so that any BFR in the second AS that receives the NLRI and BIER Path Attribute adds a corresponding BIFT forwarding table entry in the local position index forwarding table BIFT.

2. The method according to claim 1, characterized in that The collecting of the BFR IDs of the BFRs in the first AS includes: Collecting BFRIDs of BFIRs deployed as bit forwarding ingress routers in the first AS; and Collect the BFRIDs of the BFERs deployed as bit forwarding egress routers in the first AS.

3. The method according to claim 1, characterized in that The BIER Path Attribute carries a first TLV; the first TLV includes at least one field pair, each field pair includes a BFR ID field and a BFRID range field having a corresponding relationship; The first TLV carries the BFR IDs collected by the first ASBR in the first AS through at least one field pair. In each field pair, the parameter carried by the BFR ID Range field is used to represent a BFR ID segment with continuous values, and the BFR ID field carries the starting BFR ID of the BFR ID segment.

4. The method according to claim 1, wherein The BIER Path Attribute also carries: a second TLV; The type field in the second TLV is used to carry the BIER encapsulation type supported by the first ASBR; The second TLV also includes: a BIER encapsulation information field, wherein the BIER encapsulation information field is used to carry BIER encapsulation information supported by the first ASBR; The BIER encapsulation information is used to determine the table entry identifier of the BIFT forwarding table entry.

5. The method according to any one of claims 1 to 4, characterized in that: The BIER Path Attribute also carries: an SD configuration field; the SD configuration field carries SD configuration information; The SD configuration information at least includes: the first SD and the BFR ID of the first ASBR.

6. A BIER route announcement method applied to IPv6, characterized in that: The method is applied to a network device in a second autonomous system (AS) in an inter-AS BIER scenario, and includes: When the network device is a second border router (ASBR), and the second ASBR is connected to a first ASBR in a first AS, then: Receive a routing update UPDATE message announced by a first ASBR in a first AS; the UPDATE message carries network layer reachability information NLRI and a bit-indexed display replication path attribute BIER Path Attribute; the NLRI includes at least a first BFR prefix of the first ASBR in the first SD; the BIER Path Attribute includes at least a BFRID collected by the first ASBR in the first AS; The NLRI and BIER Path Attribute are announced in the second AS so that any BFR in the second AS that receives the NLRI and BIER Path Attribute adds a corresponding BIFT forwarding table entry in the local position index forwarding table BIFT.

7. The method according to claim 6, characterized in that When the network device is any BFR except the second ASBR, the method further includes: When the NLRI and BIER Path Attribute announced by the second ASBR in the second AS are received, a corresponding BIFT forwarding table entry is added to the local position index forwarding table BIFT; the BIFT forwarding table entry includes at least: a BFR neighbor and a forwarding bit mask F-BM, the BFR neighbor is the first BFR prefix, and the F-BM represents the BFR ID corresponding to each BFR reachable through the BFR neighbor, wherein each BFR reachable through the BFR neighbor includes the BFR corresponding to the BFRID collected by the first ASBR in the first AS.

8. The method according to claim 7, characterized in that The method further comprises: When the original multicast message is received, the IPv6 message corresponding to the original multicast message is forwarded to the target BFR; the IPv6 message is obtained by encapsulating BIER information and IPv6 information on the original multicast message, and the BIER information at least includes a bit string Bitstring, and the bit corresponding to the BFR ID of the target BFR in the Bitstring is set to a first value for indicating forwarding, the BFR ID represented by the F-BM includes the BFR ID of the target BFR, and the outer IPv6 destination address in the IPv6 information is the first BFR prefix.

9. The method according to claim 6 or 8, characterized in that When the network device is a second ASBR, the method further includes: When the IPv6 message corresponding to the original multicast message is received, the IPv6 message is unicast forwarded according to the outer IPv6 destination address in the IPv6 message; the IPv6 message is obtained by encapsulating BIER information and IPv6 information on the original multicast message.

10. An electronic device, characterized in that: The electronic device includes: a processor and a machine-readable storage medium; The machine-readable storage medium stores machine-executable instructions that can be executed by the processor; The processor is configured to execute machine-executable instructions to implement the method steps of any one of claims 1-9.

Images