Bit-indexed explicit replication traffic engineering fast reroute

Abstract

This application discloses a method implemented by network nodes in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain. The method includes generating a fast reroute bit index forwarding table (FRR-BIFT), which contains backup paths for one or more bits from a network node to each next-hop node of its neighboring nodes; when a neighboring node fails, data packets are sent to the next-hop node of the neighboring node based on one or more bits in the backup paths of the FRR-BIFT.

Description

[0001] Cross-citation of related applications

[0002] This patent application claims the priority benefit of U.S. Patent Application No. 63 / 128,567, filed by Huaimo Chen on December 21, 2020, entitled “BIER-TE Fast Rerouting”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This invention generally relates to the field of fast re-route (FRR) protection, and more specifically to FRR protection provided for node failures in the Bit Index Explicit Replication-Traffic Engineering (BIER-TE) domain. Background Technology

[0004] The BIER mechanism optimizes multicast packet forwarding through BIER domains. BIER domains may not require explicit multicast distribution tree construction using protocols. Furthermore, BIER domains may not require intermediate nodes to maintain any flow-by-flow state. IJ. Wijnands et al. further described BIER in detail in their November 2017 Request for Comments (RFC) 8279, titled "Multicast Using Bit-Indexed Explicit Replication (BIER)".

[0005] Traffic engineering (TE) is the process of offloading traffic to a telecommunications network to facilitate efficient use of available bandwidth between a pair of routers. The IETF paper "Bit Index Explicit Replication (BIER) Tree Engineering (BIER-TE)" published by T. Eckert et al. on July 9, 2021, describes Bit Index Explicit Replication (BIER) traffic / tree engineering (BIER-TE). Summary of the Invention

[0006] The disclosed aspects / embodiments provide a fast rerouting process for the BIER-TE domain. To facilitate the implementation of the fast rerouting process, network nodes generate a fast reroute bit index forwarding table (FRR-BIFT) containing backup paths for one or more bits of each next-hop node from the network node to its neighboring nodes. When a neighboring node fails, the network node sends a data packet to the neighboring node's next-hop node based on the one or more bits in the backup path of the FRR-BIFT. Therefore, packet routing within the BIER-TE domain is improved.

[0007] The first aspect relates to a method implemented by a network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, comprising: generating a fast reroute bit index forwarding table (FRR-BIFT), wherein the FRR-BIFT contains backup paths from the network node to each next-hop node of a neighboring node of the network node, the backup paths being represented by one or more bits for indicating adjacency on the backup paths; and, when a neighboring node fails, sending data packets to the next-hop node of the neighboring node according to the one or more bits in the backup paths of the FRR-BIFT.

[0008] Alternatively, according to any of the above aspects, in another implementation of said aspect, when the neighbor node is working normally, the data packet is sent to the neighbor node according to the FRR-BIFT.

[0009] Optionally, according to any of the above aspects, in another implementation of said aspect, one or more bits in the point-to-multipoint (P2MP) path of the data packet are replaced with one or more bits of the backup path before the data packet is sent to the next-hop node of the neighboring node.

[0010] Optionally, according to any of the above aspects, in another implementation of said aspect, when the neighbor node is working normally, the entry in the backup entry active (BEA) field of the FRR-BIFT is set to a first value, and when the neighbor node fails, the entry in the backup entry active (BEA) field of the FRR-BIFT is set to a second value.

[0011] Alternatively, according to any of the above aspects, in another implementation of said aspect, the first value is 0 and the second value is 1.

[0012] Optionally, according to any of the above aspects, in another implementation of said aspect, when the BFER is located on the backup path to the next-hop node, but not on any branch of the point-to-multipoint (P2MP) path in the packet from the network node, the bit-forwarding egress router (BFER) bits in the packet are cleared before the packet is sent to the next-hop node.

[0013] Alternatively, according to any of the above aspects, in another implementation of said aspect, the FRR-BIFT is generated by the network node before receiving the data packet.

[0014] Alternatively, according to any of the above aspects, in another implementation of said aspect, the failure of the neighboring node is detected, wherein the FRR-BIFT is generated by the network node before the failure is detected.

[0015] Optionally, according to any of the above aspects, in another implementation of said aspect, sending the data packet to the next-hop node of the neighbor node includes: clearing the bits in the data packet that represent the adjacency relationship from the neighbor node to the next-hop node on the point-to-multipoint (P2MP) path, and when the next-hop node is located on the P2MP path, adding one or more bits from the backup path from the network node to the next-hop node to the data packet before sending the data packet to the next-hop node.

[0016] The second aspect relates to a network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, comprising: a memory storing instructions; and one or more processors coupled to the memory, wherein the one or more processors are configured to execute the instructions such that the network node: generates a fast reroute bit index forwarding table (FRR-BIFT), wherein the FRR-BIFT contains backup paths from the network node to each next-hop node of the network node's neighboring nodes, the backup paths being represented by one or more bits indicating adjacency relationships on the backup paths; and, when a neighboring node fails, sends data packets to the next-hop node of the neighboring node according to the one or more bits in the backup paths of the FRR-BIFT.

