Bit-indexed explicit replication traffic engineering egress protection

Abstract

A method implemented by a network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain for providing fast egress protection. The method comprises: receiving a type length value (TLV) structure, wherein the TLV structure comprises a bit position of a backup egress node of a primary egress node; generating an egress protection bit index forwarding table (EP-BIFT) according to the bit position of the backup egress node when the network node is adjacent to the primary egress node, wherein the EP-BIFT comprises a backup path to the backup egress node; and forwarding a packet according to the EP-BIFT when the primary egress node fails.

Description

[0001] Cross-referencing related applications

[0002] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 127,613, filed on December 18, 2020, entitled “BIER-TE Egress Protection”, the contents of which are incorporated herein by reference. Technical Field

[0003] This invention generally relates to the field of egress protection, and more particularly to egress protection against failure of nodes or links in the BitIndex Explicit Replication-Traffic Engineering (BIER-TE) domain. Background Technology

[0004] The BIER mechanism optimizes the forwarding of multicast datagrams through BIER domains. BIER domains may not require explicit construction of the multicast distribution tree using protocols. Furthermore, BIER domains may not require intermediate nodes to maintain any flow state. BIER is detailed in the following literature: Request for Comments (RFC) 8279 of the Internet Engineering Task Force (IETF), titled "Multicast Using BitIndex Explicit Replication (BIER)". (IJ. Wijnands et al., November 2017)

[0005] Traffic engineering (TE) is a process of directing traffic to a telecommunications network to facilitate efficient use of available bandwidth by a pair of routers. Bit Index Explicit Replication (BIER) traffic / tree engineering (BIER-TE) is described in the IETF document “Tree Engineering for Bit Index Explicit Replication (BIER-TE)” published by T. Eckert et al. on July 9, 2021. Summary of the Invention

[0006] The disclosed aspects / implementations provide fast egress protection (EP) for the BIER-TE domain. To facilitate the fast egress protection process, the network node upstream of the egress node establishes an egress protection bit index forwarding table (EP-BIFT). The network node uses EP-BIFT to forward packets in the event of an egress node failure. 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. The method includes: receiving a type length value (TLV) structure, wherein the TLV structure includes bit positions of a backup egress node of a primary egress node; when the network node is adjacent to the primary egress node, generating an egress protection bit index forwarding table (EP-BIFT) based on the bit positions of the backup egress node, wherein the EP-BIFT includes a backup path to the backup egress node; and when the primary egress node fails, forwarding packets along the backup path.

[0008] Optionally, according to any of the above aspects, in one implementation of said aspect, the TLV structure is received from the primary egress node or a neighboring network node.

[0009] Alternatively, according to any of the above aspects, in another implementation of said aspect, the TLV structure includes an entry indicating whether the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver or to different CE receivers.

[0010] Optionally, according to any of the above aspects, in another implementation of said aspect, the EP-BIFT includes an entry indicating whether the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver or to different CE receivers, the entry being set in the same CE receiver (SC) field in the EP-BIFT.

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

[0012] Alternatively, according to any of the above aspects, in another implementation of said aspect, the backup exit node is identified in the backup path field of the EP-BIFT.

[0013] Optionally, according to any of the above aspects, in another implementation of said aspect, generating EP-BIFT includes: generating the backup path in the backup path field, wherein when the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver, the backup path includes the bit position of the forward connection adjacency of intermediate nodes on the backup path to the backup egress node and the bit position of the backup egress node of the primary egress node.

[0014] Optionally, according to any of the above aspects, in another implementation of said aspect, generating EP-BIFT includes: generating the backup path in the backup path field, wherein, when the primary egress node and the backup egress node send the message to different customer edge (CE) receivers, the backup path includes the bit position of the forward connection adjacency of intermediate nodes on the backup path leading to the backup egress node and the bit position of the primary egress node.

[0015] The second aspect relates to a network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain. The network node includes: 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 to cause the network node to perform the following operations: receive a type length value (TLV) structure, wherein the TLV structure includes bit positions of backup egress nodes of a primary egress node; when the network node is adjacent to the primary egress node, generate an egress protection bit index forwarding table (EP-BIFT) based on the bit positions of the backup egress nodes, wherein the EP-BIFT includes a backup path to the backup egress node; and when the primary egress node fails, forward packets along the backup path.

[0016] Optionally, according to any of the above aspects, in one implementation of said aspect, the TLV structure is received from the primary egress node or a neighboring network node.

[0017] Alternatively, according to any of the above aspects, in another implementation of said aspect, the TLV structure includes an entry indicating whether the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver or to different CE receivers.

[0018] Optionally, according to any of the above aspects, in another implementation of said aspect, the EP-BIFT includes an entry indicating whether the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver or to different CE receivers, the entry being set in the same CE receiver (SC) field in the EP-BIFT.

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

[0020] Alternatively, according to any of the above aspects, in another implementation of said aspect, the backup exit node is identified in the backup path field of the EP-BIFT.

[0021] Optionally, according to any of the above aspects, in another implementation of said aspect, generating EP-BIFT includes: generating the backup path in the backup path field, wherein when the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver, the backup path includes the bit position of the forward connection adjacency of intermediate nodes on the backup path to the backup egress node and the bit position of the backup egress node of the primary egress node.

