The present disclosure is generally related to the field of traffic engineering and, in particular, to Interior Gateway Protocol (IGP) extensions for Bit Index Explicit Replication-Traffic Engineering (BIER-TE).
BIER mechanisms provide optimized forwarding of multicast data packets through a BIER domain. BIER domains may not require the use of a protocol for explicitly building multicast distribution trees. Further, BIER domains may not require intermediate nodes to maintain any per-flow state. BIER is described in further detail in Internet Engineering Task Force (IETF) document Request for Comments (RFC) 8279 entitled “Multicast Using Bit Index Explicit Replication (BIER)” by U. Wijnands, et al., published November 2017.
Traffic Engineering (TE) is the process of steering traffic across to a telecommunications network to facilitate efficient use of available bandwidth between a pair of routers. Bit Index Explicit Replication (BIER) Traffic/Tree Engineering (BIER-TE) is described in IETF document “Tree Engineering for Bit Index Explicit Replication (BIER-TE)” by T. Eckert, et al., published Jul. 9, 2021.
The disclosed aspects/embodiments provide IGP extensions for BIER-TE. The IGP extensions are utilized to distribute bit positions for forward connected adjacencies configured on the links in a BIER-TE domain. Therefore, packet routing within the BIER-TE domain is improved.
A first aspect relates to a method implemented by a network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, comprising: encoding a bit position configured on a link in a bit position field of a BIER-TE sub-type length value (sub-TLV); and distributing the BIER-TE sub-TLV in the BIER-TE domain.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the bit position is encoded in the bit position field of the BIER-TE sub-TLV when a link type of a link in an open shortest path first version 2 (OSPFv2) TLV or in an open shortest path first version 3 (OSPFv3) TLV has a first value or a second value.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first value indicates a point-to-point connection to another network node, and the second value indicates a connection to a transit network.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV is distributed to neighbor network nodes immediately adjacent to the network node.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV is an open shortest path first version 2 (OSPFv2) BIER-TE sub-TLV.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the OSPFv2 BIER-TE sub-TLV is distributed within an OSPFv2 extended link TLV of an OSPFv2 extended link opaque link state advertisement (LSA).
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV is an open shortest path first version 3 (OSPFv3) BIER-TE sub-TLV.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the OSPFv3 BIER-TE sub-TLV is distributed within an OSPFv3 router link TLV of an OSPFv3 extended router link state advertisement (LSA).
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV is an intermediate system-intermediate system (IS-IS) BIER-TE sub-TLV.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the IS-IS BIER-TE sub-TLV is distributed within an extended intermediate system (IS) reachability TLV of a multi-topology (MT) intermediate systems TLV.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV further comprises a designated router (DR) end bit position field configured to include a bit position of a connection on a DR end.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV further comprises one or more of a type field indicating that the BIER-TE sub-TLV is a BIER-TE sub-TLV, a length field indicating a length of the BIER-TE sub-TLV field, a sub-domain identifier field identifying the BIER-TE domain, a multi-topology identifier field identifying a topology associated with the BIER-TE domain, a BIER algorithm (BAR) field identifying the BIER algorithm used to calculate underlay paths, or an Interior Gateway Protocol (IGP) algorithm field identifying the IGP algorithm used to modify, enhance, or replace a calculation of underlay paths to reach other network nodes as defined by a BAR value.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the bit position field contains only a single bit position.
A second aspect relates to 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 to cause the network node to: encode a bit position configured on a link in a bit position field of a BIER-TE sub-type length value (sub-TLV); and distribute the BIER-TE sub-TLV in the BIER-TE domain.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the bit position is encoded in the bit position field of the BIER-TE sub-TLV when a link type of a link in an open shortest path first version 2 (OSPFv2) TLV or in an open shortest path first version 3 (OSPFv3) TLV has a first value or a second value.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first value indicates a point-to-point connection to another network node, and the second value indicates a connection to a transit network.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV is distributed to neighbor network nodes immediately adjacent to the network node.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV is an open shortest path first version 2 (OSPFv2) BIER-TE sub-TLV.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the OSPFv2 BIER-TE sub-TLV is distributed within an OSPFv2 extended link TLV of an OSPFv2 extended link opaque link state advertisement (LSA).
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV is an open shortest path first version 3 (OSPFv3) BIER-TE sub-TLV.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the OSPFv3 BIER-TE sub-TLV is distributed within an OSPFv3 router link TLV of an OSPFv3 extended router link state advertisement (LSA).
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV is an intermediate system-intermediate system (IS-IS) BIER-TE sub-TLV.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the IS-IS BIER-TE sub-TLV is distributed within an extended intermediate system-intermediate system (IS-IS) (IS) reachability TLV of a multi-topology (MT) intermediate systems TLV.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV further comprises a designated router (DR) end bit position field configured to include a bit position of a connection on a DR end.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the BIER-TE sub-TLV further comprises one or more of a type field indicating that the BIER-TE sub-TLV is a BIER-TE sub-TLV, a length field indicating a length of the BIER-TE sub-TLV field, a sub-domain identifier field identifying the BIER-TE domain, a multi-topology identifier field identifying a topology associated with the BIER-TE domain, a BIER algorithm (BAR) field identifying the BIER algorithm used to calculate underlay paths, or an Interior Gateway Protocol (IGP) algorithm field identifying the IGP algorithm used to modify, enhance, or replace a calculation of underlay paths to reach other network nodes as defined by a BAR value.
Optionally, in any of the preceding aspects, another implementation of the aspect provides that the bit position field contains only a single bit position.
A third aspect relates to network node in a Bit Index Explicit Replication Traffic Engineering (BIER-TE) domain, comprising: means for encoding a bit position in a bit position field of a BIER-TE sub-type length value (sub-TLV); and means for distributing the BIER-TE sub-TLV in the BIER-TE domain.
A fourth aspect relates to a non-transitory computer readable medium comprising a computer program product for use by a network node, the computer program product comprising computer executable instructions stored on the non-transitory computer readable medium that, when executed by one or more processors, cause the network node to: encode a bit position in a bit position field of a Bit Index Explicit Replication Traffic Engineering (BIER-TE) sub-type length value (sub-TLV); and distribute the BIER-TE sub-TLV in a BIER-TE domain.
For the purpose of clarity, any one of the foregoing embodiments may be combined with any one or more of the other foregoing embodiments to create a new embodiment within the scope of the present disclosure.
These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.
For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.
It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
The bit forwarding router identifier (BFR-id) of each bit forwarding egress router (BIHER) is distributed in the BIER-TE domain (a.k.a., BIER-TE network). However, there are no interior gateway protocol (IGP) (e.g., OSPFv2, OSPFv3, or Intermediate System-Intermediate System (IS-IS)) extensions that can be used to distribute Bit Positions (a.k.a., bit positions) configured on the links in the BIER-TE domain.
Disclosed herein are techniques allowing IGP to distribute Bit Positions configured on the links in a Bit Index Explicit Replication (BIER) Traffic/Tree Engineering (BIER-TE) domain. In order to facilitate the techniques, the present disclosure provides a BIER-TE sub-TLV that extends OSPFv2, OSPFv3, and IS-IS. Using the extensions, packet routing within the BIER-TE domain is improved relative to existing techniques.
For ease of discussion, all of the network nodes 104-119 have been given a letter designation. For example, the network node 104 has the designation A, the network node 106 has the designation B, the network node 108 has the designation C, the network node 110 has the designation D, the network node 112 has the designation E, the network node 114 has the designation F, the network node 116 has the designation G, the network node 118 has the designation H, and the network node 119 has the designation I.
Each of the network nodes 104-119 is a bit forwarding router (BFR). Some of the network nodes, namely the network nodes 104, 110, 112, 114 and 118, are disposed at an edge of the BIER-TE domain 102. The network nodes 104, 110, 112, 114 and 118 receiving multicast packets from outside the BIER-TE domain 102 may be referred to as an ingress BFR (BFIR). The network nodes 104, 110, 112, 114 and 118 transmitting multicast packets out of the BIER-TE domain 102 may be referred to as an egress BFR (BFER). Depending on the direction of multicast packet traffic, each of the network nodes 104-118 may function as a BFIR or a BFER.
As shown in
As an example of how the BPs for fw-con adjacencies operate with regard to
Each of the network nodes 104, 110, 112, 114, and 118 may be referred to herein as a destination network node or egress BFR (BFER). The network nodes 104, 110, 112, 114 and 118 have each been assigned a BP, a set index (SI), and a BitString. The BP of a BFER is called a local decapsulation (decap) adjacency, a local decap BP, or the BFR-id. In the illustrated example, the BP of a BFER is represented as j, where j is an integer corresponding to one of the local decap adjacencies in the BIER-TE domain 102. In the illustrated embodiment of
In an embodiment, the BPs for fw-con adjacencies are represented by (SI:BitString), where SI>=6 and BitString is of 8 bits. For example, the BP of 2′ has a SI of 6, and has a BitString of 00000010 (collectively represented by 2′ (6:00000010)). The BP of 4′ has a SI of 6, and has a BitString of 00001000 (collectively represented by 4′ (6:00001000)). The BP of 6′ has a SI of 6, and has a BitString of 00100000 (collectively represented by 6′ (6:00100000)). The BP of 8′ has a SI of 6, and has a BitString of 10000000 (collectively represented by 8′ (6:10000000)). In this way, the BP is represented by a number that indicates which bit is set in the BitString.
Each of the network nodes 104-119 has one or more neighbor nodes. As used herein, a neighbor node refers to a network node that is only one hop away from the network node. For example, network node 106 has four neighbor nodes in
The network nodes 104-119 in
Unlike the BIER-TE topology 100 of
Each link 220 connecting the pseudo node 235 to one of the neighbor network nodes is assigned two BPs. One BP is for LAN-connected adjacency (a.k.a., the LAN adjacency) from the neighbor network node to the pseudo node 235, and the other BP is for the forward connected adjacency from the pseudo node 235 to neighbor network node. For example, the forward connected adjacency from the pseudo node 235 to network node 208 is assigned BP 13′, and the LAN-connected adjacency from network node 208 to the pseudo node 235 is assigned BP 14′. In addition, the forward connected adjacency from pseudo node 235 to network node 216 is assigned BP 15′, and the LAN-connected adjacency from network node 216 to pseudo node 235 is assigned BP 16′. Likewise, the forward connected adjacency from pseudo node 235 to network node 218 is assigned BP 17′, and the LAN-connected adjacency from network node 218 to pseudo node 235 is assigned BP 18′. Finally, the forward connected adjacency from pseudo node 235 to network node 210 is assigned BP 19′, and the LAN-connected adjacency from network node 210 to pseudo node 235 is assigned BP 20′.
The FRR-BIFT 300 depicted in
A second column 304 identifies a neighbor node (BFR-NBR) of the network node 106, 206. During normal operations, the neighbor node may be reached using the adjacency identified in the first column 302, which is why the neighbor node in the second column 304 may also be referred to as the next hop of the network node 106. In the illustrated embodiment, the neighbor node in the second column is designated by the letter C, which corresponds to the network node 108, 208.
The third column 306 includes a backup path field. An entry in the backup path field identifies a backup path used to reach each next hop of a neighbor node of the network node when the neighbor node is operating abnormally or has failed. As shown in
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 forward connected adjacency 6′ (i.e., the BP of the forward connected adjacency from network node 106 to the network node 116), then 20′ (i.e., the BP of the forward connected adjacency from network node 116 to the network node 118), and then 27′ (i.e., the BP of the forward connected adjacency from network node 118 to the network node 110). The third backup path includes the expression B→I: {6′, 17′}. This expression indicates that the backup path from network node 106 to network node 119 is along forward connected adjacency 6′ (i.e., the BP of the forward connected adjacency from network node 106 to the network node 116) and then 17′ (i.e., the BP of the forward connected adjacency from network node 116 to the network node 119).
Keeping the above in mind and referring back to
The network node 116 receives the packet, which now contains the path {20′, 4′, 12′, 4, 1}. The network node 116 removes its adjacency 20′ from the packet and transmits the packet to network node 118 using adjacency 20′ (i.e., the forwarding entry for the forward connected adjacency 20′ in the FRR-BIFT built on the network node 116). The network node 118 receives the packet, which now contains the path {4′, 12′, 4, 1}. The network node 118 decapsulates the packet with BP=4 for BFER H (i.e., egress node118) and transmits the payload of the packet to the multicast overlay.
The network node 106 receives the packet, which contains the path {20′, 4′, 12′, 4, 1}. The network node 106 removes its adjacency 4′ from the packet and transmits the packet to network node 108 using adjacency 4′ (i.e., the forwarding entry for the forward connected adjacency 4′ in the FRR-BIFT built on the network node 106). The network node 108 receives the packet, which contains the path {20′, 12′, 4, 1}. The network node 108 removes its adjacency 12′ from the packet and transmits the packet to network node 110 using adjacency 12′ (i.e., the forwarding entry for the forward connected adjacency 12′ in the FRR-BIFT built on the network node 108). The network node 110 receives the packet, which now contains the path {20′, 4, 1}. The network node 118 decapsulates the packet with BP=1 for BFER D (i.e., egress node 110) and transmits the payload of the packet to the multicast overlay.
During abnormal operations (e.g., network node 108 has failed), when a packet is received at network node 104, the network node 104 adds or encapsulates a point to multipoint (P2MP) path into the packet. For example, the network node 104 adds the path from node A to nodes D and H {26′, 20′, 7′, 4′, 12′, 4, 1} into the received packet. Thereafter, the network node 104 removes its adjacencies 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 26′. The network node 104 also makes a second copy of the packet, and sends the second copy to network node 106 using adjacency 7′.
The network node 116 receives the packet, which now contains the path {20′, 4′, 12′, 4, 1}. The network node 116 removes its adjacency 20′ from the packet and transmits the packet to network node 118 using adjacency 20′. The network node 118 receives the packet, which now contains the path {4′, 12′, 4, 1}. The network node 118 decapsulates the packet with BP=4 and transmits the payload of the packet to the multicast overlay.
The network node 106 receives the packet, which contains the path {20′, 4′, 12′, 4, 1}. The network node 106 removes its adjacency 4′ from the packet. Since network node 108, which is a neighbor node of the network node 106, has failed, the network node 106 removes BP 12′ for the forward connected adjacency from the failed node 108 to the network node 110 that is a next hop of the failed node 108 and is on the path in the packet, removes the BP 4 (i.e., the local decap adjacency of BFER H) from the path of the packet that is on the backup path because BFER H is not on a path branch of the path in the packet from network node 106, and adds the BPs for the backup path from network node 106 to network node 110. The added BPs are {6′, 27′}. Thus, the packet now contains the path {6′, 20′, 27′, 1}. Thereafter, network node 106 removes its adjacency 6′ from the packet and transmits the packet to network node 116 using adjacency 6′.
The network node 116 receives the packet, which contains the path {20′, 27′, 1}. The network node 116 removes its adjacency 20′ from the packet and transmits the packet to network node 118 using adjacency 20′. The network node 118 receives the packet, which now contains the path {27′, 1}. The network node 118 removes its adjacency 27′ from the packet and transmits the packet to network node 110 using adjacency 27′. The network node 110 receives the packet, which now contains the path 111. The network node 110 decapsulates the packet with BP=1 for BFER D (i.e., egress node 110) and transmits the payload of the packet to the multicast overlay.
The packet routing in the BIER-TE domain 202 of
While the BIER-TE domain 102, 202 are suitable for packet routing, there are no IGP extensions that can be used to distribute Bit Positions configured on the links in the BIER-TE domains 102, 202. Therefore, the present disclosure provides a BIER-TE sub-TLV that extends OSPFv2, OSPFv3, and IS-IS. Examples of the BIER-TE sub-TLV are provided below.
The type field 602 is 16 bits and includes a value that indicates the type of sub-TLV. In an embodiment, the value is to be assigned by the Internet Assigned Numbers Authority (LANA) and is to be determined (TBD). The length field 604 is 16 bits and includes a value that indicates a length of the sub-TLV, exclusive of the type field 602 and the length field 604.
The sub-domain ID field 606 is 8 bits and includes a value that identifies a BIER-TE sub-domain (e.g., the BIER-TE domain 102). The MT-ID field 608 is 8 bits and includes a value that identifies the topology (e.g., OSPFv2, OSPFv3, IS-IS) associated with the sub-domain. The BAR field 610 includes a value that identifies the BIER algorithm used to calculate underlay paths to other BFRs. The IPA field 612 includes a value that identifies the IGP algorithm used to modify, enhance, or replace the calculation of underlay paths to reach other BFRs as defined by the value in the BAR field 610.
The BitPosition field 614 includes a value that identifies the bit position (a.k.a., BitPosition) locally configured on a point-to-point (P2P) link (e.g., link 120) or on a broadcast link (e.g., link 222). That is, the BitPosition field 614 is configured to carry a bit position such as, for example, bit position 4′. In an embodiment, the BitPosition field 614 contains only a single bit position. When a network node advertises a bit position on a link attached to the network node, the OSPFv2 BIER-TE sub-TLV 600 may be utilized. By sending the OSPFv2 BIER-TE sub-TLV 600 to a neighbor node sending the sub-TLV to its neighbor nodes, a network node is able to report the bit position configured on the link (a.k.a., the BP for forward connected adjacency) as well as the information in the other fields to the neighbor node and other network nodes.
The sub-TLVs field 818 is configured to include the OSPFv2 BIER-TE sub-TLV 600 as shown in
The type field 1102 is 8 bits and includes a value that indicates the type of sub-TLV. In an embodiment, the value is to be assigned by the LANA and is to be determined (TBD). The length field 1104 is 8 bits and includes a value that indicates a length of the sub-TLV, exclusive of the type field 1102 and the length field 1104.
The sub-domain ID field 1106 is 8 bits and includes a value that identifies a BIER-TE sub-domain (e.g., the BIER-TE domain 102). The BAR field 1108 includes a value that identifies the BIER algorithm used to calculate underlay paths to other BFRs. The IPA field 1110 includes a value that identifies the IGP algorithm used to modify, enhance, or replace the calculation of underlay paths to reach other BFRs as defined by the value in the BAR field 1108.
The BitPosition field 1112 includes a value that identifies the bit position (a.k.a., BitPosition) locally configured on a P2P link (e.g., link 120) or on a broadcast link (e.g., link 222). That is, the BitPosition field 1112 is configured to carry a bit position such as, for example, bit position 4′. In an embodiment, the BitPosition field 1112 contains only a single bit position. When a network node advertises a bit position on a link attached to the network node, the IS-IS BIER-TE sub-TLV 1100 may be utilized. By sending the IS-IS BIER-TE sub-TLV 1100 to a neighbor node, a network node is able to report the bit position configured on the link (a.k.a., the BP for forward connected adjacency) as well as the information in the other fields to the neighbor node.
In block 1202, the network node encodes a bit position configured on a link in a bit position field of a BIER-TE sub-TLV. In an embodiment, the bit position is a bit position of (a.k.a., locally configured on) a link/interface of the network node. For example, the network node 104 is configured to encode the bit position 26′ in the bit position field of the BIER-TE sub-TLV to represent that the network node 104 is able to reach the network node 116 (which is immediately adjacent to the network node 114) using the link 120 that starts at the network node 104 and ends at the network node 116.
In an embodiment, the bit position is encoded in the bit position field of the BIER-TE sub-TLV when a link type of a link in an OSPFv2 TLV or in an OSPFv3 TLV has a first value (e.g., 1) or a second value (e.g., 2). In an embodiment, the first value indicates a point-to-point connection to another network node. In an embodiment, the second value indicates a connection to a transit network.
In an embodiment, the BIER-TE sub-TLV is an OSPFv2 BIER-TE sub-TLV (e.g., the OSPFv2 BIER-TE sub-TLV 600). In an embodiment, the BIER-TE sub-TLV is an OSPFv3 BIER-TE sub-TLV (which is similar or identical to the OSPF v2 BIER-TE sub-TLV 600). In an embodiment, the BIER-TE sub-TLV is an IS-IS BIER-TE sub-TLV (e.g., the IS-IS BIER-TE sub-TLV 1100).
In an embodiment, the BIER-TE sub-TLV further comprises a DR end bit position field configured to include a bit position of a connection on a DR end. The DR end bit position field may be the DrEndBitPosition field 616. In an embodiment, the DR end is a connection to a pseudo node. The DrEndBitPosition field 616 may include a bit position of the connection from a network node to the pseudo node representing a broadcast link or a LAN.
In an embodiment, the BIER-TE sub-TLV further comprises one or more of a type field indicating that the BIER-TE sub-TLV is a BIER-TE sub-TLV, a length field indicating a length of the BIER-TE sub-TLV field, a sub-domain identifier field identifying the BIER-TE domain, a multi-topology identifier field identifying a topology associated with the BIER-TE domain, a BIER algorithm (BAR) field identifying the BIER algorithm used to calculate underlay paths, or an Interior Gateway Protocol (IGP) algorithm field used to modify, enhance, or replace a calculation of underlay paths to reach other network nodes as defined by a BAR value.
In an embodiment, the bit position field contains only a single bit position. In such cases, the network node distributes a separate BIER-TE sub-TLV with one bit position to each neighbor node.
In block 1204, the network node distributes (e.g., transmits, sends, forwards) the BIER-TE sub-TLV in the BIER-TE domain. In an embodiment, the OSPFv2 BIER-TE sub-TLV is distributed within an OSPFv2 extended link TLV (e.g., the OSPFv2 extended link TLV 500) of an OSPFv2 extended link opaque LSA (e.g., the OSPFv2 extended link opaque LSA 400). In an embodiment, the OSPFv3 BIER-TE sub-TLV is distributed within an OSPFv3 router link TLV (e.g., OSPFv3 router link TLV 800) of an OSPFv3 extended router LSA (e.g., OSPFv3 extended router LSA 700). In an embodiment, the IS-IS BIER-TE sub-TLV is distributed within an extended IS reachability TLV (e.g., extended IS reachability TLV 1000) of a MT intermediate systems TLV (e.g., MT intermediate systems TLV 900). In an embodiment, the BIER-TE sub-TLV is distributed to neighbor network nodes immediately adjacent to the network node. For example, the network node 104 distributes the BIER-TE sub-TLV to the network nodes 116, 106 since the network nodes 116, 106 are immediately adjacent to the network node 104. In an embodiment, immediately adjacent means that one network node is directly connected to another network node. That is, there are no network nodes disposed between two immediately adjacent network nodes.
The processor/processing means 1330 is implemented by hardware and software. The processor/processing means 1330 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor/processing means 1330 is in communication with the ingress ports/ingress means 1310, receiver units/receiving means 1320, transmitter units/transmitting means 1340, egress ports/egress means 1350, and memory/memory means 1360. The processor/processing means 1330 comprises a BIER-TE IGP module 1370. The BIER-TE IGP module 1370 is able to implement the methods disclosed herein. The inclusion of the BIER-TE IGP module 1370 therefore provides a substantial improvement to the functionality of the network apparatus 1300 and effects a transformation of the network apparatus 1300 to a different state. Alternatively, the BIER-TE IGP module 1370 is implemented as instructions stored in the memory/memory means 1360 and executed by the processor/processing means 1330.
The network apparatus 1300 may also include input and/or output (I/O) devices or I/O means 1380 for communicating data to and from a user. The I/O devices or I/O means 1380 may include output devices such as a display for displaying video data, speakers for outputting audio data, etc. The I/O devices or I/O means 1380 may also include input devices, such as a keyboard, mouse, trackball, etc., and/or corresponding interfaces for interacting with such output devices.
The memory/memory means 1360 comprises one or more disks, tape drives, and solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory/memory means 1360 may be volatile and/or non-volatile and may be read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and/or static random-access memory (SRAM).
While several embodiments have been provided in the present disclosure, it may be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.
In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, components, techniques, or methods without departing from the scope of the present disclosure. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and may be made without departing from the spirit and scope disclosed herein.
This patent application is a continuation of International Application No. PCT/US2022/015805 filed on Feb. 9, 2022, which claims the benefit of U.S. Provisional Patent Application No. 63/148,974 filed Feb. 12, 2021, each of which is hereby incorporated by reference.
Number | Date | Country | |
---|---|---|---|
63148974 | Feb 2021 | US |
Number | Date | Country | |
---|---|---|---|
Parent | PCT/US2022/015805 | Feb 2022 | US |
Child | 18448757 | US |