[0017] Alternatively, according to any of the above aspects, in another implementation of said aspect, the one or more processors are configured to send the data packet to the neighbor node according to the FRR-BIFT when the neighbor node is operating normally.

[0018] Optionally, according to any of the above aspects, in another implementation of said aspect, the FRR-BIFT includes a backup entry active (BEA) field, wherein an entry in the BEA field is set to indicate whether the neighboring node is working or has failed.

[0019] Optionally, according to any of the above aspects, in another implementation of said aspect, the one or more processors are configured to set an entry in the backup entry active (BEA) field of the FRR-BIFT to a first value when the neighbor node is working normally, and to set an entry in the backup entry active (BEA) field of the FRR-BIFT to a second value when the neighbor node fails.

[0020] Alternatively, according to any of the above aspects, in another implementation of said aspect, the first value is 0 and the second value is 1.

[0021] Optionally, according to any of the above aspects, in another implementation of said aspect, when the BFER is located on the backup path to the next-hop node, but not on any branch of the point-to-multipoint (P2MP) path in the packet from the network node, the bit-forwarding egress router (BFER) bits in the packet are cleared before the packet is sent to the next-hop node.

[0022] Alternatively, according to any of the above aspects, in another implementation of said aspect, the FRR-BIFT is generated by the network node before receiving the data packet.

[0023] Alternatively, according to any of the above aspects, in another implementation of said aspect, the one or more processors are used to detect the failure of the neighboring node, wherein the FRR-BIFT is generated by the network node before the failure is detected.

[0024] Optionally, according to any of the above aspects, in another implementation of said aspect, sending the data packet to the next-hop node of the neighbor node includes: clearing the bits in the data packet that represent the adjacency relationship from the neighbor node to the next-hop node on the point-to-multipoint (P2MP) path, and when the next-hop node is located on the P2MP path, adding one or more bits from the backup path from the network node to the next-hop node to the data packet before sending the data packet to the next-hop node.

[0025] The third aspect relates to a network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, comprising: generating a fast reroute bit index forwarding table (FRR-BIFT), wherein the FRR-BIFT contains backup paths from the network node to each next-hop node of the network node's neighboring nodes, the backup paths being represented by one or more bits indicating adjacency relationships on the backup paths; and when a neighboring node fails, sending data packets to the next-hop node of the neighboring node according to the one or more bits in the backup paths of the FRR-BIFT.

[0026] For clarity, any of the above embodiments can be combined with any one or more of the other embodiments described above to create new embodiments within the scope of the present invention.

[0027] These and other features will become clearer from the following detailed description in conjunction with the accompanying drawings and claims. Attached Figure Description

[0028] To gain a more complete understanding of the present invention, reference is made to the following brief description in conjunction with the accompanying drawings and specific embodiments, wherein similar reference numerals denote similar parts.

[0029] Figure 1 This is a schematic diagram of the BIER-TE topology, including the BIER-TE domain;

[0030] Figure 2 This is a schematic diagram of the fast reroute bit index forwarding table (FRR-BIFT) for network nodes provided in an embodiment of the present invention;

[0031] Figure 3 This is an algorithm provided by an embodiment of the present invention for implementing a part of the forwarding process using FRR-BIFT;

[0032] Figure 4 This is an algorithm provided by an embodiment of the present invention for implementing a part of the forwarding process using FRR-BIFT;

[0033] Figure 5 This is a method implemented by network nodes in the BIER-TE domain, provided by an embodiment of the present invention;

[0034] Figure 6 This is a schematic diagram of a network device provided in an embodiment of the present invention. Detailed Implementation

[0035] First, it should be understood that although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods can be implemented using any number of techniques, whether currently known or existing. The invention is by no means limited to the illustrative implementations, drawings, and techniques described below, including the exemplary designs and implementations illustrated and described herein, but can be modified within the full scope of the appended claims and their equivalents.

[0036] Existing BIER-TE FRR schemes have shortcomings. One approach is point-to-point (PTT) tunneling. In PTT, BIER-TE packets are rerouted by the point of local repair (PLR) near the fault to the next hop (NH) node and the NH node of the neighboring node via a unicast tunnel. The next hop is a routing term referring to the next nearest network node (e.g., a router) the packet can traverse. Therefore, PTT depends on the tunnel. However, tunneling can increase operation expense (OPEX). Another approach is BIET-in-BIER encapsulation (BBE). In BBE, BIER-TE packets are encapsulated with another BIER-TE header and then rerouted by the PLR ​​to the NH node and the NH node of the neighboring node. However, the additional BIER-TE header increases overhead. Yet another approach is header modification (HM). In HM, the AddBitMask and ResetBitmask functions are used to add a backup path to the existing BIER-TE header. However, this process may result in some destinations receiving duplicate packets.

[0037] This application discloses a fast rerouting process for BIER-TE domains. To facilitate the implementation of the fast rerouting process, network nodes generate a fast reroute bit index forwarding table (FRR-BIFT), which contains backup paths for one or more bits of each next-hop node from the network node to its neighboring nodes. When a neighboring node fails, the network node sends (e.g., forwards) data packets to the neighboring node's next-hop node based on the one or more bits in the backup path of the FRR-BIFT. Therefore, the packet routing method within the BIER-TE domain is improved.