[0022] Optionally, according to any of the above aspects, in another implementation of said aspect, generating EP-BIFT includes: generating the backup path in the backup path field, wherein, when the primary egress node and the backup egress node send the message to different customer edge (CE) receivers, the backup path includes the bit position of the forward connection adjacency of intermediate nodes on the backup path leading to the backup egress node and the bit position of the primary egress node.

[0023] The third aspect relates to a method implemented by network nodes in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain. The method includes: generating a type length value (TLV) structure, wherein the TLV structure includes the bit positions of backup egress nodes of the primary egress node; and sending the TLV structure to neighboring network nodes of the primary egress node.

[0024] Optionally, according to any of the above aspects, in one implementation of said aspect, the TLV structure is an open shortest path first (OSPF) backup egress TLV.

[0025] Alternatively, according to any of the above aspects, in another implementation of said aspect, the TLV structure is an intermediate system-intermediate system (IS-IS) backup exit TLV.

[0026] Optionally, according to any of the above aspects, in another implementation of said aspect, the TLV structure includes an entry indicating whether the primary egress node and the backup egress node send messages to the same customer edge (CE) or to different customer edges (CEs).

[0027] The fourth aspect relates to a network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain. The network node includes: a receiving component for receiving a type length value (TLV) structure, wherein the TLV structure includes the bit positions of a backup egress node of the primary egress node; a generating component for generating an egress protection bit index forwarding table (EP-BIFT) based on the bit positions of the backup egress node when the network node is adjacent to the primary egress node, wherein the EP-BIFT includes a backup path to the backup egress node; and a forwarding component for forwarding packets along the backup path when the primary egress node fails.

[0028] The fifth aspect relates to a network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain. The network node includes: a generation component for generating a type length value (TLV) structure, wherein the TLV structure includes the bit positions of backup egress nodes of the primary egress node; and a transmission component for transmitting the TLV structure to neighboring network nodes of the primary egress node.

[0029] 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.

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

[0031] 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 the same reference numerals denote the same parts.

[0032] Figure 1 This is a schematic diagram of the BIER-TE topology, which includes the BIER-TE domain.

[0033] Figure 2 This is a schematic diagram of an egress protection bit index forwarding table (EP-BIFT) for a network node provided in an embodiment of the present invention.

[0034] Figure 3 This is a schematic diagram of an EP-BIFT backup egress node provided in one embodiment of the present invention.

[0035] Figure 4 This is an embodiment of the Open Shortest Path First (OSPF) type length value (TLV) structure provided by the present invention.

[0036] Figure 5 This is an embodiment of the present invention that provides an intermediate system-intermediate system (IS-IS) type length value (TLV) structure.

[0037] Figure 6This is an algorithm provided by one embodiment of the present invention that uses EP-BIFT to implement part of the forwarding process.

[0038] Figure 7 This is an algorithm provided by one embodiment of the present invention that uses EP-BIFT to implement part of the forwarding process.

[0039] Figure 8 This is a method implemented by network nodes in the BIER-TE domain, provided by one embodiment of the present invention.

[0040] Figure 9 This is a schematic diagram of a network device provided in one embodiment of the present invention. Detailed Implementation

[0041] 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.

[0042] Currently, there is no fast protection technology to prevent the failure of egress nodes in the BIER-TE domain. Therefore, when an egress node in the BIER-TE domain fails, the customer edge (CE) receiver will not receive request messages.

[0043] This paper discloses a fast egress protection (EP) method for the BIER-TE domain. To facilitate the fast egress protection process, the network node upstream of the egress node establishes an egress protection bit index forwarding table (EP-BIFT). The network node uses EP-BIFT to forward packets when the egress node fails. Therefore, packet routing within the BIER-TE domain is improved.

[0044] Figure 1This is a schematic diagram of a BIER-TE topology 100 including BIER-TE domain 102. BIER-TE domain 102 may be part of a larger BIER-TE domain (not shown). Therefore, BIER-TE domain 102 may be referred to herein as a BIER-TE subdomain. BIER-TE domain 102 includes multiple network nodes 104, 106, 108, 110, 112, 114, 116, and 118. Although eight network nodes 104 to 118 are shown in BIER-TE domain 102, more or fewer nodes may be included in practical applications.

[0045] For ease of discussion, network nodes 104 to 118 are all provided with letter identifiers. For example, network node 104 has the identifier A, network node 106 has the identifier B, network node 108 has the identifier C, network node 110 has the identifier D, network node 112 has the identifier E, network node 114 has the identifier F, network node 116 has the identifier G, and network node 118 has the identifier H.

[0046] Network nodes 104 through 118 are all bit-forwarding routers (BFRs). 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 that receive multicast messages from outside the BIER-TE domain 102 can be called ingress BFRs (BFIRs). Network nodes 104, 110, 112, 114, and 118 that send multicast messages from within the BIER-TE domain 102 can be called egress BFRs (BFERs). Depending on the direction of the multicast message traffic, network nodes 104 through 118 can be used as either BFIRs or BFERs.

[0047] like Figure 1 As shown, the bit position (BP) identifies the forward connection (fw-con) adjacency between each network node 104 to 118. In the illustrated example, the BP of the fw-con adjacency is denoted as i′, where i is an integer corresponding to one of the forward adjacencies between network nodes 104 to 118 in the BIER-TE field 102. Figure 1 In the illustrated embodiment, the 20 fw-con adjacencies have a total of 20 BPs. However, in practical applications, other BIER-TE domains may have more or fewer BPs for their fw-con adjacencies.