[0038] Figure 1This is a schematic diagram of the BIER-TE topology 100, including BIER-TE domain 102. BIER-TE domain 102 can be part of a larger BIER-TE domain (not shown). Therefore, BIER-TE domain 102 can be referred to here as a BIER-TE subdomain. BIER-TE domain 102 includes multiple network nodes: 104, 106, 108, 110, 112, 114, 116, 118, and 119. Although network nodes 104-119 are shown in BIER-TE domain 102, in practice, BIER-TE domain 102 may include more or fewer nodes.

[0039] For ease of discussion, network nodes 104-119 are named with specific letters. For example, network node 104 is named A, network node 106 is named B, network node 108 is named C, network node 110 is named D, network node 112 is named E, network node 114 is named F, network node 116 is named G, network node 118 is named H, and network node 119 is named I.

[0040] Each of network nodes 104-119 is a bit forwarding router (BFR). Some network nodes, namely network nodes 104, 110, 112, 114, and 118, are located at the edge of the BIER-TE domain 102. Network nodes 104, 110, 112, 114, and 118 receive multicast packets from outside the BIER-TE domain 102 and can therefore be referred to as ingress BFRs (BFIRs). Network nodes 104, 110, 112, 114, and 118 transmit multicast packets outward from the BIER-TE domain 102 and can therefore be referred to as egress BFRs (BFERs). Depending on the direction of the multicast packet traffic, each of network nodes 104-118 can act as either a BFIR or a BFER.

[0041] like Figure 1 As shown, the bit positions (BP) used to represent the adjacency relationships of the forward-connected (fw-con) connections between various network nodes 104-119 have been marked. In the example shown, the BP of the fw-con adjacency relationship indicates how to reach the neighboring node and is denoted as i′, where i is an integer corresponding to one of the adjacency relationships of the forward connections between network nodes 104-119 in the BIER-TE field 102. Figure 1In the illustrated embodiment, the adjacency relationships of the 28 fw-con have a total of 28 BPs. However, in practical applications, the adjacency relationships of fw-con may have more or fewer BPs in other BIER-TE domains.

[0042] refer to Figure 1 The diagram illustrates how the BP (Block Buffer) used to represent the adjacency relationship of fw-con nodes is used. 7′ is the BP used to represent the adjacency relationship of fw-con nodes from node 104 to node 106, and 8′ is the BP used to represent the adjacency relationship of fw-con nodes from node 106 to node 104. 7′ is configured on the link from node 104 to node 106 and advertised to all network nodes in the network. 8′ is configured on the link from node 106 to node 104 and advertised to all network nodes in the network. As another example, 12′ is the BP used to represent the adjacency relationship of fw-con nodes from node 108 to node 110, and 11′ is the BP used to represent the adjacency relationship of fw-con nodes from node 110 to node 108. 12′ is configured on the link from node 108 to node 110 and advertised to all network nodes in the network. 11' is configured on the link from node 110 to node 108 and advertised to all network nodes in the network. Similarly, 14' is a BP used to represent the adjacency relationship of fw-con from node 108 to node 119, and 13' is a BP used to represent the adjacency relationship of fw-con from node 119 to node 108. 14' is configured on the link from node 108 to node 119 and advertised to all network nodes in the network. 13' is configured on the link from node 119 to node 108 and advertised to all network nodes in the network. Other BPs used to represent the adjacency relationship of fw-con can be determined in a similar manner, such as... Figure 1 The various values ​​of i′ are shown. For ease of discussion, each BP used to represent the adjacency relationship of fw-con can here be simply referred to as BP, adjacency relationship, or BP of adjacency relationship.

[0043] Each of network nodes 104, 110, 112, 114, and 118 can be referred to here as a destination network node or an egress BFR (BFER). Each of network nodes 104, 110, 112, 114, and 118 is assigned a BP, a set index (SI), and a BitString. The BP of a BFER is called a local decapsulation (decap) adjacency or local decapsulation BP. In the example shown, the BP of a BFER is denoted as j, where j is an integer corresponding to one of the local decapsulation adjacencies in BIER-TE field 102. Figure 1In the illustrated embodiment, the five network nodes 104, 110, 112, 114, and 118 operating as a BFER have five locally decapsulated adjacency relationships. For example, the BPs of network nodes 104, 110, 112, 114, and 118 are 5, 1, 3, 2, and 4, respectively. For simplicity, these BPs of locally decapsulated adjacency relationships are represented by (SI: BitString), where SI = 0 and BitString is 8 bits. BPs 1, 2, 3, 4, and 5 are represented by 1 (0: 00000001), 2 (0: 00000010), 3 (0: 00000100), 4 (0: 00001000), and 5 (0: 00010000), respectively. The BPs of the BFER are advertised to all network nodes in the network by the BFER.