[0048] To combine Figure 1Taking the operation of fw-con adjacency BPs as an example, 7′ is a BP fw-con adjacency from node 104 to node 106, and 8′ is a BP fw-con adjacency 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. Similarly, 18′ is a BP fw-con adjacency from node 108 to node 110, and 17′ is a BP fw-con adjacency from node 110 to node 108. 18′ is configured on the link from node 108 to node 110 and advertised to all network nodes in the network. 17′ is configured on the link from node 110 to node 108 and advertised to all network nodes in the network. Similarly, 10′ is the BP adjacent to the fw-con link from node 108 to node 118, and 9′ is the BP adjacent to the fw-con link from node 118 to node 108. 10′ is configured on the link from node 108 to node 118 and advertised to all network nodes in the network. 9′ is configured on the link from node 118 to node 108 and advertised to all network nodes in the network. Other BPs adjacent to the fw-con link can be determined in a similar manner by… Figure 1 The various values ​​of i′ in the diagram are represented. For ease of discussion, each BP adjacent to fw-con can be simply referred to as BP or adjacency in this paper.

[0049] Network nodes 104, 110, 112, 114, and 118 can all be referred to as destination network nodes or egress BFRs (BFERs) in this paper. Network nodes 104, 110, 112, 114, and 118 are all assigned a BP, a set index (SI), and a bit string. The BP of a BFER is called a local decapped adjacency or local decap BP. In the illustrated example, the BP of a BFER is denoted as j, where j is an integer corresponding to one of the local decapped adjacencies in the BIER-TE field 102. Figure 1In the illustrated embodiment, the five BFERs 104, 110, 112, 114, and 118 have five local decap adjacencies. For example, the BPs of BFERs 104, 110, 112, 114, and 118 are 5, 1, 3, 2, and 4, respectively. For simplicity, these BPs of local decap adjacencies are represented by (SI: BitString), where SI = 0 and BitString is 5 bits. BPs 1, 2, 3, 4, and 5 are uniformly represented by 1 (0:00001), 2 (0:00010), 3 (0:00100), 4 (0:01000), and 5 (0:10000), respectively. The BPs of the BFERs are advertised by the BFERs to all nodes in the network.

[0050] In one embodiment, the BP adjacent to fw-con is represented by (SI: BitString), where SI ≥ 6 and BitString is 5 bits. For example, BP 3′ has SI of 6 and the bit string is 00100 (uniformly represented by 3′(6:00100)). Assuming that SI of 6 corresponds to the first group of five BPs adjacent to fw-con, then BP 3′ corresponds to the third bit in the bit string that is set to 1 from the right. That is, when SI is 6, BP 1′ corresponds to the first bit set to 1, BP 2′ corresponds to the second bit set to 1, BP 3′ corresponds to the third bit set to 1, BP 4′ corresponds to the fourth bit set to 1, and BP 5′ corresponds to the fifth bit set to 1.

[0051] Assuming that SI of 7 corresponds to the second group of five BPs adjacent to fw-con immediately following the first group of five BPs, then BP 6′, 7′, 8′, 9′, and 10′ are uniformly represented by 6′ (7:00001), 7′ (7:00010), 8′ (7:00100), 9′ (7:01000), and 10′ (7:10000), respectively. That is, when SI is 7, BP 6′ corresponds to the first BP set to 1, BP 7′ corresponds to the second BP set to 1, BP 8′ corresponds to the third BP set to 1, BP 9′ corresponds to the fourth BP set to 1, and BP 10′ corresponds to the fifth BP set to 1.

[0052] Assuming that SI of 8 corresponds to the third group of five BPs adjacent to fw-con, immediately following the second group of five BPs, then BP 11′, 12′, 13′, 14′, and 15′ are uniformly represented by 11′ (8:00001), 12′ (8:00010), 13′ (8:00100), 14′ (8:01000), and 15′ (8:10000), respectively. That is, when SI is 8, BP 11′ corresponds to the first bit set to 1, BP 12′ corresponds to the second bit set to 1, BP 13′ corresponds to the third bit set to 1, BP 14′ corresponds to the fourth bit set to 1, and BP 15′ corresponds to the fifth bit set to 1.

[0053] Assuming that SI of 9 corresponds to the fourth group of five BPs adjacent to fw-con, immediately following the third group of five BPs, then BP 16′, 17′, 18′, 19′, and 20′ are uniformly represented by 16′ (9:00001), 17′ (9:00010), 18′ (9:00100), 19′ (9:01000), and 20′ (9:10000), respectively. That is, when SI is 9, BP 16′ corresponds to the first BP set to 1, BP 17′ corresponds to the second BP set to 1, BP 18′ corresponds to the third BP set to 1, BP 19′ corresponds to the fourth BP set to 1, and BP 20′ corresponds to the fifth BP set to 1.

[0054] Network nodes 104 through 118 each have one or more neighbor nodes. In this paper, a neighbor node refers to a network node that is only one hop away from a network node. For example, network node 106... Figure 1 The network has four neighboring nodes: network node 104, network node 108, network node 112, and network node 116. In fact, network nodes 104, 108, 112, and 116 are all only one hop away from network node 106.

[0055] Figure 1 Network nodes 104 to 118 are coupled and communicate with each other via link 120. Link 120 can be a wired link, a wireless link, or some combination thereof. In one embodiment, link 120 may incur costs. Depending on the BIER-TE network and its conditions, the costs of each link 120 may be the same or different.