[0044] In one embodiment, the BP used to represent the adjacency relationship of fw-con is represented by (SI: BitString), where SI is greater than or equal to 6 and BitString is 8 bits. For example, the SI of 2′ BP is 6 and BitString is 00000010 (commonly represented as 2′(6:00000010)). The SI of 4′ BP is 6 and BitString is 00001000 (commonly represented as 4′(6:00001000)). The SI of 6′ BP is 6 and BitString is 00100000 (commonly represented as 6′(6:00100000)). The SI of 8′ BP is 6 and BitString is 10000000 (commonly represented as 8′(6:10000000)). Thus, BP is represented by a number that indicates which bit is set in BitString.

[0045] Each network node in network nodes 104-119 has one or more neighbor nodes. As used herein, a neighbor node is a network node that is only one hop away from a given network node. For example, in Figure 1 In this example, network node 106 has four neighboring nodes: network node 104, network node 108, network node 112, and network node 116. In fact, each of these network nodes is only one hop away from network node 106.

[0046] Figure 1 Network nodes 104-119 are coupled to each other and communicate with each other via link 120. Link 120 can be wired, wireless, or some combination thereof. Each link 120 may have overhead. Depending on the BIER-TE network and the conditions therein, the overhead of each link 120 may be the same or different.

[0047] Figure 2 This is a schematic diagram of the fast reroute bit index forwarding table (FRR-BIFT) 200 for network nodes. Figure 1 In the BIER-TE topology 100, each network node 104-119 generates an FRR-BIFT 200. In one embodiment, the FRR-BIFT is generated based on the bit index routing table (BIRT) or bit index forwarding table (BIFT) (not shown) established by the network nodes 104-119.

[0048] Figure 2 The FRR-BIFT 200 shown is based on Figure 1 The FRR-BIFT 200 is located on network node 106 in the BIER-TE topology 100. As shown, FRR-BIFT 200 includes five columns of information. The first column 202 includes the BP, SI, and BitString for each adjacency directly coupled to network node 106 in the BIER-TE topology 100. The adjacency in column 202 can be a forward connection adjacency from network node 106 to a destination network node (e.g., network node 112 or network node 104), or a forward connection adjacency from network node 106 to a neighboring network node (e.g., network node 108 or network node 116). The second column 204 indicates the action to be taken by network node 106; in the example shown, it indicates a forward connection adjacency. The third column 206 identifies the neighboring node (BFR-NBR) of network node 106 through which the adjacent network node identified by the adjacency in the first column 202 can be reached. This is why the neighboring node in the third column 206 can also be referred to as the next-hop node of network node 106. The first column 202, the second column 204, and the third column 206 in FRR-BIFT 200 can be used by network node 106 during normal operation (i.e., when the network node identified in column 206 is functioning normally). In other words, these columns are used when the entry in the backup entry active (BEA) field is set to 0.

[0049] Column 4, 218, includes the Backup Entry Active (BEA) field. The BEA field is set to indicate whether the network node identified in column 206 (i.e., the BFR-NBR or next-hop node) is active or has failed. For example, when the BEA field is set to 0, the network node identified in column 206 is active. However, when the BEA field is set to 1, the network node identified in column 206 is not active (i.e., has failed). Columns 4, 218, and 5, 220 in FRR-BIFT 200 can be used by network node 106 during abnormal operation (i.e., when the network node identified in column 206 is not active or has failed). That is, these columns are used when the BEA field is set to 1.

[0050] Column 5, 220, includes the Backup Path field. The entries in the Backup Path field identify the backup path used to reach each next-hop node of a network node when its neighboring nodes are malfunctioning or failing. For example... Figure 2 As shown, a backup path may include one or more BPs (e.g., 4′ and 10′) in an ordered set. For example, the backup path field in the first row 208 of FRR-BIFT 200 includes the expression B→F: {4′, 10′}. This expression indicates a backup path from network node 106 (also known as network node B) to network node 114 (also known as network node F), which is the next-hop node of network node 112 (also known as network node E) identified in the third column 206. This backup path follows the forward connection adjacency relation 4′ (i.e., the BP used to represent the forward connection adjacency relation from network node 106 to network node 108) and then to 10′ (i.e., the BP used to represent the forward connection adjacency relation from network node 108 to network node 114).

[0051] The backup path field in the second row 210 of FRR-BIFT 200 identifies backup paths to each next-hop node of network node 108 (also known as network node C) without passing through node 108. The first backup path includes the expression B→F: {2′, 22′}. This expression indicates a backup path from network node 106 to network node 114, which is the next-hop node of network node 108 (also known as network node C) identified in the third column 206. This backup path follows the forward connection adjacency relation 2′ (i.e., the BP used to represent the forward connection adjacency relation from network node 106 to network node 112) and then to 22′ (i.e., the BP used to represent the forward connection adjacency relation from network node 112 to network node 114).

[0052] The second backup path includes the expression B→D: {6′, 20′, 27′}. This expression indicates that the backup path from network node 106 to network node 110 is along the forward connection adjacency 6′ (i.e., the BP used to represent the forward connection adjacency from network node 106 to network node 116), then along 20′ (i.e., the BP used to represent the forward connection adjacency from network node 116 to network node 118), and then to 27′ (i.e., the BP used to represent the forward connection adjacency from network node 118 to network node 110). The third backup path includes the expression B→I: {6′, 17′}. This expression indicates a backup path from network node 106 to network node 119, which follows the adjacency relation 6′ (i.e., the BP used to represent the adjacency relation of the forward connection from network node 106 to network node 116) and then to 17′ (i.e., the BP used to represent the adjacency relation of the forward connection from network node 116 to network node 119).

[0053] The backup path field in row 212 of FRR-BIFT 200 identifies backup paths to each next-hop node of network node 116 (also known as network node G) without passing through node G. The first backup path includes the expression B→I: {4′, 14′}. This expression indicates a backup path from network node 106 to network node 119, which is the next-hop node of network node 116 (also known as network node G) identified in column 206. This backup path follows the forward connection adjacency relation 4′ (i.e., the BP used to represent the forward connection adjacency relation from network node 106 to network node 108) and then to 14′ (i.e., the BP used to represent the forward connection adjacency relation from network node 108 to network node 119).

[0054] The second backup path includes the expression B→H: {4′, 14′, 16′}. This expression indicates that the backup path from network node 106 to network node 118 is along the forward connection adjacency 4′ (i.e., the BP used to represent the forward connection adjacency from network node 106 to network node 108), then along 14′ (i.e., the BP used to represent the forward connection adjacency from network node 108 to network node 119), and then to 16′ (i.e., the BP used to represent the forward connection adjacency from network node 119 to network node 118). The third backup path includes the expression B→A: {8′}. This expression indicates the backup path from network node 106 to network node 104, which is along the forward connection adjacency 8′ (i.e., the BP used to represent the forward connection adjacency from network node 106 to network node 104).

[0055] The backup path field in line 214 of FRR-BIFT 200 identifies backup paths to each next-hop node of network node 104 (also known as network node A) without passing through node 104. The first backup path includes the expression B→G: {6′}. This expression indicates a backup path from network node 106 to network node 116, which is the next-hop node of network node 104 (also known as network node A) identified in column 206, along the adjacency relation 6′ of the forward connection (i.e., BP used to represent the adjacency relation of the forward connection from network node 106 to network node 116).

[0056] Remember the above information and refer to it. Figure 1 . Figure 1 This illustrates how packets are routed during normal operation and during a failure. During normal operation, when network node 104 receives a packet, it adds or encapsulates a point-to-multipoint (P2MP) path into the packet. For example, network node 104 adds the P2MP path {26′, 20′, 7′, 4′, 12′, 4, 1} from node A to nodes D and H to the received packet. Subsequently, network node 104 removes its adjacency relations 26′ and 7′ from the packet, makes a first copy of the packet, and transmits the first copy of the packet to network node 116 using adjacency relation 26′ (i.e., the forwarding table entry for adjacency relation 26′ in the forward join established on network node 104). Network node 104 also makes a second copy of the data packet, removes its adjacency relations 26′ and 7′ from the second copy, and sends the second copy to network node 106 using adjacency relation 7′ (i.e., the forwarding table entry of adjacency relation 7′ in the forward connection established on network node 104 in FRR-BIFT).

[0057] Network node 116 receives the data packet, which now contains the path {20′, 4′, 12′, 4, 1}. Network node 116 removes its adjacency 20′ from the data packet and uses adjacency 20′ (i.e., the forwarding table entry for adjacency 20′ in the forward connection of FRR-BIFT established on network node 116) to forward the data packet to network node 118. Network node 118 receives the data packet, which now contains the path {4′, 12′, 4, 1}. Network node 118 decapsulates the data packet with BP=4 for BFER H (i.e., egress node 118) and forwards the payload of the data packet to the multicast overlay network.

[0058] Network node 106 receives a data packet containing the path {20′, 4′, 12′, 4, 1}. Network node 106 removes its adjacency 4′ from the data packet and uses adjacency 4′ (i.e., the forwarding table entry for adjacency 4′ in the FRR-BIFT established on network node 106) to forward the data packet to network node 108. Network node 108 receives the data packet containing the path {20′, 12′, 4, 1}. Network node 108 removes its adjacency 12′ from the data packet and uses adjacency 12′ (i.e., the forwarding table entry for adjacency 12′ in the FRR-BIFT established on network node 108) to forward the data packet to network node 110. Network node 110 receives the data packet, now containing the path {20′, 4, 1}. Network node 118 decapsulates the data packet with BP=1 for BFER D (i.e., egress node 110) and transmits the payload of the data packet to the multicast overlay network.

[0059] During abnormal operation (e.g., network node 108 fails), when network node 104 receives a data packet, network node 104 adds or encapsulates a point-to-multipoint (P2MP) path into the data packet. For example, network node 104 adds the path {26′, 20′, 7′, 4′, 12′, 4, 1} from node A to nodes D and H to the received data packet. Afterward, network node 104 removes its adjacency relations 26′ and 7′ from the data packet, makes a first copy of the data packet, and transmits the first copy of the data packet to network node 116 using adjacency relation 26′. Network node 104 also makes a second copy of the data packet, removes its adjacency relations 26′ and 7′ from the second copy, and sends the second copy to network node 106 using adjacency relation 7′.