[0056] Network node 110 can be referred to herein as the primary egress node (or simply egress node), and network node 118 can be referred to herein as the backup egress node of the primary egress node 110. As shown in the figure, network nodes 110 and 118 are respectively coupled to a first customer edge (CE) receiver 122 outside the BIER-TE domain 102. Therefore, the first CE 122 is used to receive packets from and send packets to network nodes 110 and 118. Network node 118 is coupled to a second CE receiver 124 outside the BIER-TE domain 102. Therefore, the second CE receiver 124 is used to receive packets from and send packets to network node 118.

[0057] Figure 2 This is a schematic diagram of the egress protection bit index forwarding table (EP-BIFT) 200 of a network node. Figure 1 In the BIER-TE topology 100, network nodes 104 to 118 generate EP-BIFT 200 respectively. In one embodiment, EP-BIFT is generated based on the bit index routing table (BIRT) or bit index forwarding table (BIFT) (not shown) constructed by network nodes 104 to 118.

[0058] Figure 2 The EP-BIFT 200 shown is built on Figure 1The EP-BIFT 200 is located above network node 108 in the BIER-TE topology 100. As shown, the EP-BIFT 200 includes six columns of information. The first column 202 includes the BP, SI, and bit string of each adjacency directly coupled to network node 108 in the BIER-TE topology 100. The adjacency in column 202 can be a forward-connected adjacency from network node 108 to a destination network node (e.g., network node 118, network node 114, and network node 110), or a forward-connected adjacency from network node 108 to a neighboring network node (e.g., network node 106). The second column 204 indicates the action to be performed by network node 108, which in the illustrated example is a forward-connected adjacency. The third column 206 identifies the neighboring node (BFR-NBR) of network node 108 used to reach the adjacent network node identified by the adjacency in the first column 202. This is why the neighboring node in the third column 206 can also be referred to as the next hop of network node 108. The first column 202, the second column 204, and the third column 206 in EP-BIFT 200 can be used by network node 108 during normal operation (i.e., when the primary egress node 110, which is a neighboring node of network node 108, is operating normally). That is, these columns are used when the entry in the backup entry active (BEA) field is set to 0.

[0059] Column 4, 218, includes the Backup Entry Active (BEA) field. The BEA field is set to indicate whether the primary egress node is active or has failed. For example, when the BEA field is set to a value of 0, the primary egress node (e.g., network node 110) is functioning normally. However, when the BEA field is set to a value of 1, the primary egress node is not functioning normally (i.e., has failed). Columns 4, 218, 5, 220, and 6, 222 in EP-BIFT 200 can be used by network node 108 in cases of abnormal operation (i.e., when the primary egress node 110 is not functioning normally or has failed). That is, these columns are used when the BEA field is set to 1.

[0060] Column 5, 220, includes the Same Receiver (SC) field. Entries in the SC field indicate whether the primary egress node (e.g., network node 110) and the backup egress node (e.g., network node 118) send the message payload to the same CE receiver (e.g., CE receiver 122) or to different CE receivers (e.g., CE receiver 122 and CE receiver 124). For example, when an entry in the SC field is set to 1, the primary egress node and the backup egress node send the message payload to the same CE receiver. When an entry in the SC field is set to 0, the primary egress node and the backup egress node send the message to different CE receivers.

[0061] Column 6, 222, includes the Backup Path field. When the primary egress node malfunctions or fails, the entries in the Backup Path field identify the backup path used to reach the primary egress node from the backup egress node. For example, the Backup Path field in row 208 of EP-BIFT 200 includes the expression C→H: {10′, 1}. This expression indicates that the backup path from network node 108 (also known as network node C) to backup egress network node 118 (also known as network node H) follows the forward join adjacency 10′ (i.e., the BP of the forward join adjacency from network node 108 to backup egress network node 110), and then follows the local unpacking adjacency 1 of the primary egress node 110.