[0060] Network node 116 receives the data packet, which now contains the path {20′, 4′, 12′, 4, 1}. Network node 116 removes its adjacency 20′ from the data packet and uses adjacency 20′ to transmit the data packet to network node 118. Network node 118 receives the data packet, which now contains the path {4′, 12′, 4, 1}. Network node 118 decapsulates the data packet with BP of 4 and transmits the payload of the data packet to the multicast overlay network.

[0061] Network node 106 receives a data packet containing the path {20′, 4′, 12′, 4, 1}. Network node 106 removes its adjacency 4′ from the data packet. Since network node 108, a neighboring node of network node 106, has failed, network node 106 removes BP 12′, which represents the forward connection from the failed node 108 to network node 110, where network node 110 is the next-hop node of the failed node 108 and is on the path in the data packet. Since BFER H is not on the path branch in the data packet from network node 106, network node 106 removes BP 4 (i.e., the local decapsulation adjacency of BFER H) from the path in the data packet on the backup path and adds BP for the backup path from network node 106 to network node 110. The added BP is {6′, 20′, 27′}. Therefore, the data packet now contains the path {6′, 20′, 27′, 1}. Subsequently, network node 106 removes its adjacency relation 6′ from the data packet and uses adjacency relation 6′ to transmit the data packet to network node 116.

[0062] Network node 116 receives the data packet containing the path {20′, 27′, 1}. Network node 116 removes its adjacency 20′ from the data packet and uses adjacency 20′ to transmit the data packet to network node 118. Network node 118 receives the data packet, now containing the path {27′, 1}. Network node 118 removes its adjacency 27′ from the data packet and uses adjacency 27′ to transmit the data packet to network node 110. Network node 110 receives the data packet, now containing the path {1}. Network node 110 decapsulates the data packet with BP=1 for BFER D (i.e., egress node 110) and transmits the payload of the data packet to the multicast overlay network.

[0063] As shown in the figure. Figure 3 This is an algorithm 300 according to embodiments of the present disclosure for implementing a forwarding process using FRR-BIFT as part of a forwarding process. Specifically, algorithm 300 can be used to clear bits (also known as adjacency relations) in the P2MP path encoded in packets on the backup path as described above.

[0064] For a relay point BFR-NBR N on a P2MP path encoded in a packet, when a network node detects a failure of N (also known as a neighboring node of the network node), the network node sets the value of BEA in the corresponding row of the FRR-BIFT established on the network node to 1, and the BFR-NBR in the corresponding column of that row is N. If N fails (i.e., BEA is 1), the network node clears the BP used to represent the adjacency relationship from the network node to N. For any BP on a BFER on a path encoded in a packet, if the BFER is on a backup path and not on a branch of the P2MP path encoded in a packet from a network node that is a point of local repair (PLR), the network node removes the BP of the BFER from the path. For each next-hop node of N on the path encoded in the data packet, the network node removes the BP used to represent the adjacency relationship from N to the next-hop node, makes a copy of the data packet, and sends the data packet copy to the next-hop node along the backup path from the network node to the next-hop node by adding the BP of the backup path established in the FRR-BIFT on the network node to the data packet copy.

[0065] As shown in the figure. Figure 4 This is an algorithm 400 according to embodiments of the present disclosure for implementing a forwarding process using FRR-BIFT as part of a forwarding process. Specifically, algorithm 400 can be used to remove bits (also known as adjacency relations) from the point-to-multipoint (P2MP) path encoded in the data packets as described above.

[0066] Upon receiving a data packet, for each BP k (starting from the right side of the BitString in the data packet), if BPk represents a local decapsulation adjacency (i.e., the BP of the egress node), the network node makes a copy of the data packet, sends the copy to the multicast stream overlay network, and clears bit k from the BitString of the data packet.

[0067] If BP k represents the adjacency relationship of the forward connection of a BFR (i.e., a network node), the network node uses BP k to find the forwarding table entry for the BIER-TE field in the FRR-BIFT. If the neighboring node fails (BEA is 1), the network node removes BP k from the bitstring of the packet. For each BP j in the bitstring of the BFER of the packet, if BP j is on the backup path and the BP in the bitstring cannot reach BP j from the network node, then BP j is removed from the bitstring of the packet.

[0068] For each next-hop node of a neighboring node on a point-to-multipoint (P2MP) path in the packet's BitString, the network node clears the BP used to represent the adjacency relationship from the neighboring node to the next-hop node and adds the BP of the backup path to the next-hop node of the neighboring node to the packet's BitString.

[0069] Otherwise, the network node makes a copy of the packet by updating the bitstring of the packet by clearing all BPs used to represent the BFR (i.e., network node) adjacency relationship, and sends the updated copy to the BFR-NBR.

[0070] As shown in the figure. Figure 5 Method 500 is implemented by a network node (e.g., network node 106) in a BIER-TE domain according to an embodiment of this disclosure. This method can be executed by the network node to facilitate a fast rerouting process.

[0071] In block 502, the network node generates a fast reroute bitindex forwarding table (FRR-BIFT), which contains backup paths from the network node to each next-hop node of the network node's neighboring nodes, and the backup paths are represented by one or more bits used to indicate the adjacency relationship on the backup paths.