[0062] The backup path field in row 210 of EP-BIFT 200 includes the expression C→E: {3′, 2′, 3}. This expression represents the backup path from network node 108 (also known as network node C) to backup egress network node 112 (also known as network node E) along forward connection adjacency 3′ (i.e., the forward connection adjacency BP from network node 108 to intermediate network node 106 (also known as network node B), along forward connection adjacency 2′ (i.e., the forward connection adjacency BP from network node 106 to backup egress node 112), and then along the local decapsulation adjacency 3 of backup egress node 112. Unlike row 208, the entry in the SC field of column 220 is set to 1 in row 210 to indicate that the primary egress node and the backup egress node send the payload of the message to the same CE receiver. Since the backup egress node 112 and the primary egress node 114 share the same CE receiver, the local decapsulation adjacency 3 of the backup egress node 112 is used in the backup path instead of the local decapsulation adjacency 2 of the primary egress node 114.

[0063] The backup path field in line 212 of EP-BIFT 200 includes the expression C→D: {18′, 4}. This expression indicates that the backup path from network node 108 (also known as network node C) to backup egress network node 110 (also known as network node D) follows the forward connection adjacency 18′ of the primary egress node 118 (also known as network node C) (i.e., the BP of the forward connection adjacency from network node 108 to backup egress network node 110), and then follows the local decapsulation adjacency 4 of the primary egress node 118.

[0064] The backup path field in line 4, 214 of EP-BIFT 200 does not list a backup path because network node 106 (also known as network node B) is not an egress node (i.e., BFER). In other words, the backup path field in line 4, 214 of EP-BIFT 200 may contain empty entries or no entries at all.

[0065] Figure 3 This is a schematic diagram of an EP-BIFT 300 backup egress node provided in one embodiment of the present invention. Figure 3 The EP-BIFT 300 shown is built on Figure 1 The EP-BIFT 300 is located above network node 118, which is a backup egress node for network node 110. As shown in the figure, the EP-BIFT 300 includes six columns of information. The first column 302 includes the BP for each adjacent node of network node 118 in the BIER-TE topology 100. The second column 304 indicates the action to be performed by network node 118, which in the illustrated example is forward connection adjacency, local decapsulation, or no operation (nop), depending on the row involved. No operation as used herein refers to a forwarding operation in which no BP is present in the received packet. The third column 306 identifies the BFR-NBR (also known as the next hop) of network node 118. The first column 302, the second column 304, and the third column 306 in the EP-BIFT 300 can be used by network node 118 during normal operation. That is, these columns are used when the entries in the BEA field are set to 0.

[0066] The BEA field in column 308, column 310, and the backup path field in column 312 of EP-BIFT 300 are similar to the BEA, SC, and backup path fields in EP-BIFT 200. Therefore, these fields will not be discussed in detail again. Columns 308, 310, and 312 of EP-BIFT 300 can be used by network node 118 in case of abnormal operation (i.e., when the primary egress node 110 is not operating properly or has failed). That is, these columns are used when the BEA field entry is set to 1.

[0067] When an entry in the BEA field of EP-BIFT 300 is set to 0 or an entry in the SC field of EP-BIFT 300 is set to 1, network node H uses entries in rows 314, 316, and 318 of columns 302, 304, and 306 to route packets. In fact, the entries in rows 314, 316, and 318 of columns 302, 304, and 306 are the same as those in a standard BIFT without egress protection used by network node H.

[0068] When network node 118 detects a failure in the primary egress node D (e.g., a destination node with BP, SI, and bit string 1 (0:00001)), network node 118 sets the value in the BEA field of row 4, 320 to 1 and routes the packet using entries in columns 308, 310, and 312 of row 4, 320 in EP-BIFT300, as well as BP1 of the primary egress node D. At this point, network node 118 sends the packet payload to the CE1 receiver with network node D as the destination.

[0069] It is worth noting that one or more network nodes described in this paper can use bidirectional forwarding detection (BFD) or similar methods to detect faults in neighboring network nodes. Another network node that is not directly coupled to or adjacent to a node can use multi-hop BFD or similar methods to detect faults in other network nodes.

[0070] Figure 4 An OSPF TLV structure 400 according to one embodiment of the present invention is illustrated. In one embodiment, the OSPF TLV structure 400 is generated by a primary egress node (e.g., network node 110) and sent to another network node (e.g., network node 108). The OSPF TLV structure 400 can be used to construct the EP-BIFT described herein.

[0071] As shown in the figure, the OSPF TLV structure 400 includes a type field 402, a length field 404, a reserved field 406, an S field 408, a BP field 410 for backup egress nodes, and an optional sub-TLV field 412. The type field 402 is two octets and is configured to include a value (also known as an entry) that has not yet been assigned by the Internet Assigned Numbers Authority (IANA). The length field 404 is two octets and is configured to include a value indicating the length of the TLV structure, which does not include the type and length fields. In one embodiment, the value is 4 when the sub-TLV field 412 does not include any sub-TLVs, and the value is 4 plus the length of the sub-TLV when the sub-TLV field 412 includes a sub-TLV.

[0072] Reserved field 406 is 15 bits. In one embodiment, when sending OSPF TLV structure 400, reserved field 406 is filled with all zeros, while when receiving OSPF TLV structure 400, reserved field 406 is ignored.

[0073] S field 408 is 1 bit (also known as a 1-bit flag). This flag is set to 1 to indicate that the primary egress node and the backup egress node send the message payload to the same CE receiver (e.g., CE receiver 122). This flag is set to 0 to indicate that the primary egress node and the backup egress node send the message payload to different CE receivers (e.g., CE receiver 122 and CE receiver 124).

[0074] The BP field 410 of the backup egress node consists of two octets. The value in the BP field 410 of the backup egress node is the BP of the backup egress node used to prevent failure of the primary egress node (i.e., the node that generates the OSPF TLV structure 400). In other words, the value in the BP field 410 of the backup egress node identifies the backup egress node.

[0075] Figure 5 This is an IS-IS TLV structure 500 provided in one embodiment of the present invention. In one embodiment, the IS-IS TLV structure 500 is generated by a primary egress node (e.g., network node 110) and sent to another network node (e.g., network node 108). The IS-IS TLV structure 500 can be used to construct the EP-BIFT described herein.

[0076] As shown in the figure, the IS-IS TLV structure 500 includes a type field 502, a length field 504, a reserved field 506, an S field 508, a BP field 510 for backup egress nodes, and an optional sub-TLV field 512. The type field 502 is an octet and is configured to include a value not yet assigned by IANA. The length field 504 is an octet and is configured to include a value indicating the length of the TLV structure, which does not include the type and length fields. In one embodiment, the value is 4 when the sub-TLV field 512 does not include any sub-TLVs, and the value is 4 plus the length of the sub-TLV when the sub-TLV field 512 includes a sub-TLV.

[0077] Reserved field 506 is 15 bits. In one embodiment, when the IS-IS TLV structure 500 is sent, reserved field 506 is filled with all zeros, while when the IS-IS TLV structure 500 is received, reserved field 506 is ignored.

[0078] S field 508 is 1 bit (also known as a 1-bit flag). This flag is set to 1 to indicate that the primary egress node and the backup egress node send the message payload to the same CE receiver (e.g., CE receiver 122). This flag is set to 0 to indicate that the primary egress node and the backup egress node send the message payload to different CE receivers (e.g., CE receiver 122 and CE receiver 124).

[0079] The BP field 510 of the backup egress node consists of two octets. The value in the BP field 510 of the backup egress node is the BP of the backup egress node used to prevent failure of the primary egress node (i.e., the node that generates the IS-IS TLV structure 500).

[0080] Remember the above information and return to the reference. Figure 1 This provides an example of how to route messages during normal operation and how to route messages in the event of a failure. During normal operation, when network node 104 receives a message, it adds or encapsulates a path into the message. For example, network node 104 adds the path {7′, 4′, 18′, 12′, 2, 1} to a received message. Then, network node 104 removes the adjacent 7′ from the message and sends the message to network node 106. Network node 106 receives the message, which now includes the path {4′, 18′, 12′, 2, 1}. Network node 106 removes the adjacent 4′ from the message and sends the message to network node 108.

[0081] Network node 108 receives the message, which at this time includes the path {18′, 12′, 2, 1}. Network node 108 generates a first copy of the message, removes adjacent nodes 18′ and 12′ from the first copy, and sends the first copy to network node 110. Network node 108 also generates a second copy of the message, removes adjacent nodes 18′ and 12′ from the second copy, and sends the second copy to network node 114.

[0082] Network node 110 receives a message including the path {2, 1}, decapsulates the message with BP=1 at the egress node 110, and sends the message payload to the multicast overlay layer, which then sends the payload to the first CE receiver 122. Network node 114 receives a message including the path {2, 1}, decapsulates the message with BP=2 at the egress node 114, and sends the message payload to the multicast overlay layer, which then sends the payload to another CE receiver (not shown) communicating with network node 114.

[0083] In the event of abnormal operation (e.g., a failure of network node 110), when network node 104 receives a message, network node 104 adds or encapsulates the path into the message. For example, network node 104 adds the path {7′, 4′, 18′, 12′, 2, 1} to the received message. Then, network node 104 removes the adjacent 7′ from the message and sends the message to network node 106. Network node 106 receives the message, which now includes the path {4′, 18′, 12′, 2, 1}. Network node 106 removes the adjacent 4′ from the message and sends the message to network node 108.

[0084] Network node 108 receives the message, which at this point includes the path {18′, 12′, 2, 1}. Since network node 108 has detected a failure in network node 110, network node 108 generates a first copy of the message and sets the value of BEA in the first row 208 of EP-BIFT 200 to 1. Then, network node 108 generates the first copy of the message using the backup path indicated in the sixth column 222 of the first row 208. That is, network node 108 removes adjacent nodes 18′ and 12′ from the first copy and adds the BP of the backup path to the first copy. Afterwards, network node 108 sends the first copy to network node 118.

[0085] However, if the value of SC in the fifth column 220 of the first row 208 of EP-BIFT 200 is set to 1, then the backup path in the sixth column 22 is C→H: {10′, 4} instead of C→H: {10′, 1}. In this case, network node 108 removes adjacent nodes 18′ and 12′ from the first replica and adds adjacent node 10′ to the first replica. Network node 108 also replaces BP 1 corresponding to network node 110 in the first replica with BP 4 corresponding to network node 118. After that, network node 108 sends the first replica to network node 118. Network node 108 also generates a second replica of the message, removes adjacent nodes 18′ and 12′ from the second replica, and sends the second replica to network node 114.

[0086] Network node 118 receives the message, which at this time includes the path {2, 4}. Network node 118 decapsulates the message with BP=4 of the backup egress node 118 using the third line 318 of EP-BIFT 300 and sends the message payload to the multicast overlay layer, which sends the payload to the first CE receiver 122. If network node 118, as the backup egress node, and network node 110, as the primary egress node, send their message payloads to different CE receivers, then when the primary egress node 110 fails, network node 108 sends a copy of the message including the path {2, 1} to network node 118. Network node 118 has detected the failure of the primary egress node 110 and sets the entry in the BEA field 308 of the fourth line 320 to 1 in its EP-BIFT 300. Network node 118 receives the message, which at this time includes the path {2, 1}. Network node 118 uses the fourth column 308, fifth column 310 and sixth column 312 in the fourth row 320 of EP-BIFT 300 to decapsulate the BP=1 message of the main egress node 110 and send the message payload to the first CE receiver 122 (i.e. CE1).

[0087] Figure 6 This is an embodiment of the present invention that provides an algorithm 600 that uses EP-BIFT to implement a portion of the forwarding process. The first part of the algorithm 600 is implemented at the point of local repair (PLR), while the second part of the algorithm 600 is implemented at the backup egress network node.

[0088] When BFR-NBR N is used as an exit code in a message, on the PLR ​​of BFR-NBR N, if BEA=1 (i.e., the primary exit has failed and should therefore be protected), the PLR ​​clears the BP of N's adjacent exit and the BP of BFER N. If the BP of N's backup exit B in the message is 0 or SC=0, the PLR ​​adds the BP of the backup path to the bit string of the message copy and sends the message copy to B along the backup path.

[0089] When the primary egress code is in the message, on the backup egress, if BEA=1 (i.e., the primary egress has failed and should therefore be protected), the backup egress sends the message payload to the CE receiver of the primary egress.

[0090] Figure 7 This is an embodiment of the present invention that provides an algorithm 700 for implementing a portion of the forwarding process using EP-BIFT. Specifically, algorithm 700 can be used to clear or add bits in the packet bit string as described above.

[0091] Upon receiving a message, for each BP k (starting from the right in the message bit string), if BP k is a locally decapsulated adjacency (i.e., the BP of the primary egress node) and the primary egress node has failed (BEA=1), then the backup egress node sends the message payload to the CE receiver of the primary egress node. Otherwise, the network node copies the message, sends a copy to the multicast stream overlay layer, and removes bit k from the message bit string.

[0092] If BP k is a forward-connected adjacency of the BFR (i.e., the network node), the network node uses BP k to look up the forwarding table entry in the EP-BIFT of the BIER-TE domain. If the primary egress node fails (BEA=1), the network node clears BP k and the BP in the BFR-NBR's bit string. If the backup egress's BP=0 or SC=0, the network node adds the BP of the backup path to the backup egress to the bit string. Otherwise, the network node replicates the message, updates the bit string by clearing all BPs adjacent to the BFR (i.e., the network node), and sends the updated copy to the BFR-NBR.

[0093] Figure 8This is a method 800 provided by an embodiment of the present invention, implemented by a network node (e.g., network node 108) in a BIER-TE domain. This method can be executed by the network node to provide protection for the egress node.

[0094] In step 802, the network node receives a type length value (TLV) structure, wherein the TLV structure includes the bit positions of the backup egress node of the primary egress node. In one embodiment, the TLV structure is received from either the primary egress node or a neighboring network node. In one embodiment, the TLV structure includes entries indicating whether the primary egress node and the backup egress node are sending messages to the same customer edge (CE) receiver or to different CE receivers.

[0095] In step 804, when a network node is adjacent to the primary egress node, the network node generates an egress protection bit index forwarding table (EP-BIFT), which includes a backup path to the backup egress node. The backup egress node is identified based on its bit position. In one embodiment, the EP-BIFT includes entries indicating whether the primary egress node and the backup egress node are sending packets to the same customer edge (CE) receiver or to different CE receivers, and these entries are set in the same CE receiver (SC) field of the EP-BIFT. In one embodiment, the EP-BIFT includes a backupentry active (BEA) field, where entries are set to indicate whether the primary egress node is active or has failed.

[0096] In one embodiment, the backup egress node is identified in the backup path field of the EP-BIFT. In one embodiment, generating the EP-BIFT includes generating a backup path in the backup path field, wherein, when the primary egress node and the backup egress node send messages to the same customer edge (CE) receiver, the backup path includes the bit positions of the forward connection adjacencies of intermediate nodes along the path to the backup egress node and the bit positions of the backup egress node corresponding to the primary egress node (i.e., the local decap adjacency of the backup egress node). In one embodiment, generating the EP-BIFT includes generating a backup path in the backup path field, wherein, when the primary egress node and the backup egress node send messages to different customer edge (CE) receivers, the backup path includes the bit positions of the forward connection adjacencies of intermediate nodes along the path to the backup egress node and the bit positions of the primary egress node (i.e., the local decap adjacency of the primary egress node).

[0097] In step 806, when the primary egress node fails, the network node forwards packets along the backup path.

[0098] Figure 9 This is a schematic diagram of a network device 900 (e.g., a network node, a destination node, a neighbor node, etc.). The network device 900 is suitable for implementing the disclosed embodiments described herein. The network device 900 includes an ingress port / ingress component 910 and a receiver unit (Rx) / receiver block 920 for receiving data; a processor, logic unit, or central processing unit (CPU) / processing component 930 for processing data; a transmit unit (Tx) / transmitter component 940 and an egress port / egress component 950 for transmitting data; and a memory / storage component 960 for storing data. The network device 900 may also include optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress port / ingress component 910, the receiver unit / receiver component 920, the transmit unit / transmitter component 940, and the egress port / egress component 950 for the entry or exit of optical or electrical signals.

[0099] Processor / processing component 930 is implemented in hardware and software. Processor / processing component 930 can be implemented as one or more CPU chips, one or more cores (e.g., 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 component 930 communicates with ingress port / ingress component 910, receiver unit / receiver unit 920, transmitter unit / transmitter unit 940, egress port / egress component 950, and memory / storage component 960. Processor / processing component 930 includes a BIER-TE fast egress protection module 970. BIER-TE fast egress protection module 970 is capable of implementing the methods disclosed herein. Therefore, including BIER-TE fast egress protection module 970 provides a substantial improvement to the functionality of network device 900 and enables the transition of network device 900 to different states. Alternatively, the BIER-TE fast exit protection module 970 is implemented with instructions stored in memory / storage component 960 and executed by processor / processing component 930.

[0100] The network device 900 may also include input and / or output (I / O) devices or I / O components 980 for data communication with a user. The I / O devices or I / O components 980 may include output devices, such as a display for showing video data, a speaker for outputting audio data, etc. The I / O devices or I / O components 980 may also include input devices, such as a keyboard, mouse, trackball, etc., and / or corresponding interfaces for interacting with these output devices.

[0101] Memory / storage component 960 includes one or more disks, one or more tape drives, and one or more solid-state drives, and can be used as an overflow data storage device to store such programs when a program is selected for execution, as well as instructions and data read during program execution. Memory / storage component 960 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).

[0102] 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.

[0103] 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, The method includes: Receive a type length value (TLV) structure, wherein the TLV structure includes the bit positions of the backup egress node of the primary egress node; When the network node is adjacent to the primary egress node, an egress protection bit index forwarding table (EP-BIFT) is generated based on the bit position of the backup egress node, wherein the EP-BIFT includes a backup path to the backup egress node; When the primary egress node fails, packets are forwarded along the backup path.

2. The method according to claim 1, characterized in that, The TLV structure is received from the main egress node or a neighboring network node.

3. The method according to claim 1 or 2, characterized in that, The TLV structure includes entries indicating whether the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver or to different CE receivers.

4. The method according to any one of claims 1 to 3, characterized in that, The EP-BIFT includes an entry indicating whether the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver or to different CE receivers, the entry being set in the same CE receiver (SC) field of the EP-BIFT.

5. The method according to any one of claims 1 to 4, characterized in that, The EP-BIFT includes a backup entry active (BEA) field, where entries in the BEA field are set to indicate whether the primary egress node is active or has failed.

6. The method according to any one of claims 1 to 5, characterized in that, The backup exit node is identified in the backup path field of the EP-BIFT.

7. The method according to any one of claims 1 to 6, characterized in that, The generation of EP-BIFT includes: generating the backup path in the backup path field, wherein, when the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver, the backup path includes the bit position of the forward connection adjacency of the intermediate node on the backup path leading to the backup egress node and the bit position of the backup egress node of the primary egress node.

8. The method according to any one of claims 1 to 6, characterized in that, The generation of EP-BIFT includes: generating the backup path in the backup path field, wherein when the primary egress node and the backup egress node send the message to different customer edge (CE) receivers, the backup path includes the bit position of the forward connection adjacency of intermediate nodes on the backup path leading to the backup egress node and the bit position of the primary egress node.

9. A network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, characterized in that, The network nodes 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 to cause the network node to perform the following operations: Receive a type length value (TLV) structure, wherein the TLV structure includes the bit positions of the backup egress node of the primary egress node; When the network node is adjacent to the primary egress node, an egress protection bit index forwarding table (EP-BIFT) is generated based on the bit position of the backup egress node, wherein the EP-BIFT includes a backup path to the backup egress node; When the primary egress node fails, packets are forwarded along the backup path.

10. The network node according to claim 9, characterized in that, The TLV structure is received from the main egress node or a neighboring network node.

11. The network node according to claim 9 or 10, characterized in that, The TLV structure includes entries indicating whether the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver or to different CE receivers.

12. The network node according to any one of claims 9 to 11, characterized in that, The EP-BIFT includes an entry indicating whether the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver or to different CE receivers, the entry being set in the same CE receiver (SC) field of the EP-BIFT.

13. The network node according to any one of claims 9 to 12, characterized in that, The EP-BIFT includes a backup entry active (BEA) field, where entries in the BEA field are set to indicate whether the primary egress node is active or has failed.

14. The network node according to any one of claims 9 to 13, characterized in that, The backup exit node is identified in the backup path field of the EP-BIFT.

15. The network node according to any one of claims 9 to 14, characterized in that, The generation of EP-BIFT includes: generating the backup path in the backup path field, wherein, when the primary egress node and the backup egress node send the message to the same customer edge (CE) receiver, the backup path includes the bit position of the forward connection adjacency of the intermediate node on the backup path leading to the backup egress node and the bit position of the backup egress node of the primary egress node.

16. The network node according to any one of claims 9 to 14, characterized in that, The generation of EP-BIFT includes: generating the backup path in the backup path field, wherein when the primary egress node and the backup egress node send the message to different customer edge (CE) receivers, the backup path includes the bit position of the forward connection adjacency of intermediate nodes on the backup path leading to the backup egress node and the bit position of the primary egress node.

17. A method implemented by network nodes in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, characterized in that, The method includes: Generate a type length value (TLV) structure, wherein the TLV structure includes the bit positions of the backup egress nodes of the primary egress node; The TLV structure is sent to the neighboring network nodes of the main egress node.

18. The method according to claim 17, characterized in that, The TLV structure is an Open Shortest Path First (OSPF) backup egress TLV.

19. The method according to claim 17 or 18, characterized in that, The TLV structure is an intermediate system-to-intermediate system (IS-IS) backup exit TLV.

20. The method according to any one of claims 17 to 19, characterized in that, The TLV structure includes entries indicating whether the primary egress node and the backup egress node send messages to the same customer edge (CE) or to different customer edges (CEs).

21. A network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, characterized in that, The network nodes include: A receiving component is used to receive a type length value (TLV) structure, wherein the TLV structure includes the bit positions of the backup egress node of the primary egress node; The component is generated for: when the network node is adjacent to the primary egress node, generating an egress protection bit index forwarding table (EP-BIFT) based on the bit position of the backup egress node, wherein the EP-BIFT includes a backup path to the backup egress node; Forwarding component: Used to forward packets along the backup path when the primary egress node fails.

22. A network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, characterized in that, The network nodes include: Generate a component for generating a type length value (TLV) structure, wherein the TLV structure includes the bit positions of the backup exit nodes of the primary exit node; A sending component is used to send the TLV structure to the neighboring network nodes of the main egress node.

Images