[0072] In one embodiment, before sending the packet to the next-hop node of the neighboring node, the network node replaces one or more bits in the point-to-multipoint (P2MP) path of the packet with one or more bits of the backup path. In one embodiment, the FRR-BIFT includes a backup entry active (BEA) field, where an entry in the BEA field is set to indicate whether the neighboring node is active or has failed. In one embodiment, when the neighboring node is active, the network node sets the entry in the backup entry active (BEA) field of the FRR-BIFT to a first value; when the neighboring node fails, it sets the entry in the backup entry active (BEA) field of the FRR-BIFT to a second value. In one embodiment, the first value is 0 and the second value is 1.

[0073] In block 504, when the neighboring node fails, the network node sends (e.g., forwards) a data packet to the neighboring node's next-hop node according to the backup path of the FRR-BIFT. In one embodiment, when the neighboring node fails, the network node sends a data packet to the neighboring node's next-hop node according to one or more bits in the backup path of the FRR-BIFT. In one embodiment, when the neighboring node is functioning normally, the network node forwards the data packet to the neighboring node according to the FRR-BIFT.

[0074] In one embodiment, when the BFER is located on the backup path to the next-hop node, but not on any path branch of the P2MP path in the packet from the network node, the network node clears the bit-forwarding egress router (BFER) bits in the packet before sending the packet to the next-hop node. In one embodiment, the FRR-BIFT is generated by the network node before receiving the packet.

[0075] In one embodiment, the network node detects a failure in the neighboring node, wherein the FRR-BIFT is generated by the network node prior to detecting the failure. In one embodiment, sending the packet to the next-hop node of the neighboring node includes: removing bits from the packet representing the adjacency relationship from the neighboring node to the next-hop node on the point-to-multipoint (P2MP) path, and adding one or more bits from the backup path from the network node to the next-hop node to the packet before forwarding the packet to the next-hop node when the next-hop node is located on the P2MP path.

[0076] As shown in the figure. Figure 6This is a schematic diagram of a network device 600 (e.g., a network node, a destination node, a neighbor node, etc.). Network device 600 is suitable for implementing the embodiments disclosed herein. Network device 600 includes an ingress port / ingress device 610 and a receiver unit (Rx) / receiver unit 620 for receiving data; a processor, logic unit, or central processing unit (CPU) / processing device 630 for processing data; a transmitter unit (Tx) / transmitter unit 640 and an egress port / egress device 650 for transmitting data; and a memory / memory device 660 for storing data. Network device 600 may also include optical-to-electrical (OE) components and electro-optical (EO) components coupled to the ingress port / ingress device 610, the receiver unit / receiver unit 620, the transmitter unit / transmitter unit 640, and the egress port / egress device 650 for the entry or exit of optical or electrical signals.

[0077] Processor / processing device 630 is implemented by hardware and software. Processor / processing device 630 can be implemented as one or more CPU chips, one or more cores (e.g., implemented as a multi-core processor), one or more field-programmable gate arrays (FPGAs), one or more application-specific integrated circuits (ASICs), and one or more digital signal processors (DSPs). Processor / processing device 630 communicates with ingress port / ingress device 610, receiver unit / receiver device 620, transmitter unit / transmitter device 640, egress port / egress device 650, and memory / memory device 660. Processor / processing device 630 includes a BIER-TE fast rerouting module 670. BIER-TE fast rerouting module 670 is capable of implementing the methods disclosed herein. Therefore, including BIER-TE fast rerouting module 670 provides a substantial improvement to the functionality of network device 600 and enables the transition of network device 600 to different states. Alternatively, the BIER-TE fast rerouting module 670 can be implemented as instructions stored in memory / memory device 660 and executed by processor / processing device 630.

[0078] Network device 600 may also include input and / or output (I / O) devices or I / O devices 680 for sending or receiving communication data to or from users. I / O devices or I / O devices 680 may include output devices, such as a display for showing video data, a speaker for outputting audio data, etc. I / O devices or I / O devices 680 may also include input devices, such as a keyboard, mouse, trackball, etc., and / or corresponding interfaces for interacting with these output devices.

[0079] The memory / memory device 660 includes one or more disk drives, tape drives, and solid-state drives, and can be used as an overflow data storage device to store such a program when a program is selected for execution, and to store instructions and data read during program execution. The memory / memory device 660 can be volatile and / or non-volatile, and can be read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and / or static random-access memory (SRAM).

[0080] While this invention provides several embodiments, it should be understood that the disclosed systems and methods can also be embodied in many other specific forms without departing from the spirit or scope of the invention. These examples are intended to be illustrative rather than restrictive and are not intended to be limited to the details given herein. For example, various elements or components may be combined or integrated into another system, or some features may be omitted or not implemented.

[0081] Furthermore, the techniques, systems, subsystems, and methods described and illustrated as discrete or separate in the various embodiments may be combined or integrated with other systems, components, techniques, or methods without departing from the scope of the invention. Those skilled in the art can identify other examples of changes, substitutions, and modifications, and make such changes, substitutions, and modifications without departing from the spirit and scope of the invention.

Claims

1. A method implemented by network nodes in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, characterized in that, include: Generate a fast reroute bit index forwarding table (FRR-BIFT), wherein the FRR-BIFT contains backup paths from the network node to each next-hop node of the network node's neighboring nodes, and the backup paths are represented by one or more bits for indicating the adjacency relationship on the backup paths; When the neighboring node fails, a data packet is sent to the next-hop node of the neighboring node according to the backup path of the FRR-BIFT.

2. The method according to claim 1, characterized in that, Also includes: When the neighboring node is working normally, the data packet is sent to the neighboring node according to the FRR-BIFT.

3. The method according to any one of claims 1-2, characterized in that, Also includes: Before sending the data packet to the next-hop node of the neighbor node, one or more bits in the point-to-multipoint (P2MP) path of the data packet are replaced with one or more bits of the backup path.

4. The method according to any one of claims 1-3, characterized in that, Also includes: When the neighbor node is working normally, the entry in the backup entry active (BEA) field of the FRR-BIFT is set to the first value; when the neighbor node fails, the entry in the backup entry active (BEA) field of the FRR-BIFT is set to the second value.

5. The method according to claim 4, characterized in that, The first value is 0, and the second value is 1.

6. The method according to any one of claims 1-5, characterized in that, Also includes: When the BFER is located on the backup path to the next-hop node, but not on any branch of the point-to-multipoint (P2MP) path in the packet from the network node, the bit-forwarding egress router (BFER) bits in the packet are cleared before the packet is sent to the next-hop node.

7. The method according to any one of claims 1-6, characterized in that, The FRR-BIFT is generated by the network node before it receives the data packet.

8. The method according to any one of claims 1-7, characterized in that, Also includes: Detecting faults in neighboring nodes, wherein the FRR-BIFT is generated by the network node before the fault is detected.

9. The method according to any one of claims 1-8, characterized in that, Sending the data packet to the next-hop node of the neighbor node includes: clearing the bits in the data packet that represent the adjacency relationship from the neighbor node to the next-hop node on the point-to-multipoint (P2MP) path, and when the next-hop node is located on the P2MP path, adding one or more bits from the backup path from the network node to the next-hop node to the data packet before sending the data packet to the next-hop node.

10. A network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, characterized in that, include: Memory that stores instructions; One or more processors coupled to the memory, wherein the one or more processors are configured to execute the instructions causing the network node to: Generate a fast reroute bit index forwarding table (FRR-BIFT), wherein the FRR-BIFT contains backup paths from the network node to each next-hop node of the network node's neighboring nodes, and the backup paths are represented by one or more bits for indicating the adjacency relationship on the backup paths; When the neighboring node fails, a data packet is sent to the next-hop node of the neighboring node according to the backup path of the FRR-BIFT.

11. The network node according to claim 10, characterized in that, The one or more processors are used to send the data packet to the neighbor node according to the FRR-BIFT when the neighbor node is working normally.

12. The network node according to any one of claims 10-11, characterized in that, The one or more processors are configured to replace one or more bits in the point-to-multipoint (P2MP) path of the data packet with one or more bits of the backup path before sending the data packet to the next-hop node of the neighbor node.

13. The network node according to any one of claims 10-12, characterized in that, The one or more processors are configured to: set the entry in the backup entry active (BEA) field of the FRR-BIFT to a first value when the neighbor node is working normally, and set the entry in the backup entry active (BEA) field of the FRR-BIFT to a second value when the neighbor node fails.

14. The network node according to claim 13, characterized in that, The first value is 0, and the second value is 1.

15. The network node according to any one of claims 10-14, characterized in that, Also includes: When the BFER is located on the backup path to the next-hop node, but not on any branch of the point-to-multipoint (P2MP) path in the packet from the network node, the bit-forwarding egress router (BFER) bits in the packet are cleared before the packet is sent to the next-hop node.

16. The network node according to any one of claims 10-15, characterized in that, The FRR-BIFT is generated by the network node before it receives the data packet.

17. The network node according to any one of claims 10-16, characterized in that, The one or more processors are used to detect faults in the neighboring nodes, wherein the FRR-BIFT is generated by the network node before the fault is detected.

18. The network node according to any one of claims 10-17, characterized in that, Sending the data packet to the next-hop node of the neighbor node includes: clearing the bits in the data packet that represent the adjacency relationship from the neighbor node to the next-hop node on the point-to-multipoint (P2MP) path, and when the next-hop node is located on the P2MP path, adding one or more bits from the backup path from the network node to the next-hop node to the data packet before sending the data packet to the next-hop node.

19. A network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, characterized in that, include: A generating device is used to generate a fast reroute bit index forwarding table (FRR-BIFT), wherein the FRR-BIFT contains backup paths from the network node to each next-hop node of the network node's neighboring nodes, and the backup paths are represented by one or more bits for indicating adjacency relationships on the backup paths; A sending device is used to send data packets to the next-hop node of the neighbor node according to the backup path of the FRR-BIFT when the neighbor node fails.

Images